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
-
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
-
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
-
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.
