Pattern and Song Editors UX

[cme]

Hi all,

The Song Editor and Pattern Editors have been undergoing a bit of a usability overhaul, with the addition of selection, copy & paste, keyboard-based editing, multiple note property editing and so on.

These features are aimed at being as "discoverable" and following the natural behaviour a user would expect from experience with other software.

It would be really great to get some more user feedback from regular Hydrogen users, to work out rough edges and prove out what users really expect (rather than what I expect them to expect ;) ). The pattern editor changes are already on master, song editor work is currently on #1079 .

We have some open questions in particular which I'll consolidate out of various threads shortly, but which include:

• Should the keyboard input cursor be shown or hidden by default?
• Some keys that would naturally be used for keyboard-based editing are already allocated to interactive functions, like Restart pattern is mapped to the Backspace key, and tempo changes on the + and - keys. Which use for these keys would be better, deleting selections or the current bindings?
• Unifying the appearance of highlighted selections and lasso rectangles
• Should copy and paste insertion position correspond to the top-left selected item, as in spreadsheets?

Thanks! :)

[oddtime]

Great!

Should copy and paste insertion position correspond to the top-left selected item, as in spreadsheets?

Yes, in my humble opinion. Also, when you select some notes, hydrogen should not change the selected instrument.

[cme]

Thanks! This seems to be the majority opinion :)

Making the a selection mouse drag keep the same instrument sounds reasonable too, I shall try it and see how it feels.

[cme]

I've changed the selection origin for the song and pattern editors on dev-song-editor-refactor. It has the additional advantage that it allowed DrumPatternEditor::copy() and PianoRollEditor::copy() to be combined and moved up to PatternEditor::copy() so overall saves LOC :)

Making the a selection mouse drag keep the same instrument sounds reasonable too, I shall try it and see how it feels.

This felt wrong to me; it deviates from the spreadsheet model behaviour of setting the focused cell at the beginning of the drag. Or perhaps what you mean would be more like decoupling the selected instrument from the keyboard cursor position, such that the cursor moves but the selected instrument doesn't change?

[oddtime]

such that the cursor moves but the selected instrument doesn't change

I am not sure to understand. I meant: when you press shift+ left click and move the mouse cursor to form a "selection dashed rectangle", I don't expect that the selected instrument (i.e. the instrument which turns bright and is displayed in the instrument editor...) changes.
Especially if that instrument has not any note inside the selection rectangle, if you draw a big rectangle like that:

However the strange thing was that after that, the selected notes were pasted in a instrument depending on the origin of the rectangle (since the selected instrument changed to that before copying the notes) and not just on the selected notes. Does it make sense?

I have tried dev-song-editor-refactor and now the notes are pasted to the expected instrument, but I am confused by the position the notes are pasted to (should I write and delete a note / draw another rectangle in the desired position before pasting?)

[theGreatWhiteShark]

This felt wrong to me; it deviates from the spreadsheet model behaviour of setting the focused cell at the beginning of the drag. Or perhaps what you mean would be more like decoupling the selected instrument from the keyboard cursor position, such that the cursor moves but the selected instrument doesn't change?

I found the change in instrument strange at first too but get used to it real quick. However, this is also a good reminder for the user that changes in the note property ruler do only affect the selected notes of the currently selected instrument and not of all selected notes.

[oddtime]

Yes, I get used to it quickly too.

[theGreatWhiteShark]

Should the keyboard input cursor be shown or hidden by default?

Is the intended behavior that it is hidden at the beginning of a session and once an associated key is pressed it is displayed till the user quits Hydrogen? At least for me (using i3 version 4.17.1) the cursor disappears whenever I press any system-wide keyboard shortcut (all associated with the [Super] key), e.g. increasing volume.

[cme]

Should the keyboard input cursor be shown or hidden by default?

Is the intended behavior that it is hidden at the beginning of a session and once an associated key is pressed it is displayed till the user quits Hydrogen? At least for me (using i3 version 4.17.1) the cursor disappears whenever I press any system-wide keyboard shortcut (all associated with the [Super] key), e.g. increasing volume.

The intention was primarily to hide it again on a mouse movement, I'm not sure why it would disappear on system-wide key shortcuts (except perhaps that the window might lose focus?).

