I often find myself deleting a rack/plugin from a song, in order to replace it with some other similar rack/plugin, but when I do that, any routes to the original rack/plugin get deleted. This is really irritating if the route had carefully tweaked keyboard zone, velocity curve or MIDI filter settings.
I know there’s "Use Different Rack"on the rack context menu, but for some reason I find it hard to get into the habit of using it. And there appears to be no equivalent for plugins, so no way to drop an alternative plugin into an existing routing. I usually end up undoing the delete, copying the route, deleting again and pasting the route back.
I understand that deleting a rack/plugin will leave a route “dangling” with no target, but it would feel to me more polite to leave the route in an error state, flagged accordingly in the UI, so that the user can delete it if they want, or hook it up to some other rack/plugin if preferred.
It doesn’t make sense to replace a media player so for this approach just the ability to replace a plugin would cover it.
I’m leaning towards including an option to delete and keep the routes though. I agree with @Neil_Durant - delete and re-insert feels conceptually simpler than a replace operation.
I agree with Neil as well. I find myself doing the same thing: deleting a plugin to try another one, intending to use the same route. As long as care is taken so that any “dangling” routes that are accidentally left do not cause any problems in performance…
In fact, thinking about it, if you delete a route, it currently doesn’t delete the rack/plugin it’s pointing at. So there’s some inconsistency there. I’m not sure about the assumptions Cantabile is making about the user’s intentions, to make these two cases behave differently.
My preference would be that when you delete something, it deletes just that, by default, without any side effects. Same when deleting a plugin when there’s a binding to it. Then if another type of delete is added, it would be something like “Delete with routes/bindings” or similar, as a more exotic special case.
New command “Delete (Keep Connections)” is bound to Shift+Delete - it deletes the object and keeps all associated routes, triggers and bindings. There’s no menu command for it so it’s keyboard only.
I’ve also fixed deleting an object not deleting associated triggers (which was inconsistent) and I’ve fixed renaming objects (and routes) so that associated bindings are updated (which was a bug).
The reason deleting a route doesn’t delete the target object is because you might have multiple routes connected to it.
(btw: I realize Shift+Delete is an old old Windows shortcut for Cut, but I don’t think anyone uses it any more).
That would work but then you’d need to use shift delete in other places too (eg: set list). What I could do is also map the new delete command in those other contexts too which would make that work better. I’ll look at it tomorrow.
Hey @Neil_Durant - build 3176 supported the DeleteKeepConnections command in other panels now so you should be able to remap the delete key and have it work everywhere.
Actually, just revisiting this, I notice that the default behaviour of deleting the route when deleting a plugin is actually quite dangerous. If I have a “multi-purpose” route, that routes to different plugins/racks for different song states (i.e. state behaviour target object is enabled), if I delete one of the plugins/racks that the route targets in a particular state, the whole route is deleted, thus breaking routing to other plugins/racks on all other song states, and potentially lots of carefully programmed routing/filtering and so on.
I would argue that in this case, where the route’s target is state-dependent, the route should be kept, but with the target left unconnected in that state, regardless of which variety of delete is used.
Lucky for me that Cantabile has undo, otherwise I would have lost quite a lot of work just now
