I leave ‘Track Selection Follows Event Selection’ on by default, as I prefer the workflow, of seeing the channel(s) of the events I have selected… but,
There are certain issues, like when ‘Cut’ events across multiple tracks is used, to say, cut to a new track version across all tracks… it selects the first track in the selection instead of retaining the multi-selected tracks:
If this behaviour can’t change because there are certain engineers who need it to behave this way, then giving us a separate on/off command for the preference instead of a toggle to add into our macros/PLE scripts would suffice.
But also, this behaviour can be annoying even without Macros/PLEs, just editing normally in the DAW.
I don’t get what your saying, nor make out what is happening in your video. Don’t you assign a key to the Key Command to activate/deactivate the pref Edit>Track Selection Follows Event Selection
No I do not see the details you speak of in your 4 second video, where the menu covers most of the screen and which is cluttered with many objects.
Have some consideration for others who might not have your visual perspicacity and create explicit and specific repro sequences in text that others can try to reveal the exact thing you are talking about.
It goes from 3 tracks being selected, to 1 track being selected.
Have multiple events selected across multiple tracks which are also selected with ‘Track Selection Follows Event Selection’ on, ‘Cut’ the events. Now only 1 track is selected.
This hinders for example, creating a New TrackVersion after the cut, to paste the ‘Cut’ on the new trackversion across the multiple tracks.
@awesomeaudio, to me this is the expected behaviour, since after cutting there are no events in the two tracks that should be followed. Cubase most probably just keeps one track selected, the one registered as the very first one.
A solution:
Create a PLE for appending a key to the names of the selected tracks, in the example here, I chose the key [Selected].
As you can see, I’ve placed in its Pre-Process section, the very first PLE which adds the key, and then the Cut command. In its Post-Process section, I’ve added the PLE for restoring their names to the original ones (the ones before appending the key).
@m.c This is actually already what I do, but was just in the process of converting my old Macro systems into the new PLE amenities and was trying to reduce, simplify and condense the amount of script/macro daisy chaining. Plus, the PLE can only do 4 pre/post commands each.
But also, I think this protocol behaviour is questionable just in general, even without PLE/Macro.
The user is doing an action across multiple tracks - and there are a series of other actions that user might want to continue doing across those multiple tracks after the initial action (TrackVersion manipulation, locating next events, etc)
imo, if a multi-track selection action takes place, the selection should remain multi-track… just as it would if ‘Track Selection Follows Event Selection’ were off. Unless there is a reason for it to be this way that people need.
Essentially, with this mode on, if ‘Cut’ events across multiple tracks, it should read this as a “invisible” selection in clipboard expecting that the user might continue to do actions with those cut events on that multi-track selection.
Then please note this next time. No reason for me (or others) to spend time posting “solutions” if you already have a working solution.
A setting should be respected. In the case discussed, we just have a binary state. Do we have any events/parts selected? If yes, highlight the tracks. If no, just highlight the registered track selected. If exceptions begin to emerge, we’ll run into spaghetti coding. From one side it will be Steinberg altering the code, and from the other side, many users out there having to edit their PLEs based on the new direction. And trust me, there will be many complaints in this case.
I’m not sure it would make a difference to peoples PLE scripts if the behaviour changed, certainly out of the 2000 or so I’ve created I can’t think of any where I’m wanting a multi-track selection to be reduced to one track.
But imo, the predominant and most encountered situation should win the behaviour change - TrackVersions being the best example… TrackVersions is something you want at the core to have attached to other core functions of the program - like cutting events across multiple tracks, creating a NewVersion across those multiple tracks, and pasting.
For example, creating a NewVersion, does not deselect tracks.
Deleting events also causes this, which then negates all sorts of track-selection-based-event-selection commands like ‘Select Events Under Cursor’.
To, me, it makes much more sense for Cutting and Deleting to cause Track Selection hold… to allow for all sorts continued of multi-track functionality after the fact. If the user does want to go to single track/top track selection, all they need to do is hit ‘Select None’.
