Pitch Bending Directly in the Piano Roll

[regulus79]

This PR modifies how the Detuning tool works in the piano roll to let the user modify the automation curve right on the notes. This is actually fairly simple, as automation clips already contain the functions for dragging and removing points like in the Automation Editor. So essentially all that's being done is calculating the relative pos of the mouse to the nearest note, and setting the drag value in the automation clip to that position and key.

You can still access the old automation editor version by shift-click (should I change it to be double-click?)

pitchbending_demo.mp4

(Apologies for the non-standard theme; I didn't feel like recording another demo)

@messmerd asked if the code could be made general for any future note parameter besides detuning, in preparation for CLAP per-note parameter automation. I have refactored the relevant functions to accept an enum type for the kind of note parameter, although currently only detuning is supported.

Changes

• A new enum type was added, Note::ParameterType, which currently only has Detuning.
• New variables were added to handle the detuning in PianoRoll.h, to store the mouse states, the current notes being operated on, and the last changed tick.
• New functions were added to handle the detuning, for setting up the note vector, updating the drag position, and applying the drag position. Each of these functions take in a Note::ParameterType and use a switch statement to get the right automation clip in the note (currently only detuning is supported). Another function was also added to get the closest note to the mouse taking into account the shape of the automation curve.
• The drawing of the detuning info was changed to have circles around the automation nodes.
• The logic handling the detuning mode in the mouse event functions was updated.

[sakertooth]

@szeli1 I believe you had similar ideas, but it was for manually editing automation clips directly in the Song Editor?

[szeli1]

@szeli1 I believe you had similar ideas, but it was for manually editing automation clips directly in the Song Editor?

#7317
It is stuck because it doesn't improve the speed of automation. Shortcuts would fix this.

[bratpeki]

What if I slide pitch from one note onto a place where another note already exists, and then click on that other note? If you don't get what I mean, I'll record a video demo when I can.

[bratpeki]

Just tried it, it works on selections, so even if you overlap notes, there's no issue! And it supports making selections in the automation mode! Excellent! 😁

[bratpeki]

Mind the quality of the video, I overcompressed it. But I found a bug!

out.mp4

[szeli1]

I didn't test this PR, but I reviewed it.

[regulus79]

But I found a bug!

Is the bug you are referring to the fact that after duplicating notes, changing one's detuning pattern changes the other? I believe that is also in master #5940 (but should be fixed in #7477)

[bratpeki]

@regulus79, could very well be! My exact steps were Ctrl+A, Shift-Dragging new notes into existence, and then attempting to change the pitch of those new notes, since they were selected afterwards. I'll try that on master and let you know if that's the same behavior.

[regulus79]

I have added a lot of comments and refactored the switch statement out into a separate function. Hopefully the PR is easier to read now.

[Rossmaxx]

Out of scope for this PR, i see a chance we can replace lmms::shared_object to std::shared_ptr. Afaik shared_object is used only for detuning. I was supposed to do it for #7677 but was fearing a change in functionality and a few build fails. I am not in a position to test any changes.

[bratpeki]

@regulus79, the named issue definitely exists on master. Adding it to my notes and opening a corresponding issue if there isn't one.

[bratpeki]

Not big on Qt (please interpret as "barely has any idea what they're doing"), but the overall logic the PR seems okay to me.

• mousePressEvent looks fine
• applyParameterEditPos, which is ran inside mouseReleaseEvent looks fine
• updateParameterEditPos, which is ran inside mousePressEvent and handles both LMB and RMB logic looks fine

I'll keep testing, but I think there's nothing more to see. @messmerd could we get some final opinions and merge?

[sakertooth]

Could've made a couple of nitpicks but don't want to withhold this much needed feature. Tested it and it works mostly fine, but found a minor bug (?) where the green line disconnects once moved to the edge near the keys in the Piano Roll. Not sure if you want to look into that here or later (or at all).

[regulus79]

Thanks for approving!

found a minor bug (?) where the green line disconnects once moved to the edge near the keys in the Piano Roll

I'm not sure what bug you are referring to. I did notice a similar potential bug where dragging a node past the left edge of the note and dragging it back without releasing the mouse could cause it to update the height of the first node, even though it wasn't explicitly clicked and dragged. That's mainly due to the hacky way I'm using the automation clip editing functions to disallow the user from dragging the first node left/right. I think it's a pretty minor bug (and would probably be tricky to solve without a lot of reworking) so it might be okay to leave it for now. Though I'm not sure if that's the same bug you are referring to.

[sakertooth]

Thanks for approving!

found a minor bug (?) where the green line disconnects once moved to the edge near the keys in the Piano Roll

I'm not sure what bug you are referring to. I did notice a similar potential bug where dragging a node past the left edge of the note and dragging it back without releasing the mouse could cause it to update the height of the first node, even though it wasn't explicitly clicked and dragged. That's mainly due to the hacky way I'm using the automation clip editing functions to disallow the user from dragging the first node left/right. I think it's a pretty minor bug (and would probably be tricky to solve without a lot of reworking) so it might be okay to leave it for now. Though I'm not sure if that's the same bug you are referring to.

2026-01-03.10-19-06.mp4

I think this is the same bug you're mentioning, but just for clarify I attached a video. I think we should fix this before merge?

[regulus79]

I've fixed the bug. I also made it smoother to use, so instead of the old drag ending and a new drag starting, it just kind of clamps the drag but still lets you move it up and down. It's hard to explain, but I think it feels better.

2026-01-04.10-35-58.mp4

[sakertooth]

I've fixed the bug. I also made it smoother to use, so instead of the old drag ending and a new drag starting, it just kind of clamps the drag but still lets you move it up and down. It's hard to explain, but I think it feels better.
2026-01-04.10-35-58.mp4

Great, thats a bit better, but I think the first node should always be attached to the note right?

[regulus79]

I think the first node should always be attached to the note right?

Not always, since a user might want to add a quick pitch-up or down from the previous note:

[sakertooth]

I think the first node should always be attached to the note right?

Not always, since a user might want to add a quick pitch-up or down from the previous note:

Oh, okay. If the first node only connects on either end of the note then thats fine. It just shouldn't float away because we wouldn't know what note is being shifted.

[regulus79]

Are we good to merge?

[bratpeki]

IMO, yes.

[sakertooth]

I am okay with it. We can revisit later if something pops up but this seems good for now and was tested quite aggressively.

[MWstudios]

Will this new tool support 0.5 semitone bending in the future, like the automation editor (or even finer tuning, for that matter)?

[regulus79]

Will this new tool support 0.5 semitone bending in the future, like the automation editor (or even finer tuning, for that matter)?

It probably wouldn't be extremely hard to add, perhaps letting the user hold down alt or ctrl or something. For vertical un-quantized movement, that's fine. But for the horizontal un-quantized adjustment, the current implementation where it essentially interfaces with the functions used by the automation editor means that it's a bit more tricky to get that to work.

[bratpeki]

Will this new tool support 0.5 semitone bending in the future

I think it's just noise, since it's a rare use-case.
Shift-clicking notes still opens the Automation editor, though, so there's that!

or even finer tuning

That'd require a rewrite of that part of the core, I'd think.
Just using the PITCH knob works for now.

[rdrpenguin04]

I feel like I end up using half-semitone detuning very often, frequently as an intermediate in a larger bend, or when I'm just bending a note for an effect rather than trying to hit a particular pitch