Ah, now I think I understand you - you want to copy, not the patterns but the pattern-tracks (a.k.a. matrix slots) ? This is of course possible.
Similar recording features have already been discussed in this topic’s previous page (hello dby!!).
I think I would settle for an approach which copies any modification in the GRID PIE pattern to the originating slots, and vice versa (bi-directionally).
Edit: Sharing my development roadmap for all the major features that could arrive within the next few versions:
== Streaming output ==
Splitting the output into smaller chunks means that Grid Pie could avoid those dangerous CPU spikes
So, depending on the song’s tempo, notes & automation data output is being written to the pattern just prior to being played.
== Scheduling ==
Because the pattern is being written prior to being played, we are able to support pattern scheduling
(this feature depend on streaming output to be implemented first)
== Multiple-slot scheduling ==
Just like how you can schedule multiple patterns in Renoise, this feature will enable you to
schedule slots: on a grid controller, simply press two buttons in the same row, and any slots in
between will become scheduled
(this feature depend on scheduling to be implemented first)
–
PS: I moved the posts which dealt with Grid Pie into this thread
I thought I suggested this before, but it seems not:
When working with a lot of tracks it would be nice to not have all of them exposed on gridpie. Suppose I build a beat in six tracks, each with individual effects, and I’d like to have only the entire beat displayed on gridpie. I could put them in a group, and use that, but an option to “not display sub tracks of groups in gridpie” would be awesome. That way I could easily choose how much detail I want to control in gidpad, and keep clutter (= confusion, something I don’t like on stage) out of the way…
Does it make sense?
And apologies if I already suggested, but I just couldn’t remember or find it…
I just now discovered GridPie, after overlooking it for a few months. It seems pretty amazing, and I’m excited to see what features appear in its future versions.
I wrote a similar sequencer for the Monome myself, called Phrases, in another programming language; it was just an informal project. I’m glad to see better programmers than myself exploring this sort of sequencer! In fact, I will probably switch over to using GridPie for my own music eventually. However, there is a useful yet not-necessarily-obvious feature I stumbled upon, which I think you might want to consider. I hope it’s alright if I make the suggestion right now, even though I’ve just started toying around with GridPie itself.
You may want to add an optional queue system for keystrokes, so that button presses will only be processed when the timeline hits a multiple of the LPB, or some other user-defined number. This would allow the user to trigger many tracks simultaneously without having to time them all on an exact beat. Quite useful if, for example, you can only have your hands on the controller some of the time, or if you’re working with a very fast tempo or meticulous tracks.
Yes, this is what is I refer to as scheduling. I imagine that it would be simple to use, and allow one slot in each track to become scheduled for a specific point in time.
The actual point could be determined by the recombination-pattern’s length*, or set to a fixed number of beats.
To keep things simple (avoid “modifier” buttons) I also have suggested that multiple-slot scheduling is the result of pressing two buttons in the same track - automatically schedule those slots, and the slots between them.
But I guess a “multiple-slot” modifier button could be added too, so we are able to add any slot to our schedule, and not just those that happen to be situated next to each other.
I would like to think of those as two approaches to the same thing - “press two buttons to schedule the range” is a convenient way to achieve something useful, and one’s song and workflow could easily be adapted to make good use of this.
The other approach, “press the modifier button first, then the buttons you want to schedule” is more flexible, but less ergonomic (since it’s a two hand operation).
(*) The recombination pattern’s length is determined by the “least common multiplier”, which basically means that if you combine 48 and 64, you end up with 192 lines. Obviously, we need some kind of provision for when this length is higher than the maximum possible size (512 lines), I’m not entirely sure how to deal with this.
So, we are talking about saving horizontal (track) space by hiding grouped tracks, exposing only the group itself on the controller, but allowing any changes to this group to affect the tracks contained within the group?
This should be optional, I guess, but how about multiple nested groups - should they be hidden or exposed? For example, we could make the option cover a variable depth (0 = disabled/no depth, 1 = one level, etc.)
Well my objective is not so much saving space as avoiding clutter. I don’t want to think about “my drum track is composed of a bd, sd, clap, hh, oh, shaker and cabassa” or “this atmosphere is made up of a long strange sample, a bell sound and three pads” when I know beforehand, that I only want to work with the atmosphere as one thing on stage.
Gridpie at its current version exposes both the sub tracks and the group (only mute in the group though). So I guess a part of the deal if someone choose to expose only the group, is that each track within the group plays/are scheduled/launched at the same pattern number in a linked fashion, like they were columns in a track. When/if the bi-directional copy source clip/GRID_PIE pattern is implemented, things should obviously be copied bi-directionally if I change something in the subtracks.
Hmmm, nested groups… Variable depth would make sense. I honestly haven’t thought about that, maybe because I rarely put groups in groups.
NB: This whole thing could be solved by some other means, like having the user select exactly which tracks should be visible in gridpie. But I just though that handling this with groups would be more elegant, logical, user-friendly and take advantage of something already in renoise and thus familiar to the user…
Exact mapping of each track would require a place to store those connections. And we can’t save data in a song as such - any possible solution I can think of would be a bit of a hack.
As you are saying, it’s better if this could somehow be translated to something which is easily accessible from Renoise.
Here’s an idea: we have the shortcut for expanding and contracting (SHIFT-CTRL-j), which will take a group track and toggle it’s display state (same thing as clicking the tiny arrow to the left in each track’s label)
If Grid Pie listened to this we could detect when the entire group was fully collapsed, that is to say, with no visible tracks at all (I just checked and it all seems possible with the Renoise API).
Once we know that a group is fully collapsed, we change the way we interact with it into the mode that you suggest - with changes affecting each hidden sub-track within the group.
Expand/contract comes with a standard keyboard shortcut, and, as a sort of bonus, you can also toggle into compact viewing mode, in which only the selected track is displayed.
That sounds a little a-symmetrical to me. Fully collapsed groups will be exposed, but I can’t see the data inside the pattern (in the pattern editor), non-collapsed tracks will be exposed, but here I can see the data in the pattern.
But I understand what you’re trying to do; look for a simple, logical mapping from the gridpie works to the renoise world.
Well your solution is gonna save settings per-song, my suggestion (+ you initial suggestion, regarding depth) is global.
The way I would use this would be the same for all songs, so I would prefer a global setting. But actually all these options could peacefully co-exist with the right settings. Then the user could decide if and how he wants to handle the too-many-tracks-visible-on-my-launchpad-problem…
I think the idea of having it work on expanded tracks, while skipping over collapsed ones, makes good sense.
If you want your drum break, or section of it, to be worked together you would put them in the same group and then collapse the individual tracks keeping the group expanded. You can even see sub-tracks open, so fill could be brought in and out or the whole controlled.
With an 8 note width melody track you could still have screen real estate by putting it in its own group track and collapsing it.
Seems quite elegant to me but not yet received my controller that really lets me try it out.
I think I understand your point. For example, when I suggest that we implement a special case for fully collapsed group tracks, this is a problem because you can’t see/edit the tracks contents in Renoise then?
Having the controller in sync with Renoise at all times, like I suggest, is obviously both an advantage and a drawback, it depends on how you want to use it.
Can you describe your own creative process - what combination of features would be optimal for your particular workflow? I’m really trying to see the larger picture here…
–
Edit: speaking of pictures, here is an illustration to clarify how this expanded/contracted business could work:
I might want to edit something in renoise and not have it shown in gridpie. Remember we might end up with bi-directional in-sync-keeping between origin-clip-slots and the GRID_PIE pattern. So the user might want to edit a hidden sub-track in renoises pattern editor. She would then have to expand/collapse tracks until the correct track is identified (unless the user can actually remember which track she wants to edit by looking on the track names). Then edit, then collapse the edited track, for gridpie to look as before the edit.
Agree. And basically I also think your solution is more elegant, since it’s a mapping of something already familiar to the user (collapsing/expanding). However it’s not really optimal in other regards…
How about implementing either one of the “ways” or both, and we could play with them and see what works best? Which reminds me: do you accept patches?
Well I’m generally hoping to be able to have no distinction between composing and performing, a (high-level) few details:
My controllers (currently: launchpad, bcr2000, usb-keyboards) should map to a useful subset of high-level controls of renoise. A subset that should be easy to change on-the-fly.
It should be possible to do the most common performance and composition tasks (gridpie style lanching of “clips”, realtime/step recording, knob tweaking of effects) without touching and/or looking at the computer.
It should be possible to “record” a performance, so there’s a performance oriented way of coming from the building blocks to a fixed “arrangement”.
Does that make any sense?
Without trying to recreate Ableton Live (which I never tried), something like this youtube video could be nice. At 0:25 it seems like he’s recording the drums in real-time.
A nice thing here is that if you have more launchpads, and they could easily be switched between modes, you could change (at least part of) the “subset” I mentioned in 1) on-the-fly.
Regarding keeping launchpad/renoise in sync I have a question regarding the current version:
The “mixer” knob is mapped to follow, right? When I start grid-pie, the eight right most arrows on the launch-pad doesn’t show where in the pattern I am. So I press “mixer” and follow is on and the position is running. Pressing “mixer” agin turns follow off, but the light keep running. Any hidden logic here?
Also when follow is on and the renoise window is visible the lights get out of sync, possibly due to the high stress on the cpu (I’m also re-encoding a film while writing this)…
You have enabled pattern + track follow in Grid Pie? Because then, you are always looking at the source pattern, not the GRID PIE pattern.
However, the loop-block does only display the looped segment for the GRID PIE pattern, as it’s the one actually playing. A bit confusing, I know.
The eight buttons that you can use for looping is actually a different application called Navigator. I guess we could modify it, so it always display the loop-block, regardless of the pattern we are currently editing.
But right now, pressing buttons to change position and looping should still work, even without the visual feedback. And If you disable pattern-sync, so that the active pattern become the GRID PIE one, the buttons should display the correct range?
I was thinking that something like the “Single Track Edit Mode” feature would be really useful here? It really is a very useful feature in Renoise (another one I’m yet to make proper use of )
Basically, Duplex could map it to some button and then, you can use it to toggle between displaying the selected track, and the “normal” view (which can be any combination of partially, or fully expanded/collapsed content)
That makes (some) sense. Still if I enable follow mode, the launchpad loses sync with renoise on the eight arrows (as mentioned probably due to high cpu load as a result of too much updating on my 23" screen)
Could be, I never used Single Track Edit Mode (I think a great thing about a tracker is the ability to see events across multiple tracks in one window)…
With STEM on and selecting different tracks in renoise gridpie updates launchpad in a, to me, unpredictable way. Did you try that? Maybe more hidden (to me) logic…
If we stick to the above approach, “don’t show track in group” would be equivalent to collapsing the track. Then it is still playing, but not displayed on the controller.
The thing is, the illustration is showing groups that are collapsed, not tracks. If just one track (say, 1b) was collapsed, we would not enter the special collapsed mode.
So, if I understand you right, this is something which fit into the concept with no need for additional features.
I’ve spent some time writing specs, to try and get a good idea about which features that would be the most all-round useful.
This is not a final set of specs in any way, but it should give everyone a better idea about the actual implementation details (something to discuss)
–
Mapping: Pattern triggers
Same as pressing & holding a single slot (the mapping exist to accommodate devices with no support for release & hold events) - Align with grid (control-map group would need same height)
Feature: Edit-sync
Edit-synchronization means that any change to a GRID PIE pattern-track (such as manually transposing, deleting or editing notes) are automatically broadcast to the source pattern-track - Edit-sync works both ways: changes to the source pattern-track are also broadcast to the GRID PIE pattern-track - To begin with, edit-sync will affect notes only, and not include automation data - When an expanded recombination track (such as 16 lines expanded to 96 lines) is modified, the change is broadcast to each (16-line) segment within the (96 line) track. - This feature might be a CPU intensive task and could perhaps benefit from being implemented as a co-routine
Feature: Session-recording
Tied to “Loop pattern” in Renoise (disable pattern loop to enter the session recording mode) - Session recording is a “true” live performance mode, in the sense that you can concentrate on jamming while the song sequence is automatically being expanded (new patterns created on-the-fly), inspired by how the AutoClonePattern tool works - Just like now, we only need one recombination pattern and the maximum length of a Renoise pattern (512 lines) still applies. So no magic silver bullet in that regard. - Session recording will be complemented by the “schedule mode”, which allow a configurable delay before changes happen.
Mapping: Schedule mode
Scheduling can be mapped to a button, implemented as an option, or both. - While the “schedule” mode is active, slot changes are delayed by a configurable amount - (if quantization is aligned to the recombination pattern) expand into the pattern (current/next pattern, depending on whether pattern-loop is enabled or not)
Only changed tracks need to be expanded, any other tracks should be fine as they are
If the recombination pattern will have a different length as a result of the changed slot, a new pattern is created. Otherwise, the change is applied “within” the current recombination pattern - Mapping (quant_enable) - Options (Quantization):
Instant change
Wait for source pattern
Wait for recombination pattern
Wait for 1/2/3/4/5/6/7/8 beat(s)
Gesture: multi-schedule
Press two buttons in the same track at the same time to schedule the pattern-tracks in-between
Mapping: multi-schedule (atomic)
Introduces a new mapping, “multi_schedule”, implemented as a push-button - While holding the “multi” button, press one or more slots to schedule them
Mapping: Add to sequence
Introduces a new mapping, “add_to_seq”, implemented as a push-button - Inserts the current GRID PIE pattern into the pattern sequence (located at the end, just before the current GRID PIE pattern). Useful for creating a song structure on the fly, a cheap sort of alternative to the session-recording feature
Gesture: combine slots
Hold two buttons in the same track to combine the pattern-tracks inbetween (selected slots are lit)
