New Tool (2.8) Duplex: Grid Pie

This quick fix worked like a charm, thank you.

Hi !!!
I try the new beta and gridpie reset all trhe tracks when i switch mixer configuration (or other) to gridpie… but when I switch gridpie to mixer (or effect or other configuration ) no problem…

I try to find in the script but it’s too hard for me … :panic:
I create a switch configuration for replacing the start and loop button (ok work perfect) but that’s all for me (and my little script language )…

And excuse me for my english!!! :huh:

Hey Mooko, I have to give you the same reply as I gave you a week ago:

The reason that Mixer, Effect etc. seem to “remember” their settings is simply, that they are designed to represent the current state in Renoise (the selected track, device etc.). Grid Pie, on the other hand, is doing stuff temporarily.
The solution to your problem will require modifications to Grid Pie. Stay tuned for updates…

Ok thank you so much Mr Danoise!!!
Wait & see :unsure:

I’m really loving this…

I agree, Conner did something wonderful when he came up with the idea for this tool :slight_smile:
Also, don’t be afraid to suggest new features - for example, I’d like to see scheduled triggering (wait until pattern reach it’s end, or X number of beats)

I’d like to add that this is not really an issue anymore - Grid Pie (the Duplex port) is now actively setting the playback position to the GRID PIE pattern, so it’s actually possible to create and manipulate blockloops even when follow_pos is enabled. You’re still missing out on visual feedback on the current position, though.


Hi, I need your help again. :rolleyes:

Now I try to make GridPie config for APC, but it seems that the button colors are different from the normal configs. Although I tried to edit it by myself somehow, I don’t yet understand the way…

2618 apc-gridpie.png

[Duplex Browser] >> [APC]

  • Muted slot [dark red] >> [not lit]
  • Selected slot [yellow] >> [yellow]
  • Selected blank slot [orange] >> [red]

But I want them to be lit like,

  • Muted slot >> [red]
  • Selected slot >> [yellow]
  • Selected blank slot >> [red blink (or green?)]

[from the APC protocol pdf]

0=off, 1=green, 2=green blink, 3=red, 4=red blink, 5=yellow, 6=yellow blink, 7-127=green  

Where and how can I edit them??

Okay, first thing I notice is the dark red color in the virtual control surface. AFAIK, the APC can produce only the following three colors for those buttons

Yellow = 1,1,0
Red = 1,0,0
Green 0,1,0

But the colorspace for those buttons on the APC20 have been defined as 2,2,0 in the control-map. That’s actually wrong, isn’t it - it should be just 1,1,0 ?
If you try and change that, the virtual control surface should only display colors that the APC is actually capable of…

As for the application’s colors, this is actually quite easy to change - if you open GridPie.lua and look for “palette”, you’ll find the colors specified as RGB values. Try and experiment?

