Ah, I’m assuming you’re using a Launchpad here?
Under all circumstances, the TrackSelector and PatternSequence apps are the ones you’re looking for.
Start by opening LaunchPad_GridPie.lua, or LaunchPad_GridPieFull.lua (whichever you are using) in a text editor. The files themselves are located in the tool folder, under /Controllers/Launchpad/Configurations
Then locate the lines containing h_prev, h_next, v_prev and v_next mappings and remove them (or comment them out using --[[and]] ).
Next, add new entries for the TrackSelector and PatternSequence apps:
Here’s a modified version of the GridPieFull config that does what you want
4172 LaunchPad_GridPieFull.lua
hey, thank you so much for your response danoise. i think you attached the wrong file, supposed to be the the lua not the xml. i am trying to work it out myself but am having a hard time figuring out where exactly to make my cut. ill keep trying, its good for learning and ill post back if i crak it! forgive me i have a hard time with lua
using launchpad, gridpiefull, i’m noticing a problem with the navigator strip on the right side, specifically the top button on the right, to trigger the first 1/8 of the pattern. If you keep pressing it over and over again quickly, gridpie seems to glitch out and fill the gridpie row up with the row above it, instead of just triggering the first line of the current pattern. just try it! open new song, add a couple patterns, launch gridpie full, enable follow playhead, press play, and start tapping the top button of the righthand navigator strip. hopefully you will see what i am talking about, im a little thick so its hard to convey my thoughts!
edit: it also enables/disables the repeat pattern button randomly (located next to the play button) when this glitchiness occurs
phooka, thanks for reporting this. It seems to be the result of a complex interplay between the Navigator and Grid Pie
Basically, you are able to jump around inside patterns with continuous playback.
However, the first position is special since it will (when you are pressing the button just when exiting the first block) jump to the last line of the previous pattern
This is then picked up by grid pie, and will cause it to switch to that pattern - which, in itself, is the way it’s supposed to work. But in this case, isn’t what we want.
I have to think about a way to avoid this - probably a hackaround which will simply ignore pattern-switching when at the very end.
As for the loop button being highlighted, this is just the transport telling duplex that the pattern is looped (the grid pie pattern is always looped, but using a pattern sequence loop), and nothing to worry about.
Finally!! Here is a version that has blinking LEDs for monochrome devices, such as the monome.
monome64 owners: I am lazy and have only made a monome128 configuration…
In order to display normal (unselected) content as lit LEDs, you need to tweak the palette. See how, in the “m128_GridPie.lua” configuration file
content_active = { val=true } -- this tells the monome to light up content
Yeeehaaaw! I love it, no more need to memorize the whole layout of a song!
To be the ungrate, I’ll put in another feature request immediately: Would it be lots of boring work to make the blinking synced to BPM? Perhaps linked to LPB, and/or an option to set like half or double speed in the config file. Of course mostly a cosmetic crowdpleaser, but also a little helpful visual feedback.
Would it be lots of boring work to make the blinking synced to BPM? Perhaps linked to LPB, and/or an option to set like half or double speed in the config file.
Nope, a tempo-synced version isn’t that hard to make - already got this logic sorted out in the Recorder.
On the TODO list…
Big fan of GridPie here, and I’ve just discovered today that the tool is able to record pattern changes live into the song data - YES!
This allows me to do something I’ve been wanting for a long while - create a series of patterns in Renoise, then live jam them out in order to create a rough song structure to work from.
However, on testing this I’ve ran into some issues
GridPie works fine in non-recording mode, creating aliased patterns no problem. It’s the session-record mode I encounter issues with. The manual says -
Finally, it’s worth mentioning that Grid Pie also come with a session-record mode. This is
identical to the normal recording mode, except that it will produce a continuous stream of new
patterns for as long as it’s active. To enable the session recording mode, enable song-follow
and edit-mode, and then turn off the pattern loop (which is enabled as the default when starting
Grid Pie).
So I arm playback-follow, edit-mode and remove the pattern loop, but strange things happen. Instead of creating a stream of patterns that are consistent with the originals, I get a broken up sequence of smaller ones. This is best illustrated in a screen recording I made -
You can see me activating patterns via the launchpad, and a block of several new pattern sets being created at once instead of one. This behaviour seems to happen near the end of pattern playback.
Am I doing something wrong, or is this a bug? I could have a go at fixing it, just wanted to check it’s not me first. Thanks!
Hello Community,
I am using a Launchpad mini that I am trying to set up with Gridpie. Sadly, when I am running Jack (no problem with Alsa) the Playback transport button flashes violently.
I went through the lua configuration file and through the default parameters but no change seemed to make a difference.
I wouldn’t believe that it is a bug, I probably have something setup in a bad way.
What is it and how can I find some kind of log file that helps you guys figure out what my pc is doing?
edit 1
I should mention that the problem occurs for playback mode only, when I tick “Run” in the Launchpads Gridpie Tab in Duplex Browser
edit 2
okay so I checked and it apparently affects not only the Launchpad but all devices when using the with GridPie
edit3
this is the output of the console
Warning: voice manager received a process without a configuration userdata: 0x0xfaa5778 (BrowserProcess object)
*** std::logic_error: 'can not assign an alias to itself.'
*** stack traceback:
*** [C]: ?
*** [C]: in function '__newindex'
*** [string "do..."]:22: in function <[string "do..."]:9>
*** ./Duplex/Applications/GridPie.lua:602: in function 'alias_slot'
*** ./Duplex/Applications/GridPie.lua:1873: in function '_toggle_slot'
*** ./Duplex/Applications/GridPie.lua:1732: in function 'toggler'
*** ./Duplex/Applications/GridPie.lua:2450: in function 'on_press'
*** ./Duplex/UIButton.lua:86: in function <./Duplex/UIButton.lua:74>
*** (tail call): ?
*** ./Duplex/MessageStream.lua:392: in function '_handle_or_pass'
*** ./Duplex/MessageStream.lua:187: in function '_process_button_message'
*** ./Duplex/MessageStream.lua:136: in function '?'
*** ./Duplex/MessageStream.lua:146: in function 'input_message'
*** ./Duplex/Device.lua:582: in function '_send_message'
*** ./Duplex/MidiDevice.lua:612: in function 'build_message'
*** ./Duplex/MidiDevice.lua:555: in function <./Duplex/MidiDevice.lua:202>
FINAL EDIT
installing jack1, removing jack2 and jack2-dbus fixed the problem reliably
@danoise Were you ever able to take a look at the bug @batcat mentioned above? I’m also really excited to use Grid Pie to jam out some basic arrangements, but this issue makes it impossible, unfortunately.
@Borodin I didn’t - I’ve become a father and haven’t really got any time for maintaining this tool any more.
Like @batcat mentioned, the Grid Pie tool is mostly working fine but the session recording has some issues.And the session recording unfortunately is going to, well, most likely remain broken. It’s a half-baked solution I came up with, and is also part of my motivation to invest time into the xStream tool - written from scratch with live recording in mind.
It would be lovely if xStream could be bridged with Duplex (visual feedback and MIDI handling via Duplex, everything else handled by xStream). That, to me, would be a very flexible and open way of doing things, best of both worlds and all that
