CSI: Devices, Setup, Help -- thread now closed -- use the new CSI v3 thread

[buschag]

Ok I am up and running.... well more like crawling. Installed CSI, got the XTouch going with the MCU mst file, found a Xtouch mini config and installed that. Have the zon files in place but Im not getting into that until my last surface is defined. My Livid Code needs to be done from scratch. I checked the Wiki and different videos but they all seem to be based off of pre-made files. Can anyone point me in the direction of where to begin creating a 32 push encoder from scratch? Also, where do I get the address display program? I thought it was included in CSI. Sorry in advance, but Im clown shoes at this type of stuff.

[buschag]

Followup: so I modified my XTmini .mst to this.... Am I on the right track? I need to change the addresses once I figure out how. Also, should there be widgets for the LED ring around the encoders?
It is a .mst file but I changed it to .txt to attach if that's ok...


Update:

I think Im on to something. While some of the addresses don't make sense (number order) Im going to assume its computer wizard language. but if I turn an encoder, the CSI action to monitor input shows 4 lines each turn...
IN <- Code b0 01 11
IN <- Code b0 01 13
IN <- Code b0 01 15
IN <- Code b0 01 17

That is what happens when one encoder is turned 1 "click or step". Hope that makes sense.


Update2:

Look at me go! I think Im getting this.... Long way to go but I hope this is correct before I spend all day going down the wrong road.


Widget RotaryPush1
Press b0 01 7f
FB_TwoState b0 01 7f b0 01 00
WidgetEnd

Widget RotaryPush2
Press b0 02 7f
FB_TwoState b0 02 7f b0 02 00
WidgetEnd

Widget RotaryPush3
Press b0 03 7f
FB_TwoState b0 03 7f b0 03 00
WidgetEnd

Widget RotaryPush4
Press b0 04 7f
FB_TwoState b0 04 7f b0 04 00
WidgetEnd

Widget RotaryPush5
Press b0 05 7f
FB_TwoState b0 057f b0 05 00
WidgetEnd

Widget RotaryPush6
Press b0 06 7f
FB_TwoState b0 06 7f b0 06 00
WidgetEnd

Widget RotaryPush7
Press b0 07 7f
FB_TwoState b0 07 7f b0 07 00
WidgetEnd

Widget RotaryPush8
Press b0 08 7f
FB_TwoState b0 08 7f b0 08 00
WidgetEnd

[Funkybot]

Originally Posted by buschag

Ok I am up and running.... well more like crawling. Installed CSI, got the XTouch going with the MCU mst file, found a Xtouch mini config and installed that. Have the zon files in place but Im not getting into that until my last surface is defined. My Livid Code needs to be done from scratch. I checked the Wiki and different videos but they all seem to be based off of pre-made files. Can anyone point me in the direction of where to begin creating a 32 push encoder from scratch? Also, where do I get the address display program? I thought it was included in CSI. Sorry in advance, but Im clown shoes at this type of stuff.

Using just Reaper and CSI you can do it like this...

