There is a lingering design issue in CSI that has been driving me nuts for years.
It exists because of this:
Code:
Widget Fader1
Fader14Bit e0 7f 7f
FB_Fader14Bit e0 7f 7f
Touch 90 68 7f 90 68 00
WidgetEnd
For the coders, here is the uuuugly fragment:
Code:
if(GetActionContexts(widget).size() > 0)
{
shared_ptr<ActionContext> context = GetActionContexts(widget)[0];
context->RequestUpdate();
}
It basically says "If you find Action(s) in this Zone for a given Widget, make sure you only update the first one."
This prevents the dreaded "psychedelic display effect" from way back in the day.
I find it quite remarkable that the solution has been glaringly staring me in the face for years.
With all of the bitching I do about separating the Message Generator from the Feedback Processor -- I'm talking to you OSC, Console1, etc
the following construct does exactly the opposite:
Code:
Widget Fader1
Fader14Bit e0 7f 7f
FB_Fader14Bit e0 7f 7f
Touch 90 68 7f 90 68 00
WidgetEnd
Here we are doing exactly what I constantly bitch and moan about -- bundling the Message Generators and Touch Generators with the Feedback Processor.
Ughhh.
Methinks it's time to consider CSI 3.0.
Time to break up the components thusly.
Code:
Widget MG_Fader1
MG_Fader14Bit e0 7f 7f
WidgetEnd
Code:
Widget TG_Fader1
TG_Touch 90 68 7f 90 68 00
WidgetEnd
Code:
Widget FB_Fader1
FB_Fader14Bit e0 7f 7f
WidgetEnd
OK, that cleans up the .mst/.ost part of the bargain.
How about the Zone part ?
If we use the same approach, we end up with an explosion of Actions.
So, I don't think it's necessary to add Actions.
The existing Actions can operate in the context of the assigned Widget.
Currently we have this:
Code:
Touch+DisplayLower| TrackVolumeDisplay
Fader| TrackVolume
Here, the TrackVolume concept is split.
The TrackVolumeDisplay is a Feedback only Action, whilst the TrackVolume is triple purpose, Message Generator, Touch Generator, and Feedback Processor.
Propose we do the following:
Code:
Touch+DisplayLower| TrackVolumeDisplay
MG_Fader| TrackVolume
TG_Fader| TrackVolume
FB_Fader| TrackVolume
This does make the Zone definitions more verbose, but it does state the intentions much more explicitly.
All of this was triggered while thinking about the "NoFeedback" Widget Mode -- needless to say that disappears if we use this approach.
It would also clean up the parameter lists that follow the Action.
Message Generator parameters like step size, step lists, etc. would be on the MG_Fader line.
Feedback Processor parameters like, Widget LED ring style, colours, etc. would be on the FB_Fader line.
As far as code, the internals would clean up considerably -- the ActionContext class is currently pretty much a dog's breakfast
Just some very early morning ponderings...