New Tool (2.8) Duplex: Grid Pie

Haven’t had time to properly test the issues you’ve reported with the monome, as I’ve been busy with this:

EDIT: please download this more recent release: New Tool (2.8) Duplex: Grid Pie

We are talking about the new, simplified recording mode.
To install, unzip and overwrite the existing GridPie.lua file in Duplex/Applications/

Watch out when recording, especially the moment when the new pattern is created is a bit tricky. And in general,
creating tracks on the fly is far more CPU hungry than the normal playback mode, where you simply switch aliases.

Also, there’s a bug lurking: when session recording, sometimes we can be left in the pattern before the gridpie pattern.
This seems to happen right when the pattern is cloned, and will cause any recorded actions to end up in the next pattern
instead of the current one. Quite annoying, but recording will work again once playback reaches the destination.

I fixed this problem. Now, it feels a lot more responsive again.
Thanks for reminding me, that was obviously important to fix, but I often get carried away with details ^_^

Great! A lot more responsive, and multi-touch work fine.

The parameters responding to button presses has something to do with automation. The song has some automation, and I deleted all automation for the cutoff and the weird behaviour stopped. I figured automation would simply be ignored, but something seem to slip through.

Ok, I figured it out.

The grid pie pattern is created at the end of the song, so all automated parameters will jump to the last value. Why the cutoff was jumping to two different values is most likely due to an automated lfo that was controlling cutoff - it jumped directly to last automated value when I removed automation from the lfo.

Switching off “Update automation on song position changes” in the Preferences will fix this.

Is there some way of stopping some tracks from appearing on the grid? I wanted to group two tracks - one containing line in and signal follower, the other playing an instrument, with both tracks routed to effects in the group. I was hoping the group would be triggered by one button instead of taking up three columns. ;)

Edit: Decided not to go down this route, but it could be useful I guess. No hurry on my account tho.

Heh, this also confused me on a couple of occasions.
To make things more complex, some global commands, like tempo, will still be updated when we change position, while other commands won’t.

This is something which is planned, yes. If the expanded/contracted state of tracks was used to control how tracks appear/are controlled,
we could achieve two things: (1) simplify the controller by removing unwanted tracks from it and (2) allowing group tracks to affect it’s subtracks
See the image in this post: http://forum.renoise…post__p__271529

Agreed, I want to make this tool as stable as possible before we add any additional features ;)

Another preview release, fixing some issues and introducing a few tweaks:
EDIT: Attachment removed, go to this location for the latest beta

Again, to install this you need the latest Duplex.
Then, just unzip and overwrite the existing GridPie.lua file in Duplex/Applications/

Changelog (including all preview releases so far)

  • FIXME (Recording) better handling of patt. cloning near boundaries
  • TWEAK “Keep the beat” changed to modify playback-pos less often
  • FIXME Sess-rec.: “Stuttering” after short pattern (incremental_update)
  • FIXME Assign to slot: use patt-idx, not seq-idx (doh!)
  • FIXME Do not block “trigger gestures” in separate tracks
  • FEATURE Record: when triggering a pattern, use incremental updates
  • FEATURE Shorten pattern instead of modifying playback-pos (when possible)
  • FEATURE skip group tracks when temp-muting
  • FEATURE When muting track, delay note-off (to keep existing instr.)
  • FIXME Incremental updates should use the master slot range only
  • FIXME Don’t signal “dun goofed” when not started
  • USABILITY Restore matrix state when GP pattern is “dun goofed”

The way you wrote this, I thought that there was a discrepancy between the virtual control surface (UI) and the actual monome. But I just checked it out, and they behave in the same way.

As for the way they behave - there’s no fix for this ATM. It’s a limitation of the API that we cannot reliably modify a block loop when we are not inside the pattern containing the block loop.
Since the Navigator is doing exactly that, it doesn’t update when you are not playing & editing the same pattern - as a way of telling you that it’s not really useful in the current context.

Hm, not sure if you got me right. I know the Navigator only works when the cursor is in the Grid Pie pattern. It works when I click the right hand column in the Duplex Browser with the mouse. I doesn’t work when I press the buttons on my monome 40h, also no led feedback. It works on your virtual monome? Are you using a monome 128? I noticed the description says “Controlmap for Monome128” when I run Monome 64 Grid Pie.

Yes, happy owner of a monome 128 :slight_smile:

Ah, nailed it. If you open the control-map, you’ll see that the navigator group buttons have incorrect horizontal indices.

Where it says ```

It should go like this   
(repeat for every buttons with 15 as horizontal position)  
  
PS: sorry P.E. Viau for not basing all the m64 maps on your adaptations ![](https://files.renoise.com/forum/emoticons/default/blush.gif)

Great! That fixed the Navigator.

Congrats! :)

I can’t seem to get my monome 40h to be detected from Duplex. I’m using serialOSC.

What do I need to do?

@Skia: I’ve sent you a PM

Got an error when I tried cloning two or more patterns in the pattern sequencer:

'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...  
  
[string "-- create or convert a table to an object t..."]:66: bad argument #1 to 'table.copy' (table expected, got 'nil')  
stack traceback:  
 [C]: in function 'assert'  
 [string "-- create or convert a table to an object t..."]:66: in function 'rcopy'  
 .\Duplex/Applications/GridPie.lua:3613: in function <.><br>```

<br>
<br>
<br>
<br>
Also, a small annoyance... When clearing/cutting a muted block in the matrix, the empty slot becomes unmuted (and a led on my monome lights up when it's updated by changing pages), and I'm forced to mute it manually. Not a big deal, but slowing down work flow a bit.<br>
<br>
<br>
...After doing some more testing I found more related things:<br>
<br>
When clearing or cutting an active slot it seems to break the edit-synchronization of the related slot in the grid pie pattern. After that, any block that I copy into the active slot isn't copied/updated to the grid pie pattern until I switch the slot off and back on.<br>
<br>
Also, when dragging a muted block, that slot becomes unmuted and lights up a led. And if I drag that block to an active slot, it will play, but show as muted. Which also reflects on the monome.</.>

About to fire up Renoise and see if I can recreate the things you mention.

It seems the bug has been squashed.
You can try out the new GridPie from the SVN if you like, here is the link

About the annoyance - yeah, I can see what you mean, but as you say it’s hardly a big deal right now.
I would be implementing something into GridPie, only to fight the default behaviour in Renoise (which is to un-mute cleared slots).

But I do have a list of stuff I’d like to fix, features I’d like to add - at the top of the list:
making the row of GRID PIE buttons assignable as a separate mapping (that would make it optional too)

Thanks, I will take a closer look

Great! Works fine cloning multiple patterns now.

Oh, is that why it says “press the GP slot” in the manual, when direct copying using Multi-touch gestures? …also for saving recombined tracks when recording actions… I just thought it might be available on a different controller but not my monome40h.

Playing with Recording Actions now. This is fantastic! It’s the “pattern recorder” I’ve been missing from MLR and MolarVST. One thought… I tried setting length of the GridPie pattern to twice the length of the other patterns, to allow for a longer loop. But it reverts back. It might be nice if you could set the length of the GridPie pattern and it stays, perhaps as an option? I can imagine using say 16 step patterns and a 64, or perhaps 128 step GridPie pattern.

Oh I noticed the Navigator stopped working when I installed the latest Duplex version. Had to edit manually again.

This mode is quite demanding of the CPU, I have some optimizations planned. But yes, Grid Pie can record your live sessions :slight_smile:

I’ve been planning to improve this aspect of the tool so it automatically will create “sections” in the pattern sequence, making it
easier to spot where and when you recorded something. E.g. “GP Session 22:31”

Well, Grid Pie is “stupid” in the sense that it always combines the lengths of all slots. This is really fundamental to how the tool works.
But: if you would like to have a pattern of 128 lines all you’d need to do is to include a pattern with this length - it could even be a dummy pattern with no content.

Thanks man, this will definitely be fixed in the next release :slight_smile:

Ah, I was thinking about whether I could use some kind of dummy… Great! That solution works just fine.

I tried a 512 step GP pattern. There are some heavy lag in the Renoise GUI and the monome LED updating, but it still works quite well. I don’t think I can hear any problems with the sound or tempo. :)

Everything in beta 26 working fine so far. Good job! :)

I’ve been trying to wrap my head around editing the config/controlmap. I finally managed to add “edit mode” to the bottom left to quickly being able activate Recording Actions. Nice indeed :)
I also added Rotate: “Nudge track up” and “Nudge track down” to the two unused buttons in between. Seem to work like a charm. :yeah: