New Tool (2.8) Duplex: Grid Pie


(a773) #81

First a few terms, to make sure I understand them correctly, everything is with launchpad and gridpie in the duplex version:

Slot: A single in-grid button on the launchpad (one of the 8x8 buttons on the main matrix)
Matrix Block: (Renoise term for what (when using gridpie) corresponds to a clip in Ableton Live): A container in renoise matrix editor, contains data for one track in one pattern.
Control-map: ? maybe a duplex definition of the layout of a specific controller, for instance a launchpad??
Recombination track: ?
Expansion of recombination track: ?

In the current version, pressing/holding a single slot copies the corresponding pattern through all tracks to GRID_PIE pattern immediately. This feature is going away in new version?
Not sure what align with grid means, could you elaborate?

Except for the recombination stuff, that I don’t know what is, it makes perfectly sense!

So if I have loop-patten on in renoise (either by selecting it in renoise or by pressing user 2 on launchpad) gridpie is in old jam-but-dont-record-session-mode, and when loop-pattern is off in renoise, the session is recorded. This should be used to “capture” a jam on the launchpad in regular renoise patterns. Q: Are these “caputures” placed in new patterns inserted after the GIRD_PIE pattern? Will there be a way to clear a session (besides deleting the corresponding patterns in renoise)?

So there will be a new button on launchpad that I press/hold to schedule matrix block(s). If this new button is not pressed the change will happen instantly (the current way of working in gridpie). Nice with the quantization options, are those global and defined in gridpies preferences?

Nice!

How does that differ from regular scheduling? Is multi scheduling similar to the trigger queue you can use in the pattern sequencer by shift-left-clicking the number/play buttons found to the left in matrix editor?

Not sure I would use that, but then again, it makes perfectly sense, so it might come in handy.

Is this the same as pressing all affecting slots (example pressing (1,1 is top/left, meaning “first row, first column”) 2,2 and 2,4 is the same as pressing 2,2, 2,3 and 2,4)? Will this also apply when in schedule mode?

Any plans to implement the hide-collapsed-tracks-in-renoise-on-launchpad feature?


(danoise) #82

Ah yeah, we need some more clarification. I basically copy-pasted the info from my developer notes :slight_smile:
Yes, throughout this, I’m referring to the Duplex version. The original Grid Pie tool is a separate project.
Duplex Grid Pie is running on a large slice of hardware, so nothing is Launchpad-specific.

By slot, I mean one of the Grid Pie slots.
By Matrix Block/Pattern-track, I mean a specific track in a specific pattern in Renoise
Control-map: yep, you got that right. It’s just a simple XML document describing the controller.
Recombination pattern/track: it’s the GRID PIE , where everything is recombined
Expanded recombination … : this is describing the process when you combine different pattern lengths, the result being the lowest common multiplier. E.g. a 16 line pattern combined with 48 lines is 48. 48 combined with 64 will yield a total of 192 lines.

Nope, it would just become the new default scheduling value == “instant”. Btw. a new version of Grid Pie will definitely not contain all these new features, it’s best if they are grown organically (as we can work with them and feel how they perform before adding new stuff).

In that context, just that we would the same amount of trigger buttons as we have patterns.

Oh, I forgot to add that one. Probably because it’s going to be a general Duplex feature, and not just a Grid-Pie specific one :slight_smile:

Btw: I’ll reply in more details later today, as I’m currently at work. Need food on the table.


(danoise) #83

Alright, I have digested your post…

I’m not entirely sure about this. Somehow I think it will be confusing to have a large amount of patterns appear, if you’re doing some minimalistic setup with only a few source patterns. On the other hand, it could be exciting to recombine those patterns…
However, I did mention another feature, the “poor mans” session recording that simply takes the current GRID PIE and add it to the sequence. Because such an action is triggered intentionally (by pressing a button), I believe those patterns should be inserted before the GRID PIE pattern, so you - for instance - could start with a few patterns and then create some nice variations which could be triggered as complete patterns.
Most importantly, both methods could co-exist peacefully :slight_smile:

Again, this might work or it might not. We can basically treat a button like something which should be held to obtain some specific feature (a “modifier” button), or we could implement it as a toggle-button. I guess the big question here is if we need this kind of choice at all? After all, we could simply have scheduling as a “global choice” which you could choose to enable or not.

Yes, they would be global in the sense that no extra information is embedded into the song. When you start Grid Pie, it would have the same options as when you left it.

Yep, that’s how I imagine it would work. Every type of scheduling (with the exception of “instant”) would be accompanied by blinking buttons to indicate that something has been scheduled.

It’s a bit of a crazy idea, I’m not sure how realistic it would be (the combined length could easily surpass the pattern limit of 512 lines).
But I think it’s interesting to see how many gestures that can be fitted into a simple grid controller while still keeping the whole thing simple. So if you have a better idea for something interesting which could be triggered by holding two buttons in the same track, go ahead :wink:

Oh, and thanks for the detailed feedback. I’m hoping to put down some work on one or two of these features next week, starting with edit-sync.


(danoise) #84

Here is a preview of the edit-synchronization feature
This is a funny one - inserting a note and seeing it pop up in a number of other places!


Here, Grid Pie is combining 3 patterns with different lengths (4, 8 and 12 lines) into a single pattern (total of 24 lines).
The edit-synchronization feature is then making it possible to edit them in real-time - or something close to realtime.

New features

  • Edit synchronization between grid pie and the song (“as real-time as possible”)
  • Highlighting the current pattern, if the controller supports it (see Launchpad)

The edit-synchronization means that any change to either:

  • The GRID PIE pattern
  • The actual source pattern-track
    … is copied & expanded, so that both are always synchronized (represent the same data)

Download the release here



(danoise) #85

Bump So the feature preview got released late last night (see prior post).
If you ask me, Grid Pie is now becoming really tasty.

Enjoy!!


(dby) #86

YES! :yeah:


(a773) #87

Uhmmmm. Looking forward to playing with this! You are wise to develop and release in steps, and you even have a clear roadmap. I’m sure gridpie in time will kill 'em all!


(danoise) #88

Well, things just never work out 100% like you expect, you either expand or reduce on the original idea.

In this case, I originally I imagined that we should have some way of toggling edit-sync, but it seems to work better when implemented transparently - simply being a part of the “Grid Pie package”.

Also, this “edit-sync” feature has actually provided some of foundation for continuously streaming output.
Just need to get the current bugs sorted out before we move on.


(dby) #89

Edit: Looks like this was caused by a wrong setting in my bcr2000 updater in BiduleVST, so I think you can ignore it. Seems to work fine now.

Getting an error message here:

[s]‘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…

std::runtime_error: ‘notifier feedback loop detected. do not change values you are listening to within your notifiers.’
stack traceback:
[C]: in function ‘copy_from’
.\Duplex/Applications/GridPie.lua:1622: in function <.\Duplex/Applications/GridPie.lua:1568>
[C]: in function ‘copy_from’
.\Duplex/Applications/GridPie.lua:1596: in function <.\Duplex/Applications/GridPie.lua:1568>[/s]


(danoise) #90

A plugin like Bidule shouldn’t be able to cause Grid Pie to throw an error, so somehow I think I was to blame for that one!!
Beta releases in general (and this preview release in particular) is experimental, so errors are to be expected.
Btw: I just added support for detecting changes to the source pattern-length. Another step closer to full synchronization


(dby) #91

Well I have some midiCCReset VST’s in a Bidule VST to remember and update last knob position of the BCR when loading a new song, and also the positions of my custom synced LFO’s(thanks dblue). After doing a user switch in Vista, I had to update and replace some VST in Bidule and I accidentally set them to synced. Which meant they spit out MIDI snapshots to the BCR and LFO’s continually. Works fine after I fixed it.


(danoise) #92

Ah, OK, so it was hitting the GRID PIE pattern hard with messages?

This IS relevant, I’m really aiming to have Grid Pie become as stable as possible.
It might hog your CPU when doing stuff like this, but it should never throw error messages at the user!


(danoise) #93

Working to put the final touch on some of the features which were previewed last week.
Some people have already tried out the new stuff - I just made sure that the whole thing feels more solid.

Edit: Download the beta here, release notes here


(danoise) #94

Well, I’m using this tool heavily these days, it’s awesome to explore it’s many possibilities.
I thought that I’d like to share some of my findings…

For example, I have discovered that a group track is a really nice way to set up independent modulation options for a track.
Because a group track will affect those tracks within it, sample commands are working as well. This means that you
can create a track containing a long sample, and then, in the group track, have a number of patterns containing these effects:


01 0B01 <- forwards
02
03
04


01 0B00 <- backwards
02
03
04


01 0B01 <- forwards
02
03 0B00 <- backwards
04


So you get the ability to control the playback direction, and “ping-pong” loop/freeze your sound whenever you please.
And of course, you could switch the sound at any time, as it’s contained in a separate track from the effect commands!!
The same approach could be applied to just about any other aspect of Renoise, as most things are possible to enter
either into the pattern or the automation editor. There’s really a lot of creative possibilities here.

Annoyances

But still, there is a couple of things that doesn’t really work well in the tool’s present state

  1. You can’t save the combinations that work well - you have to remember them
    This can be solved by taking a copy of the GRID PIE pattern, but then you loose the information about where the track originally came from

  2. When you are switching from a short combination into a long combination, everything needs to be re-calculated
    This is true, even if you are toggling on/off - the data is recreated each time, which takes a lot of CPU calculations

  3. Deleting/modifying large amounts of data in the GRID PIE pattern can take a long time to process
    Edit-sync is otherwise working smoothly, but this particular case, it could do with some extra sophistication.

Solution to (1): Pattern storage
I propose that the ability to copy/clone the GRID PIE pattern is expanded further.
Taking a snapshot of the current pattern could be done like now, but instead of just dumping the ‘raw data’ into a new
pattern, it should create a pattern which contain pattern-track aliases, pointing to where the source material came from.
Then, each time a pattern is saved in this manner, it’s easy to re-create the pattern using up-to-date pattern data
(technically, those patterns would somehow need to be identified by Grid Pie as being special)

The mute state (mixer mute state, not matrix mute state - Grid Pie only use the mixer state) is also applied to the slots
(as you can see, some of the stored patterns contain muted slots). This is a special arrangement that will ensure that
what you are storing as a pattern is the same you’ll hear when it’s being recalled. The saved matrix mute state will
simply be applied to the current mixer mute state when the pattern is recalled.

It should be noted that the patterns which are created obviously have a length, as the result of the clips within, and
this length could change at any time (as a result of resizing one of the clips). So, when the pattern is triggered, a
quick comparison is made, to see if the length is still the same, or if we need to recreate the pattern data.

Solution to (2): Cache management
The CPU usage in Grid Pie is for sure one of the tool’s weak points. It simply is quite heavy to calculate and output
all those data, so every technique that could avoid some of that work would be a boon to the tool.

Technically, Grid Pie works with a recombination pattern that contain the combined data of all the source pattern-tracks,
extended to the point where they all loop seamlessly. So, if we are talking about a pattern length of 160, 192 or
something even higher, some of the source patterns might be just 4 or 8 lines in length. But, here is the thing:
in Renoise, patterns maintain their data, even beyond the length (up to a maximum of 512 lines). So, if we copy the
the recombination pattern data into the respective source tracks each something has changed, we end up with
with a sort of pattern-cache that we can use for recreating patterns (technically speaking, it is a lot faster to perform
a raw copy of data from track to track, than to expand them line-by-line).

The tricky part about implementing this feature would be to come up with a reliable and fast way of detecting the
current length of each clip. Perhaps Grid Pie could build a table of these values to begin with, expanding each clip
to it’s maximum possible length (512 lines)?

