it’s an interesting idea, and Im definitely open to new ideas.
however… you basically, have hit the problem I mentioned… Im already using pretty much all the UI elements…
but lets review the UI … perhaps we can think of something?
current TB UI review
enc turn = value change
push enc = reset
push + turn = fine
button 1-8 : binary functions/parameters for module
up/down : parameter row
right/left : page
LS + RS : midi/module options
theoretically LS & RS are ‘free’
but in practice they aren’t since Ive needed this in PMIX to switch between ‘groups’ of channels.
so, whilst not a generic function…
however, I suspect , this is going to be a frequent use case…
the reason is simple…
due to the 4 encoders, its natural to group everything in 4s. (e.g 4 channels)
this means, I tend to treat buttons 1-8, as 2 rows of 1-4 , to match encoders.
so you can now see… there are no buttons really left to do ‘other functions’
hence, PMIX using LS/RS!
this is a shame… as certain LS/RS would be a good place to add extra functionality.
note: GNPR buttons are NOT available for module use.
possibly P could be made available… but if it was, Id use this as a replacement for LS+RS,
because frankly I dont like this 2 button combo much… but its all that was available.
my thought on possible changes
a) replace LS+RS with P…
I’ll check if @bert is happy with this.
we don’t want to allow use of G/N/R as they have dedicated functions, and we dont want a user to get ‘stuck’ in the module view… but P really is not needed, once you are in P mode.
so I think it’ll be ok - and would be a great improvement imho.
b) LS / RS usage.
one option is to have a ‘generic’ use for these, and then things like PMIX can ‘override’ this behaviour.
I need to thing about this, and also what the usage exactly would be.
the main issue is… it needs to be a function I don’t mind ‘loosing’ in PMIX.
a lesser issue is also consistency i.e. users wondering why function doesn’t work in PMIX.
basically, this means it needs to be function that is more ‘nice to have’, rather than essential and/or doesn’t make sense in cases like pmix (so is no loss to ux)
so, not sure about this one… really I think overall id prefer to leave LS/RS as ‘module specific’ buttons.
c) push = reset → push = edit
again, need to review this…
as I mention previously, one feature I like on the ER 301 is that it has an ability to dial a value in precisely.
one idea I have is… push encoder would bring up an ‘overlaid’ panel, which is pretty big (half size of screen) with BIG numbers showing 4 digits, each encoder then changes that digit (push resets to 0)
note: the decimal place would be dependent on the scale… ie sometimes it would be 0.123 or it might be 10.21, 100.1.
now because we are in a different mode… I can ‘reuse’ all the buttons.
so Id have one for close, and could have one for ‘reset’ , but even max/min etc.
the principle behind this idea here is when we are in this mode , we are 100% focus on dialling in this parameter, not any other module function!
note: all changes to this parameter would of course be ‘live’ , so you can hear the difference its making.
what are the ‘cons’ of this idea?
the main one is reset become multi step. press encoder - press reset, press close.
ok, I could include a reset & close, but thats still 2 steps.
MOST of the time, I don’t thats an issue, but in some case it’s really nice to be able to reset quickly.
pmix is a good example of this, its nice to be able to set levels quickly…
so there we are back to a similar question - perhaps PMIX (and others) diverge from other modules?
I would say PMIX is a bit different from other modules - its quick performance focused, so its not meant to feel like you are ‘dialling in parameters’ , but rather you perform with it.
again, perhaps this is a special case - where the UX needs to be more focused on quick use, rather than lots of parameters, and dealing things in.
however, I do not think this is a UNIQUE case, e.g. I could see that CART (upcoming module) is similar, some of the ‘pleasure’ in using the module is its immediacy.
so sometimes, we need to trade immediacy for flexibility in SOME modules.
in fairness, I already have a bit of a distinction between 'standard ’ UI modules, that use a common metaphor, and ones like PMIX which have a rather different (albeit related) UI.
note: under the cover they share a my ui framework, but just can be specialised.
so I quite like this approach,
conclusion , tl;dr;
the current UI is crowded, its hard to find ‘space’ for other features.
I want the UI across my modules to be consistent.
Im pretty happy with the UI as is, and frankly, Ive a lot of UI experience, so did think this through quite well before using the model I came up with 
sure, Ive made some choices e.g. coarse has priority over fine (push) , people may prefer the other way around - but honestly, there are pro/cons both ways, neither is right - and I’m generally happy with my choices.
however, Im open to ideas, and generally do review things constantly - looking for different/better ways.
I do think perhaps I can allow a bit more ‘wiggle’ room by treating the modules with more performance oriented UIs slightly differently to other modules.
(I know when designing a module where the is a focus around performance)
I’ll look into P replacing LS+RS , though it needs a synthor change, I think it’s a nice one to do.
I don’t think I’ll re-use LS/RS, I think modules a bit of ‘space’ in the UI for custom functions.
parameter edit panel
it’s something Ive been considering for a while in different forms even though its going to take a fair bit of time to implement !
(I not only need to create panel, but intercept ALL ui events to stop them messing with existing ui code)
however, Im quite keen on doing this one, as I do think it would be a really nice addition to the UI for a few different reasons.
however, I should also say… when it comes to UI changes,
Id need to implement/prototype them, and play with the a bit, before deciding if I think they work or not.
UI/UX is all about ‘feel’ , and even the best UI ideas/designs sometimes just don’t feel right when you actually try them on the hardware.
(though in fairness, usually my experience tells me when they are likely to work, and hence worth that dev effort to try ! )
)