But @oddtime's point about paste locations is partially making me rethink this, and perhaps keeping it unhidden might be better. And certainly having it persistently visible when a selection has been made that can be cut and paste would show the user exactly where a pasted selection goes.

Perhaps a better behaviour might be:

• keep current "hide" behaviour, but make it off-by-default in preferences
• default behaviour is to hide initially, but unhide semi-permanently on any movement key, or 'copy' action.

[cme]

I've implemented this behaviour #1079 (which I'll merge soon) and it feels pretty good to me.

[theGreatWhiteShark]

keep current "hide" behaviour, but make it off-by-default in preferences

Okay. So, the initial idea of the hide behaviour was, IIRC, to allow the user to experience the old UX without a keyboard cursor, wasn't it? If it's now chosen explicitly via the preferences we may could offer the user to deactivate the keyboard interaction altogether with something like "enable keyboard editing". This way the cursor is always at the position of the mouse press - while being invisible - and there might be less confusion.

[theGreatWhiteShark]

Which use for these keys would be better, deleting selections or the current bindings?

Also, please note that we plan to make all key-bindings customizable at some not too distant point in time.

[trebmuh]

Nice to read! If you 're not aware of it yet, please see #589 which is very related.

[oddtime]

Maybe the position where notes are pasted would be clearer if the triangle was always visible?

Ok the paste-position does not depend to that particular triangle, which is for playback, but maybe this gives some idea

[cme]

The position they'll be pasted at is the position of the keyboard input cursor, which is moved when the mouse is clicked (eg. right click to get to the "Paste" menu entry). This is hidden by default. Maybe showing it explicitly in such cases would be useful. Hmm.

[oddtime]

Ah ok, now I understand

[cme]

Ah ok, now I understand

Now, the question I need to figure out the answer to is: how could I have avoided that misunderstanding? :) Would having the keyboard input cursor visible during the operation have made it obvious enough that this is where the selection would be pasted?

[oddtime]

yes

[cme]

@theGreatWhiteShark wrote over here:

In the PatternEditor the instrument is the currently selected one which is associated with the keyboard cursor. I would suggest to have the same for the SongEditor.

The problem mostly is that it implies a change to what happens when you click a cell to enable/disable it. Since the keyboard cursor follows the mouse click, if the selected pattern followed the cursor, then activating / deactivating a cell would potentially change selected pattern too. Not that this is inherently a problem, just that it's a change.
Does that sound like desirable or undesirable behaviour?

TBH, I didn't thought about the mouse click but I like it! At least for the "select mode" it gives an optical feedback by showing the added/deleted pattern and for the drag selection it is even better. I instantly thought of a use case like "I want to select all patterns up to a certain one". Using this behavior one does not have to keep an eye on the row anymore but could also drag until the desired pattern shows up in the pattern editor.

But I agree, this will be a larger change and some people might not like it.

Anyone else have opinions? :)

[oddtime]

After a very short reflection, I agree with @theGreatWhiteShark.
Such link probably makes easier to see what pattern is added deleted or selected.
I can't think of any cons now

[theGreatWhiteShark]

I just noticed that when pasting notes in the pattern editor twice there will be twice the selection on top of each other. Because the associated bars in the note properties ruler are of the same color it's very hard to notice what had happened. + if one uses only the drum pattern editor and not the piano roll one might not even know this would be possible (I just learned about it some weeks ago).

I would suggest to only paste notes if there wasn't already one present

[cme]

I would suggest to only paste notes if there wasn't already one present

Agreed, this is probably the best thing to do when pasting identical notes. Any thoughts on what should happen when pasting over non-identical notes? Eg differing pitches.

• place anyway?
• dont place at all?
• "overwrite" existing notes?

[cme]

Hmm, one conflicting scenario (which I had in mind when implementing this at first):

• the user copies some notes
• user positions cursor where they think they want the notes to go, but not quite
  • this seems like a totally fair thing for the user to guess wrong, given that we've already identified a few different behaviours the user might reasonably expect.
• user hits paste, pasting new notes, some over existing notes
• The user sees the incorrectly positioned notes, which are selected, and drags them to adjust position.
  • notes that were overwritten by the first paste are erased and not restored

It seems important to be able to freely move a selected set of notes without affecting what's underneath it.

Should pasted-but-still-selected notes be treated differently?

Should conflicting/superimposed notes be resolved by some other mechanism other than overwriting?

[oddtime]

I agree: if notes are still selected they should not overwrite the existing notes. Instead overwriting should be performed when you leave the selection. I can think to a similar behaviour in images editor like gimp.

[theGreatWhiteShark]

Should pasted-but-still-selected notes be treated differently?

Yes. Good one!

But now we have to talk about when to end a selection and write the result. E.g. a selection is still active when starting playback. Does this mean these somewhat temporary notes will be played or ignored? How about ending a selection on all mouse and keyboard inputs that are not related to keyboard editing in the *Editors, like clicking somewhere in the PlayerControl or Mixer or opening the PreferencesDialog using Alt+P?

[cme]

I think having the notes play is probably desirable, as the user might also use the sound to realise the notes are not placed where they want them.

This would make things pretty easy in terms of state in the user interface as it wouldn't need to introduce any extra state that doesn't already exist. The invariant is simple -- selected notes can be duplicates, unselected notes cannot (and must be resolved on deselection).

Taking another cue from spreadsheets, it would probably be a good idea to provide a warning dialog box on the paste operation (with a "don't show this again" option) warning that the paste will overwrite existing notes, and saying the selection can still be dragged into place or deleted.

How about ending a selection on all mouse and keyboard inputs that are not related to keyboard editing in the *Editors, like clicking somewhere in the PlayerControl or Mixer or opening the PreferencesDialog using Alt+P?

This sounds like a good idea. Is there any use case for maintaining a selection while any of these events take place? I can't think of any.

[theGreatWhiteShark]

Taking another cue from spreadsheets, it would probably be a good idea to provide a warning dialog box on the paste operation (with a "don't show this again" option) warning that the paste will overwrite existing notes, and saying the selection can still be dragged into place or deleted.

+1

I think having the notes play is probably desirable, as the user might also use the sound to realise the notes are not placed where they want them.

This would make things pretty easy in terms of state in the user interface as it wouldn't need to introduce any extra state that doesn't already exist. The invariant is simple -- selected notes can be duplicates, unselected notes cannot (and must be resolved on deselection).

Yeah, this should work fine.

Another approach would be to paste the notes and end the selection when starting playback and make [Ctrl] + [z] undo the pasting and restore the selection.

This sounds like a good idea. Is there any use case for maintaining a selection while any of these events take place? I can't think of any.

I can't think of any either.

[theGreatWhiteShark]

When having multiple notes on top of each other, [Ctrl] + [a] followed by [Ctrl] + [x] seems to copy all notes to the destination but does not remove all notes at the source location. Also, using [Ctrl] + [a] followed [delete] does not remove all notes.

[cme]

Nice find, thanks. Fixed.

[theGreatWhiteShark]

I also have to admit that I'm not feeling comfortable with the way multiple notes are handled in the PatternEditor in general. The fact that it's impossible to see in the DrumkitEditor whether there are multiple notes at one position or not just does not feel right. I think it's okay to say two notes can only coexist at the same position if they differ in their pitch and one has to switch to the PianoRollEditor to edit them. But maybe we should at least use a slightly different symbol in the DrumkitEditor to indicate the presence of multiple notes?

On the other hand, thanks to Colin's work tweaking the properties of multiple notes in a single column of the PianoRollEditor has improved a lot! No Alt + right click required anymore (which AFAIK is not even mentioned in the manual and does not work for the probability) but just selection and the usual interaction.

[theGreatWhiteShark]

It's on dev-ux-tweaks, and the labels will only show up if there are superimposed notes. Unless you have chords, you should only see the labels transiently before duplicates are resolved.

Ah. Of course! Sorry. I mistook it for a comment about the tuplet implementation since there was once the proposal to represent e.g. three triplet notes by a special full note. Well, it was a long day 😆

[theGreatWhiteShark]

When recording notes via keyboard I got a some strange results. When inserting a note twice at the same position a '3x' does appear. If I do it another time (three times in total), '5x' is displayed and so on. I have not checked whether the note display or the recording does cause this issue but something is off.

[cme]