self.palette = {  
out_of_bounds = {  
selected_filled = {  
selected_empty = {  
empty = {  
filled = {  

Once you find a set of colors you like, just PM me and I’ll make some code so we can define the palette especially for the APC. Right now Grid Pie comes with a palette which is primarily good for the Launchpad + monochrome devices. APC is sort of inbetween But it’s hugely useful to be able to see where there’s content and not.

Hmm? if I change that to 1,1,0, all the color of APC’s matrix are lit in green. So I cannot use red and yellow. Setting that as 2,2,0 works fine here (I don’t know what exactly it means though). :huh:

And I think this color specification is good for APC’s GridPie (it’s no problem that “selected_empty” does not be lit, isn’t it??).

 self.palette = {  
 out_of_bounds = {  
 selected_filled = {  
 selected_empty = {  
 empty = {  
 filled = {  

If we look at the original Grid Pie script, it only has ON and OFF states. I think any device should respect that…
IMHO a selected slot should always be lit, no matter if it’s empty or not. Otherwise, how can you see that you are toggling it?

So, I guess the following could look really ugly but be more functional ?

selected_empty = {

I’m OK with this though, then can it be set to too??
Currently, “selected_empty” in Matrix config does not be lit too (therefore I suggested also in GridPie to be not lit).

But Grid Pie isn’t the Matrix, they perform different jobs. You are right that the matrix have “dead spots” (which doesn’t do anything when pressed), but think about what’s actually happening:

-> In the Matrix app, I’m simply toggling the state of an empty matrix slot. In other words, it has no consequence
-> In Grid Pie, I copy that particular pattern-track to the GRID PIE pattern. Since the track might include automation data, it does something.

So, in Grid Pie it’s actually always important to see which are enabled and which ones that aren’t.
Finally, it’s also how Grid Pie works on devices with no color. Good point is to keep the device configurations consistent.

Maybe I’m a bit fuzzy about the details. Don’t worry. These are opinions (what stuff looks & works nicely is a personal matter), but I trust you to understand why they makes sense as the default values.

But I’ll make it a feature in Duplex to customize the colors on a device-config basis. For instance if I for some reason wanted the Monome Mixer colors to be inverted (when all buttons is lit, it’s a very bright controller, I can tell you!!), I would become able to specify this in my monome-mixer config. And eventually, maybe even visually, via some palette UI.

Oh, I didn’t know such difference. I may not be a master of GridPie yet. ;)
OK, I understand it. Go for green light in GridPie only.

Grid Pie, Duplex port, got updated once again.
Sorry sato, but this one has even more color shades

  • New feature: hold to toggle the pattern between muted/unmuted state, once all tracks are aligned (kind of hard to explain, but makes perfect sense on a grid controller)
  • New feature: If you press and hold one of the next/previous pattern or track buttons, you will go there (start of song, end of song, first track or last track)
  • New option: Follow position: follow track only
  • New option: The ability to hold the pattern is now optional - use any MIDI controller.
  • Optimized for the Launchpad, the active track is now being highlighted (see illustration)
  • Bug fixes and optimizations

The changes have been committed to SVN

Edit: Download here

Auto-capture, sure. Slow blink is reserved for the “scheduled switch” (to keep things consistent). But a brief blink (like step-sequencer) could be used instead?

I think I understand the recording function, too. Not sure about restricting editing to a single pattern-track (clip) though…
Instead, I would like to think about such a feature like record-arming any number of tracks.

So, you have this awesome Rec Arm button:

  • While pressed, you can either add or remove tracks from being armed, you simply press to toggle them.
  • While pressed, the display is temporarily inverted to make it clear that we’ve pressed the rec arm button
  • Also, while pressed the main Grid Pie grid will ignore other actions (so you can’t switch clips while rec-arming tracks)
  • If you are arming a track whose clip is currently playing (lit), it will start to flash (make it visible on monochrome devices)
  • When you release the button, the normal grid actions are restored as well as the non-inverted display

Now that you’re rec-armed some clips, their original state is remembed - not the original-original, but the grid-pie version.
Moving around in Grid Pie will now cause any rec-armed track clips to flash - making it easy to see where stuff is actively being recorded.

Times when changes are copied back to the original clip:

  • When you switch to a new clip in the same track, the old clip (the one we are leaving), is copied back.
  • When grid-pie pattern contents change (relevant track are being monitored)

Leaving the whole rec-armed mode quickly

  • Press rec-arm button + press and hold any track

No I didn’t really mean to restrict editing to one track. I see why you got that impression tho. It sometimes says clip when I meant clips, or perhaps track… confusing. :)

I was just thinking about the procedure when editing a pattern normally:
Notes are recorded to selected track when using master keyboard, except when the instrument output is assigned to a specific track I guess. Automation is recorded to whatever track the device is located. Any edited clips would then copied back to the original position.

Maybe it’s just the way I usually work, but I don’t see when it would be necessary to arm just a few specific tracks? :huh:

Well, anything could change the track or pattern. Press shift+F1/F2, and you have transposed the pattern. Use the pattern editor to enter notes.
Or you might have some other tool running that modify the pattern data on the fly, so it’s anything really.

But I just realized that copying back needs to be done only when switching clip or exiting record-mode. Too much copying would become a big CPU hog in an already quite intensive application…

Sounds sensible. I’m kinda happy my old laptop crashed, forced me to get a new one that can run GridPie. :)

I haven’t tried out polyrhythmic clips in Duplex:GridPie yet, but how would that work out with a recording mode? Anything edited in a shorter clip would have to be duplicated to all the “pasted parts”, right?

Hey dby, you’re right that a certain intelligence is needed in such a case. So, if we have a 16 line pattern and a 64 line pattern, it’s easy enough to imagine that any change to the 64-line pattern copy is copied back. But what if e.g. lines 24 and 48 in the 16-line pattern are modified “at the same time” ?

It’s an impossible scenario, really, as nothing is ever changed at the same time. Even when you’re pasting stuff to a pattern, the Renoise API will detect the change line-by-line. But looking away from the technical implementation, this is how I would intuitively understand it if I had pasted a note column into the pattern which contained a note at line 24 and 48…

I guess the best solution would be to take the first occurrence (line 24, which would be located in the second expended segment, between lines 17 and 32), and copy that change to the other segments, in real-time. And then, once you exit recording mode or change clip, the first segment (lines 1-16) are copied back to the source. This means loosing the second note at line 48, but that’s the nature of a compromise.

I guess it’s OK - the usage scenario in which changes occur “simultaneously” is a bit theoretical to begin with?

Yes I was also thinking along those lines.

Also, maybe pattern follow should be optional in Rec-mode? That way you could also move around the cursor and edit the pattern while playing without exiting Grid Pie.

Another thing to consider: What happens if a track is armed but no clip is playing? Could you still edit that empty clip? Would it be “copied back” to an empty slot?