Control Surface Integration (CSI) Technical Feature Discussion

[MixMonkey]

Originally Posted by ivanv

hey all,
long time admirer, first time poster
i wanted to know if anyone has come up with a workflow for using CSI to address reaper's track controls?

Currently, CSI has no mechanism to directly map the track controls to a surface. Instead, it maps the plugin to the surface using an FX.zon file, which lists the surface controls and the plugin parameters they are assigned to.

Are you specifically looking to use Reaper's track controls because you already have lots of projects where they are assigned or because this is how you've always accessed FX parameters in the past?

I have two C4s in my setup and have hundreds of FX.zon files that you're more than welcome too. I also have an Excel sheet that will load the raw fx file that CSI generates and allow you to layout the parameters on the C4, create useful names for them etc.

[ivanv]

Originally Posted by MixMonkey

Currently, CSI has no mechanism to directly map the track controls to a surface. Instead, it maps the plugin to the surface using an FX.zon file, which lists the surface controls and the plugin parameters they are assigned to.

Are you specifically looking to use Reaper's track controls because you already have lots of projects where they are assigned or because this is how you've always accessed FX parameters in the past?

I have two C4s in my setup and have hundreds of FX.zon files that you're more than welcome too. I also have an Excel sheet that will load the raw fx file that CSI generates and allow you to layout the parameters on the C4, create useful names for them etc.

thank you guys for the warm welcome!

i've started mapping some of my favorite plugins and customized the button layout for my MCU and C4.
this excel file you speak of sounds like it would be very useful! would you be so kind as to send that to me?

to give a bit more context around where my head is at with the track controls... i think it would be a very neat workflow -- in addition to having my favorite plugins mapped the usual way -- to be able to select parameters on an ad-hoc basis from any plugin (and across plugins on the same track!) to become track controls, and then have a section of my c4 that is always mapped to track controls 1-8 of the selected plugin.

i find that it's often the case on a dense mix that many channels just have two or three key controls that i want to 'have a handle' on, and they're often not all in the same plugin.
using track controls would allow me to quickly fly around the mix, having immediate control over these main 'handles' -- whatever they might be -- without necessarily having to open up its plugin mapping, or even having to necessarily have created an FX zone for that particular plugin at all.

[Geoff Waddington]

Originally Posted by ivanv

thank you guys for the warm welcome!

i've started mapping some of my favorite plugins and customized the button layout for my MCU and C4.
this excel file you speak of sounds like it would be very useful! would you be so kind as to send that to me?

to give a bit more context around where my head is at with the track controls... i think it would be a very neat workflow -- in addition to having my favorite plugins mapped the usual way -- to be able to select parameters on an ad-hoc basis from any plugin (and across plugins on the same track!) to become track controls, and then have a section of my c4 that is always mapped to track controls 1-8 of the selected plugin.

i find that it's often the case on a dense mix that many channels just have two or three key controls that i want to 'have a handle' on, and they're often not all in the same plugin.
using track controls would allow me to quickly fly around the mix, having immediate control over these main 'handles' -- whatever they might be -- without necessarily having to open up its plugin mapping, or even having to necessarily have created an FX zone for that particular plugin at all.

Absolutely love this idea !

Aside from being useful by itself, it also gives us a gentle way to proceed towards auto mapping.

Ok, so just to kick things off, I would envision it working like this.

First off, I think it should automatic.

When you select a Track and there are Track controls for FX params, they automatically map to your surface.

Or perhaps, make it optional like this

Zone Home // for a given surface
    OnTrackSelection MapTCPFXParams
ZoneEnd

You just need to supply a new Zone definition where the Widgets are named normally, but the Actions are TrackControlFXParams, maybe something like this.

Zone TCPFX
    Widget1 TCPFXParam 0
    Widget2 TCPFXParam 1
    Widget3 TCPFXParam 2
ZoneEnd

That's just a wild guess, and a place to start the discussion.

The floor is open folks...

[MixMonkey]

Originally Posted by ivanv

this excel file you speak of sounds like it would be very useful! would you be so kind as to send that to me?

Sure, will do I forgot to ask, are you using Windows or Mac. If Windows, I'll need to check that my current Mac version is still good on Windows (I'm afraid I've rather let it slide since going Mac only)

to give a bit more context around where my head is at with the track controls... i think it would be a very neat workflow -- in addition to having my favorite plugins mapped the usual way -- to be able to select parameters on an ad-hoc basis from any plugin (and across plugins on the same track!) to become track controls, and then have a section of my c4 that is always mapped to track controls 1-8 of the selected plugin.

This is a fantastic idea!

[Puck]

Originally Posted by ivanv

thank you guys for the warm welcome!

i've started mapping some of my favorite plugins and customized the button layout for my MCU and C4.
this excel file you speak of sounds like it would be very useful! would you be so kind as to send that to me?

