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.
I just played a bit with it and a few things confused me, first my settings->gridpie->horizontal page was set to 3 for some reason. Secondly I have hard time getting to grips with row 1 and column 7/8.
I don’t really get the behavior of row 1 (track selector). First it shifts the track layout, which is quite confusing, I’d like to scroll by one “screen full” using launchpad buttons < and >. I guess the track selector is part of the step recording stuff. However, as it is now it seems only half baked, I have to select the instrument in renoise and the octave up/down and halfstep+/- is hard to keep track of (unless I missed something, which is entirely possible). I think a goal of gridpie should be to be able to do everything from the controller. And supposed I have a pattern with more than eight lines, column 7 (step sequencer) will only affect the first eight lines. I’m also having a hard time keeping track (:-)) of which track the step sequencer is currently operating on.
I’d much prefer:
8x8 for clip launch (mutes could be achieved my pressing an already active clip or an empty slot (the red ones)). Additional stuff like step sequencer could go in other “pages”, like it seems the launchpad works with ableton live. Actually the best way IMO would be to be able to assign different duplex applications to different “pages”, making the UI clean and easy to flip. If you want instant control of several applications, duplex should support more launchpads the pretty much should work in parallel. This way I could get 4 launchpads and launch clips on 8x32 or 32x8 or have gridpie on one, step sequencer on another and what-have-you on the last two.
I hate to say this, but I think we’re gonna need a way to store info on a per-song basis. PadSynth does this (on an per-instrument basis) by writing a serialized array in the instrument name. Duplex could for instance use the song comment with a specially marked area to support regular comments. I know the user could accidentally mess this up outside of duplex, but until we get tools settings saved in the song, I think we can live with that. Per-song settings could include: (re)load duplex on this load, which duplex applications to run, which controllers they should use, + more. Actually to keep in line with the way renoise works, all settings could be moved to a per-song basis, with an added way of copying settings from songs on disk. The last thing I want is loading a song on stage and being put of by something global being changed, so my song will act funny “although it worked the last time I checked”.
I hope I’m making at least some degree of sense here
Sounds like something has messed up your configuration. Grid Pie and TrackSelector should both be using “automatic (use available width)”, with Grid Pie set to follow track (read more about the paged navigation concept in the Duplex manual).
In short: if you mean for any two applications to navigate in the same way, you need them to use the same page size.
Have you tried assigning the same name to the track and instrument? Instant synchronization between the two
Hey, easy, this is what configurations are for.
Simply save the following as “LaunchPad_GridPieFull.lua” in (Controllers/Launchpad/Configurations)
–[[----------------------------------------------------------------------------
– Duplex.Launchpad
----------------------------------------------------------------------------]]–
– setup GridPie for the Launchpad
duplex_configurations:insert {
– configuration properties
name = “GridPieFull”,
pinned = true,
– device properties
device = {
class_name = “Launchpad”,
display_name = “Launchpad”,
device_port_in = “Launchpad”,
device_port_out = “Launchpad”,
control_map = “Controllers/Launchpad/Controlmaps/Launchpad.xml”,
thumbnail = “Controllers/Launchpad/Launchpad.bmp”,
protocol = DEVICE_MIDI_PROTOCOL,
},
applications = {
GridPie = {
mappings = {
grid = {
group_name = “Grid”,
},
v_prev = {
group_name = “Controls”,
index = 1,
},
v_next = {
group_name = “Controls”,
index = 2,
},
h_prev = {
group_name = “Controls”,
index = 3,
},
h_next = {
group_name = “Controls”,
index = 4,
},
},
options = {
follow_pos = 2
},
},
Navigator = {
mappings = {
blockpos = {
group_name = “Triggers”,
},
},
},
Transport = {
mappings = {
edit_mode = {
group_name = “Controls”,
index = 5,
},
start_playback = {
group_name = “Controls”,
index = 6,
},
loop_pattern = {
group_name = “Controls”,
index = 7,
},
follow_player = {
group_name= “Controls”,
index = 8,
},
},
options = {
pattern_play = 3,
},
},
}
}
As for switching pages, this is what the SwitchConfiguration application does. But it wouldn’t work with Grid Pie, as the application is stopped when we switch away from it. To truly get the feature you’re requesting, we would need something I call “states”, which would accommodate controllers with many virtual pages, as well as hardware with “modifier keys” which change the message being sent from the hardware on-the-fly. This “states” feature is really something which is planned for the long term.
It already does. it’s basically a question of taking a copy of the Controllers/Launchpad folder and editing the device display-name. The process is documented in the Duplex manual
The new version of Grid Pie makes use a of a caching system which could benefit from such a thing. So we’re about to get the functionality you request, but to begin with, you wouldn’t really notice it at all.
Fasten your seatbelts!! The faster, better, stronger version of Grid Pie has arrived.
A whole batch of changes, so let’s take them from the top:
PERFORMANCE
Edit-synchronization is now a complete feature. Previously, certain actions would cause TERRIBLE slowdowns.
Extensive support of + use of matrix-slot aliases combined with a pattern-cache system means a HUGE difference, CPU-wise.
Together, this means that Grid Pie is now faster than ever. The worst slowdown gone, and overall performance improved.
It’s not a completely magic bullet, as you will still need to wait for Grid Pie to compute sequences, but now you only have to wait once
INTEGRATION
Integration with the Renoise workflow has been improved a lot in this version. A hardware controller is still the optimal way to
control Grid Pie, but there is a lot closer integration with the Renoise user interface:
(1) Due to limitations in the Renoise API, the first few notes will be missing when using the pattern sequence to schedule a pattern. Use a controller if you plan to use this feature in a live performance.
ETC
Here’s a tip if planning a performance: if you are working with differently-sized patterns that, when combined, form longer
patterns you can maintain the pattern cache between sessions. Otherwise, there is bound to be a lot of copy-expand
Well, this didn’t make it into this version. Not even sure if it’s practical, as the manual caching trick (mentioned above) seems good enough.
Grid Pie is a semi-alternative workflow with a practically endless list of possible features. With this most recent version out in the open, I can tell a bit about what might be ahead.
First and foremost, I think the ability to gather specific combinations of slots are a very useful performance feature. But this is currently implemented in a half-assed sort of way, as you can copy the GRID PIE pattern and it will retain references to the slots. The good thing is that it’s possible to store a specific combination - helpful when experimenting, to save such information in a reliable way. The bad thing is that apart from the storage aspect, such a pattern isn’t really very interesting: from a controller’s perspective, they take up valuable space (a whole row of slots where each slot is never unique, but always referencing some other part of the song).
Essentially, I would like to keep the current philosophy and introduce a specially-named pattern called a “preset pattern”. At any time, a preset pattern could be activated using a single button and we would import the slots it was referencing.
But, what could make the preset pattern special is that
I imagine that we could simply specify preset patterns by assigning an auto-generated name like PRESET#1, and having a dedicated mapping in Grid Pie for storing presets
So, a week after releasing the turbocharged edition, and I’ve just realized that I forgot to explain the “price” of this wonderful feature!!
See, since the first version, Grid Pie has always copied automation data into the recombination pattern / drafting area. Not a big deal really, there was already a lot of copying going on - but it was always sort of lacking in precision (it would selectively pick one value per pattern-line - so high-precision edits would be lost, but a reasonable compromise, you would get the exact same precision offered when recording automation using MIDI hardware).
But since the whole turbocharged feature is based around using aliases, and aliases does not include automation, this automation envelope support had to go. And really, the only thing lost is if a song that already has a lot of envelopes -> you would need to “convert” these to effect commands*. But otherwise, the whole functionality is exactly the same with FX command as with envelopes.
I’m almost ready with a new version. Half a dozen new features will make this the biggest update yet
The native UI integration (using the pattern matrix to control Grid Pie) will be GONE. It was too complicated and buggy, simply not worth it.
Using the pattern sequence to schedule patterns is still there, though. That feature is genuinely useful 
Stay tuned 
is it possible to record the gridpie performance?
No, but I’m working on that. It’s one of the most-wanted features on my list too
oh, ok thank you for the information