-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selected notes volume behavior in Piano Roll #322
Comments
There's a problem with this idea. The current functionality allows you to select a group of notes, and then only adjust the vol/pan of those notes, while ignoring all the others. This is especially crucial for notes that are on top of each other, in the same "timeslot". If your suggested change was implemented, then you'd have to in these situations select each note individually one by one and that would be inconvenient. |
@diizy Well, that sure never worked for me and still don't. And yes, it is extremely annoying when the notes are on top of each other. |
Sure it does. If you have two notes on top of each other, select one of them, then adjust the volume in that spot, and only the volume of the selected note changes. If that doesn't work for some reason, file an issue for it. |
Then you could preserve that functionality with the new behavior? Another request: https://lmms.io/forum/viewtopic.php?f=15&t=1692 |
I've read and I believe this request is valid from a usability perspective. I'm not entirely sure what @diizy's described conflict is with the implementation. I would expect default behavior to raise volume of all selected notes proportionally with a modifier key to allow the adjustment of a single note. |
I second this, seems like the most logical behavior. |
Is right click for individual notes on the volume/pad panel acceptable? |
Grrreeat buut, what are you implementing exactly? Are you going to have a green master volume line in the left panel, but then you don't need a shortcut key?
Logic has it that a context menu should pop up then, so Shift + Right click (and optional middle mouse button) is better. |
@Sti2nd, this feature changes the default behavior... when all notes are selected, changing the volume of one selected note raises the volume of all selected notes. To maintain the old behavior, he's asking which modifier key would allow it to go back to the single-note-volume behavior. I would say whatever we use in other areas for "fine tuning" should work here too... (CTRL?) -Tres |
Yeah, I thought he would do that, but he didn't explain anything explicitly so I asked to be certain. musikBear really confused me with that mockup. Fine tuning key is ALT with current and future Piano Roll logic, and available. |
👍
👍 👍 😆 |
This is my understanding for this feature request and the most accepted proposal:
Let me know if I am mistaken. |
Sounds good/right to me 👍
|
Yes, that's how it is and should be, I think. |
Re-reading @diizy's comment I think I understand what was his concen with this. However, we should address the superposed notes issue in a different way, in a way that supports this feature request, which is an usability improvement in my opinion. |
Isn't that what you proposed in your last comment, or are you saying we should find another smart way to solve this? |
@Sti2nd The problem with the superposed notes is an UI problem that is orthogonal to this improvement, the thing is that the old feature could alleviate some problems with the superposed notes issue that the new one won't in the same way. (requiring a modifier key now) |
Well, we still have the ability to select a single note. :) |
really .. |
I tried to understand your idea musikBear. Context menu is fine, but the location is illogical. Makes more sense to right click on the selected notes itself, or alternatively the field showing the green lines. However your idea does not fix the bug, it just adds functionality to specifically bypass it. I am also liking my own idea about a master line in the field you mention which would scale the selected lines correspondingly instead of matching all the values. This is also just a bypassing of the problem, but it can be a useful feature no matter what solution we decide. I like the way badosu suggest the most. |
👍 goody. I just try to avoid having to 'mouse-aim+ click' on very tiny hotspots, when i design ui's, because those micro-manipulation are the most damaging, in respect to lateral epikondylitt 'rotatorcuff-aching' / or in milder form 'mouse-wrist-pains' |
@Sti2nd @tresf Some time in the future we need to get rid of these keybindings that use the alt key. The issue, at least for me, is that pressing alt before clicking makes the whole window dragable, which undermines the idea of fine tuning. So you have to click, and after clicking holding alt. I almost finished this feature, I am just making this consistent with the other possible modes now, mousewheel and double-click events. |
Ah yes, that is a problem for sure. Windows and Mac don't have this window-drag hotkey in the OS like Linux does. That limits all of our ALT-based shorcuts... Hmm... I tested and CTRL+ALT+DRAG on Ubuntu and it doesn't drag the window, but that seems quite the complicated work-around. Hmmm... @Sti2nd? |
Ok, so if this is not an issue on Windows or OSX I will retain the proposal. I'll have to ask help from you guys to test the double-click with alt pressed on my PR, because I can't test this. |
:( I'll look into it, but it is only the HUD (Unity) stealing this key, right? So it isn't Linux in general |
All Linux distros have supported this as far back as I can remember. This ALT+Drag window works on Gnome, KDE, Xfce and Unity AFAIK. It may be inherent to X, but it is an important shortcut combination to remember and be cautious to avoid when picking our permanent bindings (or at least provide an acceptable alternative shortcut for the Linux users) |
@tresf generally this is true that ALT+Drag will move the whole apps window, it seems there is a possible override , well more of a feature that would need to be implemented. Some apps namely Renoise and Bitwig can go fullscreen on ubuntu ( unity ), by this i mean " totally fullscreen i.e taking area over the main top toolbar on ubuntu which causes ALT drag to Fail ( which we would want ), But this is a toggable feature which Renoise seems to be able to handle for some reason, but Bitwig goes back to the default drag window behaviour when it is under Gnome/unitys normal maximise. I hope I have explained this clearly enough to understand, if not i can make a screencast perhaps? edit I should have added that Ideally we would ( if the ALT-Drag were used ), need to be able to handle all window situations i.e fullscreen, maximised, resized etc for this to work* looks like it may be possible to achieve this with QT ( just a quick look at the docs and some research ) QWidget::setWindowFlags( Qt::X11BypassWindowManagerHint ); but I believe this overrides the window management for the whole app which would prob not be preferred, and to call this or similar on every ALT+Lmb when working in the piano roll or whatever, would probably be overkill i think? |
Yes, easy to understand, thanks. :) |
@mikobuntu Thanks for the heads up, I'll take a look to see if there's a specific window flag that just disables the alt binding. |
I don't think we'll have success without messing with volatile-to-change and desktop-environment-specific desktop settings. Instead, I think we need to have a long term plan for how we handle the ALT shortcuts that require left mouse button clicks.... (Hence tagging @Sti2nd). -Tres |
I just realized why LMMS have used ALT for fine tuning before, it is because you first click, and then press the modifier key. So we could still use ALT for fine tuning but you would have to click on the note/pattern you would like to resize or move first. When it comes to this issue I proposed a key I thought definitively wouldn't be used in combination with selection (holding CTRL is selection tool as of now), so basically I was wrong cause I didn't knew about the HUD shortcut. Maybe Alt + Super then? In the future fast select will probably not be CTRL as cloning/duplicating is usually ctrl + drag on stuff, so then maybe Ctrl could also be an alternative. I have added this functionality to the table #322. I was hoping to begin testing the new shortcuts soon if I am capable of building LMMS and change the code myself. |
ALT + Super would work fine, in a rare case it could be a user combo in compiz, but they could easily change this, so I'm behind this shortcut ;) |
ALT + CTRL + Click would probably be slightly less cumbersome, but what is the impact of this? Where else will we need to do this? Is there another modifier key available? Should we allow the old shortcut too, since those users aren't affected by this? |
Oh, I just noticed that even blender is not able/not want to overcome this problem. Alt+Click drags it's window. |
Yeah, Inksckape too... Quite a few people annoyed with this behavior... but it is not going away any time soon, we might as well accommodate it! |
I think enabling Ctrl+Alt to behave like Alt and mantaining Alt for non-linux users is sensible. |
I would need to follow the changes/planned changes for the key combos to fully answer this question and the current key combos, as i tend to be a mouse clicker more than using shortcuts sometimes in LMMS... |
I think that is the problem... we don't always have mouse or menu shortcuts for fine-tuning stuff... which is perhaps part of the problem. |
I created #1810 for us to discuss this matter. |
Non critical glitch
Intuitively, it is more logical if all marked (selected) notes volume or pan could be controlled simultaneus. Eg all maked notes should change to the same vol / pan setting as anyone of the marked notes, the user change in the vol/pan section in the piano-roll.
The text was updated successfully, but these errors were encountered: