Go Back   Cockos Incorporated Forums > REAPER Forums > MIDI Hardware, Control Surfaces, and OSC

Reply
 
Thread Tools Display Modes
Old 03-04-2019, 02:34 AM   #2681
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Thanks for your response Michael,

Quote:
Originally Posted by mschnell View Post
IMHO it's not a good idea to set the device to such toggle mode. This is very likely confusing to CSI and not supported by CSI.
This is the default mode for these buttons, but I'll research to see if I can change them. This controller has spent its whole life in Mackie mode, I've only switched it out today as I've been exploring CSI.

Out of interest though, why is it confusing to CSI?

Quote:
Originally Posted by mschnell View Post
(7f on press, 0 on release (alternative (d) in your other message, if this is the options to configure the firmware of the device)
No, these were the options I could think of for responding to it in CSI.
MalcolmG is offline   Reply With Quote
Old 03-04-2019, 04:34 AM   #2682
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
Default

Quote:
Originally Posted by MalcolmG View Post
Having had more time to think about it, this is the key. I fell into the trap of forgetting that I have to match what the hardware is doing. It's going to send what it sends, regardless. All I'm doing is deciding what I'm going to respond to.
If you're using my BCF download, you'll need to load the BCF2000_SetUp.syx file into your BCF2000 before starting. This will set up all the controls on the device to match the BCF2000.mst file.

Quote:
two unexpected things here:
- I expected it to hit the boundary of Track 1 and stop, so I'd end up with tracks 1-8 in the current bank.
- even if it didn't do that, I'd expect tracks 1-4, not 1-5. ie. it seems to be off by one
I agree, navigation is currently undergoing a major overhaul in CSI at the moment, so hopefully we'll be able to address this issue soon. It can help to set up a pair of buttons to bank by a unit of 1, as well as 8.
MixMonkey is offline   Reply With Quote
Old 03-04-2019, 04:57 AM   #2683
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
Having had more time to think about it, this is the key. I fell into the trap of forgetting that I have to match what the hardware is doing. It's going to send what it sends, regardless. All I'm doing is deciding what I'm going to respond to.

So, in the case of this button, it's like a toggle, press on and then press off. I can decide to respond to that in a few ways:

a) A Press definition with the ON message
b) Two Press definitions, one with ON and one with OFF
c) One Press definition with both messages
d) A PressRelease definition with both messages.

a) and b) make sense to me, but not clear how c) and d) deal with the physical button sending the OFF message. d) seems to run the same action as it does when it receives an ON message. c) doesn't seem to do anything on OFF.
Yeah, the switch thing can seem bizarre.

I just took a glance at your website and see you are a programmer, so we'll do it this way:

Here's the simple policy in CSI - we steal a great lick from others including the VST designers -- all values are normalized to range of 0.0 - 1.0.

That means we can substitute any control for any other -- We can assign a switch to Track Volume and have silent to full volume the only two possible settings, wouldn't recommend that one

So, in order for that to make sense, there is no sense of previous, there is no latching.

A press sends a 1 -- press it again, it sends a 1.
A release sends a 0 -- if the hardware is capable of generating it.

The FB variations send feedback from Reaper to the hardware.

The thinking is -- a Press sends a 1 to Reaper, whatever that means.
It DOES NOT light up the light on the switch !

If FB is enabled, Reaper will send the correct state to the light.

Consider pressing Record -- Reaper only goes in to Record if at least one Track is Record Armed, so pressing Record MAY engage Record...

Now consider pressing the Record GUI button with the mouse (with some Tracks armed) -- the hardware light should come on, and it will with the FB variations.

Now... to the way controllers like yours works in the mode you're using.

For good reasoning for a certain set of use cases, some controllers work in "latch" mode.

The first press sends a 1, the second press sends a 0.

For the use cases considered, this works well.

It sucks for the CSI use cases

Here's what the hardware is saying -- "Aha, you pressed 1, we're going to the 1 state"

CSI counters "Uh Uh, you ATTEMPTED to go to the 1 state, I'll tell YOU what state we go to !".

So, you can sometimes work around these types with FB variants and other tricks, but for you the best solution is to get @MixMionkeys sysEx file and tame your controller

And yeah, lots of bugs in this build, completely refactoring to support the new file syntax, will clean up after major refactor complete
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 03-04-2019 at 07:38 AM.
Geoff Waddington is offline   Reply With Quote
Old 03-04-2019, 05:08 AM   #2684
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
Default

Quote:
Originally Posted by MalcolmG View Post
Out of interest though, why is it confusing to CSI?
AFAIU, the CSI "button" definitions expect constant and distinguishable "press" and a "release" message.

-Michael
mschnell is offline   Reply With Quote
Old 03-04-2019, 02:54 PM   #2685
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Quote:
Originally Posted by MixMonkey View Post
If you're using my BCF download, you'll need to load the BCF2000_SetUp.syx file into your BCF2000 before starting. This will set up all the controls on the device to match the BCF2000.mst file.
Thanks. Didn't realise there was a sysex to go with it. If nothing else, figuring out the changes to get mine working was educational.


Quote:
Originally Posted by MixMonkey View Post
I agree, navigation is currently undergoing a major overhaul in CSI at the moment, so hopefully we'll be able to address this issue soon. It can help to set up a pair of buttons to bank by a unit of 1, as well as 8.
No issue, I understand I've jumped in while pre-alpha. I was just concerned this was me not having done things correctly.

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-04-2019, 03:06 PM   #2686
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Thanks Geoff, this helped update my mental model of how it works. So if I get it correctly, state is always managed by the DAW. Where I was getting into issues was I also had state managed in the controller.

Quote:
Originally Posted by Geoff Waddington View Post
A press sends a 1 -- press it again, it sends a 1.
A release sends a 0 -- if the hardware is capable of generating it.
That makes sense, but the one thing I wonder now is when I have a Press with two messages, what's the second one? if it is alternating (which it seems to be), doesn't that go against that model.

Quote:
Originally Posted by Geoff Waddington View Post
And yeah, lots of bugs in this build, completely refactoring to support the new file syntax, will clean up after major refactor complete
Maybe so, but I've already got this controller behaving better overall than at any time prior, so I'm in front... and I haven't even looked at my other controllers yet.

Have dozens of other questions, but I'll try and ration them out rather than flooding the forum :-)

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-04-2019, 03:07 PM   #2687
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Quote:
Originally Posted by mschnell View Post
AFAIU, the CSI "button" definitions expect constant and distinguishable "press" and a "release" message.

-Michael
OK, thanks. I might have to file that away and come back to it once I've delved further.

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-04-2019, 04:42 PM   #2688
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
That makes sense, but the one thing I wonder now is when I have a Press with two messages, what's the second one? if it is alternating (which it seems to be), doesn't that go against that model.
Consider the MCU Stop button
Code:
Stop 	    PressFB 90 5d 7f  90 5d 00
When a 90 5d 7f is received, a 1 is output as normal.

This button has no release behaviour so that the heck is 90 5d 00 there for ?

The light.

So in reality what we are dealing with here is the use of one protocol for two purposes.

When the button is pushed 90 5d 7f is sent from the hardware to CSI.

CSI can control the light state by sending 90 5d 7f (on) or 90 5d 00 (off) to the hardware.

Here's where things get funky with some surfaces.

Let's assume a surface with some PressFB button with a light.

When the button is pressed, 7f gets sent to CSi AND the surface sets it's own internal state to 7f, also turning on the light, in the process.

Next time the button is pressed it notices it is in the 7f state so it sends a 00, and thereby turns off the light.

CSI can also set then light state.

With many of these type controllers, that ALSO sets the internal state, so the next press (7f or 00) is also dependant on what state CSI set the button light to.

Clear as mud ?

I know, it's quite a mess

The best results are always achieved by getting the hardware to "let go and stop trying to be such a control freak, just let CSI provide the feedback"
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 03-04-2019 at 05:27 PM.
Geoff Waddington is offline   Reply With Quote
Old 03-04-2019, 05:18 PM   #2689
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
The light.
Aha! I feel like one just went on for me.

So it would only be PressFB that had two values, never Press?

Quote:
Originally Posted by Geoff Waddington View Post
CSI can control the light state by sending 90 5d 7f (on) or 90 5d 7f (off) to the hardware.
Do light on and light off really have the same values, or is that a mistype?

