View Single Post
Old 03-07-2019, 07:13 PM   #2711
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Quote:
Originally Posted by Geoff Waddington View Post
But, upon further reflection a Widget is a container that contains a ControlGenerator (CG), a FeedbackProcessor (FP), or both, or more than one of each, etc.
OK, that helps a few thing slot into place for me. The nomenclature of widgets, displays and controls has been a bit fluid in my mind.

So is everything a Widget? eg. If I just had a Press, that's a CG. Would that still be contained in a widget, or a widget is only when I want to compose multiple CG's/FG's together?

Actually, re-reading after writing this I think that's what you're getting at. If I had a non-motorised fader, I might define that just as a CGFader14Bit. But if I have a motorised one, I can use a couple of these primitives (CGFader14Bit, FBFader14Bit) together in a composite Widget. So a widget becomes an optional structure we can use to combine multiple primitives to model something more complex.

Is this what you're thinking?

This might also simplify the earlier discussion about the messages in the PressFB doing double duty for control and feedback. Here they're separated within the widget, so can be entirely different messages.

Edit: Oh wow, just had an "Aha!" moment. If you take this further, one widget doesn't have to map down to one physical entity on a surface (like a button). No reason I couldn't create a widget that combined a button with a seperate light for FB, or two buttons into a single logical Widget. Their messages are separately defined, so CSI probably doesn't care. Given they are all in the one MST, I guess the main restriction is they are on the same surface.

Cheers
Malcolm

Last edited by MalcolmG; 03-07-2019 at 07:45 PM.
MalcolmG is offline   Reply With Quote