1. Create an empty livid.mst to start (it's just a .txt file with a different extension)
2. Create a Livid Zone folder - can be empty to start
3. Setup CSI in Reaper according to the Wiki
4. Setup a new device in CSI for the Livid even though the zone and .mst files are blank
5. Open up Reaper's action list
6. Search for "CSI"
7. You should see an option called something like "CSI: monitor input from surfaces"

That's your logger. You'd press a button on your surface and you'd see something like:

Livid: b1 01 7f 
Livid: b1 01 00

That's CSI saying via the input monitor, "hey, this device spit out a message that doesn't exist in the .mst, here's what that message is." On a button, the first half of that would be the press message, the second half is the release message.

Then you create a widget that looks like this:

Widget Button1
	Press 90 20 7f 90 20 00
WidgetEnd

If the button has feedback then:

Widget Button1
	Press 90 20 7f 90 20 00
        FB_TwoState 90 20 7f 90 20 00
WidgetEnd

On an encoder, you want to figure out if it sends acceleration values. So start by turning clockwise. Turn it slow, turn it fast, turn it really slow, turn it really fast. Does it send different messages?

Livid: b0 00 41
...[bunch of values in between]
Livid: b0 00 4f

That would indicate, "ok, this controller sends messages between 41 to 4f when being turned clockwise."

Do the same for counter-clockwise turns. Let's say those were between 01 and 0f.

Then you create a widget that would look like this:

Widget Rotary5
	Encoder b0 14 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 14 7f
WidgetEnd

EDIT: you beat me to it.

[Funkybot]

buschag, question: when you press a button does the device also send a release message? If yes, include both press and release like this on the press row:

Widget RotaryPush1
Press b0 01 7f b0 01 00
FB_TwoState b0 01 7f b0 01 00
WidgetEnd

[buschag]

that encoder help is huge... buttons are simple... two states, but encoders are difficult to wrap my head around. Thanks for your help. Once this is done, ill share it with anyone that is considering one of these devices.

[Funkybot]

Originally Posted by buschag

that encoder help is huge... buttons are simple... two states, but encoders are difficult to wrap my head around. Thanks for your help. Once this is done, ill share it with anyone that is considering one of these devices.

This page covers the syntax for encoders:

https://github.com/GeoffAWaddington/.../wiki/Encoders

[buschag]

I set it up to be toggle in the code editor. so I believe it sends a message only on press, not release. at least that's what I had intended.

....and that encoder wiki page looks like a foreign language so that will take me time time.

[buschag]

slow and fast is the same:

IN <- Code b0 01 01
IN <- Code b0 01 03
IN <- Code b0 01 05
IN <- Code b0 01 07
IN <- Code b0 01 09
IN <- Code b0 01 0b
IN <- Code b0 01 0d
IN <- Code b0 01 0f
IN <- Code b0 01 11
IN <- Code b0 01 13
IN <- Code b0 01 15
IN <- Code b0 01 17
IN <- Code b0 01 19
IN <- Code b0 01 1b
IN <- Code b0 01 1d
IN <- Code b0 01 1f
IN <- Code b0 01 21
IN <- Code b0 01 23
IN <- Code b0 01 25
IN <- Code b0 01 27
IN <- Code b0 01 29
IN <- Code b0 01 2b
IN <- Code b0 01 2d
IN <- Code b0 01 2f
IN <- Code b0 01 31
IN <- Code b0 01 33
IN <- Code b0 01 35
IN <- Code b0 01 37
IN <- Code b0 01 39
IN <- Code b0 01 3b
IN <- Code b0 01 3d
IN <- Code b0 01 3f
IN <- Code b0 01 41
IN <- Code b0 01 43
IN <- Code b0 01 45
IN <- Code b0 01 47
IN <- Code b0 01 49
IN <- Code b0 01 4b
IN <- Code b0 01 4d
IN <- Code b0 01 4f
IN <- Code b0 01 51
IN <- Code b0 01 53
IN <- Code b0 01 55
IN <- Code b0 01 57
IN <- Code b0 01 59
IN <- Code b0 01 5b
IN <- Code b0 01 5d
IN <- Code b0 01 5f
IN <- Code b0 01 61
IN <- Code b0 01 63
IN <- Code b0 01 65
IN <- Code b0 01 67
IN <- Code b0 01 69
IN <- Code b0 01 6b
IN <- Code b0 01 6d
IN <- Code b0 01 6f
IN <- Code b0 01 71
IN <- Code b0 01 73
IN <- Code b0 01 75
IN <- Code b0 01 77
IN <- Code b0 01 79
IN <- Code b0 01 7b
IN <- Code b0 01 7d
IN <- Code b0 01 7f

So would that be similar to a MFT encoder?

[Funkybot]

Originally Posted by buschag

slow and fast is the same:

Ok, that doesn't look like an endless encoder at all. That looks like a standard 7bit MIDI knob with absolute start and end values.

That would just use the Fader7Bit syntax.

Widget RotaryA1
     Fader7Bit b0 21 7f
     FB_Fader7Bit b0 21 7f    // for the LED ring
WidgetEnd

[buschag]

oh, that makes sense, although I don't know if that's any benefit. I thought endless would be better... I wonder if I can change it in the editor software...

[Funkybot]

Originally Posted by buschag

oh, that makes sense, although I don't know if that's any benefit. I thought endless would be better... I wonder if I can change it in the editor software...

There's pros and cons to each IMO.

Endless Encoders

Pros:
You can get finer resolution of parameters
You can adjust the acceleration curves

Cons:
More syntax in the .mst file
More syntax in the zone files

Absolute Rotaries

Pros:
Easier syntax - everything has a fixed start and end point so there's no "extra stuff" to worry about

Cons:
Won't get as fine resolution (but may be good enough for most things)

[buschag]

well I appreciate all of your assistance today... I got the all surfaces mapped for the .mst files (I hope), but Ill have to work on .zon files tomorrow.... brain is starting to hurt.... BEER TIME!

[vlab]

Hi !
I just got a X-Touch Extender (as I don't need all the buttons and jogwheel, nor I have that space on my desk). I'm new to CSI, and read the doc trying to grasp as much as I could, amazing things happens, but it leaves me still with a lot of questions

Anyhow, I use the MCU_XT MST/ZON files as a base.

I began configuring my plugin view (only 1 Brainworx SSL-E for now, so can do all my mistakes on a single plugin!), and I run into an issue where the displays that are not configured/assigned for the plugin, still shows the main ¨Mixer mode¨ (i.e. tracks 1 to 8), instead of being blank, but for the few knobs I have assigned controls to, it updates just fine. It makes the displays very cluttered and messy!

Is there a way to make sure that, when I switch to a plugin, all displays turns blank (except the assigned ones of course)? I thought that configuring the ZON as FocusedFXNavigator would do this?

Any help would be gladly welcomed, (MST/ZON files attached)
Thanks a lot !

V

[MixMonkey]

Originally Posted by vlab

Is there a way to make sure that, when I switch to a plugin, all displays turns blank (except the assigned ones of course)? I thought that configuring the ZON as FocusedFXNavigator would do this?

Absolutely!:) Just assign any displays/controls you're not using for the plugin to NoAction.

Like this:

DisplayUpper1  NoAction

Regarding your FX.zon file, you should comment out that long list of widgets at the end:

/VUMeter1
/VUMeter2
/VUMeter3
/VUMeter4
/VUMeter5
/VUMeter6
/VUMeter7
/VUMeter8

As an alternate way of approaching FX mapping, it can be easier if you create a template of your controller with all the Widgets mapped to NoAction. Then change the Widgets you want to assign, safe in the knowledge that all the others are already disabled.

For MackieXT type device it could look something like this:

Zone "VST3: SomeFXPlugin"
FocusedFXNavigator
DisplayUpper1    NoAction
DisplayLower1    NoAction
VUMeter1         NoAction
Rotary1          NoAction
RotaryPush1      NoAction
RecordArm1       NoAction
Solo1            NoAction
Mute1            NoAction
Select1          NoAction
Fader1           NoAction etc etc for the other seven channels

It seems conceptually easier (to me ;)) to slot the FX parameter definitions into a big map of the whole controller than it is to attach controller Widgets to FX parameters.