When recording notes via keyboard I got a some strange results. When inserting a note twice at the same position a '3x' does appear. If I do it another time (three times in total), '5x' is displayed and so on. I have not checked whether the note display or the recording does cause this issue but something is off.

This sounds pretty weird. Did you save the h2song by any chance to see what notes actually got inserted? It sounds like you're getting 2 notes inserted on each instead of 1.

The other issue is, I guess, should MIDI input also 'overwrite' existing notes rather than adding duplicates? I think 'yes' sounds like the right answer, but not sure.

[theGreatWhiteShark]

It sounds like you're getting 2 notes inserted on each instead of 1.

That's indeed true. Very strange. I'll move this one to the issues (see #1224).

[theGreatWhiteShark]

The other issue is, I guess, should MIDI input also 'overwrite' existing notes rather than adding duplicates? I think 'yes' sounds like the right answer, but not sure.

There was an attempt to integrate both destructive recording #1102 and a punch-in/-out area #1166 for recording at some point in time. But both of them are not properly implemented yet. I would suggest we postpone this to 1.2 and make a proper fix. After all, the destructive recording (in case it did worked at some point) was quite hidden and nobody complained that it was not working.

[oddtime]

Some shortcuts do not work on my computer (Lubuntu)
Alt + up/dn arrows is scrolling the pattern editor
alt + click moves the entire window (I have always had this shortcut in Ubuntu)

[oddtime]

But I actually like the idea to adjust manually and deterministically the pitch in a fine way: for example you can program the drum notes with pitch following the velocity (manually).

it should be fairly trivial to add a properties editor for it along the lines of the existing editors; whether or not that's the right interface for it is a different question!

Yes that would be a way. Or we could implement a new window showing all the properties of the selected note, where the user could change them with line widgets.

[theGreatWhiteShark]

@theGreatWhiteShark is referring to editing individual properties of a note when they're superimposed?

Yes, indeed. I thought the fine tuning of the offset did refer to the shadowed shortcut

alt + click moves the entire window (I have always had this shortcut in Ubuntu)

[theGreatWhiteShark]

the pitch in a fine way: for example you can program the drum notes with pitch following the velocity (manually).

ideally, this is what the engine should do. Well, one day... 😄

we could implement a new window showing all the properties of the selected note, where the user could change them with line widgets.

Opening a dialog for each note would be quite tedious. How would you use/interact with it?

[oddtime]

I didn't mean a new dialog for each note, but a fixed window with the properties of selected note (or notes... if values are different the field would be blank or grey) you could use it to set all the same values at once, and to allow text input

[oddtime]

the pitch in a fine way: for example you can program the drum notes with pitch following the velocity (manually).

ideally, this is what the engine should do. Well, one day... smile

ahah! Yes, but then it should change the pitch in time during the sample! ;) And act differently if instrument was a cymbal or a drum skin

[Ratfink]

I've started using master for actually making songs, and I'm really loving the new song and pattern editor UX. Being able to select and move notes around is a godsend. I've noticed one feature that seems to be missing from keyboard editing though: holding Ctrl and dragging with the mouse lets you add a second rectangle to the selection, but this doesn't seem to work when selecting with the keyboard instead of the mouse.

[cme]

Yeah, this is a bit of a pain because the keyboard bindings are determined largely by Qt's standard shortcut keys so that it does what the user naturally expects on each platform. On macOS Ctrl+Shift+Arrows is the binding to select to end/beginning of line/document, so it didn't seem totally clear what the right way to support that, in a way the user would expect, should be.

It doesn't fit in well with Qt's standard key binding system, It could be easily overridden on all platforms, leaving macOS with no select-to-begin/end, or implemented for platforms that don't use that key combo leaving macOS without it.

Glad to hear that the new features are otherwise useful for you!

[theGreatWhiteShark]

I got a strange one

In the note properties ruler (using keyboard)

• if the octave point (the upper one) is at or above the thicker middle line, [down] does decrement the pitch in the lower half by one. But if it's below the black line, the octave will be decremented instead
• if the octave point is below the black line, [up] won't have an effect anymore

[cme]