Solution to (3): Delayed notifications, segmented monitoring
When we attach a line notifier to a pattern, we can monitor any kind of changes to the pattern data. This forms
the basis of the edit-sync feature. And it works great when you’re entering/editing single notes at a time, or
editing the source track itself. But, when dealing with the recombination track (where a single track could be
repeated many times), slowdowns can occur - technically, a “quick copy” back to the source is performed for
each and every change, and this can happen dozens or, in some cases, even hundreds of times.

The solution is to introduce an extra level of delay in the line notifier, which will collect those changes and
perform a delayed copy. It would really not be that hard to make, the basics are already in place.


(petervh) #95

I’ve been really enjoying Gridpie lately. I think it is, currently, the most useful of the “live” tools.

Many thanks for all the hard work, Conner & Danoise.

One feature I would love to see in the future, is an option that allows a selected pattern to be delayed until the next pattern starts/pattern loops again. I imagine this is already on your to-do list, though (it’s a long thread to read!).


(a773) #96

Hey.

Finally checking the new beta out, not sure I appreciate the two rows spend on the step sequencer, but will play with it. To be honest I lost track of the threads concerning gridpie. Are the new features documented anywhere? As a side note found that the manual has moved to googledocs, is that the new location?

Either I’m totally thrown off by the new features, downloaded a wrong version (0.98b20) or there are some strange, strange things (bugs) going on here. Can’t even get clip launching going as in the previous version. But it might be I’m just brain dead :blink:


(danoise) #97

Thanks, that’s good to hear

Yes, it’s a long read, I have so many ideas for this tool :slight_smile:
Speaking of delayed pattern - this is the scheduling feature, and yes, it’s planned.

It’s no problem to make a “grid pie only” layout, if you don’t like the current one. Or we could simply have both?

Well, the only new features to arrive since we last talked are edit-sync and pattern highlighting.
Edit-sync is a no-brainer, it should simply make sure that everything is synchronized at all times. There are no configurable options, or anything related to that feature, it just copies modified notes back and forth.
And clip launching is working. I just checked :lol:

Yes, I used to host my own stuff, but lately I have been moved things to google docs or dropbox.


(danoise) #98

Good news - the next version of Grid Pie will be turbocharged, and we are talking a lot faster. The CPU usage has always been one of the major problems with this tool, and although the new approach is no silver bullet (you might still experience CPU spikes at certain times), it’s still a major improvement over the previous versions.

So, what is it all about? Remember the “pattern storage” that I have described in a previous post - I started working on that feature, and quickly realized that a side-effect of using aliases to reference matrix slots is, that you no longer have to copy content back and forth - that is, if you happen to have a “perfect” set of data that has created in advance, and maintained throughout. So I decided to work on a pattern cache system, and it’s already beginning to look promising. Still a lot of work left in order to make this thing stable (not to break stuff when patterns are resized, and tracks are added/deleted/swapped), but stay tuned for updates!

To be fair, I just fixed one which could cause the GRID PIE to have a wrong length. And, yes, there are obviously more bugs lurking.


(a773) #99

I just played a bit with it and a few things confused me, first my settings->gridpie->horizontal page was set to 3 for some reason. Secondly I have hard time getting to grips with row 1 and column 7/8.

I don’t really get the behavior of row 1 (track selector). First it shifts the track layout, which is quite confusing, I’d like to scroll by one “screen full” using launchpad buttons < and >. I guess the track selector is part of the step recording stuff. However, as it is now it seems only half baked, I have to select the instrument in renoise and the octave up/down and halfstep+/- is hard to keep track of (unless I missed something, which is entirely possible). I think a goal of gridpie should be to be able to do everything from the controller. And supposed I have a pattern with more than eight lines, column 7 (step sequencer) will only affect the first eight lines. I’m also having a hard time keeping track (:-)) of which track the step sequencer is currently operating on.

