Quote:
Originally Posted by mschnell
I did not mean a state of the surface, but the internal state of CSI. e.g. toggling Mute or whatever needs to hold the state of being muted or unmuted, and on the next button press use the previous state to calculate the new one.
|
Actually CSI doesn't work that way, there is no holding of state in that sense.
When you press Mute you execute an action, no notion of the button state is held.
If there is feedback the action simply asks Reaper for the current state of the Mute, and then sends that to the button.
CSI doesn't hold state, nor should it, too easy to get out of synch.
Quote:
Originally Posted by mschnell
This already does (kind of) work, but needs a single "button..." definition for as well the "press" as the "release" incoming message. This (currently) prevents CGI from internally doing different actions for press and for release.
-Michael
|
I still don't understand you I guess.
The following is an example of a button where press and release do completely different actions.
// Here we define the press and release as two separate buttons even though it's actually only a single button with press and release
SomeButtonPress
Press 90 46
7f in the .rst file -- give a name to the button press
SomeButtonRelease
Press 90 46
00 in the .rst file -- give a name to the button release
// Here we attach the 2 buttons we defined to whatever actions we choose
SomeButtonPress SomeAction in the .axt file -- tie button
press to an action
SomeButtonRelease AnotherAction in the .axt file -- tie button
release to another action
I presume this isn't what you want, but I am confused when you say "This (currently) prevents CSI from internally doing different actions for press and for release. "
The above is an example of exactly that, so I must be misunderstanding what you need.