piano roll editor : better snap to grid #4350 #4357
Conversation
|
Keeping offsets from lower quantization levels is useful. I think this may
have been discussed earlier in another issue or pull request.
If you want notes on the grid you can easily have that by placing new ones
or using the quantize button.
…On Mon, May 14, 2018, 22:12 rghvdberg ***@***.***> wrote:
When moving (dragging) notes, the notes snap to the grid lines.
Same for changing lenght (without shift or alt), note lenghts snap to the
grid.
------------------------------
You can view, comment on, or merge this pull request online at:
#4357
Commit Summary
- piano roll editor : better snap to grid #4350
File Changes
- *M* src/gui/editors/PianoRoll.cpp
<https://github.com/LMMS/lmms/pull/4357/files#diff-0> (22)
Patch Links:
- https://github.com/LMMS/lmms/pull/4357.patch
- https://github.com/LMMS/lmms/pull/4357.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4357>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIgVmnHwttxSAqPLi3o5Rt2215ZfMiyXks5tyeUWgaJpZM4T-b20>
.
|
|
Any other daw let's you drag notes to the grid lines. Current behaviour is imho very unexpected. |
|
Are you sure about that @rghvdberg? @Umcaruje can confirm this in Bitwig as well. Here's my thinking behind this:
Currently, I just move it over four 16ths, or switch the snap to quarter if I'm so inclined. With the proposed changes, the only viable option would be to use alt. I used alt to make the lead-in note, so I can't just switch it to a smaller timebase. Of course, all of this would be nullified if the PR does something considerably different from what I'm saying here, but I can attest that LMMS currently acts very similarly to other DAWs in this regard. Edit: I just noticed the issue you posted a few days ago. I should have disputed that instead of waiting until this, sorry about that! |
|
No it snaps all notes to the nearest grid.
On the initial drag it calcs the distance from a grid line and overrides
the off_ticks.
I should actually find out which note is grabbed and calc the offset needed
for that note.
Note to self: don't buy bitwig 😋
|
|
That's actually FL Studio. As I understand it, that behavior is standard across DAWs. I'll grab your code later when I get the time and make sure I'm understanding the change. |
|
Lol, I was trying to install FL studio to look how that one works. You just
saved me some time.
…On Tue, 15 May 2018, 12:50 Joshua Wade, ***@***.***> wrote:
That's actually FL Studio. As I understand it, that behavior is standard
across DAWs.
I'll grab your code later when I get the time and make sure I'm
understanding the change.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4357 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKNuh6veNKftXoVmIoqi8RATOo10Xk4Bks5tyrL-gaJpZM4T-b20>
.
|
|
Here's the PR I was thinking of, with discussion on why it's valuable to keep fine adjustments when moving at a higher Q: #4043 Here's an example in the piano roll of some recorded chords. First, the chords are on the offbeat: But perhaps I realize that I want them on the 1/2/3/4, or the recording was delayed by 1/8th for some reason. With the current behavior, I simply move them over two 16ths (though not visible in the screenshot, my Q is at 1/16th here): The chords keep their inconsistencies and slight delays. If your suggestion were implemented, they would now all hit exactly at the right time, with no delay between notes in a chord: Note that to get the notes as they are in the third screenshot, I simply hit the quantize button. So it's currently easy to achieve what I want (shifting the notes by a certain offset) and what you want (snapping the notes to certain positions). If moving notes also snapped them, it would be far more difficult to do what I want. I do not think this PR should be merged. I've explained why the current behavior is desired and SecondFlight has shown that it is common in other DAWs. That said, I do want to apologize for not bringing this up earlier, before you opened the PR. |
|
I guess I'm used to this behaviour Ardour Qtractor Drumroll .... LMMS (my PR) forgot this: the distance between the notes stays the same |
|
|
|
What if we bind that to a modifier key? Alt is taken, and I think shift is too, but we could put that on ctrl + shift or ctrl + alt or something like that. I would be open to this, and it's something I could even see myself using on occasion. I'm still very much against this as the default, though I will say that your most recent modification makes it considerably more usable in the general case IMO. Another option would be to make a toggle in the settings, something like "quantize dragged notes" (there's probably a better way to word that) |
|
Also, and I forgot to mention this before, you can quickly get a single note or the first of a group of notes to snap to the grid by dragging it all the way to the left and then back again. This might not be practical for really long patterns, but it's an intuitive way to go about it based on the interface. This doesn't beat a shortcut key or extra setting though IMO, especially with the new change you added. |
|
I've been pondering about a modifier key too. And maybe have a settings switch to set the default behaviour. |
|
I'm fine with this but not as the default. A toggle in the piano roll menu
or somewhere in the LMMS settings would be the best option IMO.
…On Wed, May 16, 2018, 07:23 rghvdberg ***@***.***> wrote:
I've been pondering about a modifier key too. And maybe have a settings
switch to set the default behaviour.
Better yet imho would be an extra move/nudge tool button.
The default being the new drag method and the old method the move/nudge
tool.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4357 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIgVmgOLR1wYg_K5TEbnKhiGTJAZq-g5ks5ty7fTgaJpZM4T-b20>
.
|
|
I've given it some thought and I think a modifier key and maybe a toggle in settings would be the best option. |
|
I agree, the UX on that is not ideal. I don't see any reason to have both a modifier key and a settings toggle. I think that would make it harder to find. Someone could turn on the setting and reasonably be confused as to why nothing has changed, unless the setting is worded right, but even then I don't see a good reason to make the user go in there if it's already behind a modifier key. |
|
Agreed 👍
…On Tue, 22 May 2018, 12:56 Joshua Wade, ***@***.***> wrote:
I agree, the UX on that is not ideal.
I don't see any reason to have both a modifier key and a settings toggle.
I think that would make it harder to find. Someone could turn on the
setting and reasonably be confused as to why nothing has changed, unless
the setting is worded right, but even then I don't see a good reason to
make the user go in there if it's already behind a modifier key.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4357 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKNuhwmDxoW3vcmX1dZ_tDdA40y4Rfylks5t0-7JgaJpZM4T-b20>
.
|
|
@rghvdberg Please use tabs for indentation. It's our coding convention. |
|
Yup I noticed. I'll fix it
…On Tue, 22 May 2018, 13:10 Hyunjin Song, ***@***.***> wrote:
@rghvdberg <https://github.com/rghvdberg> Please use tabs for
indentation. It's our coding convention.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4357 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKNuh2sM7yLVVMbxU5lo4mmZxUxdjpGcks5t0_IKgaJpZM4T-b20>
.
|
|
I've added a combo box.
|
|
This looks very nice!
As a nitpick, I think "nudge" and "snap" should be capitalized
("Nudge"/"Snap"). Our dropdowns tend to be sentence case, from the ones
I've checked.
|
|
At some point in the future it may be useful to consolidate some of the odds and ends sorts of options somehow, but at this point I don't think the UI is super cluttered. This is a fantastic solution as far as I'm concerned! Does it remember your choice between sessions? If that's not trivial then don't worry about it. |
|
Never crossed my mind to keep it between sessions. I'll have a look how to implement that. |
|
It would be a nice solution to the question of which one to put as the default. I'm not super optimistic about it since our settings require a restart to take effect. If you can find a nice way to keep a setting between sessions then we may as well be using that for all our other settings. But I suppose that's for another PR :) |
|
Do the other options (quantize, note lenght etc) persist between settings? |
|
Yeah, that's fair, they don't persist. Does it default to the old behavior? |
|
Yup. Nudge == old behaviour and the default. |
|
Are we talking about persisting in global config of lmms or in the individual project file? Or both? My two cents is that this is definitely a worth a new issue. |
|
@rghvdberg Alright, this can be merged as far as I'm concerned. Fantastic work! Aside from any potential bugs and cleanup of course. @justnope I was talking about globally. I think in this case it doesn't make sense as @rghvdberg pointed out, but separate from that it would be great to have settings that don't require you to restart the software for a simple buffer change. |
|
@PhysSong yes, in fact I think it's even more warranted now so we have consistent functionality between the editors. |
|
@rghvdberg Do you want to continue working on this, or let some of us take this over? @Spekular Are you interested in this? |
|
Would be fun to work on it again. Gimme a bit of time to set things up again. |
|
Continued in #5848. |
When moving (dragging) notes, the notes snap to the grid lines.
Same for changing lenght (without shift or alt), note lenghts snap to the grid.