Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by Freex

Just wondering if there's a way of knowing which state the Show & Write actions are (eg. Input, Output, Show FX, Write FX)

I was making a start at getting back on the horse and couldn't seem to get any FX to write to ZoneFXZoneFiles

Finally got it, but at one point I thought it wasn't write on insert but rather on deletion.

Also having "Show Fx Params" on, seems to bottle neck the process, (yes I thought I'd stress test it with a few at once lol).

Hmmm...

Yeah, that's a bit tricky with Reaper actions...

Yes, show FX params uses ReaConsole, which is not optimized for throughput, it's probably meant for status updates, we are using it in a way it was probably never intended to be used

[Geoff Waddington]

Originally Posted by Funkybot

Hi Geoff, best I can tell, there's no way to get MCUTrackPan to work as expected in OSC because there's no "toggle" message in the .ost. Or at least, I haven't found a way to successfully incorporate that yet.

This wouldn't be a big deal as I could just "GoZone PanL-R," except there doesn't appear to be TrackPanLDisplay and TrackPanRDisplay actions. Can we add those to the list? MCUTrackPan works great on physical surfaces with a rotary push, but for OSC I think we need a different solution.

That brings my requested displays up to:

TrackPanLDisplay
TrackPanRDisplay
TrackSendPanDisplay
TrackSendPrePostDisplay
PageNameDisplay

Noted.

[Geoff Waddington]

Originally Posted by paat

Some questions as I'm digging more into this:

1. What is a page?
2. Can I send arbitrary MIDI to my device in response to an action? e.g. my device (MIDI Fighter Twister) lets you set light color via MIDI. I'd like to define a zone that changes the color so I have a visual indicator of what zone I'm in.
3. How do I distinguish between the same MIDI note coming in on different channels? I haven't seen anything about MIDI channels in any of the surface definitions.
4. Can I have a zone that passes MIDI notes through to the current track? I have a controller that sends MIDI notes. I'd like to press a combo of them switch between CSI controller mode and normal MIDI note entry. How could I configure that?

Midi channels do not exist in control surface protocol, it is a meaningless concept.

For instance, the MCU defines faders this way:

Fader1 e0 7f 7f
Fader2 e1 7f 7f
Fader3 e2 7f 7f
Fader4 e3 7f 7f
...

You can see how they repurposed the channel numbers to mean fader numbers, so please forget about Midi (I know it's hard if you are used to Midi ), it is simply a way to confuse yourself when talking about control surface protocol.

Sending arbitrary messages is on the to do list.

You can't use a Midi device in both an instrument role and a controller role, that's a Reaper limitation as far as I know -- you have to disable a device in Midi devices in order to use it as a controller.

Pages provide a way to get CSI to completely change its stripes.

When you go to another Page it is like starting over.

You can have entirely different surface templates, Zone folders, etc.

It's made for big workflow changes like Tracking, Mixing, Post production, etc,, but you can use the concept for anything you like

[Freex]

Originally Posted by Geoff Waddington

Hmmm...

Yeah, that's a bit tricky with Reaper actions...

Yes, show FX params uses ReaConsole, which is not optimized for throughput, it's probably meant for status updates, we are using it in a way it was probably never intended to be used

Yeah I kinda gathered that was the reason it wasn't already done.

I set a toolbar just for the CSI actions in Reaper, obviously (due to lag) I don't want show fx open and or write fx active all the time, so would have been cool if the toolbar buttons had been able to reflect status.
But it's hardly a big deal either way. There are way more important things.

Awesome work. As always.

FYI. I got up to over 300 writes at once.
Yes I loaded over that many vsts to one track, at once, Sure it took a while for it to do (as you'd expect) but no crashes or any ugliness.
And they all wrote to the RawZoneFxFile.

[fricia]

Hey everyone

Thanks to all of you for your great work! I love CSI and really value the effort and love you (especially Geoff) put into it

I spent this afternoon trying to setup my Icon Platform x+ (standalone) and while most of the things work really well there are some problems I have run into. I have tried to work it out with the help of this thread and the wiki but couldn't find a solution.

1. When I use MapSelectedTrackSendsToWidgets and then switch to a track with more sends than the track that was selected when the sends were mapped, the additional sends aren't mapped at all. I have to press the mapping button again to map those too.

2. TrackBank is not working. Like it just doesn't do anything at all. ScrollLink is working as expected though.

3. I've tried to create an FX Zone for an EQ, but the release messages of my buttons/rotaryPush always override everything else. So I can bypass the eq band or the eq but can't unbypass it. On the Shape paramter I can toggle, by holding the rotary pressed, but on release it switches back to what it was set at before. Same thing if I map the parameters to a button. I'm not sure I understand exactly how toggle+ works, so maybe the problem lies there...

4. It there a way to get the following behaviour:
-Rotary controles pan
-Rotary press & turn controls width
-Rotary press resets pan
Just using Pan as an example here, would be useful for FX as well.

Any help is appreciated!

Widget RotaryPush1
	Press 90 20 7f 90 20 00
WidgetEnd
.
.
.
Widget RotaryPush8
	Press 90 27 7f 90 27 00 
WidgetEnd

Widget Rotary1
	Encoder b0 10 7f [ > 01-07 < 41-47 ]
	FB_Encoder b0 10 7f
     	Toggle 90 20 7f
WidgetEnd
.
.
.
Widget Rotary8
	Encoder b0 17 7f [ > 01-07 < 41-47 ]
	FB_Encoder b0 17 7f
     	Toggle 90 27 7f
WidgetEnd

Widget FaderTouch1
	Press 90 68 7f 90 68 00
WidgetEnd
.
.
.
Widget FaderTouch8
	Press 90 6f 7f 90 6f 00
WidgetEnd


Widget Fader1
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
WidgetEnd
.
.
.
Widget Fader8
	Fader14Bit e7 7f 7f
	FB_Fader14Bit e7 7f 7f
WidgetEnd


Widget Select1
	Press 90 18 7f 90 18 00
	FB_TwoState 90 18 7f 90 18 00
WidgetEnd
.
.
.
Widget Select8
	Press 90 1f 7f 90 1f 00
	FB_TwoState 90 1f 7f 90 1f 00
WidgetEnd


Widget Mute1
	Press 90 10 7f 90 10 00
	FB_TwoState 90 10 7f 90 10 00
WidgetEnd
.
.
.
Widget Mute8
	Press 90 17 7f 90 17 00
	FB_TwoState 90 17 7f 90 17 00
WidgetEnd



Widget Solo1
	Press 90 08 7f 90 08 00
	FB_TwoState 90 08 7f 90 08 00
WidgetEnd
.
.
.
Widget Solo8
	Press 90 0f 7f 90 0f 00
	FB_TwoState 90 0f 7f 90 0f 00
WidgetEnd



Widget RecordArm1
	Press 90 00 7f 90 00 00
	FB_TwoState 90 00 7f 90 00 00
WidgetEnd
.
.
.
Widget RecordArm8
	Press 90 07 7f 90 07 00
	FB_TwoState 90 07 7f 90 07 00
WidgetEnd

Zone "Home"	
	OnFXFocus	MapFocusedFXToWidgets

    IncludedZones
        "Channel"
	"Buttons"
    IncludedZonesEnd
ZoneEnd

Zone "Buttons"
	RecordArm1 		Shift
	RecordArm2		Control
	RecordArm3		GoZone "Home"
	RecordArm4		MapSelectedTrackSendsToWidgets
	RecordArm5		MapFocusedFXToWidgets
	RecordArm6		ForceScrollLink
	Shift+RecordArm6 T	ToggleScrollLink
	RecordArm7 		TrackBank "-1" 
	RecordArm8 		TrackBank "+1"

ZoneEnd

Zone "Channel"
	TrackNavigator
	
	Rotary| 		TrackPan
	RotaryPush| 		TrackUniqueSelect
	RotaryPush| 		Reaper _XENAKIOS_PANTRACKSCENTER
	Shift+Rotary|   	TrackPanWidth
	Shift+RotaryPush|	Reaper _RS94166409be8afa82828bf1e3c77365b9ca19c3ef //Reset Width
	
	Fader|			TrackVolume

	Select|			TrackUniqueSelect
	Shift+Select|		TrackSelect
	Control+Select|		TogglePin

	Toggle+Mute|		TrackMute
	Shift+Mute| 		TrackUniqueSelect
	Shift+Mute| 		Reaper _XENAKIOS_RESETTRACKVOL1

	Solo| 			TrackSolo
	Control+Shift+Solo|	TrackUniqueSelect
	Control+Shift+Solo|	Reaper 40340	//unsolo all tracks
	Control+Shift+Solo|	Reaper 40728	//solo selected track
	Control+Solo|		ClearAllSolo
ZoneEnd

Zone "Send"
     	SendNavigator
      	Mute| 		TrackSendMute
      	Fader| 		TrackSendVolume
      	Rotary| 	TrackSendPan
ZoneEnd

Zone "VST3: TDR VOS SlickEQ GE (Tokyo Dawn Labs)"
	FocusedFXNavigator

	Rotary3 FXParam 0 "LOW Gain"
	Rotary2 FXParam 1 "LOW Freq"
	Toggle+RotaryPush2 FXParam 2 "LOW Shape"
	Toggle+RotaryPush3 FXParam 27 "LOW Bypass"
	Toggle+RecordArm8 FXParam 36 "Bypass"
ZoneEnd

[MixMonkey]

Originally Posted by fricia

1. When I use MapSelectedTrackSendsToWidgets and then switch to a track with more sends than the track that was selected when the sends were mapped, the additional sends aren't mapped at all. I have to press the mapping button again to map those too.

I've noticed this too. It's a bug.

2. TrackBank is not working. Like it just doesn't do anything at all. ScrollLink is working as expected though.

Can't see why it wouldn't unless that rogue "T" is gumming up the works

4. It there a way to get the following behaviour:
-Rotary controles pan
-Rotary press & turn controls width
-Rotary press resets pan

I've tweaked your .zon a bit. We can't do Press and turn, but press should toggle between Pan And Width. See if it works any better.

Zone "Home" 
    OnFXFocus   MapFocusedFXToWidgets

    IncludedZones
        "Channel"
        "Buttons"
    IncludedZonesEnd
ZoneEnd

Zone "Buttons"
    RecordArm1          Shift
    RecordArm2          Control
    RecordArm3          GoZone "Home"
    RecordArm4          MapSelectedTrackSendsToWidgets
    RecordArm5          MapFocusedFXToWidgets
    RecordArm6          ToggleScrollLink
    RecordArm7          TrackBank "-1" 
    RecordArm8          TrackBank "+1"
ZoneEnd

Zone "Channel"
    TrackNavigator  
    Rotary|             MCUTrackPan
    RotaryPush|         NoAction
    Fader|              TrackVolume
    Select|             TrackUniqueSelect
    Shift+Select|       TrackRangeSelect
    Control+Select|     TogglePin
    Mute|               TrackMute
    Shift+Mute|         TrackUniqueSelect
    Shift+Mute|         Reaper _XENAKIOS_RESETTRACKVOL1
    Solo|               TrackSolo
    Control+Shift+Solo| TrackUniqueSelect
    Control+Shift+Solo| Reaper 40340    //unsolo all tracks
    Control+Shift+Solo| Reaper 40728    //solo selected track
    Control+Solo|       ClearAllSolo
ZoneEnd

Zone "Send"
    SendNavigator
    Mute|               TrackSendMute
    Fader|              TrackSendVolume
    Rotary|             TrackSendPan
ZoneEnd

3. I've tried to create an FX Zone for an EQ, but the release messages of my buttons/rotaryPush always override everything else. So I can bypass the eq band or the eq but can't unbypass it. On the Shape paramter I can toggle, by holding the rotary pressed, but on release it switches back to what it was set at before. Same thing if I map the parameters to a button. I'm not sure I understand exactly how toggle+ works, so maybe the problem lies there...

Toggle+ is deprecated in V1.0. It's replaced with a stepped parameter with only two steps:

Zone "VST3: TDR VOS SlickEQ GE (Tokyo Dawn Labs)"
    FocusedFXNavigator
    Rotary3 FXParam 0                       //LOW Gain
    Rotary2 FXParam 1                       //LOW Freq
    RotaryPush2 FXParam 2   [ 0.0 1.0 ]     //LOW Shape
    RotaryPush3 FXParam 27  [ 0.0 1.0 ]     //LOW Bypass
    RecordArm8 FXParam 36   [ 0.0 1.0 ]     //Bypass
ZoneEnd

As a general rule I'd avoid VST3 plugins if you have a VST2 alternative. They had (have?) a tendency to stop receiving commands from the surface for no apparent reason. See how you get on though, things might be different in V1.0.

[fricia]

Originally Posted by MixMonkey

Really helpful advice!

Thanks MixMonkey! I got the banking to work. Left banking was probably messed up by the rogue "T" and right banking works like a charm with "number" instead of "+number".

I'm aware of the MCUTrackPan function. Hoping for press and turn in V2.0 then

Ahh seems I have missed the deprecation of toggle+. I actually tried the stepped parameter solution, but I think I forgot to the delete the toggle+ when trying it. Well... you gotta learn somehow. Works perfectly now, thank you very much!

[MixMonkey]

Originally Posted by fricia

Thanks MixMonkey! I got the banking to work. Left banking was probably messed up by the rogue "T" and right banking works like a charm with "number" instead of "+number".

I'm aware of the MCUTrackPan function. Hoping for press and turn in V2.0 then

Ahh seems I have missed the deprecation of toggle+. I actually tried the stepped parameter solution, but I think I forgot to the delete the toggle+ when trying it. Well... you gotta learn somehow. Works perfectly now, thank you very much!

Excellent Glad you got it working. I totally missed the "+"
Let us know how you get on with VST3.

[Geoff Waddington]

New build is up

CSI v1_0.zip

Adds support for MFT modes.

They are specified in the RGB brackets like this { 181 31 00 }

Refer to the MFT docs for the values.

[Funkybot]

Originally Posted by Geoff Waddington

New build is up

CSI v1_0.zip

Adds support for MFT modes.

They are specified in the RGB brackets like this { 181 31 00 }

Refer to the MFT docs for the values.

Hmmm....might be doing something wrong here. Got an example of how this would work in a .zon? I've tried several variations and not seeing any change on the MFTwister.

Here's what I got for the Hex values as decimals from Paat's prior post (decimal values at the end of each line - I hope that's right)...

{ b1 1f 00 } // force inactive color { 177 31 00 }
{ b1 1f 7f } // force active color { 177 31 127 }

{ b5 1f 00 } // reset animation {181 31 00 }

// These apply to the colorful light below the encoder

{ b5 1f 01 } // strobe slow { 181 31 01 }
{ b5 1f 08 } // strobe fast { 181 31 05 }

{ b5 1f 09 } // strobe slow { 181 31 09 }
{ b5 1f 10 } // strobe fast { 181 31 10 }

{ b5 1f 11 } // light off   { 181 31 11 }
{ b5 1f 2f } // max brightness per manual  { 181 31 47 }
{ b5 1f 30 } // max brightness per my test { 181 31 30 }

// These apply to the white encoder ring value

{ b5 1f 31 } // indicator strobe slow { 181 31 31 }
{ b5 1f 38 } // indicator strobe fast { 181 31 38 }

{ b5 1f 39 } // indicator pulse slow  { 181 31 39 }
{ b5 1f 40 } // indicator pulse fast  { 181 31 40 }

{ b5 1f 41 } // light off { 181 31 41 }
{ b5 1f 5f } // max brightness per manual { 181 31 95 }
{ b5 1f 60 } // max brightness per my test { 181 31 60 }

// Special rainbow animation
{ b5 1f 7f } { 181 31 127 }

Now let's say I currently have this turning my unassigned FXParam buttons Navy blue...how would I turn the button light off { 181 31 11 }?

DisplayRotaryPushB4 FXParamNameDisplay 999 "Unassigned"
RotaryPushB4 FXParam 999 { 0 75 255 0 255 255}

I tried this to no avail...

DisplayRotaryPushB4 FXParamNameDisplay 999 "Unassigned"
RotaryPushB4 FXParam 999 { 181 31 11 }

...I also tried including it inside the brackets with RGB values both at the start and end. No luck there either.

If I wanted to do a slow strobe { 181 31 09 } between Red and Green as shown here, what would the syntax look like:

DisplayRotaryPushB8 FXParamNameDisplay 12 "Bypass"
RotaryPushB8 FXParam 12 { 90 255 0 255 50 0 }

[paat]

To further clarify the three bytes, they are:

{ channel cc value }

I know Geoff says it's not MIDI and I don't 100% understand what he means by that, but those are what's represented in the three bytes sent to / from the MFT.

So for the purposes of changing a button's color or animation, we should only need to send channel and value - cc is the same as incoming. And if we want to be even more clever, we can know that color is on channel 2 and animation is on channel 5. So perhaps it ends up looking something like this:

Button1 NoAction MF_COLOR 32 // re-writes the first byte to b1, re-uses the second byte
Button1 MF_ANIMATION 0 // re-writes the first byte to b5, re-uses the second byte

[Geoff Waddington]

Originally Posted by Funkybot

Hmmm....might be doing something wrong here. Got an example of how this would work in a .zon? I've tried several variations and not seeing any change on the MFTwister.

Here's what I got for the Hex values as decimals from Paat's prior post (decimal values at the end of each line - I hope that's right)...

{ b1 1f 00 } // force inactive color { 177 31 00 }
{ b1 1f 7f } // force active color { 177 31 127 }

{ b5 1f 00 } // reset animation {181 31 00 }

// These apply to the colorful light below the encoder

{ b5 1f 01 } // strobe slow { 181 31 01 }
{ b5 1f 08 } // strobe fast { 181 31 05 }

{ b5 1f 09 } // strobe slow { 181 31 09 }
{ b5 1f 10 } // strobe fast { 181 31 10 }

{ b5 1f 11 } // light off   { 181 31 11 }
{ b5 1f 2f } // max brightness per manual  { 181 31 47 }
{ b5 1f 30 } // max brightness per my test { 181 31 30 }

// These apply to the white encoder ring value

{ b5 1f 31 } // indicator strobe slow { 181 31 31 }
{ b5 1f 38 } // indicator strobe fast { 181 31 38 }

{ b5 1f 39 } // indicator pulse slow  { 181 31 39 }
{ b5 1f 40 } // indicator pulse fast  { 181 31 40 }

{ b5 1f 41 } // light off { 181 31 41 }
{ b5 1f 5f } // max brightness per manual { 181 31 95 }
{ b5 1f 60 } // max brightness per my test { 181 31 60 }

// Special rainbow animation
{ b5 1f 7f } { 181 31 127 }

Now let's say I currently have this turning my unassigned FXParam buttons Navy blue...how would I turn the button light off { 181 31 11 }?

DisplayRotaryPushB4 FXParamNameDisplay 999 "Unassigned"
RotaryPushB4 FXParam 999 { 0 75 255 0 255 255}

I tried this to no avail...

DisplayRotaryPushB4 FXParamNameDisplay 999 "Unassigned"
RotaryPushB4 FXParam 999 { 181 31 11 }

...I also tried including it inside the brackets with RGB values both at the start and end. No luck there either.

If I wanted to do a slow strobe { 181 31 09 } between Red and Green as shown here, what would the syntax look like:

DisplayRotaryPushB8 FXParamNameDisplay 12 "Bypass"
RotaryPushB8 FXParam 12 { 90 255 0 255 50 0 }

I read the Twister spec, it's just about impossible to unravel, because of their idiotic use of Midi terminology instead of the 3 effin bytes, can you PLEASE just give me the 3 effin bytes , but try 176 and 180 instead of 177 and 181, dunno

[Geoff Waddington]

Originally Posted by paat

To further clarify the three bytes, they are:

{ channel cc value }

No that's wrong, in midi speak it's { cc(which is b0) or'd with channel(0-15) rotary encoder number value }

Originally Posted by paat

I know Geoff says it's not MIDI and I don't 100% understand what he means by that, but those are what's represented in the three bytes sent to / from the MFT.

Here's what I mean by "It's not Midi"

We just need the 3 effin bytes to send, not this convoluted garbage -- this from the Twister manual.

"To set the animation state of a given encoder send a CC or Note On message of the same number, but on channel 2.
ie To set the animation state of the first encoder to Gate 1/4 send a Ch2 CC 0 of value 5.
It is important to note that the MIDI color setting and MIDI animation setting can be used in conjunction.
ie. To set the first encoder to yellow flashing at a rate of 1/2 first send the color information with a Ch1 CC0 of value 64, then the animation setting with a
Ch2 CC0 of value 4.
If the encoder switch MIDI channel or number settings are changed from default the color and animation controls do NOT change, ie if you change Encoder 1 in Bank 1 from channel 1 number 0 to channel 5 num- ber 8 it will send MIDI on channel 5 number 8, but its color and animation controls will stay at channel 1 number 0 and channel 2 number 0 respectivley."

Note on message ?

Does the MFT make a sound ?

No it does not.

That's why I say it's not Midi, it's just 3 bytes of information nothing to do with note on, note off, midi channels, aftertouch, polyphonic pressure, midi status -- all, of this has no meaning whatsoever and has nothing to do with control surfaces.

It's just 3 bytes of controller information.

To paraphrase the late great Sean Connery in Red October -- "Give me a byte Vasili, 3 bytes only.

If anyone wants to sort this garbage out, I'll gladly supply you with some code

Maybe the best way is just to send the bytes directly using some software, then report the results here.

[Geoff Waddington]

Ok, anyone who understands the context of this question -- @Funkybot, this means you !! -- don't let the cat out of the bag, I'm not sure I can pull it off

I would like to add some features to CSI that require the latest version (6.16) of Reaper.

That would mean everyone would need to be on 6.16 or later once this is implemented.

Is there any resistance out there to CSI requiring Reaper 6.16 or later ?

[Freex]

Originally Posted by Geoff Waddington

Ok, anyone who understands the context of this question -- @Funkybot, this means you !! -- don't let the cat out of the bag, I'm not sure I can pull it off

I would like to add some features to CSI that require the latest version (6.16) of Reaper.

That would mean everyone would need to be on 6.16 or later once this is implemented.

Is there any resistance out there to CSI requiring Reaper 6.16 or later ?

I'm sure there will be some, but I'd say for the most part v1 is working well.
So just do v1.1 and add a new.

[Funkybot]

Originally Posted by Geoff Waddington

Ok, anyone who understands the context of this question -- @Funkybot, this means you !! -- don't let the cat out of the bag, I'm not sure I can pull it off

I would like to add some features to CSI that require the latest version (6.16) of Reaper.

That would mean everyone would need to be on 6.16 or later once this is implemented.

Is there any resistance out there to CSI requiring Reaper 6.16 or later ?

So it’s in 6.16?

Go for it! It’s totally worth it!!!

[cjewellstudios]

Originally Posted by Geoff Waddington

Ok, anyone who understands the context of this question -- @Funkybot, this means you !! -- don't let the cat out of the bag, I'm not sure I can pull it off

I would like to add some features to CSI that require the latest version (6.16) of Reaper.

That would mean everyone would need to be on 6.16 or later once this is implemented.

Is there any resistance out there to CSI requiring Reaper 6.16 or later ?

None from me.

I hope it has something to do with the recent api change to know when an fx loses focus. If it does, it would seem justifiable to make the move to require it since focused fx workflow is a big part of csi.

Either way, I stay up to date with Reaper.

Looking forward to trying the new MFT stuff but I'll be honest I couldn't think of a use case for strobe. Did I also catch that there maybe a better way of setting whatever color you want?

[Funkybot]

MIDI Fighter Twister Drama Continued...

This is going to make Geoff crazy, but if I send MIDI CC data out of Reaper and to the MFTwister, I can control the button state. But only one button at a time. And which button is based on MIDI CC#. So Ch. 6 MIDI CC 0 = Button1, Ch. 6 MIDI CC 1 = Button 2, etc.

So then I converted that MIDI data to Hex, then converted from Hex to Decimal. But if I send this to RotaryPushA1...

RotaryPushA1 FXParam 999 { 181 0 23 }

...I still get nothing. But if I send out a CC0 on MIDI Channel 6 with a value of 17, that button goes off.

Here's a sample of the conversion table I created just using either solid button or off button messages (note: where it says Rotary under my Widget Name, it should say RotaryPush).


And maybe it's just me, but since each button needs it's own unique message, and CSI won't know which widget corresponds to which button on the hardware (unless there is a way and I'm not picking up how), this seems like it would be a lot of effort for a very esoteric feature. I'm imagining literally having to build out a lookup table like this for each combination of buttons on each bank. That sounds crazy to me.

Last note: I could totally have done the conversion wrong somewhere on that table. I just found a website that converts MIDI to Hex, then another that converts Hex to decimal. I have no idea what I'm doing there otherwise!

[Funkybot]

Originally Posted by cjewellstudios

I hope it has something to do with the recent api change to know when an fx loses focus. If it does, it would seem justifiable to make the move to require it since focused fx workflow is a big part of csi.

Do we know for certain that went in with 6.16? I saw it in one of the dev builds leading up to 6.16 but not in the official release notes. And there hasn't been a 6.16+dev build since. This kinda made me think it was pulled out but I'm assuming Geoff would know better than I would.

[Geoff Waddington]

Originally Posted by Funkybot

MIDI Fighter Twister Drama Continued...

This is going to make Geoff crazy, but if I send MIDI CC data out of Reaper and to the MFTwister, I can control the button state. But only one button at a time. And which button is based on MIDI CC#. So Ch. 6 MIDI CC 0 = Button1, Ch. 6 MIDI CC 1 = Button 2, etc.

So then I converted that MIDI data to Hex, then converted from Hex to Decimal. But if I send this to RotaryPushA1...

RotaryPushA1 FXParam 999 { 181 0 23 }

...I still get nothing. But if I send out a CC0 on MIDI Channel 6 with a value of 17, that button goes off.

Here's a sample of the conversion table I created just using either solid button or off button messages (note: where it says Rotary under my Widget Name, it should say RotaryPush).


And maybe it's just me, but since each button needs it's own unique message, and CSI won't know which widget corresponds to which button on the hardware (unless there is a way and I'm not picking up how), this seems like it would be a lot of effort for a very esoteric feature. I'm imagining literally having to build out a lookup table like this for each combination of buttons on each bank. That sounds crazy to me.

Last note: I could totally have done the conversion wrong somewhere on that table. I just found a website that converts MIDI to Hex, then another that converts Hex to decimal. I have no idea what I'm doing there otherwise!

Try { 181 0 17 181 0 17 }
snd { 181 0 23 181 0 23 }

Also a good idea to make sure that the action sends feedback

And make sure to monitor the output...

[Geoff Waddington]

Originally Posted by Funkybot

Do we know for certain that went in with 6.16? I saw it in one of the dev builds leading up to 6.16 but not in the official release notes. And there hasn't been a 6.16+dev build since. This kinda made me think it was pulled out but I'm assuming Geoff would know better than I would.

No promises... early days.

[Funkybot]

Originally Posted by Geoff Waddington

Try { 181 0 17 181 0 17 }
snd { 181 0 23 181 0 23 }

Also a good idea to make sure that the action sends feedback

And make sure to monitor the output...

What am I lookin for in the in output? Ignore all the iPad rows...

OUT->X-Touch One  90  38  7f 
VST: MagicDeathEye (MDE)->LoadingZone---->iPad
OUT->iPad /DisplayUpperA1 Input
OUT->iPad /DisplayUpperA2 Threshold
OUT->iPad /DisplayUpperA3 Time
OUT->iPad /DisplayUpperA4 Attack
OUT->iPad /DisplayUpperA5 
OUT->iPad /DisplayUpperA6 
OUT->iPad /DisplayUpperA7 
OUT->iPad /DisplayUpperA8 
OUT->iPad /DisplayUpperB1 
OUT->iPad /DisplayUpperB2 
OUT->iPad /DisplayUpperB3 
OUT->iPad /DisplayUpperB4 
OUT->iPad /DisplayUpperB5 
OUT->iPad /DisplayUpperB6 
OUT->iPad /DisplayUpperB7 Output Gain
OUT->iPad /DisplayUpperB8 Mix
OUT->iPad /DisplayLowerA1 7
OUT->iPad /DisplayLowerA2 0
OUT->iPad /DisplayLowerA3 2
OUT->iPad /DisplayLowerA4 2
OUT->iPad /DisplayLowerB7 0.00
OUT->iPad /DisplayLowerB8 100.00
OUT->iPad /DisplayRotaryPushA1 
OUT->iPad /DisplayRotaryPushA2 
OUT->iPad /DisplayRotaryPushA3 
OUT->iPad /DisplayRotaryPushA4 
OUT->iPad /DisplayRotaryPushA5 SC 150hz Filt
OUT->iPad /DisplayRotaryPushA6 In/Out
OUT->iPad /DisplayRotaryPushA7 Punch
OUT->iPad /DisplayRotaryPushA8 Unassigned
OUT->iPad /DisplayRotaryPushB1 Unassigned
OUT->iPad /DisplayRotaryPushB2 Unassigned
OUT->iPad /DisplayRotaryPushB3 Unassigned
OUT->iPad /DisplayRotaryPushB4 Unassigned
OUT->iPad /DisplayRotaryPushB5 Unassigned
OUT->iPad /DisplayRotaryPushB6 Unassigned
OUT->iPad /DisplayRotaryPushB7 
OUT->iPad /DisplayRotaryPushB8 Bypass
OUT->iPad /RotaryPushA1 0.272727
OUT->iPad /RotaryPushA2 0.000000
OUT->iPad /RotaryPushA3 0.000000
OUT->iPad /RotaryPushA4 0.000000
OUT->iPad /RotaryPushA6 1.000000
OUT->iPad /RotaryPushA8 -1.000000
OUT->iPad /RotaryPushB5 -1.000000
OUT->iPad /RotaryPushB6 -1.000000
OUT->iPad /RotaryPushB7 0.000000
OUT->iPad /RotaryPushB8 0.000000
OUT->iPad /RotaryA1 0.272727
OUT->iPad /RotaryA3 0.200000
OUT->iPad /RotaryA4 0.500000
OUT->iPad /RotaryB7 0.625000
OUT->iPad /RotaryB8 1.000000
OUT->MFTwister  b1  04  33 
OUT->MFTwister  b1  05  52 
OUT->MFTwister  b1  06  33 
OUT->MFTwister  b1  07  07 
OUT->MFTwister  b1  08  07 
OUT->MFTwister  b1  09  07 
OUT->MFTwister  b1  0a  07 
OUT->MFTwister  b1  0b  07 
OUT->MFTwister  b1  0c  07 
OUT->MFTwister  b1  0d  07 
OUT->MFTwister  b1  0f  33 
OUT->MFTwister  b0  00  22 
OUT->MFTwister  b0  02  19 
OUT->MFTwister  b0  03  3f 
OUT->MFTwister  b0  0e  4f 
OUT->MFTwister  b0  0f  7f

All I'd be hoping to get out of this is to be able to turn off lights for unassigned parameters. I don't' want anything blinking, or need to adjust brightness per knob...In a perfect world, I'd just be able to turn the button light off on unassigned parameters by doing something like this...

DisplayRotaryPushB1 FXParamNameDisplay 999 "Unassigned"
RotaryPushB1 FXParam 999 { 181 8 23 181 8 23}

But then, that presents another challenge, because wouldn't each button would need to receive a second message to turn the light back on when you leave the .zon? Otherwise, the button just stays off indefinitely. That was a fun thing to discover while troubleshooting this. Even the MF_Utility app wouldn't set the light back to on, only the proper MIDI message would.

And that sounds like a nightmare to manage in zone files. You'd have to send the message to set the light off then send a different message for every light widget in every zone to turn them on, just in case you happened to be coming from a zone where they were off. Unless CSI were to maintain light states, which I know your thoughts on. Honestly, I say pull the code out for this. I can't imagine an implementation of this that makes it worth the effort as an end user.

I'm happy we can make the colors work and feel like that was going above and beyond, not to mention the special encoder widget for the MFTwister.

[paat]

fwiw I came up with the notes I did above by:

1) sending a MIDI CC message from Renoise to the MFT
2) reporting what it showed as the data sent

I included a screenshot at the bottom that shows the MIDI messages. Renoise is receiving messages on channel 1 and sending them to channel 2. So the only thing that changes is the channel. With this setup, turning the knob changes the color of the light under it. Change the output to channel 6, and moving the knob changes the animation.

Originally Posted by Funkybot

And maybe it's just me, but since each button needs it's own unique message, and CSI won't know which widget corresponds to which button on the hardware (unless there is a way and I'm not picking up how), this seems like it would be a lot of effort for a very esoteric feature. I'm imagining literally having to build out a lookup table like this for each combination of buttons on each bank. That sounds crazy to me.

I don't think that's the case. Admittedly I don't have a deep understanding, it appears to be relatively straightforward to me. Channel 2 is the color control channel. Channel 6 is the animation control channel. CC is the same as sent by the encoder / button. I'll do my best to explain as I understand it.

First we'll press the top-left button after a factory reset. Midi monitor shows:



which, when turning expert mode off, it reports as channel=2, cc=0, value=127

So we produce the following configuration:

Widget Button1
  Press b1 00 7f b1 00 00
  FB_MFT_RGB b1 00 7f
WidgetEnd

To change the color, we send the same CC message on channel 2. To change the animation, we send the same CC message on channel 6. Since we know that the second byte of Button1 corresponds to the CC message, we know that changing it looks like:

channel=2 cc=incoming value=new_value // color
channel=6 cc=incoming value=new_value // animation

or, I presume, for the above example:

{ b1 00 new_value } // color
{ b5 00 new_value } // animation

So to change the color or animation of button1, the only thing we need to know is the second byte - which we have from the definition itself. No tables needed.

setColor(button, value) {
  sendMidiMessage(channel: 2, cc: button.byte2, value: value)
}

setColor(button, value) {
  sendByteMessage(channel: "b1", cc: button.byte2, value: value)
}

setAnimation(button, value) {
  sendMidiMessage(channel: 6, cc: button.byte2, value: value)
}

setAnimation(button, value) {
  sendByteMessage(channel: "b5", cc: button.byte2, value: value)
}

Renoise example (here I'm turning knob 4, which is cc=3)

[paat]

Originally Posted by Geoff Waddington

To paraphrase the late great Sean Connery in Red October -- "Give me a byte Vasili, 3 bytes only.

If anyone wants to sort this garbage out, I'll gladly supply you with some code

Maybe the best way is just to send the bytes directly using some software, then report the results here.

Do you have any suggestions on how to do this on Mac? I am happy to experiment with this. But, the only thing I know how to do at this point is send it MIDI messages and report what those messages are and the three-byte value they appear to correspond to.

[Funkybot]

Originally Posted by Geoff Waddington

No promises... early days.

Whenever it's ready. But that's definitely worth drawing a line in the sand over. I feel like most people keep Reaper up to date due to the inexpensive licensing and the policy of not restricting the product for people who don't purchase and/or have an up to date license.

[Funkybot]

Originally Posted by paat

I don't think that's the case. Admittedly I don't have a deep understanding, it appears to be relatively straightforward to me. Channel 2 is the color control channel. Channel 5 is the animation control channel. CC is the same as sent by the encoder / button. I'll do my best to explain as I understand it.

Ok, yea, I see where you're going now. We don't want to lose color functionality though. So maybe the syntax needs to change to something like:

RotaryPushB1 FXParam 999 { 0 75 255 0 75 255 (23) }

Where the 0 75 25 0 75 255 message represents the color value for on/off states, and the optional number in parenthesis represents the animation value. In this case, 23=off.

And behind the scenes CSI would convert that to:

181 0 23
...
181 16 23

...now, lets say I turned a light off? How do we get the light back on after we turned it off without adding a "light on" message to every line of every .zon file? Do we have CSI send "light on" messages by deafult so we don't have to program that in? I don't want to have to add them to the .zon files for every widget but the Twister won't turn that light back on until told to.

EDIT: maybe you add a second value in parenthesis. One for entering the .zon and one for existing the .zon (assuming CSI can tell you're no longer in it).

RotaryPushB1 FXParam 999 { 0 75 255 0 75 255 (23 0) }

So it says, set this on color, set this off color, set this animation value when entering the zone, set this animation value when existing the zone.

[paat]

Originally Posted by Funkybot

Ok, yea, I see where you're going now. We don't want to lose color functionality though. So maybe the syntax needs to change to something like:

RotaryPushB1 FXParam 999 { 0 75 255 0 75 255 (23) }

Where the 0 75 25 0 75 255 message represents the color value for on/off states, and the optional number in parenthesis represents the animation value. In this case, 23=off.

You don't need to lose the color state. In fact you can use color and animation together. I wonder if there needs to be new syntax for MFT? I don't think the RGB syntax is helpful for MFT at all - unless somehow CSI can translate a sensible RGB value into 0-127 (keeping in mind that 0 and 127 are special values that mean "reset to MF Utility-configured on/off color"). The current "one value needs to be 0, another 255, and the third something different entirely" approach doesn't reconcile with the 0-127 that the documentation shows.

Just throwing something out here, hopefully it makes sense:

RotaryPushB1 FXParam 999 { MFT_COLOR(10) MFT_COLOR(20) } { MFT_ANIMATE(0) MFT_ANIMATE(17) }

Originally Posted by Funkybot

...now, lets say I turned a light off? How do we get the light back on after we turned it off without adding a "light on" message to every line of every .zon file? Do we have CSI send "light on" messages by deafult so we don't have to program that in? I don't want to have to add them to the .zon files for every widget but the Twister won't turn that light back on until told to.

I think I see what you're saying... within a zone, yes, I think you would need to tell it when to turn back on - just like how you told it to turn off.

Maybe each zone has a default setting (something I asked about) so when you switch to them, it gets set up how you want? Personally I would love to control the lights entirely with CSI, and ignore the MFT's configuration entirely. So now the MFT configuration is really only about the messages it sends, not the lights. I would like to be able to initialize the lights when switching to a zone, so I could have different colors depending on whether I'm using an instrument, a dynamics processor, a time effect, etc. Something like:

(I'm just making up syntax to get the point across)

Widget Button1
  Press b1 00 7f b1 00 00
  FB_MFT_RGB b1 00 7f
WidgetEnd


Zone Home
  IncludedZones
    "Lights"
  IncludedZonesEnd
ZoneEnd

Zone "Lights"
  MFT_ANIMATE Button(ALL) 17 // turn off all lights
  MFT_COLOR Button1 64 // turn button 1 yellow (still off though)
  MFT_ANIMATE Button1 47 // max brightness
ZoneEnd

So if you wanted to set all lights to yellow, max brightness, it's something like:

Zone "Lights"
  MFT_ANIMATE Button(ALL) 64 //max brightness
  MFT_COLOR Button(ALL) 64 // yellow
ZoneEnd

Then your actions change color and animation as desired.

[paat]

Here's a config that I believe should change the button color whenever you press the button:

Widget Button1
  Press b1 00 7f b1 00 00
  FB_MFT_RGB b1 00 7f
WidgetEnd


Zone Home
  IncludedZones
    "Buttons"
  IncludedZonesEnd
ZoneEnd

Zone "Buttons"
  Button1 Play { 177 0 64 177 0 64 }
ZoneEnd

Pressing the button toggles the play state. But CSI doesn't report any output to the MFT at all.

[Geoff Waddington]

Thanks for the great work guys, i think I see what's wrong, you get to it @Funkybot with the (23) param

The problem we're having is we're trying to piggyback the animation on the RGB, bad idea.

It deserves it's own space, but since it is related to RGB, @Funkybots syntax works nicely.

Zone aZone
someAnimatableButton SomeAction { 0 0 0 255 255 255 (23 ) }
ZoneEnd

Internally, CSI checks if it has a parameter in parentheses, and if it does, it calls the SetProperites method on the Widget with that parameter.

If we get this right, it will allow for setup/teardown behaviour in general, not just for MFT.

Let's allow an extra param, separated by a comma, so we can have a pre action, and a post action.

Now let's allow a list of each kind -- items in each list will get executed in order.

Here's the proposed syntax:

(< 17 >, < 22 > ) // both pre and post
(< 17 >) // just pre
(, <22 >) // just post
(< 14 24 67 34 >, < 11 67 89 74 >) // list for both pre and post

etc.

And if we didn't have RGB support it would still work:

{ (< 17 >, < 22 > ) }

What do you think of this as a general mechanism for pre/post behaviours like entering and leaving FX Zones, etc. ?

[edit] So, for instance you could have a set that occurred when you enter a zone, and another set when you leave.

[Funkybot]

Originally Posted by Geoff Waddington

[edit] So, for instance you could have a set that occurred when you enter a zone, and another set when you leave.

Sounds like it would get exactly where I'd like it to go...

DisplayRotaryPushB1 FXParamNameDisplay 999 "Unassigned"
RotaryPushB1 FXParam 999 { 0 75 255 0 75 255 ( 23 , 0 ) }

...turn off the button when we enter this zone, turn on the button when we exit. Or another example might be "have the click button blink with the tempo" when in the home zone.

Now...focusing on the Twister for right now....someone may want the ability to link it to on/off states. Example: "have the record button blink when tracking (on-state), have the light turn off when not recording (off-state)." Might add unnecessary complexity, but I could see people asking for that.

I don't fully get how the "list" piece would work yet (I guess I just need a use case and some idea of what that would do with some hardware) but for the sake of the MFTwister, I really like it.

[paat]

Originally Posted by Funkybot

Now...focusing on the Twister for right now....someone may want the ability to link it to on/off states. Example: "have the record button blink when tracking (on-state), have the light turn off when not recording (off-state)." Might add unnecessary complexity, but I could see people asking for that.

If you can turn the light off (channel=6, value=17) then you can also blink it (channel=6, value=1). Assuming that this new syntax lets us send arbitrary values between 0 and 127, and accounts for the fact that on MFT color=channel 2 and animation=channel 6.

That's something I don't see in the proposed syntax. But, if it's assuming that (17) goes out on channel 6 (or has the first byte=b5), then cool.

[Funkybot]

Originally Posted by paat

If you can turn the light off (channel=6, value=17) then you can also blink it (channel=6, value=1). Assuming that this new syntax lets us send arbitrary values between 0 and 127, and accounts for the fact that on MFT color=channel 2 and animation=channel 6.

That's something I don't see in the proposed syntax. But, if it's assuming that (17) goes out on channel 6 (or has the first byte=b5), then cool.

Yes, that's the assumption I was operating under. For instance, RGB works, so Geoff must already be sending out on b1 (channel 2) for those, so the idea (for this device anyway) is that the animation commands in the parenthesis would be coded to go out on b5 (channel 6).

[Funkybot]

It's always worth pointing out: I have no idea how Geoff actually makes any of this work behind the scenes nor if any of this makes any practical sense. I just hope it's feasible and makes sense to Geoff - or he at least understands what I'm trying to say and can translate that into something that works.

[Geoff Waddington]

Originally Posted by paat

If you can turn the light off (channel=6, value=17) then you can also blink it (channel=6, value=1). Assuming that this new syntax lets us send arbitrary values between 0 and 127, and accounts for the fact that on MFT color=channel 2 and animation=channel 6.

That's something I don't see in the proposed syntax. But, if it's assuming that (17) goes out on channel 6 (or has the first byte=b5), then cool.

Yes, we will make the assumptions based on the other byte1 and byte 2 values.

[Geoff Waddington]

Originally Posted by Funkybot

I don't fully get how the "list" piece would work yet (I guess I just need a use case and some idea of what that would do with some hardware) but for the sake of the MFTwister, I really like it.

It's just if you want to send a string of values, in order, before/after.

Say for pre you wanted to ensure the light was on AND blink.

For post you could turn off blinking AND turn off the light.

[paat]

I could use some help with understanding how color is supposed to work with MFT. There is this color reference table which is incomprehensible to me.

I believe the intent is for the syntax to be { R G B } which MFT doesn't understand. Instead, it does 1-126 for colors, 0 and 127 to reset to configured color. So is there a way of figuring out what the RGB values need to be based on the 1-126?

If there were a way to send color=1-126 directly, that would be great since we can refer to the manual and see what number corresponds to what color. If it stays RGB, that's cool too since we can use any RGB tool to identify a color - but under the hood I think CSI would need to quantize it to 1-126 and I have no idea how that would work.

As it is, I don't understand how yellow = MFT(64) = RGB (242 255 0). Or rather, I don't know how to map the 1-126 listed in MFT user guide to RGB, or vice versa.

[Geoff Waddington]

Originally Posted by paat

I could use some help with understanding how color is supposed to work with MFT. There is this color reference table which is incomprehensible to me.

I believe the intent is for the syntax to be { R G B } which MFT doesn't understand. Instead, it does 1-126 for colors, 0 and 127 to reset to configured color. So is there a way of figuring out what the RGB values need to be based on the 1-126?

If there were a way to send color=1-126 directly, that would be great since we can refer to the manual and see what number corresponds to what color. If it stays RGB, that's cool too since we can use any RGB tool to identify a color - but under the hood I think CSI would need to quantize it to 1-126 and I have no idea how that would work.

As it is, I don't understand how yellow = MFT(64) = RGB (242 255 0). Or rather, I don't know how to map the 1-126 listed in MFT user guide to RGB, or vice versa.

Sure, here is the actual source code:

// Color maps are stored in Blue Green Red format
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
    
    {250, 255, 0}, // 22 - Green (Blue Fading)
    {237, 255, 0},
    {225, 255, 0},
    {212, 255, 0},
    {199, 255, 0},
    {191, 255, 0},
    {178, 255, 0},
    {165, 255, 0},
    {153, 255, 0},
    {140, 255, 0},
    {127, 255, 0},
    {119, 255, 0},
    {106, 255, 0},
    {93, 255, 0},
    {80, 255, 0},
    {67, 255, 0},
    {59, 255, 0},
    {46, 255, 0},
    {33, 255, 0},
    {21, 255, 0},
    {8, 255, 0},
    {0, 255, 0},    // 43 - Green
    
    {0, 255, 12},    // 44 - Green/ Red Rising
    {0, 255, 25},
    {0, 255, 38},
    {0, 255, 51},
    {0, 255, 63},
    {0, 255, 72},
    {0, 255, 84},
    {0, 255, 97},
    {0, 255, 110},
    {0, 255, 123},
    {0, 255, 131},
    {0, 255, 144},
    {0, 255, 157},
    {0, 255, 170},
    {0, 255, 182},
    {0, 255, 191},
    {0, 255, 203},
    {0, 255, 216},
    {0, 255, 229},
    {0, 255, 242},
    {0, 255, 255},    // 64 - Green + Red (Yellow)
    
    {0, 246, 255},    // 65 - Red, Green Fading
    {0, 233, 255},
    {0, 220, 255},
    {0, 208, 255},
    {0, 195, 255},
    {0, 187, 255},
    {0, 174, 255},
    {0, 161, 255},
    {0, 148, 255},
    {0, 135, 255},
    {0, 127, 255},
    {0, 114, 255},
    {0, 102, 255},
    {0, 89, 255},
    {0, 76, 255},
    {0, 63, 255},
    {0, 55, 255},
    {0, 42, 255},
    {0, 29, 255},
    {0, 16, 255},
    {0, 4, 255},    // 85 - End Red/Green Fading
    
    {4, 0, 255},    // 86 - Red/ Blue Rising
    {16, 0, 255},
    {29, 0, 255},
    {42, 0, 255},
    {55, 0, 255},
    {63, 0, 255},
    {76, 0, 255},
    {89, 0, 255},
    {102, 0, 255},
    {114, 0, 255},
    {127, 0, 255},
    {135, 0, 255},
    {148, 0, 255},
    {161, 0, 255},
    {174, 0, 255},
    {186, 0, 255},
    {195, 0, 255},
    {208, 0, 255},
    {221, 0, 255},
    {233, 0, 255},
    {246, 0, 255},
    {255, 0, 255},    // 107 - Blue + Red
    
    {255, 0, 242},    // 108 - Blue/ Red Fading
    {255, 0, 229},
    {255, 0, 216},
    {255, 0, 204},
    {255, 0, 191},
    {255, 0, 182},
    {255, 0, 169},
    {255, 0, 157},
    {255, 0, 144},
    {255, 0, 131},
    {255, 0, 123},
    {255, 0, 110},
    {255, 0, 97},
    {255, 0, 85},
    {255, 0, 72},
    {255, 0, 63},
    {255, 0, 50},
    {255, 0, 38},
    {255, 0, 25},    // 126 - Blue-ish
    {225, 240, 240}    // 127 - White ?
};

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)
    {
        for(int i = 1; i < 22; i++)
            if(g > colorMap7[i - 1][1] && g <= colorMap7[i][1])
                return i;
    }
    else if(g == 255 && r == 0)
    {
        for(int i = 22; i < 44; i++)
            if(b < colorMap7[i - 1][0] && b >= colorMap7[i][0])
                return i;
    }
    else if(b == 0 && g == 255)
    {
        for(int i = 44; i < 65; i++)
            if(r > colorMap7[i - 1][2] && r <= colorMap7[i][2])
                return i;
    }
    else if(b == 0 && r == 255)
    {
        for(int i = 65; i < 86; i++)
            if(g < colorMap7[i - 1][1] && g >= colorMap7[i][1])
                return i;
    }
    else if(g == 0 && r == 255)
    {
        for(int i = 86; i < 108; i++)
            if(b > colorMap7[i - 1][0] && b <= colorMap7[i][0])
                return i;
    }
    else if(b == 255 && g == 0)
    {
        for(int i = 108; i < 127; i++)
            if(r < colorMap7[i - 1][2] && r >= colorMap7[i][2])
                return i;
    }
    
    return 0;
}

[cjewellstudios]

Originally Posted by Geoff Waddington

Sure, here is the actual source code:

That's so awesome

As someone who has spent 3 hours the past couple days learning excel/VBA just so I can maybe adapt that configurator that's floating around to my needs, I can appreciate and am in awe of the effort.

It also gives me a hint at why I can't just put an arbitrary number in there even if I have a 255 and 0 for the other values. Having a "practically white" possibility is also helpful.

[siniarch]

Originally Posted by Geoff Waddington

Sure, here is the actual source code:

// Color maps are stored in Blue Green Red format
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
    
    {250, 255, 0}, // 22 - Green (Blue Fading)
    {237, 255, 0},
    {225, 255, 0},
    {212, 255, 0},
    {199, 255, 0},
    {191, 255, 0},
    {178, 255, 0},
    {165, 255, 0},
    {153, 255, 0},
    {140, 255, 0},
    {127, 255, 0},
    {119, 255, 0},
    {106, 255, 0},
    {93, 255, 0},
    {80, 255, 0},
    {67, 255, 0},
    {59, 255, 0},
    {46, 255, 0},
    {33, 255, 0},
    {21, 255, 0},
    {8, 255, 0},
    {0, 255, 0},    // 43 - Green
    
    {0, 255, 12},    // 44 - Green/ Red Rising
    {0, 255, 25},
    {0, 255, 38},
    {0, 255, 51},
    {0, 255, 63},
    {0, 255, 72},
    {0, 255, 84},
    {0, 255, 97},
    {0, 255, 110},
    {0, 255, 123},
    {0, 255, 131},
    {0, 255, 144},
    {0, 255, 157},
    {0, 255, 170},
    {0, 255, 182},
    {0, 255, 191},
    {0, 255, 203},
    {0, 255, 216},
    {0, 255, 229},
    {0, 255, 242},
    {0, 255, 255},    // 64 - Green + Red (Yellow)
    
    {0, 246, 255},    // 65 - Red, Green Fading
    {0, 233, 255},
    {0, 220, 255},
    {0, 208, 255},
    {0, 195, 255},
    {0, 187, 255},
    {0, 174, 255},
    {0, 161, 255},
    {0, 148, 255},
    {0, 135, 255},
    {0, 127, 255},
    {0, 114, 255},
    {0, 102, 255},
    {0, 89, 255},
    {0, 76, 255},
    {0, 63, 255},
    {0, 55, 255},
    {0, 42, 255},
    {0, 29, 255},
    {0, 16, 255},
    {0, 4, 255},    // 85 - End Red/Green Fading
    
    {4, 0, 255},    // 86 - Red/ Blue Rising
    {16, 0, 255},
    {29, 0, 255},
    {42, 0, 255},
    {55, 0, 255},
    {63, 0, 255},
    {76, 0, 255},
    {89, 0, 255},
    {102, 0, 255},
    {114, 0, 255},
    {127, 0, 255},
    {135, 0, 255},
    {148, 0, 255},
    {161, 0, 255},
    {174, 0, 255},
    {186, 0, 255},
    {195, 0, 255},
    {208, 0, 255},
    {221, 0, 255},
    {233, 0, 255},
    {246, 0, 255},
    {255, 0, 255},    // 107 - Blue + Red
    
    {255, 0, 242},    // 108 - Blue/ Red Fading
    {255, 0, 229},
    {255, 0, 216},
    {255, 0, 204},
    {255, 0, 191},
    {255, 0, 182},
    {255, 0, 169},
    {255, 0, 157},
    {255, 0, 144},
    {255, 0, 131},
    {255, 0, 123},
    {255, 0, 110},
    {255, 0, 97},
    {255, 0, 85},
    {255, 0, 72},
    {255, 0, 63},
    {255, 0, 50},
    {255, 0, 38},
    {255, 0, 25},    // 126 - Blue-ish
    {225, 240, 240}    // 127 - White ?
};

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)
    {
        for(int i = 1; i < 22; i++)
            if(g > colorMap7[i - 1][1] && g <= colorMap7[i][1])
                return i;
    }
    else if(g == 255 && r == 0)
    {
        for(int i = 22; i < 44; i++)
            if(b < colorMap7[i - 1][0] && b >= colorMap7[i][0])
                return i;
    }
    else if(b == 0 && g == 255)
    {
        for(int i = 44; i < 65; i++)
            if(r > colorMap7[i - 1][2] && r <= colorMap7[i][2])
                return i;
    }
    else if(b == 0 && r == 255)
    {
        for(int i = 65; i < 86; i++)
            if(g < colorMap7[i - 1][1] && g >= colorMap7[i][1])
                return i;
    }
    else if(g == 0 && r == 255)
    {
        for(int i = 86; i < 108; i++)
            if(b > colorMap7[i - 1][0] && b <= colorMap7[i][0])
                return i;
    }
    else if(b == 255 && g == 0)
    {
        for(int i = 108; i < 127; i++)
            if(r < colorMap7[i - 1][2] && r >= colorMap7[i][2])
                return i;
    }
    
    return 0;
}

It's like the MATRIX, Geoff looks at this code and just sees a photograph or video. It all makes sense to him. I on the other hand, just see some weird green characters dripping down the screen. I think Geoff is the "ONE".

[spkr4thdd]

Hi guys,

I’ve been away with RL work for the past 2-3 months and have come back to a whole new world of V1 CSI!!

Is there a list somewhere of any major changes which I’ll need to know before diving straight back in??

Also, does anyone know who this guy is? I want to find out how he has his FX set up and how he has the buttons mapped...

https://youtu.be/QD1o0JenoNE