The other thing I do is to copy that whole FX parameter list to the end of the controller map (commented out, of course) and just cut'n'paste from that list to the correct Widget in the map. If you cut (rather than copy) from the list, it's easy to keep track of what parameters you've mapped. When the list has disappeared, you're done:)

[Funkybot]

Originally Posted by MixMonkey

Absolutely! Just assign any displays/controls you're not using for the plugin to NoAction.

Like this:

DisplayUpper1  NoAction

Regarding your FX.zon file, you should comment out that long list of widgets at the end:

/VUMeter1
/VUMeter2
/VUMeter3
/VUMeter4
/VUMeter5
/VUMeter6
/VUMeter7
/VUMeter8

As an alternate way of approaching FX mapping, it can be easier if you create a template of your controller with all the Widgets mapped to NoAction. Then change the Widgets you want to assign, safe in the knowledge that all the others are already disabled.

For MackieXT type device it could look something like this:

Zone "VST3: SomeFXPlugin"
FocusedFXNavigator
DisplayUpper1    NoAction
DisplayLower1    NoAction
VUMeter1         NoAction
Rotary1          NoAction
RotaryPush1      NoAction
RecordArm1       NoAction
Solo1            NoAction
Mute1            NoAction
Select1          NoAction
Fader1           NoAction etc etc for the other seven channels

It seems conceptually easier (to me ) to slot the FX parameter definitions into a big map of the whole controller than it is to attach controller Widgets to FX parameters.

The other thing I do is to copy that whole FX parameter list to the end of the controller map (commented out, of course) and just cut'n'paste from that list to the correct Widget in the map. If you cut (rather than copy) from the list, it's easy to keep track of what parameters you've mapped. When the list has disappeared, you're done

What MixMonkey said. And keep in mind, Excel can also be your friend if you're comfortable with it.

[vlab]

Originally Posted by MixMonkey

Absolutely! Just assign any displays/controls you're not using for the plugin to NoAction.

snip... !

Thanks MixMonkey and Funkybot, so glad to see there are such simple solutions for my ¨problems¨, and thanks for the workflow suggestions, indeed doing it the other way around like I did really makes it more challenging/error-prone than it deserves. and Excel makes a lot of sense to move text around!

Cheers!
V

[Mavriq]

Geoff: I think I may have found out where the confusion between the docs I sent for the MFT and the current implementation. Its actually on page 2 of this thread.

If you look at what paat wrote, he is basically stating what the manual says, but you may have interpreted what he said incorrectly.

CSI code is written so that if

"B1 1F" or "B5 1F"

send that exact message along with "b" (in rgb) in data byte 2.


What should be happening according to the manual and what you may have missed in paat's message was:

1. that you mimic back the status and 1st data byte of the original message.
  The 2nd data byte contains the value that sets 
  the animation or color code. 

2. For colors that has to be sent on midi channel 2. 

3. For the animations those have to be sent on channel 6.

I'm looking at implementing a Feedback processor for my controllers so I can set the lights the way I like. It would work with the MFT other than the channel 6 parts. MFT seems to need to send feedback on more than one channel if you want animations...

[Geoff Waddington]

Originally Posted by gvanbrunt

Geoff: I think I may have found out where the confusion between the docs I sent for the MFT and the current implementation. Its actually on page 2 of this thread.

If you look at what paat wrote, he is basically stating what the manual says, but you may have interpreted what he said incorrectly.

CSI code is written so that if

"B1 1F" or "B5 1F"

send that exact message along with "b" (in rgb) in data byte 2.


What should be happening according to the manual and what you may have missed in paat's message was:

1. that you mimic back the status and 1st data byte of the original message.
  The 2nd data byte contains the value that sets 
  the animation or color code. 

2. For colors that has to be sent on midi channel 2. 

3. For the animations those have to be sent on channel 6.

I'm looking at implementing a Feedback processor for my controllers so I can set the lights the way I like. It would work with the MFT other than the channel 6 parts. MFT seems to need to send feedback on more than one channel if you want animations...

Cool, that code is, as you can see, an afternoon hack to get someone going

Any improvements, including redesign more than welcomed !!

Thanks

[Mavriq]

Originally Posted by Geoff Waddington

Cool, that code is, as you can see, an afternoon hack to get someone going

Any improvements, including redesign more than welcomed !!

Thanks

That part looks pretty easy. Where in the code is the part that parses a zone file? Looking for the part that parses the

Zone "VST: AR-1 (Kush Audio)" 
  FocusedFXNavigator
  Toggle+ButtonB8 FXParam 0 "Bypass" { 90 255 0 255 50 0 }
 ZoneEnd

Messages to send RGB. I also need to look at the midi end to see what can be done about the extra channel needed for MFT.

[Geoff Waddington]

Originally Posted by gvanbrunt

Where in the code is the part that parses a zone file? Looking for the part that parses the

Zone "VST: AR-1 (Kush Audio)" 
  FocusedFXNavigator
  Toggle+ButtonB8 FXParam 0 "Bypass" { 90 255 0 255 50 0 }
 ZoneEnd

Messages to send RGB.

That's in a huge state of flux right now -- look at ProcessZoneFile in control_surface_integrator.cpp.

Also have a look at ActionContext constructor, lots in there

Originally Posted by gvanbrunt

I also need to look at the midi end to see what can be done about the extra channel needed for MFT.

Do you mean like this:

    virtual void ForceRGBValue(int r, int g, int b) override
    {
        lastR = r;
        lastG = g;
        lastB = b;
        
        if((r == 177 || r == 181) && g == 31) // this sets the different MFT modes
            SendMidiMessage(r, g, b);
        else
            SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));
    }

[Mavriq]

Originally Posted by Geoff Waddington

Do you mean like this:

    virtual void ForceRGBValue(int r, int g, int b) override
    {
        lastR = r;
        lastG = g;
        lastB = b;
        
        if((r == 177 || r == 181) && g == 31) // this sets the different MFT modes
            SendMidiMessage(r, g, b);
        else
            SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));
    }

Ya that is the part that isn't quite correct. What I mean about the MFT issue is that it requires 2 midi output channels to operate correctly. 2 and 6. 6 is needed if you want animations. So it's different than every other controller. The output channels are however hardwired so you don't need to worry about what the user sets.... Hope that make sense.

[Geoff Waddington]

Originally Posted by gvanbrunt

Ya that is the part that isn't quite correct. What I mean about the MFT issue is that it requires 2 midi output channels to operate correctly. 2 and 6. 6 is needed if you want animations. So it's different than every other controller. The output channels are however hardwired so you don't need to worry about what the user sets.... Hope that make sense.

Ummm...

I think we're in agreement here.

177 is B1 hex -- send B on channel 2

181 is B5 hex -- send B on channel 6

So there is a partial implementation.

The logic says, if you find a B1 or B5 treat the RGB values as state changes and send them directly.

Otherwise, treat it as a colour.

Am I missing something here ?

[Mavriq]

Originally Posted by Geoff Waddington

Ummm...

Am I missing something here ?

only the fact that I should lay off crack for a while... LOL


Don't know what I was thinking, that part of the code is in fact correct. There is one part of the code that needs a change so that you can send any midi number from 0 to 256 for the value though. As I mentioned before you couldn't send 1 or 2. If you change this part:

uint8_t colorMap7[128][3] = {{0, 0, 0},    // 0
    {255, 0, 0},    // 1 - Blue
    {255, 21, 0},    // 2 - Blue (Green Rising)
    {255, 34, 0},
    {255, 46, 0},
    {255, 59, 0},
    {255, 68, 0},
    {255, 80, 0},
    {255, 93, 0},
    {255, 106, 0},
    {255, 119, 0},
    {255, 127, 0},
    {255, 140, 0},
    {255, 153, 0},
    {255, 165, 0},
    {255, 178, 0},
    {255, 191, 0},
    {255, 199, 0},
    {255, 212, 0},
    {255, 225, 0},
    {255, 238, 0},
    {255, 250, 0},    // 21 - End of Blue's Reign

to this

uint8_t colorMap7[128][3] = { {0, 0, 0},    // 0
    {255, 0, 0},    // 1 - Blue
    {255, 13, 0},    // 2 - Blue (Green Rising)
    {255, 26, 0},
    {255, 38, 0},
    {255, 51, 0},
    {255, 64, 0},
    {255, 77, 0},
    {255, 89, 0},
    {255, 102, 0},
    {255, 115, 0},
    {255, 128, 0},
    {255, 140, 0},
    {255, 153, 0},
    {255, 166, 0},
    {255, 179, 0},
    {255, 191, 0},
    {255, 204, 0},
    {255, 217, 0},
    {255, 230, 0},
    {255, 242, 0},
    {255, 255, 0},    // 21 - End of Blue's Reign

it then works correctly.


I would send you a git push, but I'm working with the 1.1 commit so nothing "breaks" while I'm figuring out how everything works. Easier to copy and past to your current.

[Geoff Waddington]

Originally Posted by gvanbrunt

only the fact that I should lay off crack for a while... LOL

Haha, do that all the time myself, and without the aid of external substances

It' really hard to read existing code (my own included)

Originally Posted by gvanbrunt

There is one part of the code that needs a change so that you can send any midi number from 0 to 256 for the value though.

It's great that you actually have an MFT !

Once you tested all values in your table on the unit (perhaps you already have ), just post it here, I'll include it.

Thanks again, so great to be able to give up flying blind on this one !

[airon]

Include some docs for plebs like me. I‘ve got three of those things and I‘m itching to colour those things to shreds.

Btw, is anyone else interested in supporting the Midifighter 3d ? It‘s like the Novation Launchpad Mini but only 4x4 with forever arcade buttons. I‘m currently binding it to Reaper actions directly.

Only if there‘s more than myself using it though. You have more important things to spend your time on imho.

[cjewellstudios]

Originally Posted by airon

Include some docs for plebs like me. I‘ve got three of those things and I‘m itching to colour those things to shreds.

Btw, is anyone else interested in supporting the Midifighter 3d ? It‘s like the Novation Launchpad Mini but only 4x4 with forever arcade buttons. I‘m currently binding it to Reaper actions directly.

Only if there‘s more than myself using it though. You have more important things to spend your time on imho.

I'll have a 3d eventually

Do you mean RGB wise? Is it really not the same spec as the Twister?

They do so some funky stuff with their devices.

....

With the new sendMidi/sendOSC actions coming, we should be able to get access to the animations for the twister unless gvanrbrunt also plans on expanding the FB processor to allow for that too

[Mavriq]

Originally Posted by Geoff Waddington

It's great that you actually have an MFT !

Once you tested all values in your table on the unit (perhaps you already have ), just post it here, I'll include it.

Sadly I don't have one. I only noticed the issue because I'm using the MFT Feedback Processor with my 2 controllers. They use values between 01 and 07 for the 2nd data byte. I noticed it was never producing a 1. It jumped from 00 to 02. If you look at the "1st part of the table" you can see there is a large jump there compared to the the "other 5 parts". The jump is from 0 to 21. Using the one I posted above it now works correctly.

For testing I'm posting a v1.1 test build with the correction. Can someone test this with your MFT and see that it works? FYI its 64 bit even though it doesn't have the 64 at the end of the filename.

Originally Posted by airon

Btw, is anyone else interested in supporting the Midifighter 3d ? It‘s like the Novation Launchpad Mini but only 4x4 with forever arcade buttons. I‘m currently binding it to Reaper actions directly..

It can work with the current MFT Processor. It does work slightly different, but can work with it. There is a few things missing from the Wiki docs that I'd be happy to update if Geoff gives me access.

The way the current MFT Feedback works you specify an RGB that gets translated into a hex number under the hood. It can be a bit of a chore to figure out what value to use to get the color you want. The is a table at the end of the MFT page for some of the values.

I'm going to be writing a Feedback Processor that is more general purpose. It essentially works the same way as the MFT, but instead of RGB values you just specify the Needed Hex for the color codes. It will then work with a wide variety of controllers, including the MFT. If you can be patient I'm going to do that in the next bit. It's taken me a bit as my C++ was rather stale and I had/have to learn the CSI code. I'm getting a good handle on it and hopefully can have something in the next couple of weeks.

Geoff: I sent you a PM, in case you didn't see it.

[Geoff Waddington]

Originally Posted by gvanbrunt

Geoff: I sent you a PM, in case you didn't see it.

PMd you.

[Mavriq]

OK, so I finally came down from my crack binge and can now explain what is wrong with the MFT implementation.

To recap CSI code is written so that if

    "B1 1F" or "B5 1F" 

  if((r == 177 || r == 181) && g == 31) // this sets the different MFT modes
      SendMidiMessage(r, g, b);

send that exact message along with "b" (in rgb) in data byte 2. What it should be sending is :

"x1 ab cd" or "x5 ab cd"

where x is either a note (9) or CC message (B) it can be setup for both.
1 sends on channel 2 and will set the color. A 5 sets animation.

ab is the original note or cc data byte.

cd is the color or animation code you want to set.

Colors will work currently as most users will have something like:

 
Widget ButtonB8
   Press  B0 1E 7F  B0 1E 00
   FB_MFT_RGB B1 1E 7F
WidgetEnd

in their mst file. So if they specify something like this:

  ButtonB8 Play { 0 25 255 0 189 255 }

That will send the correct status and first data byte from the mst for the control and so it will work. But what if you want to set and animation? According to CSI if you send something like this:

  ButtonB8 Play { 0 25 255 177 31 255 }

That will output B1 1F FF on a B8 button press. Which will animate whatever button actually happens to assigned B1 1F, not the one you are targeting.

So the question is how to fix that going forward. Is the RGB code after an action in a zone only for the MFT at this point Or do other controllers take advantage of it? Faderport seems to

Could interpretation be left up to the feedback processor? As it stands it's the part of the action context in the RGBValues_ vector.

I know you have a lot on your plate right now, but since you are in the middle of a huge overhaul, it might be a good time to think about now as a breaking change may work better in the long run. Maybe store the parameters in the action context and pass to feedback process and let it sort it out? That won't be breaking and would allow processes to do whatever they need.

[Geoff Waddington]

Originally Posted by gvanbrunt

OK, so I finally came down from my crack binge and can now explain what is wrong with the MFT implementation.

To recap CSI code is written so that if

    "B1 1F" or "B5 1F" 

  if((r == 177 || r == 181) && g == 31) // this sets the different MFT modes
      SendMidiMessage(r, g, b);

send that exact message along with "b" (in rgb) in data byte 2. What it should be sending is :

"x1 ab cd" or "x5 ab cd"

where x is either a note (9) or CC message (B) it can be setup for both.
1 sends on channel 2 and will set the color. A 5 sets animation.

ab is the original note or cc data byte.

cd is the color or animation code you want to set.

Colors will work currently as most users will have something like:

 
Widget ButtonB8
   Press  B0 1E 7F  B0 1E 00
   FB_MFT_RGB B1 1E 7F
WidgetEnd

in their mst file. So if they specify something like this:

  ButtonB8 Play { 0 25 255 0 189 255 }

That will send the correct status and first data byte from the mst for the control and so it will work. But what if you want to set and animation? According to CSI if you send something like this:

  ButtonB8 Play { 0 25 255 177 31 255 }

That will output B1 1F FF on a B8 button press. Which will animate whatever button actually happens to assigned B1 1F, not the one you are targeting.

So the question is how to fix that going forward. Is the RGB code after an action in a zone only for the MFT at this point Or do other controllers take advantage of it? Faderport seems to

Could interpretation be left up to the feedback processor? As it stands it's the part of the action context in the RGBValues_ vector.

I know you have a lot on your plate right now, but since you are in the middle of a huge overhaul, it might be a good time to think about now as a breaking change may work better in the long run. Maybe store the parameters in the action context and pass to feedback process and let it sort it out? That won't be breaking and would allow processes to do whatever they need.

Ah, I think I see where the confusion is coming from.

You don't set RGB colours in the .mst, you set them in the Zone files.

The .mst in your example should look like this:

Widget ButtonB8
   Press  B0 1E 7F  B0 1E 00
   FB_MFT_RGB B0 1E 7F
WidgetEnd

Here's how it was implemented:

https://forum.cockos.com/showpost.ph...0&postcount=79

So you would end up with something like:

{ 0 255 0   181 31 9 }

for slow strobing green.

At least that's how I remember it working

[edit] or it might be this:

{ 181 31 9   0 255 0 }

[Mavriq]

I know the the response CSI generates is from both the mst and the Zone file. It does work correctly for colors.

However, no matter what button is in the mst, CSI will always generate "B5 1F <color>" where color is the RGB b value. When trying to set an animation. So it will only be able to work with one button/encoder.

For Example

Zone "Buttons"
    But8Ch7                Play    { 0 25 255 181 31 255 }
    But8Ch8                Stop    { 0 25 255 181 31 12 }
 ZoneEnd

The mst

Widget But8Ch7
 Press 90 3e 7F 80 3e 7F
FB_MFT_RGB 90 3e 7F
WidgetEnd

Widget But8Ch8
 Press 90 3f 7F 80 3f 7F
 FB_MFT_RGB 90 3f 7F
 WidgetEnd

The output when the 1st, then the second buttons are pressed:

OUT->APC Mini  b5  1f  ff 
OUT->APC Mini  90  3f  03 
OUT->APC Mini  b5  1f  0c 
OUT->APC Mini  90  3e  03

That is from an actual test I ran with the actual output from Reaper. Notice it produces the same "b5 1f" for both buttons. That is supposed to be note specific. It is supposed to return the original cc or note values and the color for the 2nd data byte.

[Geoff Waddington]

Originally Posted by gvanbrunt

I know the the response CSI generates is from both the mst and the Zone file. It does work correctly for colors.

However, no matter what button is in the mst, CSI will always generate "B5 1F <color>" where color is the RGB b value. When trying to set an animation. So it will only be able to work with one button/encoder.

For Example

Zone "Buttons"
    But8Ch7                Play    { 0 25 255 181 31 255 }
    But8Ch8                Stop    { 0 25 255 181 31 12 }
 ZoneEnd

The mst

Widget But8Ch7
 Press 90 3e 7F 80 3e 7F
FB_MFT_RGB 90 3e 7F
WidgetEnd

Widget But8Ch8
 Press 90 3f 7F 80 3f 7F
 FB_MFT_RGB 90 3f 7F
 WidgetEnd

The output when the 1st, then the second buttons are pressed:

OUT->APC Mini  b5  1f  ff 
OUT->APC Mini  90  3f  03 
OUT->APC Mini  b5  1f  0c 
OUT->APC Mini  90  3e  03

That is from an actual test I ran with the actual output from Reaper. Notice it produces the same "b5 1f" for both buttons. That is supposed to be note specific. It is supposed to return the original cc or note values and the color for the 2nd data byte.

Ah, OK, I think my feeble brain just clicked

In my "one afternoon" implementation (as shown on the quoted post), I read the spec supplied by the user as absolute -- DOH

So, likely what you want to do is to change this :

   virtual void ForceRGBValue(int r, int g, int b) override
    {
        lastR = r;
        lastG = g;
        lastB = b;
        
        if((r == 177 || r == 181) && g == 31) // this sets the different MFT modes
            SendMidiMessage(r, g, b);
        else
            SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));
    }