This helps, as I have a Novation Launchpad Mini that I was planning on experimenting with. This might let me use it as a big array of buttons with FB lights. Is it limited to one message for the lights, or can it be a bit more complex? ie. multiple messages so that I could turn on multiple lights/vary the colour/etc?


Quote:
Originally Posted by Geoff Waddington View Post
The best results are always achieved by getting the hardware to "let go and stop trying to be such a control freak, just let CSI provide the feedback"
Yeah, that was my realisation from the earlier message. Controllers should be mostly dumb and do what they are told by CSI.

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-04-2019, 05:28 PM   #2690
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
Aha! I feel like one just went on for me.

So it would only be PressFB that had two values, never Press?
Yes.



Quote:
Originally Posted by MalcolmG View Post
Do light on and light off really have the same values, or is that a mistype?
Doh, yup
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-04-2019, 06:12 PM   #2691
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
Default

Quote:
Originally Posted by MalcolmG View Post
Thanks. Didn't realise there was a sysex to go with it. If nothing else, figuring out the changes to get mine working was educational.
Sorry about that. The BCF2000 CSI was a spin-off from the BCR2000 CSI I put together previously and it was the BCR download page that had all the support info.

I'll update the page when I get a chance or combine it with the BCR page.

Quote:
So if I get it correctly, state is always managed by the DAW. Where I was getting into issues was I also had state managed in the controller.
Yes, the LED state is always managed by the DAW, But here's what confuses me about the BCR (and probably also the BCF, I don't have one to try).

When I created the BCR settings, I started by trying to get the encoders to work in a 'relative' mode (ie increment/decrement) because this is what I was familiar with on the Mackie C4 and because I couldn't see how the feedback from the DAW was going to work when the LEDs were controlled by the BCR itself. I got nowhere.

So I figured I'd give 'Absolute' a try, not really expecting it to work. It worked like a charm and I still don't really understand why

Without Reaper running, the BCR does indeed control the LEDs on the surface (unlike the C4, where nothing happens if you turn a control) When you launch Reaper (with the appropriate CSI files installed) the controls map properly according to the .mst and the feedback works to control the surface LEDs.

Somehow the BCR knows to not use its local connection and only update the status with what it receives from the DAW.
MixMonkey is offline   Reply With Quote
Old 03-04-2019, 08:59 PM   #2692
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
Consider the MCU Stop button
Code:
Stop 	    PressFB 90 5d 7f  90 5d 00
<snip>

CSI can control the light state by sending 90 5d 7f (on) or 90 5d 00 (off) to the hardware.
Geoff, following on from our earlier discussion, the second param above is not just the light state, but more specifically, the light state when turned off. The light state for ON would be the same as the first param, so it's doing double duty as both the incoming message and the message sent back for the ON light state.

Is that right?

That works fine for single colour buttons, but I was just doing some testing of the Launchpad Mini, and it allows you to specify the colour, brightness and flashing state using that last hex value. So for the button I'm testing looks like this:

MyButton PressFB 90 01 7f 90 01 0f

where the 0f in the last message represents Red, non flashing and high brightness.

The behaviour is that when the button is in an off state, it's Red, and when I press it, it goes to Yellow because 7f happens to line up with Yellow, non flashing, high brightness.

Note, none of these are being set by the controller, it's all by the OUT messages of CSI.

So for this it would be handy to be able to separately specify the On and Off state colours. Same would go for PressReleaseFB.

Does all that make sense? Am I misunderstanding something, and if not, is it possible to put this as a low priority item on the backlog?

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-04-2019, 09:03 PM   #2693
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Quote:
Originally Posted by MixMonkey View Post
But here's what confuses me about the BCR (and probably also the BCF, I don't have one to try).
I can sympathise, I'm battling that Encoder at the moment, trying to map it to an effect param. The Fader maps fine, but not the Encoder. If I switch the params around, the new one still doesn't work on that Encoder, and the old one works fine on the Fader, so my suspicion is I've mucked up the config of the Encoder on the device. Time to dive into the manual deeper.
MalcolmG is offline   Reply With Quote
Old 03-05-2019, 04:35 AM   #2694
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
I can sympathise, I'm battling that Encoder at the moment, trying to map it to an effect param. The Fader maps fine, but not the Encoder. If I switch the params around, the new one still doesn't work on that Encoder, and the old one works fine on the Fader, so my suspicion is I've mucked up the config of the Encoder on the device. Time to dive into the manual deeper.
Try EncoderFB first.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-05-2019, 04:44 AM   #2695
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
Geoff, following on from our earlier discussion, the second param above is not just the light state, but more specifically, the light state when turned off. The light state for ON would be the same as the first param, so it's doing double duty as both the incoming message and the message sent back for the ON light state.

Is that right?
100% correct.

To make matters worse, the 2 params also act as range for faders, etc.

The syntax is still in flux and should improve with age

Quote:
Originally Posted by MalcolmG View Post
That works fine for single colour buttons, but I was just doing some testing of the Launchpad Mini, and it allows you to specify the colour, brightness and flashing state using that last hex value. So for the button I'm testing looks like this:

MyButton PressFB 90 01 7f 90 01 0f

where the 0f in the last message represents Red, non flashing and high brightness.

The behaviour is that when the button is in an off state, it's Red, and when I press it, it goes to Yellow because 7f happens to line up with Yellow, non flashing, high brightness.

Note, none of these are being set by the controller, it's all by the OUT messages of CSI.

So for this it would be handy to be able to separately specify the On and Off state colours. Same would go for PressReleaseFB.

Does all that make sense? Am I misunderstanding something, and if not, is it possible to put this as a low priority item on the backlog?

Cheers
Malcolm

We've discussed this concept before (like, a gajillion pages back ), it is probably a good idea to make the syntax more verbose with a dedicated feedback set of parameters.

By doing something like that, we could eliminate the Feedback variants of the controls.

Maybe syntax something like:

Code:
Play Press 90 5e 7f Feedback 90 5e 7f 90 5e 00
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 03-05-2019 at 04:49 AM.
Geoff Waddington is offline   Reply With Quote
Old 03-05-2019, 07:07 AM   #2696
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
Default

Quote:
Originally Posted by Geoff Waddington View Post
Try EncoderFB first.
This didn't work for me (aka 'increment/decrement)

Fader7BitFB works, with the BCF Encoder set to Absolute. This is how all the rotaries in my setup are configured.

The faders use the pitchbend control (e0, e1 etc), but in reality this could just as well be Fader7BitFB, as the BCR/BCF only sends 8bit pitchbend data.
MixMonkey is offline   Reply With Quote
Old 03-05-2019, 07:09 AM   #2697
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
Default

Quote:
Originally Posted by Geoff Waddington View Post
Maybe syntax something like:

Code:
Play Press 90 5e 7f Feedback 90 5e 7f 90 5e 00
This sounds like a plan As I think you said once before, who would have thought buttons could be this complicated
MixMonkey is offline   Reply With Quote
Old 03-05-2019, 08:50 AM   #2698
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Hmmm...

Thanks @MalcomG and @MixMonkey...

Let's make the syntax more consistent with the new Zone style, this will allow for future expansion - especially in the Feedback section:

Code:
Widget Play
    Press 90 5e 7f
    Feedback 90 5e 7f 90 5e 00
    Feedback - some future feedback addition here
    ...
WidgetEnd
We can even get back the Channel shortcut notation in the .mst:

Code:
Widget Fader|1-8
    Fader14bit e| 7f 7f e| 00 00
WidgetEnd
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 03-05-2019 at 08:56 AM.
Geoff Waddington is offline   Reply With Quote
Old 03-05-2019, 08:54 AM   #2699
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
Default

The syntax seems to evolve to being XML ...

Might be a good idea !

-Michael
mschnell is offline   Reply With Quote
Old 03-05-2019, 03:57 PM   #2700
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
We've discussed this concept before (like, a gajillion pages back ), it is probably a good idea to make the syntax more verbose with a dedicated feedback set of parameters.

By doing something like that, we could eliminate the Feedback variants of the controls.

Maybe syntax something like:

Code:
Play Press 90 5e 7f Feedback 90 5e 7f 90 5e 00
Feel free to tell me I'm overthinking this, but I've been thinking about the separation of concerns off and on since yesterday.

There is currently a nice separation between the structure of the controller (ie. what buttons/faders/etc we have) in the mst, and the behaviour (ie. what we want to happen when we press a button) in the axt/fxt. This allows me to take MixMonkey's mst for the bcf and use it, in theory unchanged, while still controlling my custom behaviour separately.

So the question is, where do the colours belong?

Where I'm leaning is that the colours relate to the behaviour, not the button. Maybe I want the button associated with the Record arm action to be flashing red when it is armed. So that would tell me it should be in the axt/fxt. The fact that this control supports feedback is in the mst, but the details of what form that feedback should take (ie. colour, flashing, etc) possibly belongs in the axt/fxt.

That does leave us with the issue that maybe that behaviour is associated with a control that doesn't support feedback, in which case it'll be ignored, but conceptually it seems that is where it belongs.

Not raising this as a blocker, as the fallback of just editing the mst is not a showstopper, but it does kinda go against the separation so far.

Thoughts?
MalcolmG is offline   Reply With Quote
Old 03-05-2019, 04:24 PM   #2701
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
Feel free to tell me I'm overthinking this, but I've been thinking about the separation of concerns off and on since yesterday.

There is currently a nice separation between the structure of the controller (ie. what buttons/faders/etc we have) in the mst, and the behaviour (ie. what we want to happen when we press a button) in the axt/fxt. This allows me to take MixMonkey's mst for the bcf and use it, in theory unchanged, while still controlling my custom behaviour separately.
Just change "the structure of the controller" to " the capabilities of the controller" and the stuff below will fall right into place

Quote:
Originally Posted by MalcolmG View Post
So the question is, where do the colours belong?

Where I'm leaning is that the colours relate to the behaviour, not the button. Maybe I want the button associated with the Record arm action to be flashing red when it is armed. So that would tell me it should be in the axt/fxt. The fact that this control supports feedback is in the mst, but the details of what form that feedback should take (ie. colour, flashing, etc) possibly belongs in the axt/fxt

Thoughts?
Well, the .mst states that the control supports feedback in the form of colour info.

The .axt/.fxt (soon to be .zon) dictates how that control'sl capabilities (colour) are utilized.

So the answer is -- it's split -- the colour capability is presented in the .mst and utilized in the .axt/.fxt.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-05-2019, 04:39 PM   #2702
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
Well, the .mst states that the control supports feedback in the form of colour info.

The .axt/.fxt (soon to be .zon) dictates how that control'sl capabilities (colour) are utilized.

So the answer is -- it's split -- the colour capability is presented in the .mst and utilized in the .axt/.fxt.

So from the axt/fxt there would be someway to specify the colour (out of all the capabilities defined in the mst) to display? Or would the axt be limited to the colours that the mst author defined for that control?

For example in the Launchpad case, there are dozens of colours one button can display, plus brightness levels and flashing states. These are the capabilities in the mst. But from the axt I could say: For this action/control combination, the ON state should be red flashing and the OFF state should be blue non-flashing.

Or more complicated, maybe it could be red non-flashing if the track is armed, red flashing if armed and recording, otherwise no light.

Is that the sort of separation you're thinking of?

Last edited by MalcolmG; 03-05-2019 at 05:01 PM.
MalcolmG is offline   Reply With Quote
Old 03-05-2019, 05:23 PM   #2703
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
So from the axt/fxt there would be someway to specify the colour (out of all the capabilities defined in the mst) to display? Or would the axt be limited to the colours that the mst author defined for that control?
A bit of both

The .axt would need a Widget that supported the capabilities.

We've been lucky so far in making Widgets that are generic, with just the right amount of customization to support things like this.

Quote:
Originally Posted by MalcolmG View Post
For example in the Launchpad case, there are dozens of colours one button can display, plus brightness levels and flashing states. These are the capabilities in the mst. But from the axt I could say: For this action/control combination, the ON state should be red flashing and the OFF state should be blue non-flashing.

Or more complicated, maybe it could be red non-flashing if the track is armed, red flashing if armed and recording, otherwise no light.

Is that the sort of separation you're thinking of?
Yes, or even a bit more complex -- send feedback to more the one control...
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-05-2019, 05:26 PM   #2704
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
A bit of both

The .axt would need a Widget that supported the capabilities.

We've been lucky so far in making Widgets that are generic, with just the right amount of customization to support things like this.

Yes, or even a bit more complex -- send feedback to more the one control...
Cool I'll add Widgets to the list of things I need to look at. I've seen them mentioned in the thread but will re-read now that I have a snippet of what they're about.

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-07-2019, 03:58 PM   #2705
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default TrackCycle

Just wondering what the TrackCycle action does? It has an unusual syntax (ie. arguments that seem to be a mixture of other controls and also actions):

RotaryG31 TrackCycle RotaryPushG31 "TrackPan 0" "TrackPanWidth 1"

My guess is it's some sort of conditional (eg. If the status of RotaryPushG31 is ON, then TrackPan 0, otherwise TrackPanWidth 1), but I've set it up to try and test this but I can't see what it's doing (either I can't notice the change or I haven't got it setup properly).

Cheers
Malcolm

Last edited by MalcolmG; 03-07-2019 at 04:33 PM.
MalcolmG is offline   Reply With Quote
Old 03-07-2019, 04:40 PM   #2706
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default CSI Notes Wiki

Also, if it's useful for anyone else, as I've been trawling through the thread and figuring out how things work, I've been making notes in a github wiki (same repo where I'm storing my config files).

I haven't written too much on the axt/fxt/actions side, as the syntax of these looks like it's changing quite a bit at the moment, but even just pulling together a full list of Actions has been useful to me so far.

Link is below, feel free to comment/correct/add if you can.

https://github.com/malcolmgroves/reaper_csi/wiki

Cheers
Malcolm
MalcolmG is offline   Reply With Quote
Old 03-07-2019, 05:11 PM   #2707
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
Just wondering what the TrackCycle action does? It has an unusual syntax (ie. arguments that seem to be a mixture of other controls and also actions):

RotaryG31 TrackCycle RotaryPushG31 "TrackPan 0" "TrackPanWidth 1"

My guess is it's some sort of conditional (eg. If the status of RotaryPushG31 is ON, then TrackPan 0, otherwise TrackPanWidth 1), but I've set it up to try and test this but I can't see what it's doing (either I can't notice the change or I haven't got it setup properly).

Cheers
Malcolm
Yeah that's a Cycle Action in a Track context.

So, push the top to switch from the rotary controlling and displaying Pan, to rotary controlling and displaying Width, of course you must have the tracks set to use stereo pan for this to work.

Push again to return to Pan.

If there were more things, say Pan, Width, and Depth, it would Cycle through these.

Essentially it's just a way to add a convenient, oft encountered navigation -- Cycle through a set of options.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-07-2019, 05:13 PM   #2708
Mr. Green
Human being with feelings
 
Join Date: Jul 2010
Posts: 373
Default

Quote:
Originally Posted by MalcolmG View Post
Also, if it's useful for anyone else, as I've been trawling through the thread and figuring out how things work, I've been making notes in a github wiki (same repo where I'm storing my config files).

I haven't written too much on the axt/fxt/actions side, as the syntax of these looks like it's changing quite a bit at the moment, but even just pulling together a full list of Actions has been useful to me so far.

Link is below, feel free to comment/correct/add if you can.

https://github.com/malcolmgroves/reaper_csi/wiki

Cheers
Malcolm
Hey! - Can we add this link to the first post? (assuming it's kept up to date?)
(and THANK YOU MalcolmG!)
Mr. Green is offline   Reply With Quote
Old 03-07-2019, 05:24 PM   #2709
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
Also, if it's useful for anyone else, as I've been trawling through the thread and figuring out how things work, I've been making notes in a github wiki (same repo where I'm storing my config files).

I haven't written too much on the axt/fxt/actions side, as the syntax of these looks like it's changing quite a bit at the moment, but even just pulling together a full list of Actions has been useful to me so far.

Link is below, feel free to comment/correct/add if you can.

https://github.com/malcolmgroves/reaper_csi/wiki

Cheers
Malcolm
WOW !!

Great stuff, thanks man !

One thing, I was going to correct something, but it actually got me to rethink everything, and hopefully improve it, thanks again for the discussion.

You separate the Control types from Widgets, actually the original design was that they were all widgets, it seemed awkward to call a display a control.

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.

Take the Fader:

Code:
Widget Fader1
    CGFader14Bit e0 7f 7f e0 00 00
    FPFader14bit e0 7f 7f e0 00 00
