The obvious fallout from this is any PLE that makes use of targetting a specifically named track (to be selected / affected somehow).
The result is that if you previously clicked to highlight any track in the Visibility Zone it will also be affected by that PLE (which is targetting a specific track name).
Example:
I have a PLE to record arm only a track named “Guitar1”
I previously highlighted a track named “Drums” in the Visibility Zone while I was using it before
Executing the above PLE now arms both “Guitar1” and “Drums” tracks
Can we see from a developer viewpoint how this is not good?
In my attempt to simplify the actual real world, layered, PLE I am using, I conceptualized a bad example which is not even true, so please ignore that. The issue is more to do with DE/SELECTION of invisible tracks. From this alone, downstream problems can eventuate. So let me explain it in a better way.
Fact:
Any track that is highlighted in the Visilibty Zone but which is hidden from the project window has no container or property type that can be applied to Deselect it.
Consider these 3 scenarios (ignore the PLE preset name):
Result: PLE will select only ‘Guitar1’ track – Great, this is what we always want.
In my case, I was using a layered PLE with pre- and post- commands that depend on the above scenarios but becomes inconsistent due to the results of Scenario 2 & 3 above.
Note the issue is not relevant to when tracks are selected by manually clicking on a track (visible or not) - as then the selection changes in both the track in project window and the Visibility Zone, doesn’t matter if that track is visible or not.
