Definition of „Message generator“: This term seems to be used for the functionality provided by the hardware device but then “Message Generators allow you to define” does not make immediate sense.
MST file syntax:
Within widgets always lines containing Keyword message message message …
Comments ?
A comprehensive List of all currently allowed keywords (allowing future enhancement by appropriate description)
We seem to have
Press
Faser7Bit
Fader14Bit
Encoder
EbncoderPlain
EncoderRevers
AnyPress
FB_TwoState
FB_ Fader14Bit
FB_ Fader7Bit
FB_ Encoder
FB_VUMeter
FB_GainReductionMeter
FB_QConProXMasterVUMeter
FB_MCUTimeDisplay
FB_MCUVUMeter
FB_MCUDisplayUpper
FB_MCUDisplayLower
FB_MCUXTDisplayUpper
FB_MCUXTDisplayLower
FB_MCUC4DisplayUpper
FB_MCUC4DisplayLower
FB_MFT_RGB
Are there even more already existing or planned ?
Is it officially supported to use the same (Midi) message in multiple (Generator) Widgets ? (See Shift / Shift_R example in the Wiki.) Will this fire all these Widget-actions ?
Is there a way to test the MST file without crating any zone file ? (i.e. some kind of debug window showing the result of the Widget definitions whenever something is sent by the surface device, and allowing to send something to the MST-widgets and watching the result on the surface device.
Wiki: “It's important to understand it's not the surface deciding when to turn the light on or off. It's doing it in response to a message from CSI. We don't want the surface managing the state of the buttons, that responsibility belongs to Reaper/CSI.”
Unfortunately this behavior can’t be avoided with several Surface devices (such as the XTouch Compact that I do own). As we don’t want to have the surface internally remember the state of a “TwoStae” we need to configure it as a “PushButton”. The LED of a button shows the state of the button pressed=On, released = Off. Hence the state toggled by pressing the button needs to be always sent after receiving a release message. I seem to remember that with certain devices it might be necessary to impose some delay before sending the Feedback message to avoid misbehavior.
Similarly the LED Ring of the rotaries are moved when turning the knob. And this can’t be switched off.
Recently we discussed a Widget that converts the turning of a “fader”-type rotary to a pair of “up/down” buttons. (i.e. encoder).
There is no description on Fader14Bit yet. I suppose this generator will cover the MCU-like “pseudo-Midi” messages. But there also is an official “high resolution CC” Midi definition for this kind of messages I don’t know if any surfaces actually do use this.). Moreover there is Midi2 and NRPM around the corner… (We found that NRPM in combination with HR CC is already used by A&H see ->
https://forum.cockos.com/showthread.php?p=2250425#7076 .)
Some devices use Sysex messages instead of standard Midi messages. How is this covered by CSI ?
While it’s obviously great to have Generators and Feedback processors dedicated to certain surfaces, IMHO it would be very appropriate to have a small set of more versatile (and hence less easy to use) “expert” Generators and Feedback processors allow for special purpose applications.
For Zone files:
“Action Reference” seems to provide a comprehensive list of all currently allowable actions. Are all of them intended to already be functional ?
It would be good to have a debug mode that does not actually execute these actions but just shows them in a log on the screen.
Do all such actions automatically provide the appropriate feedback to the Widget (or multiple widgets) they are associated with ?
Wiki -> Home-> Examples that come with the alpha download does not seem to work correctly
-Michael