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=“■”,
},
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).
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 
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:
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:
Leaving the whole rec-armed mode quickly
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? 
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?
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.
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
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?
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
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.
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.
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.) ?
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 
.
I’ll try using monomeserial to directly access duplex, might be pages messing up the messages again.
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.
I have been tinkering with a couple of new features in Grid Pie, “running start” and “keep the beat”.
While I was at it, I discovered a bug in the polyrhythmic pattern-length computation, which got fixed too
So, what is running start? It’s simply a way to provide a smooth transition into Grid Pie’d mode -
Here’s how it works:
“Keep the beat” is a bit harder to describe, but it essentially makes playback more solid, as you switch between/combine patterns of different lengths.
This should make Grid Pie an even more performance-friendly tool