Key ranges are displayed using a overlaid bar from note center to center (notice the way the top end of the green indicator includes the F# note) and they’re drawn in the color of the slot that the route connects to
Great to see work on this feature going ahead! A few things I’m not keen on :
It means that in order to benefit from the key range indicators we need to use rack colour, which we might need for other uses (eg distinguishing effects/instrument racks, indicating which racks route to which stereo output pair, etc).
It means that in order to benefit from the key range indicators we must use the onscreen keyboard, which takes up valuable screen space, particularly in live mode.
It means we need to visually cross-reference using colours when setting up zones. Look at the on screen keyboard, see the zone is red, so look to see which rack is red, then look to see what route maps to that rack, then you an finally edit the range…
It looks like a fair solution for use when setting up songs, as long as you’re happy to have your racks multi-coloured etc. But the need to cross reference visually by colour feels cumbersome to me. How about interlacing horizontal bars into the route rows in some way, so the visual indication is right where you go to edit the ranges? It would also clarify the situation when you’re using multiple MIDI controllers. Perhaps this in addition to the on screen keyboard.
Also, for those who need to use colour for something else, defaulting to one colour and having the key range bar light up when a key is routed in that zone?
Another approach might be to have the ranges appear in a separate horizontal widget that you can stack below the onscreen keyboard, or alternatively have displayed on its own. This would be great in live mode where you often just need to remember the rough zone layout for a given song state, and don’t necessarily need to see exact split points.
Thanks for the insights. I did consider some of what you suggested. Here’s my thoughts:
If these indicators were put inline with the routes then they wouldn’t be visible when using Show Notes, which means not visible in Live Mode, which I’m guessing is where the main value of these lies.
The colors just seemed an obvious choice but I agree with your comments that there might be conflicting purposes here.
Showing them as a second bar below the keyboard panel is a good idea, but I’m not sure how you’d correlate what’s displayed to an actual keyboard range when the keyboard is hidden. Would that indicator scale/scroll with the other keyboard panel?
I wanted to build this in a way that the height of the display area could be fixed so the window arrangement wouldn’t be jumping around as different numbers of ranges needed to be displayed. This makes is really hard to display any sort of text information - so I chose colors as the representation and overlaying on the on-screen keyboard seemed like a good idea since that takes no additional screen real-estate - so long as you have the keyboard displayed anyway.
I guess I’m a little conflicted over the purpose of this. Is it to accurately show exactly what’s mapped to what, or is it more just a visual cue, a reminder of what key ranges are active?
Thinking about your comments, just had another idea… what if the keyboard could be switched into “indicator mode” - which would collapse the keyboard panel down to just these indicators and a really thin strip to show the black key positions so you’d have a point of reference. This mode could be tied into the saved window layout for live mode too. Still doesn’t solve the colors problem though.
True…though not everybody uses Show Notes in Live Mode. But yes, you have a point - routes are probably the last place you’re looking when playing.
On the other hand, if you’ve got Show Notes visible, you won’t be able to see the racks, so the correspondence between zone and rack/plugin colour would be lost.
My thinking was that if you have the keyboard hidden, you don’t care about the exact positioning of zones, and all you care about it to see the general way the keyboard is split up (eg one small split on the left, then one big split above it, etc). The indicator would somehow lock to the keyboard’s size when they’re together, so the two are always in sync.
I think they’re both distinct use cases. While setting up songs you probably want to know the exact zone positions, so you can adjust them to what you need. But when playing I imagine most people would just want a visual cue/reminder of the general layout. Just my thinking though - we have many people on the forum who use Cantabile in very different ways!
I like that, and it also feels consistent with the way other aspects of Cantabile work, where the differences in usage between setting up and performing demand different layouts.
Regarding the colours, how about each route has a “Zone Colour” selector, which allows you to select a colour, and one of the selectable colours is “Use rack/plugin colour”? Another of the selection items could also be “Auto”, which chooses a unique colour; that way you can still get different distinct colours (for visual clarity) even if you don’t colour your racks.
Feature request 1 - if you click on the zone bar, it could bring up the route dialog where the corresponding zone is defined (if you don’t plan to make the zones draggable etc).
Feature request 2 - when you’re in the route dialog, setting up a zone, could the zone bars in the on-screen keyboard move dynamically, to give visual feedback of the zone while you’re setting it up?
One further feature request here (tell me to shut up if I make too many!)…if this were vertically resizable so that the zone bars get thicker as you expand it vertically, I think that would be excellent for Live Mode. Then you can spend as much vertical space on it as you like, and make sure the bars are thick enough to see (particularly for people using small displays live).
I’ve decided against the in-routing slot indicators (at least for now) but I have added both a color selector on the route with the option to use the target plugin/rack color and I’ve partially implemented what I’m calling “Compact Keyboard Mode” (see screen shot below). Also MIDI routes have a new state behaviour “Key Range Display” so different states can be displayed differently if necessary.
When in Compact mode the octave indicators disappear, the channel picker and capture mode button disappears, the black notes become very short. Also, the width of the keys is controlled by the non-compact mode height. ie: entering compact model essentially squashes everything vertically but keeps things the same horizontally. All of these metrics are stored twice - once for normal window layout and once for Live mode. I’m also probably going to disable playing the keyboard - it’s just too squishy.
I’ve decided against auto color allocation because it gets really complicated to keep the colors consistent as different songs and racks load and I think it would be confusing if the ranges display in different auto colors depending on what else is loaded.
Clicking on the indicators would interfere with normal “playing” of the keybaord, but I’m thinking of perhaps a right click menu to either bring up the route’s settings or enter an “edit” mode where you can drag the key range around.
New command on the route context menu that switches the keyboard into range editing mode, selects the route and if the route doesn’t currently have a range set, sets it to two octaves around Middle C - so you can then quickly drag the range:
A few thoughts on the situation when you have a route covering the whole keyboard range, and there’s no range bar:
Edit key ranges mode on the on-screen keyboard doesn’t allow you to modify that range
If you expect to see a certain colour for a certain rack/plugin when you have a route/range driving that rack/plugin, it feels a bit odd to not see that colour, in song states when you happen to be driving the whole keyboard range.
In fact if you start with a shorter range and extend it to fill the whole keyboard, it’s a bit unsettling when the bar disappears!
For the range indicators in route rows, it might also feel more natural to show them when you have a range that spans the whole keyboard, and maybe instead hide them when a route is disabled?
Good points and questions I also considered. Basically I was trying to avoid the situation where you end up with a stack of horizontal bars across the whole keyboard because it doesn’t add much.
That’s why I added right click on route “Set Key Range” command - it sets up a range so you can edit from there.
Maybe better would be to show the full range routes, but have the “show key range” check box turned off initially and automatically turn it on when a range is first set. That way it would behave similarly but you’d still have full control.
But if every other non-full range can be edited by just dragging the bar, it feels odd to me to require a different action for ranges that cover the full range.
I guess it depends how you think of MIDI routes - either as something that always has a range (even if it’s notes 0-127), or something that can optionally filter by note range. In the former case the visual bars represent what notes will play; in the latter case the visual bars represent the optional filtering action. The former feels more natural to me.
But I do see your point about the redundancy of lots of full range bars - although it does still provide useful information if you know what colour plays what sound.
I’ve just been setting up a routing which should just apply to a single note, i.e. a range E1-E1, and it seems that this isn’t necessarily well covered by the new key range indicators. Firstly you can’t drag a range to be any less that 2 notes, as far as I can see (which I can understand, given that it would be hard to draw the drag handles!). But secondly, if you set up a single-note range via the route settings dialog, the range disappears from the on-screen keyboard view.
This may be by design, on the basis that such a narrow range would be hard to do anything useful with. However, I would think it should at least be possible to show the range, even if it’s not editable? Typical use case, triggering a sample / sound effect. That’s precisely when a handy reminder of the zones is useful too…