|
|
|
03-04-2019, 02:34 AM
|
#2681
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Thanks for your response Michael,
Quote:
Originally Posted by mschnell
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
(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.
|
|
|
03-04-2019, 04:34 AM
|
#2682
|
Human being with feelings
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
|
Quote:
Originally Posted by MalcolmG
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.
|
|
|
03-04-2019, 04:57 AM
|
#2683
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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.
|
|
|
03-04-2019, 05:08 AM
|
#2684
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
|
Quote:
Originally Posted by MalcolmG
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
|
|
|
03-04-2019, 02:54 PM
|
#2685
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by MixMonkey
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
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
|
|
|
03-04-2019, 03:06 PM
|
#2686
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
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
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
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
|
|
|
03-04-2019, 03:07 PM
|
#2687
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by mschnell
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
|
|
|
03-04-2019, 04:42 PM
|
#2688
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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.
|
|
|
03-04-2019, 05:18 PM
|
#2689
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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
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
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
|
|
|
03-04-2019, 05:28 PM
|
#2690
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
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
|
|
|
03-04-2019, 06:12 PM
|
#2691
|
Human being with feelings
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
|
Quote:
Originally Posted by MalcolmG
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.
|
|
|
03-04-2019, 08:59 PM
|
#2692
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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
|
|
|
03-04-2019, 09:03 PM
|
#2693
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by MixMonkey
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.
|
|
|
03-05-2019, 04:35 AM
|
#2694
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
|
|
|
03-05-2019, 04:44 AM
|
#2695
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
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.
|
|
|
03-05-2019, 07:07 AM
|
#2696
|
Human being with feelings
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
|
Quote:
Originally Posted by Geoff Waddington
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.
|
|
|
03-05-2019, 07:09 AM
|
#2697
|
Human being with feelings
Join Date: Sep 2017
Location: London, England.
Posts: 4,835
|
Quote:
Originally Posted by Geoff Waddington
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
|
|
|
03-05-2019, 08:50 AM
|
#2698
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
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.
|
|
|
03-05-2019, 08:54 AM
|
#2699
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
|
The syntax seems to evolve to being XML ...
Might be a good idea !
-Michael
|
|
|
03-05-2019, 03:57 PM
|
#2700
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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?
|
|
|
03-05-2019, 04:24 PM
|
#2701
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
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
|
|
|
03-05-2019, 04:39 PM
|
#2702
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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.
|
|
|
03-05-2019, 05:23 PM
|
#2703
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
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
|
|
|
03-05-2019, 05:26 PM
|
#2704
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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
|
|
|
03-07-2019, 03:58 PM
|
#2705
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
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.
|
|
|
03-07-2019, 04:40 PM
|
#2706
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
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
|
|
|
03-07-2019, 05:11 PM
|
#2707
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
|
|
|
03-07-2019, 05:13 PM
|
#2708
|
Human being with feelings
Join Date: Jul 2010
Posts: 373
|
Quote:
Originally Posted by MalcolmG
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!)
|
|
|
03-07-2019, 05:24 PM
|
#2709
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
|
|
|
03-07-2019, 05:28 PM
|
#2710
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by Mr. Green
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
|
|
|
03-07-2019, 07:13 PM
|
#2711
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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.
|
|
|
03-07-2019, 07:24 PM
|
#2712
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by Geoff Waddington
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
|
|
|
03-07-2019, 11:22 PM
|
#2713
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
|
Quote:
Originally Posted by MalcolmG
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
|
|
|
03-08-2019, 04:33 AM
|
#2714
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by MalcolmG
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
|
|
|
03-08-2019, 05:57 AM
|
#2715
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
|
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.
|
|
|
03-08-2019, 06:07 AM
|
#2716
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
Quote:
Originally Posted by mschnell
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
|
|
|
03-08-2019, 07:11 AM
|
#2717
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
|
OK, so "CGPress" might handle this.
curious for a description of same.....
-Michael
|
|
|
03-08-2019, 10:46 PM
|
#2718
|
Human being with feelings
Join Date: Jun 2015
Location: Sydney, Australia
Posts: 180
|
Quote:
Originally Posted by mschnell
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.
|
|
|
03-09-2019, 06:09 AM
|
#2719
|
Human being with feelings
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,150
|
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.
|
|
|
03-10-2019, 01:00 AM
|
#2720
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,634
|
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.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 10:13 PM.
|