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!

[thommazk]

bump for the next release

[ferropop]

+1, huge benefit for what seems like a fairly basic tweak devs <3

[kotll]

bump as well, really annoying when editing MIDI

[Chris Diablo]

Agreed.

Please address this, Reaper gods.

[thommazk]

Bump for 6.67.
@devs, I believe this would benefit the feel of writing in the MIDI Editor so much.. I hope this isn't something super hard to fix!

[ferropop]

This same logic comes into play in a few spots. Would really clean things up and make the feel of the DAW so much more consistent and reliable if it were looked at.

I know it's not a sexy request, it's just quality of life stuff that unfortunately rarely gets looked at. In reality though, more people probably care about this than CLAP plugin support... but different strokes i suppose.

[thommazk]

bump for 6.68!

@devs, let us know if you're aware of this bug. I'm bumping this thread every release to see if you can check this out, as it's affecting many users.

[thommazk]

Devs, can you take a look at this one?

[strachupl]

Originally Posted by thommazk

bump for 6.68!

@devs, let us know if you're aware of this bug. I'm bumping this thread every release to see if you can check this out, as it's affecting many users.

thank you for keeping eye on this I support

[thommazk]

Bumping this as we got a new build.

[ferropop]

Thanks for taking the time to explain and demonstrate with the GIFs thommazk, the FL Studio comparison makes it clear as day.

[thommazk]

Another bump! Seeing a lot of MIDI Editor fixes recently, so I hope @devs can look at this one.

[thommazk]

bump

[thommazk]

Since v7.0 had updates in the MIDI Editor, I'm bumping this FR.

[thommazk]

This fix would be a good fit with all the ME improvements that v7 will have.

[ferropop]

Same goes when say, grid is set to 1/32 but Zoom only shows 1/8 gridlines -- Reaper still allows 1/32 positioning! It's such a simple tweak to fix, and infinitely frustrating in its current form.

[Arthur McArthur]

This would be a big improvement to the feel of the MIDI editor

[thommazk]

bump for the new MIDI overhaul feature branch that's being included

[elcalen]

Well, if you read the changelogs for recent builds... I haven't tested these myself, but v7.36rc1 did have these lines...

• + MIDI editor: add option for snap to visible grid
• + MIDI editor: snap to grid matches grid line visibility

[thommazk]

Originally Posted by elcalen

Well, if you read the changelogs for recent builds... I haven't tested these myself, but v7.36rc1 did have these lines...

• + MIDI editor: add option for snap to visible grid
• + MIDI editor: snap to grid matches grid line visibility

The snap still feels like it doesn't follow the mouse cursor position, even with these recent changes.

[thommazk]

Thanks for the fix, @devs! Dragging to extend a note feels much better now

While we're on the topic, dragging a note to move still feels a bit inconsistent:

[Cyaoeu]

For me extending notes still feels bad. The editor closes when it loses focus though so I can't record it.

For me what feels bad is that the place where you clicked decides the starting point instead of just using the grid lines that exist. I want the note to move whenever I cross a grid line with the cursor, that way every action is consistent with the grid instead of having a new snapping behavior for every pixel the cursor is offset when clicking the note.

I made a bug report a few years ago which shows the issue - https://forum.cockos.com/showthread.php?t=250421

To see the behavior I would like to see you can enable "Snap notes/CC to the left" and move a 1 grid size note, it will always move whenever the cursor crosses a line. It breaks on larger notes though and doesn't work with extending or inserting (and dragging) notes.