to give a bit more context around where my head is at with the track controls... i think it would be a very neat workflow -- in addition to having my favorite plugins mapped the usual way -- to be able to select parameters on an ad-hoc basis from any plugin (and across plugins on the same track!) to become track controls, and then have a section of my c4 that is always mapped to track controls 1-8 of the selected plugin.

i find that it's often the case on a dense mix that many channels just have two or three key controls that i want to 'have a handle' on, and they're often not all in the same plugin.
using track controls would allow me to quickly fly around the mix, having immediate control over these main 'handles' -- whatever they might be -- without necessarily having to open up its plugin mapping, or even having to necessarily have created an FX zone for that particular plugin at all.

I think this is a very good idea. Realearn has this functionality I do believe. But having a few key track controls per track makes a ton of sense.

[MixMonkey]

Originally Posted by Geoff Waddington

Absolutely love this idea !

Aside from being useful by itself, it also gives us a gentle way to proceed towards auto mapping.

I think this might very well be the auto-mapping solution in itself. You assign a parameter to a track control and it maps to the surface. What's more automatic than that?

Ok, so just to kick things off, I would envision it working like this.

First off, I think it should automatic.

When you select a Track and there are Track controls for FX params, they automatically map to your surface.

Or perhaps, make it optional like this

Zone Home // for a given surface
    OnTrackSelection MapTCPFXParams
ZoneEnd

You just need to supply a new Zone definition where the Widgets are named normally, but the Actions are TrackControlFXParams, maybe something like this.

Zone TCPFX
    Widget1 TCPFXParam 0
    Widget2 TCPFXParam 1
    Widget3 TCPFXParam 2
ZoneEnd

That's just a wild guess, and a place to start the discussion.

The floor is open folks...

All of this sounds great!

[kevrose]

Originally Posted by MixMonkey

Currently, CSI has no mechanism to directly map the track controls to a surface. Instead, it maps the plugin to the surface using an FX.zon file, which lists the surface controls and the plugin parameters they are assigned to.

Are you specifically looking to use Reaper's track controls because you already have lots of projects where they are assigned or because this is how you've always accessed FX parameters in the past?

I have two C4s in my setup and have hundreds of FX.zon files that you're more than welcome too. I also have an Excel sheet that will load the raw fx file that CSI generates and allow you to layout the parameters on the C4, create useful names for them etc.

MixMonkey, you were very kind in the past to send me your files as I have a similar set up - MCU, 2xXT, C4. I've had quite an enforced hiatus from recording but am now looking to get my CSI 1.1 migrated to the current version over the festive break and realise there are quite a lot of changes to get my had around. Is there any chance you could send me the relevant files so I can get up to speed quicker? It certainly would be a great Christmas present!

Cheers

Kevin

[MixMonkey]

Originally Posted by kevrose

MixMonkey, you were very kind in the past to send me your files as I have a similar set up - MCU, 2xXT, C4. I've had quite an enforced hiatus from recording but am now looking to get my CSI 1.1 migrated to the current version over the festive break and realise there are quite a lot of changes to get my had around. Is there any chance you could send me the relevant files so I can get up to speed quicker? It certainly would be a great Christmas present!

Cheers

Kevin

Sure thing! Let me just check the support file versions are up to date (should have done this a while ago) and I'll post them for you.

[Geoff Waddington]

Originally Posted by MixMonkey

I think this might very well be the auto-mapping solution in itself. You assign a parameter to a track control and it maps to the surface. What's more automatic than that?

Yup, I agree.

I also think we can lose this:

Zone Home // for a given surface
    OnTrackSelection MapTCPFXParams
ZoneEnd

If you want your surface to auto map, define a TCPFX Zone, simple as that.

TCPFXParamValueDisplay is easy, the only tricky bit is TCPFXParamNameDisplay, where we don't have the luxury of being able to define an alias...

[MixMonkey]

Originally Posted by kevrose

Is there any chance you could send me the relevant files so I can get up to speed quicker? It certainly would be a great Christmas present!

Here you go! If you could report back any errors/problems so I can correct them for the support files, that would be great.

[MixMonkey]

Originally Posted by Geoff Waddington

Yup, I agree.

I also think we can lose this:

Zone Home // for a given surface
    OnTrackSelection MapTCPFXParams
ZoneEnd

If you want your surface to auto map, define a TCPFX Zone, simple as that.

Absolutely!

TCPFXParamValueDisplay is easy, the only tricky bit is TCPFXParamNameDisplay, where we don't have the luxury of being able to define an alias...

Can we not pick up the parameter alias as defined in Reaper?

[Funkybot]

I think it might be a good idea to keep the mapping action as optional with the ability to default to off. Example: I might be keen to use this from time to time but I would want to enable it because I don't have dedicated controls to spare.