to:

   virtual void ForceRGBValue(int r, int g, int b) override
    {
        lastR = r;
        lastG = g;
        lastB = b;
        
        if(r == 177 || r == 181) // this sets the different MFT modes
            SendMidiMessage(r, midiFeedbackMessage1_->midi_message[1], b);
        else
            SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));
    }

Does that do it ?



I always try to forget about the musical definition of midi, because the controller protocols hijack it to mean something else.

What we really have here is:

byte1 -- 0x90 -- it's a button

byte2 -- ?? -- which button

byte3 -- which colour

Nothing to do with notes, cc, or anything else musical



In the mode switch case we have:

byte1 -- 0xB1 or 0xB5 -- which mode -- inactive colour or animation

byte 2 -- ?? -- which button

byte 3 -- which mode value -- active/inactive/strobe, etc.

This one amounts to a double hijack

They are not r, g, b values, but rather r = mode, g = ignored (replaced by actual button ID), b = mode value

Do I finally have this right ?

And thanks for your patience




BTW, you a curling fan ?

I see you are in Thunder Bay, catching any of the Scotties ?

[Mavriq]

Originally Posted by Geoff Waddington

Does that do it ?

I'm not sure, but I think so. Let me build that and test. FYI There was also some more tweaking needed on the color table. I'm going to whip up a test and make sure it can output every number correctly from 0 to 127.

Originally Posted by Geoff Waddington

BTW, you a curling fan ?

I see you are in Thunder Bay, catching any of the Scotties ?

Yep, good ol' Tbay. I've been so busy I haven't followed any sports closely. Even Hockey. Thought that was a requirement for being Canadian. Don't tell anyone, I'd hate to have my citizenship revoked... LOL

[cjewellstudios]

Don't worry, my hockey fandom makes up for the Canadians in this thread who choose not to partake

