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
Finally I am satisfied with the new version. And yes, Grid Pie now has real-time recording.
Please check out the manual (download locations for PDF/HTML format are located in the first post), because this time around there are just too many features to explain in one post
Good work! 
When I try to initialize grid-pie through duplex, selecting my lpd8 controller, I get:
Fixed, thanks
Note to self: the session recording (recording with unlooped pattern) should commence only when the first track has been altered.
Right now, you have to be really quick in order to enable recording mode AND make a modification, BEFORE the playback goes to the first pattern in the song 
say what now!? that’s really great!
… just had a first jam with it, not sure yet how the recording actually works but i shall read the manual tomorrow after sleep :] for now it was great fun already! freefloooow, thank you
ps: unrelated, something is wrong with the forum clock… x]
I got this today after booting up the computer / renoise:
I terminated the script and got:
Great work! Can’t wait to try it out.
I’m looking forward to this tool. Sometimes I use a lot of automation… with a limit of 8 FX columns I’d probably have to prioritize some above others. I’m already using two columns to control my synced LFO.