New Tool (2.8) Duplex: Grid Pie

[satobox]

@danoise

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…

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).

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 = {  
 color={0x00,0x00,0x00},   
 text="",  
 },   
 selected_filled = {  
 color={0xFF,0xFF,0x80},  
 text="■",  
 },  
 selected_empty = {  
 color={0x00,0x00,0x00},  
 text="■",  
 },  
 empty = {  
 color={0x00,0x00,0x00},  
 text="□"   
 },  
 filled = {  
 color={0xFF,0x00,0x00},  
 text="□",  
 }  
 }  
  

[danoise]

@satobox

it’s no problem that “selected_empty” does not be lit, isn’t it??

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 = {
color={0x00,0xFF,0x00},
text=“■”,
},

[satobox]

@danoise

selected_empty = {
color={0x00,0xFF,0x00},
text=“■”,
},

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

[danoise]

@satobox

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.

[satobox]

@danoise

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.

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.

[danoise]

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

[danoise]

@dby

I also have a few ideas for GridPie (I noticed three unassigned buttons in the monome 64 layout).

• Auto capture instrument and track when selecting a clip would be nice (last selected, maybe a slow blink indicating the active clip). That way you can quickly select instrument/track and jam along.

• A recording function. Press Rec button. Assuming the above suggested function, this enables pattern follow and edit mode (Indicating active clip with fast blink). This allows you to record notes and automation. Switching Rec off copies the edited clip back to it’s original position.

• Another unassigned button could simply be an undo button.

• And a third unassigned button could be copy. Press and hold, select target clip (indicating with blink), select destination… and the clip is copied.

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

[dby]

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?

[danoise]

@dby

I was just thinking about the procedure when editing a pattern normally:

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…

[dby]

@danoise

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?

[danoise]

@dby

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?

[dby]

@danoise

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?

[danoise]

@dby

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.

We already include an option to follow the pattern or not - the reasoning being this is two people jamming: one is programming notes & stuff in Renoise, the other is copying and arranging stuff on the fly using Grid Pie. It’s sort of a recording mode already, and IMHO things would get too complex if something started to override the existing options in specific situations? But nevertheless, it’s the first kind of recording mode I considered - but I like your approach even better.

@dby

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?

Absolutely, there really isn’t such a thing as an empty clip - it’s always pointing to somewhere within your song. If this wasn’t possible, you couldn’t create a Grid Pie’d arrangement from scratch (if someone dared to do such a thing)

BTW: did you read my own suggestions for improving this tool?
http://www.renoise.c…post__p__257231

[dby]

@danoise

We already include an option to follow the pattern or not - the reasoning being this is two people jamming: one is programming notes & stuff in Renoise, the other is copying and arranging stuff on the fly using Grid Pie. It’s sort of a recording mode already, and IMHO things would get too complex if something started to override the existing options in specific situations? But nevertheless, it’s the first kind of recording mode I considered - but I like your approach even better.

I only notice it wasn’t possible to enable pattern follow when running GridPie, it jumps to the play position and switches off again.

Didn’t even try to edit the way you describe as I always like to hear the changes I make. But I see how it could be useful in some situations now that I tried it. Anyways, that method would still be possible to use even after a Rec-mode being implemented?

@danoise

BTW: did you read my own suggestions for improving this tool?
http://www.renoise.c…post__p__257231

No I missed those suggestions. No 1 would be really nice. The other two went a bit over my head

[danoise]

@dby

No I missed those suggestions. No 1 would be really nice. The other two went a bit over my head

No, it’s surely because I failed to describe them properly “Keep the beat” is basically about the fact that Renoise can/will cause a “jump” when you switch between patterns of varying lengths. Try switching between a very short, and a very long pattern? I’m simply proposing a method for ensuring that this doesn’t happen (after all, G.P. is a live performance tool).

PS: I forgot to add “scheduled clips” to the list of proposed features

[dby]

Ah, yes keeping the beat is very important indeed. I had lots of timing problems with my old laptop before it crashed, so I know.

I don’t think I would use scheduling very much cause I like the direct approach, but I’m sure many would find it very useful, perhaps essential even.

[dby]

Trying out GridPie in Duplex 0.98b13 with my Monome40h. Running SerialOSC through Pages 0.2.2a33.

I can’t trigger any of the Mutes from my Monome, works when I click the GUI.

And also navigation jumps twice as far as it’s supposed to, ie 12 instead of 6 horisontally and 14 instead of 7 vertically. Very easy to work around, so no biggie.

[danoise]

@dby

Trying out GridPie in Duplex 0.98b13 with my Monome40h. Running SerialOSC through Pages 0.2.2a33.

Hmm…works perfectly here, both mutes and navigation - I’m not using Pages though…are the other application working as they’re supposed to (recorder et al.) ?

@dby

And also navigation jumps twice as far as it’s supposed to, ie 12 instead of 6 horisontally and 14 instead of 7 vertically. Very easy to work around, so no biggie.

Again, strange. Sounds like messages are being doubled somehow, but I can’t replicate it here.
As a workaround, you can simply set the vertical and horizontal page size to whatever you like (well, half of that .

[dby]

I’ll try using monomeserial to directly access duplex, might be pages messing up the messages again.

[dby]

Yes. Mutes work fine when I use monomeserial directly. Pattern position in the far right column doesn’t work. No LED feedback and no reaction to button presses. Works in GUI.

I’ll report the Mutes problem to Phortran who makes Pages.

When I run SerialOSC through Pages the LED feedback of Pattern position does work, but not button presses.