Skip to content
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

Closed
musikBear opened this issue Feb 16, 2014 · 43 comments
Closed

Selected notes volume behavior in Piano Roll #322

musikBear opened this issue Feb 16, 2014 · 43 comments
Milestone

Comments

@musikBear
Copy link

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.

@diizy
Copy link
Contributor

diizy commented Feb 17, 2014

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.

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 27, 2014

@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.

@diizy
Copy link
Contributor

diizy commented Mar 4, 2014

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.

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 18, 2015

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.

Then you could preserve that functionality with the new behavior? Another request: https://lmms.io/forum/viewtopic.php?f=15&t=1692

@tresf
Copy link
Member

tresf commented Feb 18, 2015

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.

@tresf tresf added this to the 1.3.0 milestone Feb 18, 2015
@Umcaruje
Copy link
Member

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.

@tresf tresf changed the title Glitch: Marked notes and volume in piano-roll Selected notes volume behavior in Piano Roll Feb 18, 2015
@badosu
Copy link
Contributor

badosu commented Feb 24, 2015

@tresf @Umcaruje @Sti2nd Can you please propose a modifier key? I am thinking in implementing this.

@badosu
Copy link
Contributor

badosu commented Feb 24, 2015

Is right click for individual notes on the volume/pad panel acceptable?

@musikBear
Copy link
Author

Is right click for individual notes on the volume/pad panel acceptable?

Do you mean here:
paste
Yes that will imo be good. a right-click at the cross, and a input box allowing all selected notes to have same value. This will also preserve the current functionality, that diiz describes
I really cant see any significant value in the current select between to modes -these can already be toggle changed with left-click at the same spot. Input for a group would be a much more valuble functionality, and could at later be extended to a meny allowing things like humanize or change by

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 24, 2015

Can you please propose a modifier key? I am thinking in implementing this.

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?

Is right click for individual notes on the volume/pad panel acceptable?

Logic has it that a context menu should pop up then, so Shift + Right click (and optional middle mouse button) is better.

@tresf
Copy link
Member

tresf commented Feb 24, 2015

@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

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 24, 2015

this feature changes the default behavior

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.

@tresf
Copy link
Member

tresf commented Feb 24, 2015

Fine tuning key is ALT with current and future Piano Roll logic, and available.

👍

musikBear really confused me with that mockup

👍 👍 😆

@badosu
Copy link
Contributor

badosu commented Feb 24, 2015

This is my understanding for this feature request and the most accepted proposal:

  • Today if we select more than one note and change the volume/pan of it, it changes each note individually. Except that @diizy told that there is a way to edit more than one note at once, but I never saw this.
  • There is a perception that it would be good if the default behaviour could be changed to change all selected notes at once by default, instead of individual ones
  • Then the old behaviour could still be used by holding a modifier key to fine-tune any individual notes even when they are selected. Currently, there's support for using the ALT key.

Let me know if I am mistaken.

@Spekular
Copy link
Member

Sounds good/right to me 👍
On Feb 24, 2015 10:05 PM, "Amadeus Folego" notifications@github.com wrote:

This is my understanding for the this feature request and the most
accepted proposal:

  • Today if we select more than one note and we change the volume/pan
    of it, it changes wach note individually. Except that @diizy
    https://github.com/diizy told that there is a way to edit more than
    one note at once, but I never saw this.
  • There is a perception that it would be good if the default behaviour
    could be changed to change all selected notes at once by default, instead
    of individual ones
  • Then the old behaviour could still be used by using a modifier key
    to fine-tune any individual notes even when they are selected. Currently,
    there's support for using the ALT key.

Let me know if I am mistaken.


Reply to this email directly or view it on GitHub
#322 (comment).

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 24, 2015

Yes, that's how it is and should be, I think.

@badosu
Copy link
Contributor

badosu commented Feb 24, 2015

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.

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 24, 2015

However, we should address the superposed notes issue in a different way

Isn't that what you proposed in your last comment, or are you saying we should find another smart way to solve this?

@badosu
Copy link
Contributor

badosu commented Feb 25, 2015

@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)

@tresf
Copy link
Member

tresf commented Feb 25, 2015

@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. :)

@musikBear
Copy link
Author

musikBear really confused me with that mockup

really ..
i was op, and my idear would preserve current behavior, and eradicate a strange redundent menu, that noone would miss. On top of that, we would have a contexr oppotunity for more interesting extention down the road
http://youtu.be/OH4K5331OWQ
but only imo

@Sti2nd
Copy link
Contributor

Sti2nd commented Feb 25, 2015

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.

@musikBear
Copy link
Author

👍 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'

@badosu
Copy link
Contributor

badosu commented Mar 1, 2015

@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.

@tresf
Copy link
Member

tresf commented Mar 2, 2015

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.

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?

@badosu
Copy link
Contributor

badosu commented Mar 2, 2015

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.

@Sti2nd
Copy link
Contributor

Sti2nd commented Mar 2, 2015

:( I'll look into it, but it is only the HUD (Unity) stealing this key, right? So it isn't Linux in general

@tresf
Copy link
Member

tresf commented Mar 2, 2015

:( 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)

@mikobuntu
Copy link
Contributor

@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?

@tresf
Copy link
Member

tresf commented Mar 2, 2015

I hope I have explained this clearly enough to understand, if not i can make a screencast perhaps?

Yes, easy to understand, thanks. :)

@badosu
Copy link
Contributor

badosu commented Mar 2, 2015

@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.

@mikobuntu
Copy link
Contributor

@tresf @badosu thanks guys :)

@tresf
Copy link
Member

tresf commented Mar 2, 2015

@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

@Sti2nd
Copy link
Contributor

Sti2nd commented Mar 2, 2015

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.

@mikobuntu
Copy link
Contributor

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 ;)

@tresf
Copy link
Member

tresf commented Mar 2, 2015

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?

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?

@badosu
Copy link
Contributor

badosu commented Mar 2, 2015

Oh, I just noticed that even blender is not able/not want to overcome this problem. Alt+Click drags it's window.

@tresf
Copy link
Member

tresf commented Mar 2, 2015

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!

@badosu
Copy link
Contributor

badosu commented Mar 2, 2015

I think enabling Ctrl+Alt to behave like Alt and mantaining Alt for non-linux users is sensible.

@mikobuntu
Copy link
Contributor

@tresf

      "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?"

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...

@badosu @tresf ... yeah this is an annoyance!

@tresf
Copy link
Member

tresf commented Mar 2, 2015

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.

@badosu
Copy link
Contributor

badosu commented Mar 2, 2015

I created #1810 for us to discuss this matter.

@mikobuntu
Copy link
Contributor

@tresf For sure and I think the way LMMS is at the moment with it's inconsistent shortcut behaviour across all windows makes it harder to remember the shortcuts too.... ok @badosu good idea :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants