The two links are the same, or?
I did nothing, just plugged it in and it showed up along with my other usb midi stuff. The link you posted is from 2009, lots of water under the bridge since then…
Oops, definitely the same. I meant for the other link to be this one: [Howto] Launchpad + Linux
And yeah, it would seem that the Launchpad has gotten kernel support since then. But from what you’re telling, it sounds like it’s not perfect.
Perhaps a dedicated linux/driver/audio forum could be more helpful than this (rather particular) thread ?
Any chance of this tool being in the works? I’m about to prepare for a live set and was wondering if I should wait and do the automated stuff last, or just go ahead and do things manually. No pressure. 
Uhm, now that you mention it… Here’s a draft I made:
It’s just a raw sketch … but I thought I’d share the mockup anyway 
–
Speaking of Grid Pie, I have spent some time doing an honest recreation of a composition by Philip Glass - interesting to see how a piano piece that have multiple time signatures and varying accents and “floating” tempo could be translated to Grid Pie.
The first thing that struck me was that “keep the beat” was interfering with how I wanted to transition from pattern to pattern.
As the original song consist patterns with lengths between 48,60 and 64 lines, played in order and not on top of each other, the playback position should be changed only when needed.
You could argue that playing things one-by-one and then stacking them are two different playing styles? For this reason, I have experimented with how the “keep the beat” feature could be tweaked, in the hope that it could become more intuitive to use.
I really don’t want to have two separate modes for keeping the beat, so I hope to have succeeded: now, we only change the playback position when the pattern line no longer exists.
It still has a few difficult cases: to go from the end of a short pattern into the beginning of a long(er) one is no longer done automatically, playback instead crosses the extraneous lines at the end of the long pattern.
I hope to find a solution for this that doesn’t involve going back to the previous “beat keeping” method (perhaps via scheduling?), because otherwise it’s definitely a better approach.
For example, a side benefit is that the recording mode would work much more simple as well (as recording is rather limited in the sense that it can never modify the playback position, so the less changes the better).
I’ll release a new version soon, so you can tell me if it’s an improvement or not.
The sketch looks good. All the features one would need, by the looks of it.
About keeping the beat, I haven’t tried it out yet since I’ve been composing in traditional linear mode lately. I’ll air some thoughts anyway - that may or may not be relevant… I’m not sure if you already thought of or implemented any of this already.
The Grid Pie version I used paste from the start of the grid pie pattern, with line 00 ending up at line 00 in the grid pie pattern. And pasting is instant. This is kinda cool. But there are two options, assignable to each of the tracks I’d like to see:
Scheduling/quantize of pasting/switching. Something like bars, 8th, 16th, 32th and instant.
“Follow mode”, where line 00 is pasted at the current play head position in the grid pie pattern. Combined with scheduling, line 00 would be pasted at the start of next bar, 8th, 16th etc.
After reading a bit in the manual, I realize this has nothing to do with keeping the beat. Well, call it a feature suggestion. I don’t have any ideas for keep the beat and different time sigs.
This is definitely on the todo list. Actually, minimizing how much “keep the beat” is interfering with playback is in itself a stepping stone toward a scheduling system, so it’s all good
Hm, there you lost me. Can you describe in detail how you would imagine this to work, what you hope to obtain?
Great! When I read about scheduling before, it sounded more like some queuing up patterns deal.
Normally the original sequence is pasted at the exact same position in the grid pie pattern. ie line 00 at line 00, line 01 at line 01 and so on. What I suggest is to push the sequence back to the current play head position. So if the play head is at line 16 when pasting, line 00 of the original sequence would be pasted on line 16, line 01 on line 17 and so on. And wrap the remaining lines to the top of the grid pie pattern.
This way you could line up interesting “off beat” rhythm variations easily just by “starting” tracks at different positions. Also retriggering of individual tracks.
I was also thinking about an alternative use for the far right column that is now used to jump position in the pattern. It could be used to set the start position from where to copy. So in “normal mode” pressing for example the second button in column, it would perhaps start pasting line 16 on line 00 in the grid pie pattern when then launching a clip. And in “follow mode” it of course pastes line 16 at the current play head position. Top button resets to start at line 00.
With these features, you could do similar things as with MLR for the Monome: http://www.youtube.com/watch?v=1YVzTpkLco0 …except you couldn’t start from different position on different tracks quite as quickly.
Ah, then I actually did understand you
If you add the Rotate application to your device configuration, you will - sort of - be able to do this right away. At least, it’s possible to play around with various different offsets for the patterns. Disclaimer: I haven’t actually tested if this combination will break something in Grid Pie, I’m thinking the edit-sync might have a seizure 
But along with scheduling and all the other ideas lined up, I think the Rotate application would do this job beautifully.
Also, try Grid Pie in the polyphonic mode in order to understand that doing this natively might not be as simple as relying on another app. As the Duplex eco-system grows, this really gets more true for each new app & feature…
Hell, I even think I know how cool it would be for Rotate to have “specific interval buttons” (e.g. 8 buttons to control offsets between -4 and +4), instead of just the simple nudge up/down buttons it currently has.
Believe me, it would be easier to code an MLR clone from the ground up than to make Grid Pie behave the same way 
Yes, using Rotate certainly seem like an option. I haven’t tried it, but I must say I don’t like the idea of nudging. Sure it can be useful. But simply triggering in time with the tune is far more intuitive, and more like playing an instrument rather than deejaying. Like playing a sample on the keyboard. Kinda like when you trigger first button in MLR (like he does 0:15-0:30) - that’s why I included the link, not suggesting to implement the exact same functions.
Triggering at different positions is only an extension of the idea, which is actually quite similar to Rotate but with more direct access than nudge. The default is triggering from line 00.
All this depends on how much you can control the copy/paste process in detail… but I remember you made it so it pastes stuff in smaller chunks so I figure it would be theoretically possible. And yes, I’m also thinking this might conflict with edit-sync, just as Rotate might.
I’m trying out Duplex 0.98b22 / monomeserial / monome40h.
It’s a lot slower/less responsive than b20 (the last one I have used). And it only works if I press one button at a time, I can’t launch several slots at once any more. Muting several at once work, but not launching in the grid.
Also, on this track I’m testing, a parameter on my Instr.MIDI Control device that control the synth cutoff reacts to button presses on the monome or grid pie GUI. On first press the value jumps to 58, on second press to 105 - then it stays at 105 unless I change the parameter after which it jumps to 58 and 105. It doesn’t react when pressing mutes or navigation, only grid - on/off and transport - play.
Far right column that control pattern position doesn’t respond to button presses and no led feedback, works in GUI… the same problem in b20 and earlier versions too I think.
Thanks for the feedback.
Uhm yes, it’s just the way gestures are recognized - the whole multi-touch input got rewritten in the last version.
I should obviously allow certain button presses combination that currently are blocked. It’s on the list.
So, the monome running the standard Grid Pie configuration is somehow controlling a MIDI control device … Hm, that’s really strange 
I guess you are talking about the Navigator application. Thanks for reporting this!
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.