If we stick to the above approach, “don’t show track in group” would be equivalent to collapsing the track. Then it is still playing, but not displayed on the controller.
The thing is, the illustration is showing groups that are collapsed, not tracks. If just one track (say, 1b) was collapsed, we would not enter the special collapsed mode.
So, if I understand you right, this is something which fit into the concept with no need for additional features.
I’ve spent some time writing specs, to try and get a good idea about which features that would be the most all-round useful.
This is not a final set of specs in any way, but it should give everyone a better idea about the actual implementation details (something to discuss)
–
Mapping: Pattern triggers
Same as pressing & holding a single slot (the mapping exist to accommodate devices with no support for release & hold events) - Align with grid (control-map group would need same height)
Feature: Edit-sync
Edit-synchronization means that any change to a GRID PIE pattern-track (such as manually transposing, deleting or editing notes) are automatically broadcast to the source pattern-track - Edit-sync works both ways: changes to the source pattern-track are also broadcast to the GRID PIE pattern-track - To begin with, edit-sync will affect notes only, and not include automation data - When an expanded recombination track (such as 16 lines expanded to 96 lines) is modified, the change is broadcast to each (16-line) segment within the (96 line) track. - This feature might be a CPU intensive task and could perhaps benefit from being implemented as a co-routine
Feature: Session-recording
Tied to “Loop pattern” in Renoise (disable pattern loop to enter the session recording mode) - Session recording is a “true” live performance mode, in the sense that you can concentrate on jamming while the song sequence is automatically being expanded (new patterns created on-the-fly), inspired by how the AutoClonePattern tool works - Just like now, we only need one recombination pattern and the maximum length of a Renoise pattern (512 lines) still applies. So no magic silver bullet in that regard. - Session recording will be complemented by the “schedule mode”, which allow a configurable delay before changes happen.
Mapping: Schedule mode
Scheduling can be mapped to a button, implemented as an option, or both. - While the “schedule” mode is active, slot changes are delayed by a configurable amount - (if quantization is aligned to the recombination pattern) expand into the pattern (current/next pattern, depending on whether pattern-loop is enabled or not)
Only changed tracks need to be expanded, any other tracks should be fine as they are
If the recombination pattern will have a different length as a result of the changed slot, a new pattern is created. Otherwise, the change is applied “within” the current recombination pattern - Mapping (quant_enable) - Options (Quantization):
Instant change
Wait for source pattern
Wait for recombination pattern
Wait for 1/2/3/4/5/6/7/8 beat(s)
Gesture: multi-schedule
Press two buttons in the same track at the same time to schedule the pattern-tracks in-between
Mapping: multi-schedule (atomic)
Introduces a new mapping, “multi_schedule”, implemented as a push-button - While holding the “multi” button, press one or more slots to schedule them
Mapping: Add to sequence
Introduces a new mapping, “add_to_seq”, implemented as a push-button - Inserts the current GRID PIE pattern into the pattern sequence (located at the end, just before the current GRID PIE pattern). Useful for creating a song structure on the fly, a cheap sort of alternative to the session-recording feature
Gesture: combine slots
Hold two buttons in the same track to combine the pattern-tracks inbetween (selected slots are lit)
First a few terms, to make sure I understand them correctly, everything is with launchpad and gridpie in the duplex version:
Slot: A single in-grid button on the launchpad (one of the 8x8 buttons on the main matrix)
Matrix Block: (Renoise term for what (when using gridpie) corresponds to a clip in Ableton Live): A container in renoise matrix editor, contains data for one track in one pattern.
Control-map: ? maybe a duplex definition of the layout of a specific controller, for instance a launchpad??
Recombination track: ?
Expansion of recombination track: ?
In the current version, pressing/holding a single slot copies the corresponding pattern through all tracks to GRID_PIE pattern immediately. This feature is going away in new version?
Not sure what align with grid means, could you elaborate?
Except for the recombination stuff, that I don’t know what is, it makes perfectly sense!
So if I have loop-patten on in renoise (either by selecting it in renoise or by pressing user 2 on launchpad) gridpie is in old jam-but-dont-record-session-mode, and when loop-pattern is off in renoise, the session is recorded. This should be used to “capture” a jam on the launchpad in regular renoise patterns. Q: Are these “caputures” placed in new patterns inserted after the GIRD_PIE pattern? Will there be a way to clear a session (besides deleting the corresponding patterns in renoise)?
So there will be a new button on launchpad that I press/hold to schedule matrix block(s). If this new button is not pressed the change will happen instantly (the current way of working in gridpie). Nice with the quantization options, are those global and defined in gridpies preferences?
Nice!
How does that differ from regular scheduling? Is multi scheduling similar to the trigger queue you can use in the pattern sequencer by shift-left-clicking the number/play buttons found to the left in matrix editor?
Not sure I would use that, but then again, it makes perfectly sense, so it might come in handy.
Is this the same as pressing all affecting slots (example pressing (1,1 is top/left, meaning “first row, first column”) 2,2 and 2,4 is the same as pressing 2,2, 2,3 and 2,4)? Will this also apply when in schedule mode?
Any plans to implement the hide-collapsed-tracks-in-renoise-on-launchpad feature?
Ah yeah, we need some more clarification. I basically copy-pasted the info from my developer notes 
Yes, throughout this, I’m referring to the Duplex version. The original Grid Pie tool is a separate project.
Duplex Grid Pie is running on a large slice of hardware, so nothing is Launchpad-specific.
By slot, I mean one of the Grid Pie slots.
By Matrix Block/Pattern-track, I mean a specific track in a specific pattern in Renoise
Control-map: yep, you got that right. It’s just a simple XML document describing the controller.
Recombination pattern/track: it’s the GRID PIE , where everything is recombined
Expanded recombination … : this is describing the process when you combine different pattern lengths, the result being the lowest common multiplier. E.g. a 16 line pattern combined with 48 lines is 48. 48 combined with 64 will yield a total of 192 lines.
Nope, it would just become the new default scheduling value == “instant”. Btw. a new version of Grid Pie will definitely not contain all these new features, it’s best if they are grown organically (as we can work with them and feel how they perform before adding new stuff).
In that context, just that we would the same amount of trigger buttons as we have patterns.
Oh, I forgot to add that one. Probably because it’s going to be a general Duplex feature, and not just a Grid-Pie specific one
Btw: I’ll reply in more details later today, as I’m currently at work. Need food on the table.
Alright, I have digested your post…
I’m not entirely sure about this. Somehow I think it will be confusing to have a large amount of patterns appear, if you’re doing some minimalistic setup with only a few source patterns. On the other hand, it could be exciting to recombine those patterns…
However, I did mention another feature, the “poor mans” session recording that simply takes the current GRID PIE and add it to the sequence. Because such an action is triggered intentionally (by pressing a button), I believe those patterns should be inserted before the GRID PIE pattern, so you - for instance - could start with a few patterns and then create some nice variations which could be triggered as complete patterns.
Most importantly, both methods could co-exist peacefully
Again, this might work or it might not. We can basically treat a button like something which should be held to obtain some specific feature (a “modifier” button), or we could implement it as a toggle-button. I guess the big question here is if we need this kind of choice at all? After all, we could simply have scheduling as a “global choice” which you could choose to enable or not.
Yes, they would be global in the sense that no extra information is embedded into the song. When you start Grid Pie, it would have the same options as when you left it.
Yep, that’s how I imagine it would work. Every type of scheduling (with the exception of “instant”) would be accompanied by blinking buttons to indicate that something has been scheduled.
It’s a bit of a crazy idea, I’m not sure how realistic it would be (the combined length could easily surpass the pattern limit of 512 lines).
But I think it’s interesting to see how many gestures that can be fitted into a simple grid controller while still keeping the whole thing simple. So if you have a better idea for something interesting which could be triggered by holding two buttons in the same track, go ahead 
Oh, and thanks for the detailed feedback. I’m hoping to put down some work on one or two of these features next week, starting with edit-sync.
Here is a preview of the edit-synchronization feature
This is a funny one - inserting a note and seeing it pop up in a number of other places!
Here, Grid Pie is combining 3 patterns with different lengths (4, 8 and 12 lines) into a single pattern (total of 24 lines).
The edit-synchronization feature is then making it possible to edit them in real-time - or something close to realtime.
New features
The edit-synchronization means that any change to either:
Download the release here
Bump So the feature preview got released late last night (see prior post).
If you ask me, Grid Pie is now becoming really tasty.
Enjoy!!
YES! 
Uhmmmm. Looking forward to playing with this! You are wise to develop and release in steps, and you even have a clear roadmap. I’m sure gridpie in time will kill 'em all!
Well, things just never work out 100% like you expect, you either expand or reduce on the original idea.
In this case, I originally I imagined that we should have some way of toggling edit-sync, but it seems to work better when implemented transparently - simply being a part of the “Grid Pie package”.
Also, this “edit-sync” feature has actually provided some of foundation for continuously streaming output.
Just need to get the current bugs sorted out before we move on.
Edit: Looks like this was caused by a wrong setting in my bcr2000 updater in BiduleVST, so I think you can ignore it. Seems to work fine now.
Getting an error message here:
[s]‘C:\Users\DBY\AppData\Roaming\Renoise\V2.8.0\Scripts\Tools\com.renoise.Duplex.xrnx\main.lua’ failed in one of its notifiers.
The notifier will be disabled to prevent further errors.
Please contact the author (danoise [bjorn.nesby@googlemail.com]) for assistance…
std::runtime_error: ‘notifier feedback loop detected. do not change values you are listening to within your notifiers.’
stack traceback:
[C]: in function ‘copy_from’
.\Duplex/Applications/GridPie.lua:1622: in function <.\Duplex/Applications/GridPie.lua:1568>
[C]: in function ‘copy_from’
.\Duplex/Applications/GridPie.lua:1596: in function <.\Duplex/Applications/GridPie.lua:1568>[/s]
A plugin like Bidule shouldn’t be able to cause Grid Pie to throw an error, so somehow I think I was to blame for that one!!
Beta releases in general (and this preview release in particular) is experimental, so errors are to be expected.
Btw: I just added support for detecting changes to the source pattern-length. Another step closer to full synchronization 
Well I have some midiCCReset VST’s in a Bidule VST to remember and update last knob position of the BCR when loading a new song, and also the positions of my custom synced LFO’s(thanks dblue). After doing a user switch in Vista, I had to update and replace some VST in Bidule and I accidentally set them to synced. Which meant they spit out MIDI snapshots to the BCR and LFO’s continually. Works fine after I fixed it.
Ah, OK, so it was hitting the GRID PIE pattern hard with messages?
This IS relevant, I’m really aiming to have Grid Pie become as stable as possible.
It might hog your CPU when doing stuff like this, but it should never throw error messages at the user!
Working to put the final touch on some of the features which were previewed last week.
Some people have already tried out the new stuff - I just made sure that the whole thing feels more solid.
Well, I’m using this tool heavily these days, it’s awesome to explore it’s many possibilities.
I thought that I’d like to share some of my findings…
For example, I have discovered that a group track is a really nice way to set up independent modulation options for a track.
Because a group track will affect those tracks within it, sample commands are working as well. This means that you
can create a track containing a long sample, and then, in the group track, have a number of patterns containing these effects:
01 0B01 <- forwards
02
03
04
01 0B00 <- backwards
02
03
04
01 0B01 <- forwards
02
03 0B00 <- backwards
04
So you get the ability to control the playback direction, and “ping-pong” loop/freeze your sound whenever you please.
And of course, you could switch the sound at any time, as it’s contained in a separate track from the effect commands!!
The same approach could be applied to just about any other aspect of Renoise, as most things are possible to enter
either into the pattern or the automation editor. There’s really a lot of creative possibilities here.
–
Annoyances
But still, there is a couple of things that doesn’t really work well in the tool’s present state
You can’t save the combinations that work well - you have to remember them
This can be solved by taking a copy of the GRID PIE pattern, but then you loose the information about where the track originally came from
When you are switching from a short combination into a long combination, everything needs to be re-calculated
This is true, even if you are toggling on/off - the data is recreated each time, which takes a lot of CPU calculations
Deleting/modifying large amounts of data in the GRID PIE pattern can take a long time to process
Edit-sync is otherwise working smoothly, but this particular case, it could do with some extra sophistication.
Solution to (1): Pattern storage
I propose that the ability to copy/clone the GRID PIE pattern is expanded further.
Taking a snapshot of the current pattern could be done like now, but instead of just dumping the ‘raw data’ into a new
pattern, it should create a pattern which contain pattern-track aliases, pointing to where the source material came from.
Then, each time a pattern is saved in this manner, it’s easy to re-create the pattern using up-to-date pattern data
(technically, those patterns would somehow need to be identified by Grid Pie as being special)
The mute state (mixer mute state, not matrix mute state - Grid Pie only use the mixer state) is also applied to the slots
(as you can see, some of the stored patterns contain muted slots). This is a special arrangement that will ensure that
what you are storing as a pattern is the same you’ll hear when it’s being recalled. The saved matrix mute state will
simply be applied to the current mixer mute state when the pattern is recalled.
It should be noted that the patterns which are created obviously have a length, as the result of the clips within, and
this length could change at any time (as a result of resizing one of the clips). So, when the pattern is triggered, a
quick comparison is made, to see if the length is still the same, or if we need to recreate the pattern data.
Solution to (2): Cache management
The CPU usage in Grid Pie is for sure one of the tool’s weak points. It simply is quite heavy to calculate and output
all those data, so every technique that could avoid some of that work would be a boon to the tool.
Technically, Grid Pie works with a recombination pattern that contain the combined data of all the source pattern-tracks,
extended to the point where they all loop seamlessly. So, if we are talking about a pattern length of 160, 192 or
something even higher, some of the source patterns might be just 4 or 8 lines in length. But, here is the thing:
in Renoise, patterns maintain their data, even beyond the length (up to a maximum of 512 lines). So, if we copy the
the recombination pattern data into the respective source tracks each something has changed, we end up with
with a sort of pattern-cache that we can use for recreating patterns (technically speaking, it is a lot faster to perform
a raw copy of data from track to track, than to expand them line-by-line).
The tricky part about implementing this feature would be to come up with a reliable and fast way of detecting the
current length of each clip. Perhaps Grid Pie could build a table of these values to begin with, expanding each clip
to it’s maximum possible length (512 lines)?
Solution to (3): Delayed notifications, segmented monitoring
When we attach a line notifier to a pattern, we can monitor any kind of changes to the pattern data. This forms
the basis of the edit-sync feature. And it works great when you’re entering/editing single notes at a time, or
editing the source track itself. But, when dealing with the recombination track (where a single track could be
repeated many times), slowdowns can occur - technically, a “quick copy” back to the source is performed for
each and every change, and this can happen dozens or, in some cases, even hundreds of times.
The solution is to introduce an extra level of delay in the line notifier, which will collect those changes and
perform a delayed copy. It would really not be that hard to make, the basics are already in place.
I’ve been really enjoying Gridpie lately. I think it is, currently, the most useful of the “live” tools.
Many thanks for all the hard work, Conner & Danoise.
One feature I would love to see in the future, is an option that allows a selected pattern to be delayed until the next pattern starts/pattern loops again. I imagine this is already on your to-do list, though (it’s a long thread to read!).
Hey.
Finally checking the new beta out, not sure I appreciate the two rows spend on the step sequencer, but will play with it. To be honest I lost track of the threads concerning gridpie. Are the new features documented anywhere? As a side note found that the manual has moved to googledocs, is that the new location?
Either I’m totally thrown off by the new features, downloaded a wrong version (0.98b20) or there are some strange, strange things (bugs) going on here. Can’t even get clip launching going as in the previous version. But it might be I’m just brain dead 
Thanks, that’s good to hear
Yes, it’s a long read, I have so many ideas for this tool
Speaking of delayed pattern - this is the scheduling feature, and yes, it’s planned.
It’s no problem to make a “grid pie only” layout, if you don’t like the current one. Or we could simply have both?
Well, the only new features to arrive since we last talked are edit-sync and pattern highlighting.
Edit-sync is a no-brainer, it should simply make sure that everything is synchronized at all times. There are no configurable options, or anything related to that feature, it just copies modified notes back and forth.
And clip launching is working. I just checked 
Yes, I used to host my own stuff, but lately I have been moved things to google docs or dropbox.
Good news - the next version of Grid Pie will be turbocharged, and we are talking a lot faster. The CPU usage has always been one of the major problems with this tool, and although the new approach is no silver bullet (you might still experience CPU spikes at certain times), it’s still a major improvement over the previous versions.
So, what is it all about? Remember the “pattern storage” that I have described in a previous post - I started working on that feature, and quickly realized that a side-effect of using aliases to reference matrix slots is, that you no longer have to copy content back and forth - that is, if you happen to have a “perfect” set of data that has created in advance, and maintained throughout. So I decided to work on a pattern cache system, and it’s already beginning to look promising. Still a lot of work left in order to make this thing stable (not to break stuff when patterns are resized, and tracks are added/deleted/swapped), but stay tuned for updates!
To be fair, I just fixed one which could cause the GRID PIE to have a wrong length. And, yes, there are obviously more bugs lurking.