MIDI Editor - drag to extend a note doesn't follow the grid lines

[thommazk]

Hi, after discussing if this is either a bug or a nitpick I decided to post this problem because it looks more like a bug than just a needed improvement.

The grid when dragging the mouse to draw or extend a note doesn't correspond to where the mouse cursor is.


In the gif, the MIDI Editor seems to calculate half of the MIDI grid cell pixel size and wait for the mouse cursor to move this distance to extend the note. If you happen to click at the beginning of the cell, the note will be extended way before the mouse cursor crosses the grid to the next cell!

This makes writing in the MIDI Editor very unintuitive as it's not visually well represented (normally you'd just click in the grid you want to start, not worrying with the exact mouse cursor, and extend to the measure you want, based on the grid lines)

For reference, take a look at FL Studio MIDI Editor and what is expected:


It waits until you "draw" the entire grid measure to extend the note and that makes total sense to me.

It's probably a bug but I think it'll improve the overall experience of the MIDI editor.

Thanks a lot!

(see original discussion here)

[pcp]

It also affects note drag-to-move, not just insertion/extension, and it affects dragging left as well as right. Moreover the behaviour is inconsistent, or feels that way, as this gif shows. The first two notes (F and G) initially snap as expected, snapping correctly when the mouse cursor crosses the grid line. But the third note (F#) demonstrates the buggy behaviour, after which the initial F and G don't snap correctly any more.



That gif was recorded with scripts running but I've reproduced in a stock portable 6.61 REAPER install, on Windows 11.

I think more predictable snapping would have an outsized impact on the usability and enjoyability of the MIDI Editor. As mccrabney said in that original thread

Originally Posted by mccrabney

this is almost certainly one of the "REAPER's midi workflow is not smooth but i cannot articulate why" ghost issues that people bring up sometimes. these are very valuable fixes to make, even if the fanfare is low for them.

[ferropop]

It's this specific style of quirk that seems like nothing, but it's involved in 90% of your mouse-clicks sometimes - and that's when it's more of a bug than a quirk.

[thommazk]

bump for the next release

[ferropop]

Also -

Let's say the grid is set to 1/16ths - because of the adaptive grid, if you zoom out until the 16ths grid disappears (doesn't take much) and it goes down to 1/8th --

If you insert notes in this situation, they are still inserting at 1/16th grid, even though visibly it's 1/8th!

The number of times I end up inserting notes incorrectly between the visible grid ... it's every single day.

[ferropop]

...this should either be

1. Adaptive Grid, ie if the visual grid is going to change depending on zoom, the actual grid should follow along

2. No Adaptive Grid, so if you have 1/32 selected the grid will display 1/32 no matter the zoom.


WYSIWYG should be the usability standard always.

[nofish]

Originally Posted by ferropop

...this should either be

1. Adaptive Grid, ie if the visual grid is going to change depending on zoom, the actual grid should follow along

2. No Adaptive Grid, so if you have 1/32 selected the grid will display 1/32 no matter the zoom.


WYSIWYG should be the usability standard always.

Yes, I miss that we dont have "Grid snap settings follow grid visibility" like we have for the arrnge.

[ferropop]

Originally Posted by nofish

Yes, I miss that we dont have "Grid snap settings follow grid visibility" like we have for the arrnge.

Yup, the disconnect between visual and functional. Such a simple fix too

[EvilDragon]

Yep this is very annoying. FL did it right, really.

[strachupl]

I second that it is one of the things that makes peoples opinion about midi in R-DAW clunky.

[mccrabney]

Originally Posted by nofish

Yes, I miss that we dont have "Grid snap settings follow grid visibility" like we have for the arrnge.

very much this, but also the OP

[sockmonkey72]

please open another bug report/FR for issues unrelated to this specific problem, this is how stuff gets missed/ignored.

[pcp]

Originally Posted by pcp

the third note (F#) demonstrates the buggy behaviour, after which the initial F and G don't snap correctly any more.

I've realized that what's going on in this case is not actually a bug in the sense of unpredictable behaviour -- the notes are snapping to other notes ahead of them in the grid, which is why the snapping behaviour changed, seemingly erratically, only after adding notes in the piano roll.

It's obviously useful to snap to other note edges, but the more logical behaviour I think is for that snapping to occur based on the mouse cursor touching snappable events, so the note would only extend/move when the cursor passes the snapped-to note edge, or grid line. So really, just what thommazk said in his original post.

Otherwise, if there was a visual cue when a note is snapping to something other than the grid -- I'm thinking of something like how in Premiere Pro and other NLEs you get a vertical line when dragging through a snappable edge -- it would make the behaviour way more grokkable and intuitive.

[thommazk]

Bump!