WidgetEnd
Widget named "Fader1" consisting of:
a ControlGenerator -- you moving the Fader and sending Resper data
a FeedbackProcessor == the motor moving the Fader based on Reaper supplied data
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-07-2019, 05:28 PM   #2710
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by Mr. Green View Post
Hey! - Can we add this link to the first post? (assuming it's kept up to date?)
(and THANK YOU MalcolmG!)
Done and done !!
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
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
Old 03-07-2019, 07:24 PM   #2712
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
So, push the top to switch from the rotary controlling and displaying Pan, to rotary controlling and displaying Width, of course you must have the tracks set to use stereo pan for this to work.

Push again to return to Pan.

Ah, very cool. This makes me want to step back and replan my surfaces, as I can suddenly squeeze much more functionality into each of them. I might actually be able to get rid of some of them and reclaim my desk
MalcolmG is offline   Reply With Quote
Old 03-07-2019, 11:22 PM   #2713
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
Default

Quote:
Originally Posted by MalcolmG View Post
Also, if it's useful for anyone else, as I've been trawling through the thread and figuring out how things work, I've been making notes in a github wiki (same repo where I'm storing my config files).

I haven't written too much on the axt/fxt/actions side, as the syntax of these looks like it's changing quite a bit at the moment, but even just pulling together a full list of Actions has been useful to me so far.

Link is below, feel free to comment/correct/add if you can.

https://github.com/malcolmgroves/reaper_csi/wiki
THANKS A LOT !!!!!

I suppose the syntax is still a moving (that is why I did not yet start to help with the documentation of CIS, as I offered a long time ago). But I a decently happy that somebody did who knows more about "modern" and more dynamic and collaborative tools for this work than I do !!!

-Michael
mschnell is offline   Reply With Quote
Old 03-08-2019, 04:33 AM   #2714
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by MalcolmG View Post
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.
Yup, there ya' go

That's what happened to me as I was typing the syntax, it hit me -- BOOM !!

You can do cross surface easily with this new approach.

Let's do a very simple, arbitrary, contrived example.

We have 2 identical surfaces with a Play button that lights up.

We have the Play Action.

As usual the .zon file for both looks like:

Code:
...
Stop Stop
Play Play
Record Record
...
Now we will see why .mst's are on a per Page basis.

In one surface's .mst:

Code:
Widget Play
    CGPress 90 5e 7f 90 5e 00
WidgetEnd
and in the other:

Code:
Widget Play
    CGPressFeedack 90 5e 7f 90 5e 00
WidgetEnd
One surface has a Play button that works but no light, and the other surface has a working light but the button does nothing.

Voila ! -- cross surface
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-08-2019, 05:57 AM   #2715
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
Default

The new wiki states:

"Also notice that the first message given as an argument is performing double duty here. The first argument is both the message received by CSI to indicate the button has been pressed, and also the message sent back to the surface requesting it to show feedback for the ON state (eg. turn the light on). The second argument is the message sent back to the surface requesting it to show feedback for the OFF state (eg. turn the light off)"

While I fully agree that this is the current state, this nails down the fact that the messages sent to a button are the same as those that are received from that button.

I am not sure that this holds with all devices without any exception. there could be devices that need completely different messages for the lights. (E.g. the XTouch compact listens to additional messages for turning the button lights on and off, while the "standard" messages are always in place.)

