SHIFT+FOCUS at least is probably going to be used for other things. SHIFT+HOME is COMMIT so I would avoid that one.
Are you sure it is a good idea to have a special set of key combos that work just for your units? If I had to suggest a place to put access to alternate unit views/pages, then I would add them to the long-push menus like they already are for the existing views:
Long-push menu on unit header contains:
expand: show all controls in the “expanded” view
collapse: show only header
Long-push menu on a unit control contains:
expand: hide other controls, show only scope and focused control
collapse: show all controls again
So you would have the option of adding more views to the unit via the header menu and more control-specific views via the control’s menu.
Also, pressing ENTER on the header cycles through a unit’s views/pages while pressing ENTER on a control cycles through the control’s views/pages. That is the design intention but the current implementation is only aware of the above views and does not take into account custom views/pages. That should probably change.
Oops SHIFT + HOME is actually zero, so that’s certainly out of the question. SHIFT + ENTER is COMMIT. (Btw what is COMMIT for exactly? I don’t think I’ve used it before.)
I’m thinking more seriously about this long-press approach now… if I could tell which item the long-press scroll is hovering I could toggle the sub-screen views in real time.
I think there’s certain times when using the control sub-view is ideal, like showing the scope or a couple of related controls. But going forward there’s going to be times where the number of secondary controls you want to provide looks cluttered there, especially for non-modulatable parameters / options.
For a lot of my custom controls I’ve been gravitating towards the sub-screen to keep lesser used features out of the way but still immediately accessible. This is especially practical, I think, when trying to constrain the number of top screen controls to just 6 ply.
Edit: Oh hm here’s another wild idea: put multiple “spot” descriptors in a single ply so that one naturally scrolls over it with the encoder. Maybe kind of inconvenient though.
I had tried it once years ago. I ended up not going that route because having a spot only accessible via the encoder and not the Mx buttons was (to me) potentially confusing. Still, maybe there are some special cases where it could make sense?
Ha sorry by “tell which item the long-press scroll is hovering” I meant programmatically. So I could use the index to modify the sub-screen view to show what that view will be if the Mx button is released.
Makes sense, yea it would be kind of confusing. A lot of my ideas seem to break the “simplicity first” rules of the existing UX
No, you are right. The only officially available methods for the floating menu are currently:
-- shows the floating menu for the given UI object
-- selects an item in the floating menu
-- closes the floating menu and returns the current choice index
@odevices This does look pretty cool with the menu arc:
Perhaps kind of annoying if you want to set the gate for each one, one after another though. Maybe I could go to the next view on SHIFT + MX?
Edit: That does work out nicely, but the Section code has to be updated to honor the result of spotPressed to prevent opening the menu overlay:
function Section:spotPressed(viewName, spotHandle, shifted, isFocusedPress)
local view = self.views[viewName]
if view then
local spot = view:getSpotByHandle(spotHandle)
if spot then
local control = spot:getControl()
local index = spot:getPositionOnControl()
local handled = control:spotPressed(index, shifted, isFocusedPress)
-- Don't start the menu if the control handled the press.
if not handled and control.getFloatingMenuItems then
function PagedViewControl:onFloatingMenuChange(change, index)
-- The first index is always cancel
if index > 0 then
self.subGraphic:setPage(index - 1)
function PagedViewControl:spotPressed(spotIndex, shifted, isFocusedPress)
if shifted then return true end
return ViewControl.spotPressed(self, spotIndex, shifted, isFocusedPress)
function PagedViewControl:spotReleased(spotIndex, shifted)
if shifted then
return ViewControl.spotReleased(self, spotIndex, shifted)