• if the octave point (the upper one) is at or above the thicker middle line, [down] does decrement the pitch in the lower half by one. But if it's below the black line, the octave will be decremented instead
• if the octave point is below the black line, [up] won't have an effect anymore

Interesting, I can't reproduce this. Which branch / SHA?

[theGreatWhiteShark]

It happens at 3f52ae5 . But in current master ( 8813cc1 ) it's already fixed.

[theGreatWhiteShark]

Found some more:

• When right clicking a single pattern in the song editor grid (it is not selected), all the commands do not apply. The single pattern must be selected first. However, it would be nice if this could happen automatically when preforming right click in case no selection was done yet.
• Right clicking the instrument name in the pattern editor gives the option to copy and paste notes. But these do refer to the whole line, the selected instrument exclusively, and do not respect the selection. I think we can just drop them because the right click on the selection itself in the pattern editor is more straight forward and makes the one on the instruments redundant.

[cme]

Selecting what's under the mouse cursor on a right click sounds logical. Should probably happen in the pattern editor too.

On the instrument list "Copy notes..." functionality; that has the "all patterns" options, which isn't supported by the new pattern editor selection model. Perhaps the plain "copy" should be removed and the "all patterns" renamed to "Copy instrument in all patterns" or similar?

(I wonder how often that function really gets used...)

[oddtime]

(I wonder how often that function really gets used...)

It is very useful to me to replace an instrument

[cme]

Oh heh, yes, that :D

[theGreatWhiteShark]

It is very useful to me to replace an instrument

You are right. It's very useful indeed. How about making explicit that this is just for a single instrument and does not correspond to the selection in the pattern editor by calling it e.g. "copy instrument (all pattern)" and "paste instrument (all pattern)". This way it's less unclear.

But in the end it's something provisional. After the drumkit-independent-pattern project replacing instruments should work by drag and drop.

[oddtime]

As you prefer. "copy all notes (all patterns)" seems clear enough to me, because it appears when you click on an instrument so I expect it being related to only that instrument.

After all this function may be useful in the future too, if one wants to keep the notes played by two or more instruments for timbre effects (like current instrument components, but with separate adsr, pan... parameters).

[theGreatWhiteShark]

Moving selected notes or patterns outside of the current view of the editors does now trigger a scroll event. +1

But when moving instruments in the pattern editor or pattern in the song editor (left sidebar) there is no scrolling yet.

[cme]

Nice, I didn't think of that. Added on dev-ux-tweaks now.

[theGreatWhiteShark]

One thing I still find myself using the mouse for and switching to the draw mode is inserting a larger number of consecutive notes/patterns.