Moreover there are devices that have more than two states for the lights (e.g. the XTouch Compact can set the button lights to on, off, and flashing. There might be cases where one would want to make use of such additional ways to visualize a state.

-Michael

Last edited by mschnell; 03-08-2019 at 07:08 AM.
mschnell is offline   Reply With Quote
Old 03-08-2019, 06:07 AM   #2716
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Quote:
Originally Posted by mschnell View Post
The new wiki states:

"Also notice that the first message given as an argument is performing double duty here. The first argument is both the message received by CSI to indicate the button has been pressed, and also the message sent back to the surface requesting it to show feedback for the ON state (eg. turn the light on). The second argument is the message sent back to the surface requesting it to show feedback for the OFF state (eg. turn the light off)"

While I fully agree that this is the current state, this nails down the fact that the messages sent to a button are the same as those that are received from that button.

I am not sure that this holds with all devices without any exception. there could be devices that need completely different messages for the lights. (E.g. the XTouch compact listens to additional messages for turning the button lights on and off, while the "standard" messages are always in place.)

Moreover there are devices that have more that two states for the lights (e.g. the XTouch Compact can set the button lights to on, off, and flash. There might be cases where one would want to make use of such additional ways to visualize a state.

-Michael
Totally agree.

That's why it's being changed.

See the post just before yours for an example of the flexibility of the new control/feedbck separation approach.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 03-08-2019, 07:11 AM   #2717
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
Default

OK, so "CGPress" might handle this.

curious for a description of same.....
-Michael
mschnell is offline   Reply With Quote
Old 03-08-2019, 10:46 PM   #2718
MalcolmG
Human being with feelings
 
MalcolmG's Avatar
 
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
Default

Quote:
Originally Posted by mschnell View Post
OK, so "CGPress" might handle this.

curious for a description of same.....
-Michael
The way I understood it is you could do something like this:

Code:
Widget Button1
    CGPress e0 7f 7f e0 7f 00
    FPPress e0 7f 0B e0 7f 1c
WidgetEnd
where CGPress defines the messages sent to CSI. Nothing to do with Feedback.

Separately, FPPress defines the messages received from CSI to display feedback, which in the case of the Launchpad Mini for example, the first represents high-brightness flashing Red and the second represents Low Brightness Green.

Last edited by MalcolmG; 03-09-2019 at 12:12 AM.
MalcolmG is offline   Reply With Quote
Old 03-09-2019, 06:09 AM   #2719
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
Default

Here's a shot at the syntax for Midi Widgets and their components (with example values), what do you think ?

Control Signal Generators:

Code:
Press		90 5e 7f
PressRelease	90 46 7f   90 46 00
Fader14Bit	e0 7f 7f   e0 00 00
Fader7Bit	90 07 7f   90 07 00
Encoder		b0 10 7f   b0 10 00
Feedback Processors:

Code:
FB_Light              90 5e 7f 	 90 5e 00
FB_Fader14Bit         e0 7f 7f	 e0 00 00
FB_Fader7Bit          90 07 7f 	 90 07 00
FB_EncoderRings       b0 10 7f	 90 10 00
FB_GainReductionMeter b0 73 7f   b0 73 00
FB_VUMeter            b0 6e 7f   b0 6e 00
FB_MCUVUMeter 0
FB_MCUDisplayUpper 0
FB_MCUDisplayLower 0
FB_MCUXTDisplayUpper 4 
FB_MCUXTDisplayLower 4
FB_MCUC4DisplayUpper 1 7
FB_MCUC4DisplayLower 1 7
FB_MCUTimeDisplay
FB_QConProXMasterVUMeter
Play button definition:

Code:
MidiWidget Play
    Press     90 5e 7f
    FB_Light  90 5e 7f   90 5e 00
MidiWidgetEnd
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 03-09-2019 at 03:50 PM.
Geoff Waddington is offline   Reply With Quote
Old 03-10-2019, 01:00 AM   #2720
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
Default

Looks great !
Splitting up conrtol and feedback seems like a good idea.

I understand that "Fader14Bit" is the "special MCP Midi protocol" way of transferring 14 bit values (i.e. any Midi status can be use like 14 Bit pitchbend).

But there also is the standard 14 bit Midi protocol called "high resolution Midi CC". Here the high 7 bits are transferred as a normal CC and the low 7 bits are transferred as CC #+32. I don't know if there are any Control Surface devices that send or receive this mode, but if I would be to built one, I would implement it, as it is pure standard. Maybe implementation in CSI could result in a "FaderLow7Bits" keyword to be used in combination with "Fader7Bit".
Code:
Fader7Bit	  e0 1f 7f   e0 00 00
FaderLow7Bits	  e0 3f 7f   e0 20 00
FB_Fader7Bit	  e0 1f 7f   e0 00 00
FB_FaderLow7Bits  e0 3f 7f   e0 20 00
(If I correctly understand that with Fader7Bit the second and 5th hex code defines the range used with a Fader group. A goup of such faders could consist of only 32 faders instead of 128 in the normal 7 bit Fader7Bit variant.)

BTW.: What is the difference between "Fader7Bit" and "Encoder", If there is a difference, could a 14 bit encoder not be existing somewhere ?

-Michael

Last edited by mschnell; 03-10-2019 at 02:05 AM.
mschnell is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 10:13 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.