Quote:
Originally Posted by Puck
What I mean is this:
While banking through your project and you get to the last track, you can actually keep on banking past that for as long as you like. There should be some logic there that tells Realearn that you no longer need to bank. Let’s say you bank 6 times past the last track, you now need to bank in the opposite direction 6 times to be where you were before you went past the last track. We shouldn’t be able to do that, Realearn should stop us 
Is that more clear than “off the edge of the project into a pit of despair”?
Sorry again for being vague and using weird phrases! |
Longer answer, sorry.
It's actually what I thought, thanks for clarifying. Technically that's not a bug, but I get what you mean.
There's not the one approach to implement "track banking" in ReaLearn. There are actually 3 of them! You happen to use one which lets you keep banking past the actual number of tracks
With your way, you don't actually control a track bank. You control a parameter value.
Here are the 3 approaches of implementing track banking (which I'm aware of):
a) Following a parameter value
b) Following the currently selected track
c) Following the instance track
a) Following a parameter value
This is the approach which you use. You let some buttons/encoders/... change a parameter value (e.g. a parameter called "track bank"). Then you derive the currently controlled tracks from that value (by using dynamic track expressions which use that parameter, e.g. "p[0] + 0", "p[1]", etc.). The parameter's configured value count (= number of possible values) is constant and it's not limited by the number of tracks in your project, in fact it doesn't know anything about tracks, it's just a parameter. ReaLearn is deliberately neutral. It doesn't magically presume that it has any relation to the number of tracks ... because you could use that parameter for anything.
Here's some pro/contra if you use this technique for track banking:
(+) You can easily control the bank from automation envelopes, other instances or scripts.
(+) You can influence not just tracks by this but also let it guide other things at the same time (e.g. activate/deactivate mappings by using conditional activation)
(+) You can easily define multiple track bank parameters (e.g. let one portion of your controller work on tracks 8-16 and another one on tracks 64-72). Even within just one ReaLearn instance.
(-) You can exceed the number of tracks.
b) Following the currently selected track
With this approach, you let some buttons/encoders/... change the currently selected track. Then you derive the currently controlled tracks from that (by using dynamic track expressions with "selected_track_index + 0", "selected_track_index + 1", etc.).
Pro/contra:
(+) You can't exceed the number of tracks (because you can't select a track which doesn't exist).
(+) Track selection by definition follows track banking.
(-) Track selection by definition follows track banking
It might also be a disadvantage, depending on what you desire.
c) Following the instance track
You let some buttons/encoders/... change the instance track of a ReaLearn instance. Then you derive the currently controlled track from that (by using a dynamic track expression with "instance_track_index + 0", "instance_track_index + 1", etc.).
Pro/contra:
(+) You can't exceed the number of tracks (at least if you get the dynamic because an instance track ).
(+) You can use different banking in different ReaLearn instances (e.g. let one controller work on tracks 8-16 and another one on tracks 64-72).
(-) I haven't really built a preset for that yet because it's one of the newer features, so I'm not 100% sure if a puzzle piece is yet missing to make this the perfect track banking approach.
So ... there are many options. The choice is yours.
The
Lua script which produces the DAW control preset defaults to approach (a) but can be configured to use (b). It doesn't support (c) yet, but it's something I want to add eventually. (c) can already be done in ReaLearn, I just didn't have the time to create a decent preset using this approach.
I could in theory add some features to make "exceeding the number of tracks" impossible with (a) as well:
- Make a "track_count" variable available in dynamic track expressions, so you can limit things yourself ... but I think that wouldn't really help because it would not prevent the parameter value from increasing more and more. However, might still be a good idea to add it, also for approach (c).
- Make it possible to define a "max value expression" for a parameter. And then you could enter "track_count - 1" (or "(track_count - 1)/ 8" if the parameter stands for a bank of 8 tracks) and ReaLearn would make sure at all times that it never exceeds that maximum. Not sure yet if this is a good idea.
Threaded Mode