But yeah, this sounds like a great idea. I'm glad there's an API to pull these in. Happy holidays all!

[kevrose]

Originally Posted by MixMonkey

Here you go! If you could report back any errors/problems so I can correct them for the support files, that would be great.

Lovely, cheers! Will report back, hopefully get onto on Boxing Day.

[Geoff Waddington]

Originally Posted by MixMonkey

Can we not pick up the parameter alias as defined in Reaper?

Don't see an API for that.

Great idea though, I'll see if I can advocate for said API

[Geoff Waddington]

Originally Posted by Funkybot

I think it might be a good idea to keep the mapping action as optional with the ability to default to off. Example: I might be keen to use this from time to time but I would want to enable it because I don't have dedicated controls to spare.

But yeah, this sounds like a great idea. I'm glad there's an API to pull these in. Happy holidays all!

Good point, and Happy Holidays to all as well.

[MixMonkey]

Originally Posted by Geoff Waddington

Don't see an API for that.

Great idea though, I'll see if I can advocate for said API

Ah, pity. Track controls really could be a way of solving the fx automapping conundrum, with Reaper providing the mechanism to select FX parameters and (hopefully) set a useful alias.

Happy Hols All!

[Geoff Waddington]

The more I play around with this, the more I like it.

I knew this functionality existed, but never realized the full potential.

One of the most powerful features is the fact that you can reorder the parameters, which, in and of itself, puts it miles ahead of any auto mapping.

A very common FX workflow involves a channel strip approach.

Now, I just verified that saving Track Templates includes Track controls.

Let's say you have a favourite vocal channel with a certain EQ and compressor.

Let's say you also have a go to bass EQ and compressor pair.

Let's blend in our new TCPFX Zone.

From this marvellous gumbo we get a way to quickly insert a Track that has our preferred channel strip setup, mapped in a very consistent way to our control surface(s).

We can, by setting up the Templates carefully, ensure that, for instance, the Threshold is always mapped to a particular control surface element.

Great for muscle memory, our most often used controls are always at the same location regardless of the disparities between the actual FX on a given Track.

Very powerful stuff.

[ivanv]

Originally Posted by Geoff Waddington

The more I play around with this, the more I like it.

I knew this functionality existed, but never realized the full potential.

One of the most powerful features is the fact that you can reorder the parameters, which, in and of itself, puts it miles ahead of any auto mapping.

A very common FX workflow involves a channel strip approach.

Now, I just verified that saving Track Templates includes Track controls.

Let's say you have a favourite vocal channel with a certain EQ and compressor.

Let's say you also have a go to bass EQ and compressor pair.

Let's blend in our new TCPFX Zone.

From this marvellous gumbo we get a way to quickly insert a Track that has our preferred channel strip setup, mapped in a very consistent way to our control surface(s).

We can, by setting up the Templates carefully, ensure that, for instance, the Threshold is always mapped to a particular control surface element.

Great for muscle memory, our most often used controls are always at the same location regardless of the disparities between the actual FX on a given Track.

Very powerful stuff.

Yes, precisely! So happy to hear you're interested in this, Geoff.

Prior to diving into CSI, track templates with pre-selected Track controls was critical to how I worked. If I had the functionality in CSI, it would be incredible...