I'm just about as Canadian-adjacent as you can get.

Curling is also incredible but I have almost zero access to it.

[Mavriq]

Ok so that was close but one more change needed.

if((r == 149 || r == 181) && g == 31) // this sets the different MFT modes
    SendMidiMessage(r, midiFeedbackMessage1_->midi_message[1], b);
    //SendMidiMessage(r, g, b);
else
      SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));

You don't need to check for 177 as color already works. 181 will never conflict with color as it a color has to have 255 and 0. These two calls violate that, so its not a "color". The other code to check for is 149 (95). The MFT can be setup to send either a CC or a Note, so you have to check for both...

So with this mst:

Widget But8Ch7
 Press 90 3e 7F 80 3e 7F
 FB_MFT_RGB 90 3e 7F
WidgetEnd

Widget But8Ch8
 Press 90 3f 7F 80 3f 7F
 FB_MFT_RGB 90 3f 7F
WidgetEnd

with this zone:

Zone "Buttons"
    But8Ch6                Play     { 0 0 255 181 31 255 }
    But8Ch7                Stop     { 0 0 255 149 31 12 }
    But8Ch8                Record        { 0 0 255 255 122 0 }
ZoneEnd

We get

OUT->APC Mini  b5  3e  ff   --- Play = Midi CC
OUT->APC Mini  90  3e  00 
OUT->APC Mini  95  3e  0c   ---- Stop = Midi Note
OUT->APC Mini  90  3e  00 
OUT->APC Mini  90  3f  4c   --- Record = Color Sent with Original button
OUT->APC Mini  b5  3e  ff 
OUT->APC Mini  90  3e  00

That fixes the animation issue. Still have to get the color table working 100%. I'll make a test shortly.

[Funkybot]

Originally Posted by gvanbrunt

Ok so that was close but one more change needed.

if((r == 149 || r == 181) && g == 31) // this sets the different MFT modes
    SendMidiMessage(r, midiFeedbackMessage1_->midi_message[1], b);
    //SendMidiMessage(r, g, b);
else
      SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));

You don't need to check for 177 as color already works. 181 will never conflict with color as it a color has to have 255 and 0. These two calls violate that, so its not a "color". The other code to check for is 149 (95). The MFT can be setup to send either a CC or a Note, so you have to check for both...

So with this mst:

Widget But8Ch7
 Press 90 3e 7F 80 3e 7F
 FB_MFT_RGB 90 3e 7F
WidgetEnd

Widget But8Ch8
 Press 90 3f 7F 80 3f 7F
 FB_MFT_RGB 90 3f 7F
WidgetEnd

with this zone:

Zone "Buttons"
    But8Ch6                Play     { 0 0 255 181 31 255 }
    But8Ch7                Stop     { 0 0 255 149 31 12 }
    But8Ch8                Record        { 0 0 255 255 122 0 }
ZoneEnd

We get

OUT->APC Mini  b5  3e  ff   --- Play = Midi CC
OUT->APC Mini  90  3e  00 
OUT->APC Mini  95  3e  0c   ---- Stop = Midi Note
OUT->APC Mini  90  3e  00 
OUT->APC Mini  90  3f  4c   --- Record = Color Sent with Original button
OUT->APC Mini  b5  3e  ff 
OUT->APC Mini  90  3e  00

That fixes the animation issue. Still have to get the color table working 100%. I'll make a test shortly.

Nice progress Geoff! Would be great to add animations to the MFTwister setup.

Looking at your example, I undersand how you can use the feedback on Button8 to show the Play, Stop or Record status, but let's say those actions are assigned to 3 different buttons. What would that syntax look like?

Example: let's say someone had a Twister setup like this"

Button14   Play    { 242 255 0  0 189 255 } // yellow when not in playback, green when play is on
Button15   Stop
Button16   Record  { 255 50 0  90 255 0 }  // red when recording, green when off

...what would the syntax look like to also make the red blink when recording, or the green blink during playback?

Would there be additional widgets and rows in the code? So I'd have 3 additional FB widgets (one each for channels 6, 7, 8) for each of the 16 buttons, and then I'd have to add those to the zone files if I wanted to use them?

Would this be easier than just waiting on Geoff Waddington's implementation of "SendMIDI" as a new command type? Just trying to understand how this would all tie together.

[Geoff Waddington]

Originally Posted by gvanbrunt

Ok so that was close but one more change needed.

if((r == 149 || r == 181) && g == 31) // this sets the different MFT modes
    SendMidiMessage(r, midiFeedbackMessage1_->midi_message[1], b);
    //SendMidiMessage(r, g, b);
else
      SendMidiMessage(midiFeedbackMessage1_->midi_message[0], midiFeedbackMessage1_->midi_message[1], GetColorIntFromRGB(r, g, b));

You don't need to check for 177 as color already works. 181 will never conflict with color as it a color has to have 255 and 0. These two calls violate that, so its not a "color". The other code to check for is 149 (95). The MFT can be setup to send either a CC or a Note, so you have to check for both...

So with this mst:

Widget But8Ch7
 Press 90 3e 7F 80 3e 7F
 FB_MFT_RGB 90 3e 7F
WidgetEnd

Widget But8Ch8
 Press 90 3f 7F 80 3f 7F
 FB_MFT_RGB 90 3f 7F
WidgetEnd

with this zone:

Zone "Buttons"
    But8Ch6                Play     { 0 0 255 181 31 255 }
    But8Ch7                Stop     { 0 0 255 149 31 12 }
    But8Ch8                Record        { 0 0 255 255 122 0 }
