Hi!
Right now when I change the order of states inside a rack or when I change the program numbers of rack states, the parent song(s) keep their rack state target, but when I rename a rack state, the parent song(s) loose that target. So the parent song looks for the name of the state I think.
Is it possible to add some unique ID (and remember that ID instead of the name) to (rack-)states so I can rename/rearrange/re-number them without loosing focus?
Greetings, Tom
I can see that this could really be an issue. Not encountered it yet but a perfectly foreseeable situation.
I guess one reason why it may have been done this way is to allow “template” songs to be set up, with named rack states that can be used with different racks. Similarly with routes referencing their targets by name. I can imagine a situation where you have two “equivalent” racks with states like “Piano”, “Strings” etc., but using different plugins (maybe for use on different spec machines), so you can use one rack as a drop-in replacement for another - the states are more loosely coupled. It’s a bit of an unusual example though. I’d be interested to hear @brad’s input on the thinking behind the use of names rather than unique IDs.
I quite like the way if something points to something that no longer exists (route target, rack state of whatever), it still has a name so you can fix it accordingly. If it were entirely ID driven, and an ID wasn’t recognised (e.g. a rack state was copied and the original deleted), it would be left dangling with no clear way to determine what it used to point to.
One possible solution to the renaming thing, without requiring a complete change of data model in Cantabile, would be for Rename to offer to scan songs and rename all references. Similarly for things like rack output ports, where if you rename one, suddenly all songs using that rack will be broken.
Neil
I just fell foul of this…
I have a rack which was called “ME80 1”, and in various song states I send different controller values to it using a binding, to set glide rate on the ME80 synth plugin in the rack. I got it all set up nicely, and then thought, “Why is it called ME80 1?” so I renamed it to “ME80”, and consequently the binding stopped working, since it was targeting “ME80 1” - it was designated “Invalid Binding” in all song states. So I had to go through every song state, selecting “ME80” as the binding target.
A bit irritating, but more problematic was that all the actual binding target controller values had been reset to zero for each song state, so I had to put those back in from memory. It still had the control change numbers, but not the values. Maybe this is a bug, @brad?
Neil
Hi @Neil_Durant,
Thanks for the insight. Probably not so much a bug as a bad design decision. The bindings reset their mapping values when anything incompatible on each side of the source/target equation changes. You make a good point though - these should be preserved in this situation.
I’ll check out both issues.
Brad