In addition to the implementation you described, I could see a use-case for treating track controls almost like a send slot (i.e. having a zone on my MCU where the pan pots become Track control #1, and I can bank down to remap them to track control #2, #3, etc..)

What this opens the door to is controlling multiple channels' insert plugins at once, without ever having to leave a zone and enter a new one.

I could even look at my C4 as a 8 channels of 4x vertical track controls.

I would then for example set up the first 4 track controls of every mix channel to be high shelf, mid freq, mid cut/boost, and low shelf. All of a sudden I can EQ 8 channels against each other in real time, without leaving/entering zones.
Bank to the right and now I'm eqing the next 8 channels. Bank down and i'm adjusting the next 4 track controls
(maybe Shift + Rotary could adjust a different track control? so we can have, say, EQ frequency AND cut on the same physical pot? am i getting ahead of myself?)

Really keen to hear more thoughts on this from everyone here!

[ivanv]

Originally Posted by MixMonkey

Sure, will do I forgot to ask, are you using Windows or Mac. If Windows, I'll need to check that my current Mac version is still good on Windows (I'm afraid I've rather let it slide since going Mac only)



This is a fantastic idea!

I use windows anything you've got would be much appreciated

[Geoff Waddington]

Originally Posted by ivanv

Yes, precisely! So happy to hear you're interested in this, Geoff.

Prior to diving into CSI, track templates with pre-selected Track controls was critical to how I worked. If I had the functionality in CSI, it would be incredible...

In addition to the implementation you described, I could see a use-case for treating track controls almost like a send slot (i.e. having a zone on my MCU where the pan pots become Track control #1, and I can bank down to remap them to track control #2, #3, etc..)

What this opens the door to is controlling multiple channels' insert plugins at once, without ever having to leave a zone and enter a new one.

I could even look at my C4 as a 8 channels of 4x vertical track controls.

I would then for example set up the first 4 track controls of every mix channel to be high shelf, mid freq, mid cut/boost, and low shelf. All of a sudden I can EQ 8 channels against each other in real time, without leaving/entering zones.
Bank to the right and now I'm eqing the next 8 channels. Bank down and i'm adjusting the next 4 track controls
(maybe Shift + Rotary could adjust a different track control? so we can have, say, EQ frequency AND cut on the same physical pot? am i getting ahead of myself?)

Really keen to hear more thoughts on this from everyone here!

Great ideas !

I think we will start with the Selected Track version and expand from there.

[Manwë]

As far as the TCP Fx Parameter knobs go...

As of right now it is Midi/OSC only, would it be possible to have set Midi/OSC messages for FX Param 1-8 sent through CSI then assign them in your actions list?

So wherever you assign your

Widget1 TCPFXParam 0

it will follow your track selection.

Is CSI able to send a predetermined Midi/OSC messages? Or just allow the assigned encoder to pass through CSI in its raw form?

Maybe that could be a small Feature Request, allowing a Midi CC passthrough so Midi/OSC only Actions can be used!

[Geoff Waddington]

Merry Christmas, here's a little present from CSI central.

New build is up

CSI Exp.zip

CSI Support Files.zip

This is the first build using the new Windows environment, please check it out thoroughly.

First draft of TCPFXParam support.

Here's how I mapped it on the X Touch:

Zone Home
    OnInitialization ToggleEnableFocusedFX
    IncludedZones
        Buttons
        Track
        MasterTrack
    IncludedZonesEnd
    AssociatedZones
       SelectedTrackSend
       SelectedTrackReceive
       SelectedTrackFXMenu
       TrackSend
       TrackReceive
       TrackFXMenu
       VCA
       Folder
       TCPFX
    AssociatedZonesEnd
ZoneEnd

//  View Buttons
 
    GlobalView                  Global
    MidiTracks                  GoTCPFX
    Inputs                      NoAction
    AudioTracks                 NoAction

Zone "TCPFX"
	OnZoneActivation	SetXTouchDisplayColors Cyan
	OnZoneDeactivation	RestoreXTouchDisplayColors

	DisplayUpper1 		TCPFXParamNameDisplay 0
        DisplayLower1       	TCPFXParamValueDisplay 0
        Rotary1             	TCPFXParam 0

	DisplayUpper2 		TCPFXParamNameDisplay 1
        DisplayLower2       	TCPFXParamValueDisplay 1
        Rotary2             	TCPFXParam 1

	DisplayUpper3 		TCPFXParamNameDisplay 2
        DisplayLower3       	TCPFXParamValueDisplay 2
        Rotary3             	TCPFXParam 2

	DisplayUpper4 		TCPFXParamNameDisplay 3
        DisplayLower4       	TCPFXParamValueDisplay 3
        Rotary4             	TCPFXParam 3

	DisplayUpper5 		TCPFXParamNameDisplay 4
        DisplayLower5       	TCPFXParamValueDisplay 4
        Rotary5             	TCPFXParam 4

	DisplayUpper6 		TCPFXParamNameDisplay 5
        DisplayLower6       	TCPFXParamValueDisplay 5
        Rotary6             	TCPFXParam 5

	DisplayUpper7 		TCPFXParamNameDisplay 6
        DisplayLower7       	TCPFXParamValueDisplay 6
        Rotary7             	TCPFXParam 6

	DisplayUpper8 		TCPFXParamNameDisplay 7
        DisplayLower8       	TCPFXParamValueDisplay 7
        Rotary8             	TCPFXParam 7
ZoneEnd

[Funkybot]

Hi Geoff, Merry Christmas. Looks great! Will try to check it out tonight, worst case tomorrow. Just a small request to add broadcast and receive functionality. Would like to use this on my Twister and activate from three X-Touch One.

[Geoff Waddington]

Originally Posted by Funkybot

Hi Geoff, Merry Christmas. Looks great! Will try to check it out tonight, worst case tomorrow. Just a small request to add broadcast and receive functionality. Would like to use this on my Twister and activate from three X-Touch One.

Pretty sure it's built in, just add TCPFX to your broadcast/receive lists.

[MixMonkey]

Originally Posted by ivanv

I use windows anything you've got would be much appreciated

Here you go I've think I've caught up all the changes I made to the Mac version. It's working here on my old laptop on BootCamp/Win10.

There's no manual or Wiki for this, so just open it up and have a go. The Username it'll nag you for is the name of your Home folder so it can locate the CSI ZoneRawFXFiles and ZoneFXFiles folders.

If you click Open Zone and select the VST__TDR_VOS_SlickEQ__Tokyo_Dawn_Labs_.zon example file you should get an idea of how it works.

Once you've had a look at the completed Zone file, you can reset the sheet (probably faster to close and reopen it afresh, the ResetAll button takes ages) and then load the raw example file for the TDR_VOS_SlickEQ and have a go at assigning parameters to the controls yourself.

I'm sure you'll have questions, just ask away. The Configurator was never really intended for mass consumption (I just got tired making C4 FX.zon files manually) so it's not that user friendly and definitely has quirks and gotchas.

Once you get the hang of it, it works really well and you can load a completed Zone back in, make a quick change, re-create it and it will save back to the location you got it from.

You can make changes to the FX.zon file while Reaper is running and these will be picked up by CSI if you run the "Control surface: Refresh all surfaces" / 41743 Action.

I'm sure I don't have to point out that because it's overwriting the original Zone, backups of your FX Zone folder are essential- you have been warned

[Funkybot]

Originally Posted by Geoff Waddington

Merry Christmas, here's a little present from CSI central.

New build is up

CSI Exp.zip

CSI Support Files.zip

This is the first build using the new Windows environment, please check it out thoroughly.

First draft of TCPFXParam support.

Geoff, initial review works pretty well. This will be great for replicating a Cubase-style "Quick Controls" workflow.

One issue I'm running into: it doesn't appear to read the ZoneStepSize files yet. Example: I've mapped the stepped Mid Freq of the UADx Neve 1073 plugin, which I have a zone step file for, but I can't use my encoder to actually change the frequency.

I can appreciate if that's a little more challenging with these because first you'd need to call Reaper to get the FX Name associated with each TCPFXParam, THEN do a lookup for the ZoneStepSizes.

[Funkybot]

Writing up my TCPFX.zon, I had an idea about how to create manual offsets that I think could benefit folks in lots of scenarios.

I named my MFTwister widgets in banks of 8. So the 16 encoders on Bank 1 are A1-A8, and B1-B8, and so on. As a result, I have to do this if I want to make use of all 16 encoders across banks C and D...

Zone "TCPFX"
    RotaryC1              TCPFXParam 0
    RotaryPushC1          NoAction
    ShiftRotaryC1         NoAction
       
    RotaryC2              TCPFXParam 1
    RotaryPushC2          NoAction
    ShiftRotaryC2         NoAction    

    RotaryC3              TCPFXParam 2
    RotaryPushC3          NoAction
    ShiftRotaryC3         NoAction    
    
    RotaryC4              TCPFXParam 3
    RotaryPushC4          NoAction
    ShiftRotaryC4         NoAction   

    RotaryC5              TCPFXParam 4
    RotaryPushC5          NoAction
    ShiftRotaryC5         NoAction 

    RotaryC6              TCPFXParam 5
    RotaryPushC6          NoAction
    ShiftRotaryC6         NoAction 

    RotaryC7              TCPFXParam 6
    RotaryPushC7          NoAction
    ShiftRotaryC7         NoAction 
    
    RotaryC8              TCPFXParam 7
    RotaryPushC8          NoAction
    ShiftRotaryC8         NoAction 
    
    RotaryD1              TCPFXParam 8
    RotaryPushD1          NoAction
    ShiftRotaryD1         NoAction 

    RotaryD2              TCPFXParam 9
    RotaryPushD2          NoAction
    ShiftRotaryD2         NoAction 

    RotaryD3              TCPFXParam 10
    RotaryPushD3          NoAction
    ShiftRotaryD3         NoAction 

    RotaryD4              TCPFXParam 11
    RotaryPushD4          NoAction
    ShiftRotaryD4         NoAction 

    RotaryD5              TCPFXParam 12
    RotaryPushD5          NoAction
    ShiftRotaryD5         NoAction 

    RotaryD6              TCPFXParam 13
    RotaryPushD6          NoAction
    ShiftRotaryD6         NoAction 

    RotaryD7              TCPFXParam 14
    RotaryPushD7          NoAction
    ShiftRotaryD7         NoAction 

    RotaryD8              TCPFXParam 15
    RotaryPushD8          NoAction
    ShiftRotaryD8         NoAction 
ZoneEnd

...which is a lot from a syntax perspective and very repetitive.

What if we could do this instead?

Zone "TCPFX"
    RotaryC|              TCPFXParam |
    RotaryPushC|          NoAction
    ShiftRotaryC|         NoAction

    RotaryD|              TCPFXParam |+8
    RotaryPushD|          NoAction
    ShiftRotaryD|         NoAction 
ZoneEnd

I think that "|+8" could also be leveraged to create manual offsets in other types of zones/surfaces. Or allow users to extend their mapping across different widget types. For instance, lets say a user seldom pans their sends but wanted access to 16 sends across a single 8-channel surface using Faders AND Rotaries...

Zone "SelectedTrackSend"
     Fader|           TrackSendVolume
     DisplayUpper|    TrackSendVolumeDisplay

     Rotary|          TrackSendVolume |+8
     DisplayLower|    TrackSendVolumeDisplay |+8
ZoneEnd

...just one example of how this would allow users to get more flexibility out of CSI as right now, that wouldn't even be possible.

[Geoff Waddington]

Originally Posted by Funkybot

Geoff, initial review works pretty well. This will be great for replicating a Cubase-style "Quick Controls" workflow.

One issue I'm running into: it doesn't appear to read the ZoneStepSize files yet. Example: I've mapped the stepped Mid Freq of the UADx Neve 1073 plugin, which I have a zone step file for, but I can't use my encoder to actually change the frequency.

I can appreciate if that's a little more challenging with these because first you'd need to call Reaper to get the FX Name associated with each TCPFXParam, THEN do a lookup for the ZoneStepSizes.

Thanks for testing !!

Yes, the first draft doesn't yet read step sizes, just wanted to see if the idea was at all useful.

Will look at incorporating step sizes, as you say it is more challenging.

Are you testing on Windows ?

Also need to verify the new Windows build environment.

[Geoff Waddington]

Originally Posted by Funkybot

Writing up my TCPFX.zon, I had an idea about how to create manual offsets that I think could benefit folks in lots of scenarios.

I named my MFTwister widgets in banks of 8. So the 16 encoders on Bank 1 are A1-A8, and B1-B8, and so on. As a result, I have to do this if I want to make use of all 16 encoders across banks C and D...

Zone "TCPFX"
    RotaryC1              TCPFXParam 0
    RotaryPushC1          NoAction
    ShiftRotaryC1         NoAction
       
    RotaryC2              TCPFXParam 1
    RotaryPushC2          NoAction
    ShiftRotaryC2         NoAction    

    RotaryC3              TCPFXParam 2
    RotaryPushC3          NoAction
    ShiftRotaryC3         NoAction    
    
    RotaryC4              TCPFXParam 3
    RotaryPushC4          NoAction
    ShiftRotaryC4         NoAction   

    RotaryC5              TCPFXParam 4
    RotaryPushC5          NoAction
    ShiftRotaryC5         NoAction 

    RotaryC6              TCPFXParam 5
    RotaryPushC6          NoAction
    ShiftRotaryC6         NoAction 

    RotaryC7              TCPFXParam 6
    RotaryPushC7          NoAction
    ShiftRotaryC7         NoAction 
    
    RotaryC8              TCPFXParam 7
    RotaryPushC8          NoAction
    ShiftRotaryC8         NoAction 
    
    RotaryD1              TCPFXParam 8
    RotaryPushD1          NoAction
    ShiftRotaryD1         NoAction 

    RotaryD2              TCPFXParam 9
    RotaryPushD2          NoAction
    ShiftRotaryD2         NoAction 

    RotaryD3              TCPFXParam 10
    RotaryPushD3          NoAction
    ShiftRotaryD3         NoAction 

    RotaryD4              TCPFXParam 11
    RotaryPushD4          NoAction
    ShiftRotaryD4         NoAction 

    RotaryD5              TCPFXParam 12
    RotaryPushD5          NoAction
    ShiftRotaryD5         NoAction 

    RotaryD6              TCPFXParam 13
    RotaryPushD6          NoAction
    ShiftRotaryD6         NoAction 

    RotaryD7              TCPFXParam 14
    RotaryPushD7          NoAction
    ShiftRotaryD7         NoAction 

    RotaryD8              TCPFXParam 15
    RotaryPushD8          NoAction
    ShiftRotaryD8         NoAction 
ZoneEnd

...which is a lot from a syntax perspective and very repetitive.

What if we could do this instead?

Zone "TCPFX"
    RotaryC|              TCPFXParam |
    RotaryPushC|          NoAction
    ShiftRotaryC|         NoAction

    RotaryD|              TCPFXParam |+8
    RotaryPushD|          NoAction
    ShiftRotaryD|         NoAction 
ZoneEnd

I think that "|+8" could also be leveraged to create manual offsets in other types of zones/surfaces. Or allow users to extend their mapping across different widget types. For instance, lets say a user seldom pans their sends but wanted access to 16 sends across a single 8-channel surface using Faders AND Rotaries...

Zone "SelectedTrackSend"
     Fader|           TrackSendVolume
     DisplayUpper|    TrackSendVolumeDisplay

     Rotary|          TrackSendVolume |+8
     DisplayLower|    TrackSendVolumeDisplay |+8
ZoneEnd

...just one example of how this would allow users to get more flexibility out of CSI as right now, that wouldn't even be possible.

Great concept, will have to think about it a bit...

[Funkybot]

Originally Posted by Geoff Waddington

Thanks for testing !!

Yes, the first draft doesn't yet read step sizes, just wanted to see if the idea was at all useful.

Will look at incorporating step sizes, as you say it is more challenging.

Are you testing on Windows ?

Also need to verify the new Windows build environment.

Yes, was using my Windows build for this testing so the new build environment is working a-ok.

[Geoff Waddington]

Ok, now that the basics work, let's rename everything

This will allow us to do a Track version as ivanv proposed, a la SelectedTrackSends and TrackSends.

So, the replacement for what we have now will be SelectedTrackTCPFX and GoSelectedTrackTCPFX.

We will then add TrackTCPFX and GoTrackTCPFX.

[Funkybot]

Originally Posted by Geoff Waddington

Ok, now that the basics work, let's rename everything

This will allow us to do a Track version as ivanv proposed, a la SelectedTrackSends and TrackSends.

So, the replacement for what we have now will be SelectedTrackTCPFX and GoSelectedTrackTCPFX.

We will then add TrackTCPFX and GoTrackTCPFX.

Sounds very good!

[Funkybot]

This one may be for Diesel or Geoff: something weird is going on with the FB_MFT_RGB.

This is no longer working...

Zone "Home"
OnInitialization    SendMIDIMessage "B1 0E 01"     // Makes B7 RGB dark blue
OnInitialization    SendMIDIMessage "B1 0F 2D"     // Makes B8 RGB green

When CSI starts up now, instead of retaining the prior RGB Button color, it now clears out all buttons and turns them all off. This is one of Diesel's changes, and I think it's good behavior overall. I think the issue is that the OnInitialization messages may be occurring before all widgets are cleared. So within a few ms that message gets sent and gets cleared and I never see the button come on at all.

The other issue that now occurs is that if I have a color defined in the button zone, I can't just make that color strobe like this...

Zone Buttons
OnPlayStart      SendMIDIMessage "B2 0F 04"     // Makes B8 RGB strobe on Play start
OnPlayStop       SendMIDIMessage "B2 0F 00"     // Makes B8 RGB stop strobing on Play stop
     
      RotaryPushB8          Play { 0 75 255 90 255 0 }

The strobe commands tied to the virtual widget only work if I remove the color from the play button making me think there's an "order of operations" issue. Not a big deal because, I can workaround it by doing this (notice I had to add an action to set the color too)...

Zone Buttons
OnPlayStart      SendMIDIMessage "B1 0F 2D"     // Makes B8 RGB green on Play start
OnPlayStart      SendMIDIMessage "B2 0F 04"     // Makes B8 RGB strobe on Play start
OnPlayStop       SendMIDIMessage "B2 0F 00"     // Makes B8 RGB stop strobing on Play stop
     
      RotaryPushB8          Play

Note that this works:

Zone "Buttons"
OnPlayStart      SendMIDIMessage "B1 0F 2D"     // Makes B8 RGB green on Play start
OnPlayStart      SendMIDIMessage "B2 0F 04"     // Makes B8 RGB strobe on Play start
OnPlayStop       SendMIDIMessage "B1 0F 40"     // Makes B8 RGB yellow on Play stop
OnPlayStop       SendMIDIMessage "B2 0F 00"     // Makes B8 RGB stop strobing on Play stop


      RotaryPushB8          Play

...however, if I do that, I can't set an initial RGB state for the buttons, which is where this post started. If I could just get that OnInitialization SendMIDIMessage to work, I'd be able to do everything I want to but it's not happening. I even tried OnZoneAvtivation SendMIDIMessage and stuck that in the buttons zone and also no dice.

The other problem is I can't snoop in the CSI logs because when I refresh all surfaces, the CSI actions stop working so I can't see what's actually being sent out on initialization.

[ivanv]

Originally Posted by Geoff Waddington

Ok, now that the basics work, let's rename everything

This will allow us to do a Track version as ivanv proposed, a la SelectedTrackSends and TrackSends.

So, the replacement for what we have now will be SelectedTrackTCPFX and GoSelectedTrackTCPFX.

We will then add TrackTCPFX and GoTrackTCPFX.

Amazing... thank you Geoff!
And thank you MixMonkey for the C4 files!

[MT4U]

Funny thing:

If your fixed text is "Feedback", no text will be displayed.

DisplayUpper4  FixedTextDisplay "Feedback"

X-Touch/Win10

Happy New Year everyone!

[Geoff Waddington]

Originally Posted by MT4U

Funny thing:

If your fixed text is "Feedback", no text will be displayed.

DisplayUpper4  FixedTextDisplay "Feedback"

X-Touch/Win10

Happy New Year everyone!

Thanks for testing, along with the other bug you reported about the inability to turn to turn off feedback for the first Action mapped to a Widget.

These conditions are caused by the new ability to selectively apply feedback when there is more than one Action mapped to a Widget.

Will be fixed in next build.

[Geoff Waddington]

New build is up.

CSI Support files.zip

CSI Exp.zip



Added SelectedTrack to TCPFX, see X Touch support files.

In short, the Zone is now SelectedTrackTCPFX and the Action is GoSelectedTrackTCPFX.



Fixed Feedback bugs.

If the first Action for a given Widget has Feedback=No defined, feedback is suppressed.

If the first Action has Feedback=Yes defined, or if there is no Feedback definition, feedback is provided.

If subsequent Actions for the same Widget have Feedback=Yes defined, the last Action for the given Widget that has Feedback=Yes defined gets the feedback.

Decided to make this more explicit, might need a Wiki tweak.

[luiza177]

Hey everyone! First and foremost, thank you Geoff Waddington and everyone for all the time and effort put into this great extension!

I'm a new user writing my own zones for the FaderPort v2, I got almost everything I wanted out it working so far except for a few things. I searched the forum and found no answers to my specific questions, so here I am. I apologize if I should've gone elsewhere for this. Here goes:

1) is there a workaround to get a non-latching Rewind/FastForward behavior? I'm trying to get it to behave like it does in S1.

2) I set up both simple "press" actions as well as "hold" actions for certain buttons. I know for a fact every button in the FaderPort produces Note On and Note Off messages for pressing and releasing respectively, but when I attempt a "hold" action, I get first the "press" action, and THEN the "hold" action. I was expecting the "press" action not to happen first. Is that the way it's meant to behave?