I’d much prefer:

  1. 8x8 for clip launch (mutes could be achieved my pressing an already active clip or an empty slot (the red ones)). Additional stuff like step sequencer could go in other “pages”, like it seems the launchpad works with ableton live. Actually the best way IMO would be to be able to assign different duplex applications to different “pages”, making the UI clean and easy to flip. If you want instant control of several applications, duplex should support more launchpads the pretty much should work in parallel. This way I could get 4 launchpads and launch clips on 8x32 or 32x8 or have gridpie on one, step sequencer on another and what-have-you on the last two.

  2. I hate to say this, but I think we’re gonna need a way to store info on a per-song basis. PadSynth does this (on an per-instrument basis) by writing a serialized array in the instrument name. Duplex could for instance use the song comment with a specially marked area to support regular comments. I know the user could accidentally mess this up outside of duplex, but until we get tools settings saved in the song, I think we can live with that. Per-song settings could include: (re)load duplex on this load, which duplex applications to run, which controllers they should use, + more. Actually to keep in line with the way renoise works, all settings could be moved to a per-song basis, with an added way of copying settings from songs on disk. The last thing I want is loading a song on stage and being put of by something global being changed, so my song will act funny “although it worked the last time I checked”.

I hope I’m making at least some degree of sense here :slight_smile:


(danoise) #100

Sounds like something has messed up your configuration. Grid Pie and TrackSelector should both be using “automatic (use available width)”, with Grid Pie set to follow track (read more about the paged navigation concept in the Duplex manual).
In short: if you mean for any two applications to navigate in the same way, you need them to use the same page size.

Have you tried assigning the same name to the track and instrument? Instant synchronization between the two :slight_smile:

Hey, easy, this is what configurations are for.
Simply save the following as “LaunchPad_GridPieFull.lua” in (Controllers/Launchpad/Configurations)

Click to view contents

–[[----------------------------------------------------------------------------
– Duplex.Launchpad
----------------------------------------------------------------------------]]–

– setup GridPie for the Launchpad

duplex_configurations:insert {

– configuration properties
name = “GridPieFull”,
pinned = true,

– device properties
device = {
class_name = “Launchpad”,
display_name = “Launchpad”,
device_port_in = “Launchpad”,
device_port_out = “Launchpad”,
control_map = “Controllers/Launchpad/Controlmaps/Launchpad.xml”,
thumbnail = “Controllers/Launchpad/Launchpad.bmp”,
protocol = DEVICE_MIDI_PROTOCOL,
},
applications = {
GridPie = {
mappings = {
grid = {
group_name = “Grid”,
},
v_prev = {
group_name = “Controls”,
index = 1,
},
v_next = {
group_name = “Controls”,
index = 2,
},
h_prev = {
group_name = “Controls”,
index = 3,
},
h_next = {
group_name = “Controls”,
index = 4,
},
},
options = {
follow_pos = 2
},
},
Navigator = {
mappings = {
blockpos = {
group_name = “Triggers”,
},
},
},
Transport = {
mappings = {
edit_mode = {
group_name = “Controls”,
index = 5,
},
start_playback = {
group_name = “Controls”,
index = 6,
},
loop_pattern = {
group_name = “Controls”,
index = 7,
},
follow_player = {
group_name= “Controls”,
index = 8,
},
},
options = {
pattern_play = 3,
},
},
}
}

As for switching pages, this is what the SwitchConfiguration application does. But it wouldn’t work with Grid Pie, as the application is stopped when we switch away from it. To truly get the feature you’re requesting, we would need something I call “states”, which would accommodate controllers with many virtual pages, as well as hardware with “modifier keys” which change the message being sent from the hardware on-the-fly. This “states” feature is really something which is planned for the long term.

It already does. it’s basically a question of taking a copy of the Controllers/Launchpad folder and editing the device display-name. The process is documented in the Duplex manual

The new version of Grid Pie makes use a of a caching system which could benefit from such a thing. So we’re about to get the functionality you request, but to begin with, you wouldn’t really notice it at all.