Extended ViewControl

[tmfset]

So as is the ViewControl lua object operates on a single main-view "control" object and a sub-view display for modulation/configuration. I'd like to extend this concept to multiple main-view "control" objects each with their own sub-views.

This sounds very much the same as what the spotted strip already is; a collection of "controls", but I think there's a benefit to further segregation: graphics that expand over multiple plys.

For example, here's a POC I'm working on for register where the register view contains a single bar-chart expanding over two plys with two separate controls contained within, reset and length:

My idea here is that the reset and length sections of that view will scroll in tandem with the sub-view, allowing the user to configure "on-the-fly" which parameter they're interested in adjusting. One could, for example, switch from adjusting the "length" of the register to the "offset" (via the hold-press floating menu) and the main-view and sub-view would both update to show the selected info.

Taking this idea even further I'd like to create a sampler view that completely forefronts the wave form and embeds a set of smaller controls on top of it, tucked out of the way. I think this would make it much easier to visualize what's happening behind the scenes without having to dive into other views.

I've already started expanding on top of the built in ViewControl with some of these ideas, but I'm interested in feedback / thoughts from others.

[tmfset]

I should say that implicit in this design is the desire to not show a lot of controls for each unit. I want to add more functionality while keeping each unit under 6 ply, focusing on the important controls first but still allowing access to others.

[odevices]

May I suggest a design invariant that will keep the complexity from exploding while allowing you to do (I think) everything that you mention?

Each ply shall contain at most one focus point (usually some widget or part of a widget) that can accept user input (usually the encoder).

So for example, if you decide to stack widgets vertically, all but one of them will ever be capable of receiving the encoder's focus. The other non-focus-able widgets are just for display.

[tmfset]

Yea exactly, the M buttons must still correspond one-to-one with a control in hopefully a clear way. That will ensure it's "obvious" what will focus when pressing an M button.

In my little POC, the side showing greyed-out numbers is a hint that there are further parameters below this one that can be accessed.

[odevices]

Your POC example did spark an idea.

Currently all units have the ability to collapse horizontally in order to make navigating long chains easier. Most controls also have the ability to expand to show some kind of context (output signal scope or sample waveform atm) while hiding the other controls in order to make room for the context view.

Combining these 2 concepts so that entering a control's context view would (instead of hiding) vertically collapse the other controls to just their labels thus making room above for the context view. This is visually similar to your histogram with the shortened controls underneath but the collapsed controls are just 8-10px high labels (that you can still select) leaving as much vertical room as possible for the context view. The 64px height of the display is cramped enough as it is.

[tmfset]

In some of my previous experiments I had something like this with the histogram display taking up nearly the whole vertical space. The thing I missed most though was a clear way to still read the parameter values at a glance. I also tried removing the labels but the lack of context was just too confusing. What I really came to was, I want to have my cake and eat it too. That is have the context view and parameter values always visible by default.

So I think collapsing to display just the parameter readout and label would work well, switching focus from the faders to the scope view. In a bunch of my units I've been using the secondary views to hide additional params though so it's not clear how those would make the switch, unless I also adapt them to that inline "vertical scroll" idea.

[odevices]

The thing I missed most though was a clear way to still read the parameter values at a glance.

Do you think you would find this to still be the case if you could quickly return to the regular all controls view?

[tmfset]

I think it would be an improvement but since it's still a button press away it feels like the same problem, lack of immediacy. I would even prefer putting context first and giving the option to hide it.

Since the context (scope / whatever) can provide immediate feedback on what you're doing I think it helps first time users visualize what they're doing without any extra knowledge.

For example my first shift register unit has no display at all, so you kind of have to already know what a shift register is to really understand what it's doing. In my new version I hope that the "always on" context lets you learn and discover as you fiddle; when changing the length param you can immediately see the display update to reflect that, reinforcing the connection.

[tmfset]

It's not clear that this would actually be useful all the time, but I think even little things can go a long way.

I was messing around with the sine wave oscillator for example and thinking, wouldn't be cool to see how the feedback shapes the wave just by adjusting the parameter? As is it's a button press away but kinda takes you out of the action for a second to get there.