3) The FaderPort only has physical buttons for Read, Write and Touch (Latch, Trim/Read and Latch Preview are available using shift), so I noticed that if I go into, say, Latch mode, the associated status RGB LED is only on when the Shift button is pressed. I was hoping to get it to stay on in the Latch color (as opposed to the Touch color, which it share the button with). [Does this make sense?]

[MixMonkey]

Originally Posted by luiza177

1) is there a workaround to get a non-latching Rewind/FastForward behavior? I'm trying to get it to behave like it does in S1.

Not at the present time, though non-latching behaviour (perhaps with a separate Action) is a reasonable feature request.

2) I set up both simple "press" actions as well as "hold" actions for certain buttons. I know for a fact every button in the FaderPort produces Note On and Note Off messages for pressing and releasing respectively, but when I attempt a "hold" action, I get first the "press" action, and THEN the "hold" action. I was expecting the "press" action not to happen first. Is that the way it's meant to behave?

Yes, it's supposed to behave this way. To have it recognise the "Hold" without first recognising the "Press" would make all the non-Hold Press Actions seem very sluggish. Similarly, triggering Acions on the release message of the button is very strange too.

3) The FaderPort only has physical buttons for Read, Write and Touch (Latch, Trim/Read and Latch Preview are available using shift), so I noticed that if I go into, say, Latch mode, the associated status RGB LED is only on when the Shift button is pressed. I was hoping to get it to stay on in the Latch color (as opposed to the Touch color, which it share the button with). [Does this make sense?]

