UX of insert-at-selected-notes logic fails with certain use-cases

[Levitanus]

https://youtu.be/o-qEtGtmU5o

Still, I cannot provide information on how make it appear and how to reset to normal state. Will comment on investigation. Reaper 5.984 Reaticulate 0.3.92 xubuntu 19.04 JS_Rescript extension is installed

[Levitanus]

Ahh, got! it's because of selected notes in midi-editor. So, I suppose, it's not a bug, but the feature. But still, I think there is point of discussion: considering real-time playing it's common to put articulation after the fished fragment and continue playing on the new one. But with such mechanic there is possibility to produce a lot of mouse-clicking on the straight road, and user's misunderstanding of situation like my case. Can not make a suggestion of the best use-case now.

[Levitanus]

Also, if selected note affects articulation changing position, maybe there is a point to enhance current mechanic:

[Levitanus]

I think, now I see possibility to divide these requests:

1. If shift+click\right-click made in context of the arrange view - place articulation at cursor position
2. think on proposal of enhancing put articulation on the selected note described above

[jtackaberry]

Is it safe to say the use-case you're talking about is when step recording? When you step input notes it automatically selects them, which triggers this new behavior. But in that case I definitely see your point that the old behaviour if inserting articulations at the edit cursor is preferable.

Or were you doing something other than step-input?

[jtackaberry]

If shift+click\right-click made in context of the arrange view - place articulation at cursor position

Yes I think this makes sense too. I'll play with this implementation, so that the insert-at-selected-notes logic is only used when the MIDI editor has focus rather than the arrange view.

Like you, I'll need to think more about how to handle the step-record case when the MIDI editor is focused.

[Levitanus]

Pity, but I haven't tested with the step-input. Can try, but this behaviour is for just normal mode now.

Old part has been edited, then i set cursor to the new position, adding the articulation. Now, know how it works i make additional "lasso movement' on the clean area of midi-editor for unselect everything. It can be made like habit, but still some times I forgot to do this. Not very big deal with knowledge, but big - without))

[jtackaberry]

The insert-at-selected-notes logic is quite new. It's something I've been wanting to do for a while, and was prompted again on the Reaper forum, but I can see it probably requires a bit more attention.

Now that I play with an implementation that only uses the new logic when the MIDI editor is focused, I'm not sure I like it, because when you have lots of windows open across multiple monitors, sometimes the actual focused window is different than what you think it is, which leads to unexpected behavior. And that's even when you understand what the logic is.

I hate the idea of introducing a mouse modifier to adjust the behaviour because that isn't compatible with all the various Reaper actions to insert articulations which users may activate from control surfaces.

So all this needs a bit more consideration I think. Because I want to get 0.4.0 out the door today, I'm going to make the option configurable in Reaticulate's settings. Then you can disable it to get the 0.3.x behavior.

[jtackaberry]

I hate the idea of introducing a mouse modifier to adjust the behaviour because that isn't compatible with all the various Reaper actions to insert articulations which users may activate from control surfaces.

Ultimately I decided that perfect is the enemy of good, so I went ahead with a keyboard modifier anyway.

So now in the latest prerelease (just dropped), holding alt while clicking an articulation button in any manner that inserts the articulation (i.e. double clicking, long-pressing, or right-clicking) will always insert at the edit cursor, even when notes are selected in the MIDI editor.

[jtackaberry]

Released in 0.5.0-pre1 and I think this is probably a good enough workaround to consider the issue closed. Please reopen with arguments if you disagree. :)