ZoneEnd

We get

OUT->APC Mini  b5  3e  ff   --- Play = Midi CC
OUT->APC Mini  90  3e  00 
OUT->APC Mini  95  3e  0c   ---- Stop = Midi Note
OUT->APC Mini  90  3e  00 
OUT->APC Mini  90  3f  4c   --- Record = Color Sent with Original button
OUT->APC Mini  b5  3e  ff 
OUT->APC Mini  90  3e  00

That fixes the animation issue. Still have to get the color table working 100%. I'll make a test shortly.

Thanks, great work !!

[Mavriq]

Yikes, This took a bit to work out. Here is a much slimmed down version of GetColorIntFromRGB that works without a table. There is also a console program that runs through all the possible color values and the corresponding value that will be sent to the MFT. This and the previous change should make everything work for the MFT. I'm going to post a test 1.1 version for others to play with.

#include <iostream>


int GetColorIntFromRGB(int r, int g, int b)
{
    if (b == 0 && g == 0 && r == 0)
        return 0;
    else if (b > 224 && g > 239 && r > 239)
        return 127;
    else if (b == 255 && r == 0)
    {
        return g  / 12.16 + 1;
    }
    else if (g == 255 && r == 0)
    {
        return ((254 + 1) - b) / 12.16 + 22;
    }
    else if (b == 0 && g == 255)
    {
        return r / 12.16 + 43;
    }
    else if (b == 0 && r == 255)
    {
        return((254 + 1) - g) / 12.16 + 64;
    }
    else if (g == 0 && r == 255)
    {
        return b / 12.16 + 85;
    }
    else if (b == 255 && g == 0)
    {
        return((254 + 1) - r) / 12.16 + 106;
    }

    return 0;
}

int main()
{
    int r = 0;
    int g = 0;
    int b = 0;
    int MFT_Num;

    MFT_Num = GetColorIntFromRGB(r, g, b);
    std::cout << "{0, 0, 0} MFT Num: " << MFT_Num << "\n";

    for (g = 0; g <= 255; g++) { // Green rising
        r = 0;
        b = 255;
        MFT_Num = GetColorIntFromRGB(r, g, b);
        std::cout << "{255, " << g << ", 0} MFT Num: " << MFT_Num << "\n"; 
    }

    for (b = 254; b >= 0; b--) {    // blue fading
        r = 0;
        g = 255;
        MFT_Num = GetColorIntFromRGB(r, g, b);
        std::cout << "{" << b << ", 255, 0} MFT Num: " << MFT_Num << "\n";
    }

    for (r = 1; r <= 255; r++) {    // red rising
        b = 0;
        g = 255;
        MFT_Num = GetColorIntFromRGB(r, g, b);
        std::cout << "{0, 255, " << r << "} MFT Num: " << MFT_Num << "\n";
    }

   for (g = 254; g >= 0; g--) {    // green fading
        b = 0;
        r = 255;
        MFT_Num = GetColorIntFromRGB(r, g, b);
        std::cout << "{0, " << g << ", 255} MFT Num: " << MFT_Num << "\n";
    }
     for (b = 1; b <= 255; b++) { // Blue rising
        r = 255;
        g = 0;
        MFT_Num = GetColorIntFromRGB(r, g, b);
        std::cout << "{" << b << ", 0, 255} MFT Num: " << MFT_Num << "\n";
    }


   for (r = 254; r >= 1; r--) {    // 108 - Blue/ Red Fading
        b = 255;
        g = 0;
        MFT_Num = GetColorIntFromRGB(r, g, b);
        std::cout << "{255, 0, " << r << "} MFT Num: " << MFT_Num << "\n";
    }

   r = 255;
   g = 255;
   b = 255;
   MFT_Num = GetColorIntFromRGB(r, g, b);
   std::cout << "{255, 255, 255} MFT Num: " << MFT_Num << "\n";
   
}

[Mavriq]

Originally Posted by Funkybot

.what would the syntax look like to also make the red blink when recording, or the green blink during playback?

You would do something like this I think. I don't have a MFT to test with:

Button14   Play    { 242 255 0  0 189 255 } // yellow when not in playback, green when play is on
Button14   NoAction{ 181 31 0  181 31 4} // yellow when not in playback, green when play is on
Button15   Stop
Button16   Record  { 255 50 0  90 255 0 }  // red when recording, green when offn off
Button16   NoAction { 181 31 0  181 31 4 }  // red when recording, green when offn off

If your MFT is setup to send CC (It is by default I believe) for animations the code starst with "181 31", other wise it's "149 31". The animation code is the last value, 4 in this case. You can get them from the MFT manual.

Here is a 64bit v 1.1Windows build to test with. I don't have a mac build environment currently.

Would this be easier than just waiting on Geoff Waddington's implementation of "SendMIDI" as a new command type? Just trying to understand how this would all tie together.

This is how it was supposed to work since the end of Nov, but I guess everyone missed the change and the requester never got back to Geoff with test results. I don't know how SendMIDI implementation will look when finished, but I believe it will be similar. IE an extra row for every button you want an animation on. I'm guessing the syntax will be std midi instead of the r,g,b type value.

[buschag]

After searching through the CSI wiki pages, I can't find the page where it explains toggle button entries for fx mapping. For example, if I want a button to toggle between VU modes of gain reduction and output of a compressor, I can't imagine I just map that to "button12" and leave it at that...