Sorry to be a Negative Nancy, but this is the expected behaviour. Only when the Shift button is pressed is the button "Latch" (for both Action and feedback). When Shift is not pressed the button is "Touch" and "Touch" isn't active, so the LED is off. In this situation you're better off using an additional button (or 3) so that the radio button nature of the automation modes can be more easily discerned.

[luiza177]

Originally Posted by MixMonkey

Yes, it's supposed to behave this way. To have it recognise the "Hold" without first recognising the "Press" would make all the non-Hold Press Actions seem very sluggish. Similarly, triggering Acions on the release message of the button is very strange too.

Makes sense. That said, is there a way to have at least some buttons react on NoteOff messages? At least in some applications, for instance, using the buttons to switch (sub)zones (eg. so the big Rotary can control different things) wouldn't be unreasonable.

I suppose this also implies that CSI can't do simultaneous button presses, right? FaderPort's intended method for returning to project start, for instance, is by pressing the Rewind and Fast Forward button simultaneously, so it would be nice to be able to do that, as it's labeled that way.

Originally Posted by MixMonkey

Sorry to be a Negative Nancy, but this is the expected behaviour. Only when the Shift button is pressed is the button "Latch" (for both Action and feedback). When Shift is not pressed the button is "Touch" and "Touch" isn't active, so the LED is off. In this situation you're better off using an additional button (or 3) so that the radio button nature of the automation modes can be more easily discerned.

I see. That makes sense. In that case, I wonder if you could get away with declaring the actual button and the LED as separated widgets, and sort of manually control them with subzones or something...?