Add a simple label for "root" note and selected key/note range

[spechtstatt]

Enhancement Summary

#5868 added also a feature to select a key/note range by dragging an arrow from the left and/or the right side of the piano inside the instrument window.

The idea of this enhancement is to add a simple informational label for displaying the "root" note and the selected key/note range. Somehow similar as seen here in the piano roll limiter of FL Studio:

Taken from here: https://www.image-line.com/fl-studio-learning/fl-studio-online-manual/html/pianoroll_limit.htm

Justification

The key/note range is not really visible in the first place and can only be discovered by scrolling to the begin or the end of the piano view which many users may not do without already knowing about the feature. At least this is the state of the master branch some weeks ago.

The discussion in #6210 also showed that this feature may not be as obvious as it should be, because this already implemented feature would e.g. allow the assignment of different notes on channel 10 to use a drum pad. Of course this would not be a really convenient way to set up such a midi channel and key/note assignment - for this a different UI solution may be needed - but it would give an indirect hint to users that a possibility to modify this key/note range is at least likely.

And the additional "root" note display may allow a better visual indication if it was set to a black or white key which is sometimes difficult to see just by the rectangle marker as seen here:

Mockup

A slight increase in height of the instrument window may be needed though.

[Monospace-V]

Would reducing the width of the rectangle be a viable alternative to the root note confusion (assuming we don't add an extra informative bar)?

[he29-net]

Would reducing the width of the rectangle be a viable alternative to the root note confusion (assuming we don't add an extra informative bar)?

Or maybe even turn it to an arrow pointing down? That would also help in situations when the range starts or ends at the base note position (so the icons overlap).

As for the info bar: IMO, most people will not touch the range or base note most of the time. So most of the time, the info bar would be redundant and only take up space. I agree that the range feature is not very discoverable, but it would be nice if it could be addressed in a less "invasive" way, if that makes sense? Perhaps the range could be displayed in a tool-tip for the base note, which users already know and use? (But then again, because they know it, they won't be waiting for a tool-tip. So it would be a useful hint primarily just for new users. Unless we change tool-tips so that they are displayed with no delay in the toolbar; I remember reading some idea like that, but I'm not sure if that is something that is still planned.)

[allejok96]

How about a context menu when right clicking the piano? Set lower/upper key range. The same could potentially be added to the context menu in piano roll.

But we should be thinking about what is the real problem we are trying to fix by having a note range limitation? Is it just another hacky way to make a drum pad? Perhaps we should address that issue with a more elegant solution than making the range setting more visible.

[spechtstatt]

Well I see two basic issues here (but maybe not exhaustive though?)

1. using really a range of keys e.g. for splitting a keyboard

2. the single key assigment as it would be needed e.g. for a drumpad

The challenge is that both may mix up with the midi channel assignment - especially with the drum pad. And in both cases also an auto detection feature would be helpful.

But the key assignment itself is not necessarily related to a midi input.

I have thought a while about a convenient solution for both requirements, but I found only the following two basic options:

• add the key assignment to the midi area - as I did it in Support note filtering inside MIDI input instrument settings  #6210 but with the difference of setting the existing key range. Not sure if this would be a good idea because this "midi" setting would then also set the key range, but at least some space is available there and many users may search such a functionality where the midi input channel is located.

• add a complete new form which lists the tracks together with a key (range) assignment. This may need a filter or switch to change between instrument and bb tracks. But I would consider this more the brute force solution. On the other hand, as @he29-net mentioned, this functionality would not be needed as often.

By the way: yes, I think the arrow down for the "root" note would be a good idea.

[spechtstatt]

Regarding the context menu:

It would help if you want to set key ranges without the need to scroll all the way to the left or right to get the arrows for dragging.

Mouse click on the bar together with a key (e.g. "L" And "R") may also be an easy alternative.

[he29-net]

what is the real problem we are trying to fix by having a note range limitation? Is it just another hacky way to make a drum pad?

@allejok96 The first impulse to implement key range limits was to allow users to set up a basic split keyboard. But it isn't really an optional feature that can be replaced by something better: key range limits are part of the Scala keymap definition, it is required to support custom scales and key mappings.

I agree that the feature is not very useful to make use of drumpads, but it wasn't meant to be. One problem is the UI: something like "hold Shift while clicking the piano to set First and Last note to the current key" would probably improve this use-case a lot, but would not be any more discoverable than the hidden arrows.

But then there are other problems: the drumpad would work with a MIDI keyboard for live playing, but you would still have to record one track at a time, which defeats the purpose of having a drumpad with various instruments. Or you may want to have the drums recorded all in a single track so it is easier to manage, but then you can't distribute the notes to all the individual instruments (unless you are on Linux and use the MIDI through virtual "channel" or whatever it is).

What I'm trying to say is that there is probably much more that needs to be done for proper drumpad support. Trying to slap some GUI hacks on the range setting to shape it into some sort of "preliminary drumpad support" does not seem to me like the right way to approach it.

@spechtstatt Holding keys like "L" and "R" has two problems: one is that letters are already used as MIDI keyboard alternative, and the other, again, that the user has to know about the keys. But the context menu could probably work, and does not create any more fixed controls that would take up extra space in the instrument tabs.

Learn / autodetect feature could be useful, but I wonder where it would be triggered from? By the time you go to the piano view and select "auto-detect first note" from the context menu, you could have already pushed the key to see which one lights up, and and set it as the first note manually. It's basically the same operation, just in reverse order (press the key, right-click, set, vs. right-click, auto-detect, press the key). But the first case could involve some scrolling, so I guess autodetect still wins.

---

So, to summarize what I gathered from this discussion: (edited after subsequent posts)

1. proposed PianoView changes to improve the split keyboard use-case:

• change the base note indicator to ▼ (to make it clear which key it is pointing at and help with overlaps)
• add a context menu that can set first, last and base note directly to the key under cursor (improved convenience and discoverability)
  • optionally add auto-detect feature that sets the range based on MIDI input (low priority)
• allow to "summon arrows to the current key" by Shift + click on the bar or by a context menu option (because why not, saves time)
• add a tool-tip that shows all three values (first, base, last) when hovering over the bar (to help the discoverability of first / last note setting)

2. proper drumpad support needs more than key range hacks can offer, so apart from some generic usability improvements from use-case 1), it is an issue that should be addressed separately (I'm sure there are already issues about in, and even a few abandoned PRs).

Anything else? I may add it to my long-term ToDo list, but if anyone wants to implement it, go ahead, I can't say when I would get to it. (These are all simple changes, might be a "good first issue" for a new dev. Just sayin'. :) )

[spechtstatt]

@he29-net : yes, I was not sure if I even should write about the L/R key idea because I was somehow expecting that it would not be that easy :-)

And yes: after your comments it seems that the whole drumpad issue is much more difficult than I first thought.

So, thanks for all the feedback and because I am anyway a beginner searching for a "good first issue" I could try it. Would also help me to get more used to GitHub and the rebasing procedure.

I don't know how you organize the tracker here, but I would close this issue and add a new one (e.g. "Improve split key usage in piano view" or so) together with the list of tasks proposed by @he29-net if its ok for all.

[allejok96]

• +1 for changing the arrow
• +1 for tooltip when hovering the bar
• Skeptical of shift click. If that is added, it has to be written out somewhere for the user to see in e.g. a context menu. Please don't add more hidden modifier-key-click actions. I had to start coding before I discovered all of the ones in Piano roll.
• Auto-detect is neat, but at the same time a bit overkill in this context, as you can see which key you are pressing in the piano view. @he29-net I think your auto detect feature deserves a more refined place to live in, than just existing for these 3 seldom changed settings.
• Again, if these are all just ways to make a MIDI hack more visible, I don't think we should put that much effort on polishing it. While it's great that is is now possible, we really don't want to tell people this is the way to do it...

[allejok96]

@spechtstatt if I was you, I'd just begin by making PR for the small visual changes

[he29-net]

Skeptical of shift click. If that is added, it has to be written out somewhere for the user to see in e.g. a context menu. Please don't add more hidden modifier-key-click actions. I had to start coding before I discovered all of the ones in Piano roll.

@allejok96 There are hidden useful shortcuts all over the program, but I don't think we should get rid of them because they are hard to find. In most programs, keyboard shortcuts are typically a) used by advanced users (to make their life easier and work more efficiently) and b) discovered over time or by reading the manual. (I''m still finding new shortcuts in Blender after 15 years.. especially now that they changed half of them in a recent big UI overhaul :)) )

The Shift + click would be no different: you can still scroll to the edges and grab the arrows individually or use the context menu (to be implemented), this would just add a less intuitive way that could do it in one click as opposed to 4. Or 2, if the context menu also contains a combined "set first/last to this key" option. Actually, in that case I wouldn't really miss the Shift click, so maybe you are right and the context menu is all we need..

The autodetect seems to me as an overkill as well, I just mentioned it since it was suggested in the earlier post. But since PianoView already gets the pressed keys, it should be quite easy to add. So I thought why not, if someone wants to put the work into it.

@spechtstatt I'm just a random opportunistic contributor, so I don't feel competent talking about tracker organization. :)) But I agree with Alex, you could make a branch where you implement the small changes, then open a pull request and wait for feedback, I guess. You could also open it as a draft PR before you are finished, that way you wouldn't have to create a new separate issue to discuss it.