Ok, this is a little tread hijacking, sorry bout that, but this seems like the best place for this question, so here goes:
I’m doing an external application (not lua, outside of renoise) for handeling the launchpad. My application controls renoise through OSC. Things are going well, but there’s one thing I can’t figure out:
The fírst time I start the application the launchpad works fine. But after stopping the application and starting it again the 8x8 grids + 8 arrows doesn’t seem to send anything. However, by pressing one of the top eight (up, down, left, right, session, user1, user2 and mixer), buttons the launchpad works fine again, and all buttons send correct messages. It might be something I’m doing wrong, but I hoped that one of you guys developing duplex/gridpia, had come across this and found a solution. I tried sending 176,0,0 (reset) and 176,0,1 (set mode to x-y), but it doesn’t seem to help…
Granted And I’m sorry that I can’t provide you with anything substantial to go on, excerpt perhaps that you probably want to
disable the automap software for your launchpad (mixer2 + arrow down - but I’m pretty sure you already know about that trick).
When operating as a standard midi device, the LP is very straightforward so I cannot guess as to what is screwing with your setup.
–
On-topic: atte, FYI some of the recent features in Grid Pie are more or less a result of our discussions a couple of months ago. How cool is that?
Automap? Google suggests it’s some kind of novation software thingie, right? I’m running linux and didn’t install anything from novation (and probably couldn’t even if I wanted to)…
More tests might be needed
–
I must make sure to check out the newer version!
However, I’m currently working on my own stuff, which is quite different from duplex/gridpie, but does clip launching too. Basically it uses ChucK for the “notes” (it algorithmic) and sends OSC to renoise, which serves as a sound player. In this scenario each “clip” on the launchpad is actually a piece of ChucK-code that can be thrown in/pulled out of the virtual machine. I used to perform with a similar setup (just without renoise and without a launchpad) a few years ago, and I’d like to get back to that (and as far away from “just pressing play” as possible)…
Now with all my new tracks already in renoise, it’s just the triggering of sounds that’s missing, the mix is already done. This means it’s just the fun part of algorithm-izing a track that is required before the song is live-ready…
Yes, it’s a software designed to support Novation’s hardware with dynamic mapping of plugin parameters etc.
Win/OSX only, so you are obviously not affected by this. But I wonder how you’ve connected the Launchpad in the first place (like this or like this ?)
Regarding the new setup, def. sounds interesting … IMO it’s good to have multiple approaches to the same thing
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…
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.
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!
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.
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.
And I’m sorry that I can’t provide you with anything substantial to go on, excerpt perhaps that you probably want to