Pressing [return] without a selection does insert a note/pattern. How about making [return] fill a whole selection as well? (I can't recall it right now but I think there was already a use for this button)

This would also raise the question whether to enable this behavior in the note properties ruler (since this is not possible by mouse to allow for the drawing of multiple values at once). I think we should.

[oddtime]

I am noticing that pasted notes have probability reset to 1, but not when they are moved

[cme]

Oh, nice catch -- this is also in the 1.0 release line, albeit in a different form:

• create note
• edit probability
• click note to delete it
• Ctrl+Z to undo delete
• Note is restored with the default probability

This is because addOrDeleteNoteAction doesn't actually take a probability parameter. How did I never notice this before?

[oddtime]

Perfect!

[theGreatWhiteShark]

Just came across this issue #250 . Maybe clicking the mute or solo button should select the corresponding instrument.

[cme]

Aha, someone once tried to describe this issue to me, but I couldn't reproduce. Excellent find.

I think selecting the instrument on any click including solo/mute is probably reasonable expected behaviour, because the solo/mute buttons are contained entirely within the click-to-select area of the instrument line.

[theGreatWhiteShark]

I came across the way Musescore handles the note insertion a couple of weeks ago and I frequently revisit the idea in my mind to have something similar in Hydrogen. But I have not yet found a proposal that's not rough around some edges.

Here is what Musescore does: you enter a dedicated 'note insertion mode'. To enter a note, you press A, B, ..., G (since it's about musical scores). This will insert the corresponding note and advances the cursor to the next position. If you want to have a chord (multiple notes in at one position), you press the Alt modifier. Pressing and holding a key will thus add multiple notes in the current resolution. (And there is a null element adding a rest 0.)

This input mode feels like drawing using a keyboard. And since the current drawing mode in the song editor is a stub adding a keyboard counterpart would feel quite natural. Plus, creating patterns like this would be ultra fast.

I think this could be possible by making the draw mode something special the user has to activate via mouse click or shortcut and leave using e.g. ESC. When activated, the input mode (virtual keyboard) won't work anymore and all the keys are free to be used in drawing. The patterns/instruments could map (from to bottom) to 1-9, q-p-, a-l, z-m and a hint showing the particular mapped key can be displayed next to the pattern/instrument name. 0 would be the null element, the cursor would move with every insertion unless a modifier is pressed, +/- increase and decrease the resolution of the underlying grip, ↑ and ↓ won't do anything (or also alter the grid?), the cursor extends to the whole column, ← and → moves the cursor. In addition to the ability of adding multiple instruments in one column using the modifier, one can also take advantage of the loop mode when writing a pattern and do the instruments one after another.

What do you think, would this be something useful or too obscure to be used by the average user?

[oddtime]

I think that in a grid editor this way would not be so useful, (think of the grid resolution, while in score-notation software you select note lengths before input the notes) but it would be appropriate in the song editor, because there usually you don't leave empty "places" (empty pattern), and even if patterns may have different lengths, this is not represented in the song sequence matrix.
Does it make sense?

[oddtime]

I think actually that in a grid drum pattern editor the mouse is faster, generally.
ps: I am a massive user of keyboard note input in sibelius, which is similar to musescore

[theGreatWhiteShark]

think of the grid resolution, while in score-notation software you select note lengths before input the notes

Hmm. I don't see a difference between the two. The score-notation software basically also offers a grid resolution but do not render the individual grids and call the grid resolution "note length". It's basically the same as the Piano Roll Editor. And the Piano Roll Editor is like the Drumkit Editor but with pitches instead of instruments. Selecting the grid resolution before inserting a note/pattern should be as straight forward as in the score-notation software.

[oddtime]

Well if you think it would be useful I am not against it. I just find faster for example having 16ths notes resolution and entering quarter notes, occasionally 8ths and 16th without switching res.

Piano Roll Editor is like the Drumkit Editor

Yes of course I meant both. Musescore has not piano roll... the differences between score and grid is that in score you have to select and write lengths and write rests explicitly while in the grid editor (drum-trigger-like) we usually write and represent just the note-on signal.
In the piano-roll editor (using lengths, for pitched instruments) probably musescore-like method is more usable, even if H2 is not used this mode very often I guess.

[theGreatWhiteShark]

if you think it would be useful I am not against it

If its just me thinking it would be useful, than its probably overengineered and would not improve the overall UX ;)

[theGreatWhiteShark]

I found some time lately to actually use Hydrogen again and spotted a minor inconvenience in the Pattern Editor UX.

When clicking the region next to the grid of the DrumPatternEditor (marked with the red cross) focus changes to the Pattern Editor (expected) but a selection in the Pattern Editor is not cleared (unexpected). I think it's a good idea to maintain the selection while the user is clicking somewhere in the sidebar, like selecting a different instrument, but the part right of the grid feels like part of the editable region.

[theGreatWhiteShark]

@cme

I'm scratching my head on some shortcuts to alter properties in the NotePropertiesRuler right now:

1. Alt + scrolling does scroll the NPR to the left and right. Apart from that the corresponding ev->angleDelta().y() value is mostly 0 regardless of the scroll direction. In result it does fine tune the property but is only increases it. Ctrl + scrolling works fine.
2. Alt + up/down does fine-tune a property. But the Ctrl counterpart does not work. After figuring out 1. this feels very weird.

IIRC the Alt ones was introduced with macOS in mind. Should we make the behavior platform dependent using preprocessor directives? It feels kinda buggy in it's current state.

---

P.S. I didn't came across this while using it but because I was touching the code in theGreatWhiteShark@f81b4ae . Still, it feels like a quite usual interaction a lot of users might do.

[cme]

What would the Ctrl counterpart be? All-the-way-up/-down, or up/down by a larger amount?

I think it should be fine to add that. On macOS Command + up/down already get mapped to MoveTo{Start,End}OfDocument by Qt so the behaviour would be vaguely consistent. So I guess it's fine to just add it without any $ifing since macOS will never get there (and if it did, that would be fine too).

[theGreatWhiteShark]

What would the Ctrl counterpart be? All-the-way-up/-down, or up/down by a larger amount?

If we want to make the UX consistent with the new widgets, regular wheel or arrow key events should increase a property value by 1% and with pressed Ctrl by 5%. In the NotePropertiesRuler it's the other way around and the arrow key + kbd>Ctrl one is missing.

Alt + scrolling does scroll the NPR to the left and right. Apart from that the corresponding ev->angleDelta().y() value is mostly 0 regardless of the scroll direction. In result it does fine tune the property but is only increases it.

Just realized this behavior is consistent with the rotaries and faders. Should we throw away the wheel event in case Alt is pressed?

I think it should be fine to add that. On macOS Command + up/down already get mapped to MoveTo{Start,End}OfDocument by Qt so the behaviour would be vaguely consistent. So I guess it's fine to just add it without any $ifing since macOS will never get there (and if it did, that would be fine too).

+1

[theGreatWhiteShark]

Just had an epiphany. I reactivated the selection lasso in NPR since I really miss it when altering multiple values and realized that I can do both in there: drawing and selecting. Still, it's a little bit clumsy as it seems to decide on its own when to do what. But, hey, this is just the left mouse button, I can draw new values by pressing the right mouse button too.

How about:

• left click: exclusively starts a lasso (SE: only in selection mode; DPE, PRE, NPR: always)
• right click: draws notes/sets values (in all editors)

It would be a bit of an UX change for the NPR but I think not a bad one since it won't switch from drawing to selection mode anymore and make things predictable. Also, in order to both smooth the change in UX and to make things really consistent left mouse click will still set a property in NPR. We also would need a new way to create note offs in DPE and PRE (middle button?). But having all editors aligned in their UX while allow for both selecting and drawing would be - at least in my point of view - a very big improvement of the UX.

The main thing that gives me a headache is the discoverabilty of the feature. Will new users get the hang of it and will new ones discover it? Maybe a tooltip for the draw button and placing it prominently in the change log and doc will already do the job. But maybe I too much about it anyway.

[cme]

How about:

• left click: exclusively starts a lasso (SE: only in selection mode; DPE, PRE, NPR: always)
• right click: draws notes/sets values (in all editors)

I think the primary button should always be the most obvious thing, and the pattern editor, that's placing notes. It would also break for one button pointing devices (macs, touchpad presses). :/

[theGreatWhiteShark]

I think the primary button should always be the most obvious thing, and the pattern editor, that's placing notes.

Sorry, I did use the wrong technical term. I didn't mean "click" but "press and move". In the same spirit as already implemented in Selection: if the left mouse button was pressed and moved more than a predefined distance before being release, it's interpreted as a drag selection. For shorter distances it will be a click and toggles a note. What I wanted to suggest is to make the right button act similar: start a drag-drawing when moved sufficiently or open a popup menu etc. if not. In the DPE no existing action would be altered. Only setting individual note properties in the PRE using right button drag and disabling drag-drawing on left mouse button in the NPR would be affected. But I agree this is already quite a lot and would call for an option in the Preferences to switch between the old and new behavior. And those don't tend to make things less complex.

The main thing I'm after is the UX of the SE as right button drag is not used there yet and being able to use both drawing and selection without using the button to switch back and forth would speed up song editing quite a bit. And I'm mostly bringing this up because right now I would have the resources to implement it myself. But it's nothing pressing, just a quick idea :)

one button pointing devices (macs, touchpad presses)

Those things still exist? I only have seen such an one button mouse once in a studio more than ten years ago and was stunned by lack of functionality in its design :D . Do we have such things covered? Will those folks be able to open popup menus in e.g. the SoundLibrary or SongEditorPatternList?

[theGreatWhiteShark]

One thing I'm still surprised by at least once each month is that notes can only be deleted or their property be altered (using right click drag) in the DPE and PRE if they are located precisely at a drawn tick. For me those things would feel more natural if they are allowed for all notes and do not depend on the current resolution. Note insertion should of course be still only possible at ticks the way it is right now. What do you think?