For the love of llamas, pleas unlink visibility and selection!

[James HE]

Using the Media item lane in the MIDI editor in Automatic mode is such a breeze to work with. I use a lot of custom actions in the MIDI editor which require only the item I am editing to be selected in the arrange. (splitting, glue, take switching, etc...) So the automatic mode is the best option for me.

However, I would still prefer to see all the other item notes of the track I'm editing to be faintly drawn in the editor. - and to be able to click on them to switch the item and selection.

***edit**

uncheck "Media Item selection mirrors arrange view"
When you open all track MIDI, only one item is selected, and you can switch with a double click of a translucent event - however selection does not follow, like it did in 4.4. Also, if you then click on anything in the track list or media lanes, the drawn inactive notes disappear.



Basically, this is how it used to work. There is no working method in this cycle to actually have it work like it did before regarding the edibility of the item, and item selection. (and still see all the notes in the track)

Backward compatibility should also pertain to methodology, no?

[James HE]

Something like this....
(note the eyes next to the media lane track names.


if the eye is selected and half filled, non selected items on that track are faintly drawn, if not they are not drawn at all. If you click the name to select all the items, the eye would be full.

not sure how it would be indicated in the track list.

Just an idea....

[James HE]

working through this..

Am i just missing something? can we not simply have a mode that gives the old behavior?

Old selection / visibility behavior



New selection (un-mirrored) behavior. (Mirrored does change selection when clicking on items in the media lane - it would be nice to still see the inactive notes there! )

There is a somewhat odd behavior here in that clicking on something in the lane (or track list) gets rid of the faintly drawn notes. (Automatic Mode)



I would love love to have the old behavior of switching selection, but still seeing the unselected items notes - with the media lane.



Either way, this is all certainly workable, and these are great improvements.

[jnif]

Just had a quick look at your problem.
I think it would be solved if we had an option to link arrange view selection to editability (not to visibility). Is that correct?

Option to link arrange view selection to editability has been requested a lot already. I really hope it will be implemented.

jnif

[James HE]

Originally Posted by jnif

Just had a quick look at your problem.
I think it would be solved if we had an option to link arrange view selection to editability (not to visibility). Is that correct?



jnif

Yes, that a clear way to put it. Link selection to editability in automatic / mirrored mode, not visibility.

Automatic / Mirrored mode links editability and selection and visibility

Automatic unmirrored links editability and visibility

Manual mode / Mirrored actually does link editability and selection, but not visibility, however it takes a click on the "target" then another click on the item name just to completely unselect something. way too many clicks...

[James HE]

For clarity here, this type of custom action is why this is important (to me at least)

using the "passthrough" from the ME, you can do all sorts of useful item / track based actions. If I'm working in the ME, I can switch takes, mute, solo, arm tracks, cut, copy, anything - without even having to switch to the arrange.

This is just how to to glue an item - usefull when you want to make a looped segment discrete measures for editing.... I use this one ALL the time when arranging. The current pre cycle selection behavior turns this seamless process into a fiddly one.

[jnif]

After putting some more thought into this I think there is at least two different issues.

First is the problem related to arrange view selection mirroring. I think option to link arrange view selection to editability would help.

Second issues is related to intelligence in automatically setting proper visibility/editability states for track when user changes active item by clicking items in Media item lane or in Track list.

Here is my analysis of the current behavior and change proposal:

States of activation target before clicking Item
Case | Track                | Item
-----|----------------------|--------------------
 #1  | Visible   Editable   | Visible   Editable
 #2  | Visible   Uneditable | Visible   Uneditable
 #3  | Visible   Half-E     | Visible   Editable
 #4  | Visible   Half-E     | Visible   Uneditable
 #5  | Invisible Uneditable | Invisible Uneditable
 #6  | Half-V    Half-E     | Visible   Editable
 #7  | Half-V    Half-E     | Visible   Uneditable
 #8  | Half-V    Half-E     | Invisible Uneditable

States of activation target after clicking Item 
Case | Track                | Item              
-----|----------------------|-------------------
 #1  | Visible   Editable   | Visible   Editable
 #2  | Visible   Half-E     | Visible   Editable
 #3  | Visible   Half-E     | Visible   Editable
 #4  | Visible   Half-E     | Visible   Editable
 #5  | Half-V    Half-E     | Visible   Editable
 #6  | Half-V    Half-E     | Visible   Editable
 #7  | Half-V    Half-E     | Visible   Editable
 #8  | Half-V    Half-E     | Visible   Editable

Behavior changes needed in automatic mode
Case | Requested change
-----|---------------------------
 #1  | OK
 #2  | Target track's editability should be inherited from source track
 #3  | OK
 #4  | OK
 #5  | Traget track's editability and visibility should be inherited from source track
 #6  | OK
 #7  | OK
 #8  | OK

Target means the track/item where the active item is going to be after user has made the activation click. Source means the track/item where the active item is before the click.

Does this make sense?
Are there other meaningful cases that I missed in the case list?

jnif

[jnif]

LICEcap examples of the bad behaviors:

'Harp' track is the "source track".
'Strings' track is the "target track".

Case #2:

After clicking the middle blue item, all items on 'Strings' track should become automatically editable because all items on source track were editable.

Case #5:

A) After clicking the middle blue item at time 0:12, all items on 'Strings' track should become automatically visible and editable because all items on source track were visible and editable.
B) After clicking the middle blue item at time 0:30, all items on 'Strings' track should become automatically visible because all items on source track were visible. Editability state behavior is OK.

jnif