Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by Funkybot

Can’t we already do this with the banking actions we have? Not sure I follow what’s different. Or is this really just about what makes sense for default behavior of an MCU/X-Touch?

Just about the MCU/X-Touch type surfaces, seems more intuitive:

Zone "SelectedTrackSend"
    	DisplayUpper|               TrackSendNameDisplay
    	FaderTouch+DisplayUpper|    TrackSendVolumeDisplay
    	Mute|                       TrackSendMute
    	Rotary|                     TrackSendPan
    	Fader|                      TrackSendVolume
    	Left                        SelectedTrackSendBank -1
    	Right                       SelectedTrackSendBank 1
ZoneEnd

Zone "TrackSend"
    	DisplayUpper|               TrackNameDisplay
    	DisplayLower|               TrackSendNameDisplay
    	FaderTouch+DisplayLower|    TrackSendVolumeDisplay
    	Mute|                       TrackSendMute
    	Rotary|                     TrackSendPan
    	Fader|                      TrackSendVolume
    	Up                          TrackSendBank -1
    	Down                        TrackSendBank 1
ZoneEnd

[MixMonkey]

Originally Posted by Geoff Waddington

Zone "Buttons"
     SubZones
          "Zoom"
          "Scrub"
     SubZonesEnd

Then to activate the zones...

Zoom      GoSubZone "Zoom"
Scrub     GoSubZone "Scrub"

That's how it is currently coded.

Is this working in the current build?

[Geoff Waddington]

Originally Posted by MixMonkey

Is this working in the current build?

Not yet, just finishing off the Associated Zones.

I really wish I had gotten rid of the Avid Artist Mixes a long time ago, they are so restricted compared to the X-Touch.

One thing that makes life a lot easier is having both an upper and lower display, forgot how much I missed those.

[MixMonkey]

Originally Posted by Geoff Waddington

Not yet, just finishing off the Associated Zones.

I really wish I had gotten rid of the Avid Artist Mixes a long time ago, they are so restricted compared to the X-Touch.

One thing that makes life a lot easier is having both an upper and lower display, forgot how much I missed those.

Cool Just checking I hadn't missed a memo, with all this talk of SubZones and button assignments

Regarding the default button assignment discussion, you're quite lucky with the X-Touch as all the buttons light up. On the Mackie MCU, my button assignments are governed as much by the need for feedback as anything else For instance, the modifier keys don't illuminate, so I moved the modifiers to ones that do.

[Geoff Waddington]

Originally Posted by MixMonkey

Cool Just checking I hadn't missed a memo, with all this talk of SubZones and button assignments

Regarding the default button assignment discussion, you're quite lucky with the X-Touch as all the buttons light up. On the Mackie MCU, my button assignments are governed as much by the need for feedback as anything else For instance, the modifier keys don't illuminate, so I moved the modifiers to ones that do.

Yeah, I'm actually quite impressed with the X-Touch, a lot more than I thought I'd be

Along with the buttons lighting up, was pleased to see every button sends a release message.

I have only one beef, when moving the faders manually they are fine but when moving the faders via automation or the mouse the faders have very low resolution, they jump in small steps which results in a grindy sound, perhaps a firmware update, or swapping out the faders, or both

[MixMonkey]

Originally Posted by Geoff Waddington

I have only one beef, when moving the faders manually they are fine but when moving the faders via automation or the mouse the faders have very low resolution, they jump in small steps which results in a grindy sound, perhaps a firmware update, or swapping out the faders, or both

Might be fixable in CSI code:

https://www.youtube.com/watch?v=DtFwmEwhUHo

[Navelpluisje]

While working on my reasonus build I had issues with the Track colours. They were way off. Seems that the red and blue were switched. Switching them fixed the Track colour for me.

Current situation:

            int r = (*rgb_colour >> 0) & 0xff;
            int g = (*rgb_colour >> 8) & 0xff;
            int b = (*rgb_colour >> 16) & 0xff;

Should be:

            int r = (*rgb_colour >> 16) & 0xff;
            int g = (*rgb_colour >> 8) & 0xff;
            int b = (*rgb_colour >> 0) & 0xff;

[Navelpluisje]

Think we're almost done now with the faderport installer. Will now check the v2 stuff. See what stays alive, dies and is improved

[Geoff Waddington]

Originally Posted by MixMonkey

Might be fixable in CSI code:

https://www.youtube.com/watch?v=DtFwmEwhUHo

Thanks, will investigate at some point.

[Geoff Waddington]

Originally Posted by Navelpluisje

While working on my reasonus build I had issues with the Track colours. They were way off. Seems that the red and blue were switched. Switching them fixed the Track colour for me.

Current situation:

            int r = (*rgb_colour >> 0) & 0xff;
            int g = (*rgb_colour >> 8) & 0xff;
            int b = (*rgb_colour >> 16) & 0xff;

Should be:

            int r = (*rgb_colour >> 16) & 0xff;
            int g = (*rgb_colour >> 8) & 0xff;
            int b = (*rgb_colour >> 0) & 0xff;

Yeah, I seem to remember switching them at one point for someone's controller, maybe it was that controller that was off

[Geoff Waddington]

Originally Posted by Navelpluisje

Think we're almost done now with the faderport installer. Will now check the v2 stuff. See what stays alive, dies and is improved

Cool.

Man, your installer and docs definitely rock !!

[Navelpluisje]

Originally Posted by Geoff Waddington

Cool.

Man, your installer and docs definitely rock !!

Thanx, I think all the missing links for the faderport are now in that build. Pretty happ with the result tbh.

[Navelpluisje]

Originally Posted by Geoff Waddington

Well, technically you could add "Track" to the Associated Zone section, just can't really come up with a use case for it, in any feasible use case I can think of, you just end up at Home, as you say

If we don't hear from anyone with a valid use case for it, let's let it go...

For the faderport there is a usecase for the GoTrack, without triggering GoHome. This is something I came across in v1.1 as well. The faderport has no dedicated arm buttons. I now try to create a subzone for that (without success so far). But the idea is, you click the Arm button, the select buttons become the arm buttons.
Beside that subzone there are a lot of them for the navigation buttons (8 in total). These start on a given navigation (Bank) when triggering home zone.

Clicking Arm again you would like to go to the Track zone without triggering Home. This way the other subzones stay where they are and you do not have to swith over there every time.

GoHome feels a bit as a reset for whole the surface and resets every single zone.

[Navelpluisje]

Originally Posted by Geoff Waddington

Yeah, I seem to remember switching them at one point for someone's controller, maybe it was that controller that was off

Shouldn't it be changed in the widget code then?

[Geoff Waddington]

Originally Posted by Navelpluisje

For the faderport there is a usecase for the GoTrack, without triggering GoHome. This is something I came across in v1.1 as well. The faderport has no dedicated arm buttons. I now try to create a subzone for that (without success so far). But the idea is, you click the Arm button, the select buttons become the arm buttons.
Beside that subzone there are a lot of them for the navigation buttons (8 in total). These start on a given navigation (Bank) when triggering home zone.

Clicking Arm again you would like to go to the Track zone without triggering Home. This way the other subzones stay where they are and you do not have to swith over there every time.

GoHome feels a bit as a reset for whole the surface and resets every single zone.

This will be easy once SubZones are working.

The Arm button will GoSubZone "RecArm" (or whatever you want to name it), and within that SubZone definition, the Select buttons will map to RecArm.

Also the Arm button will remap to LeaveZone, voila, push Arm and you are back where you started before you pushed Arm

LeaveZone just sets the Zone in which it is defined to Inactive.

[Geoff Waddington]

Originally Posted by Navelpluisje

Shouldn't it be changed in the widget code then?

Yup, I think I originally thought it was a bug -- no surfaces with colour here to test with

[Funkybot]

Originally Posted by Geoff Waddington

Thanks, will investigate at some point.

X-Touch interpolation would be killer.

[Navelpluisje]

Originally Posted by Geoff Waddington

This will be easy once SubZones are working.

The Arm button will GoSubZone "RecArm" (or whatever you want to name it), and within that SubZone definition, the Select buttons will map to RecArm.

Also the Arm button will remap to LeaveZone, voila, push Arm and you are back where you started before you pushed Arm

LeaveZone just sets the Zone in which it is defined to Inactive.

So the subzones will use the same navigators as the 'parent' zone from where they were called?

And how far is SubZones now working? I used the mcu zip from this forum as a guide, but do not seem to be able to go to a subzone.

My Track:

Zone "Track"
  IncludedSubZones
    "TrackRecArm"
  IncludedSubZonesEnd

  // Some display stuff
  ScribbleLine1_|           TrackNameDisplay {% Left %}
  ScribbleLine2_|           TrackVolumeDisplay
  ScribbleLine3_|           TrackPanDisplay
  ScribbleLine4_|           NoAction

  Mute|                     TrackMute
  Solo|                     TrackSolo
  Select|                   TrackUniqueSelect  { "Track" }
  Shift+Select|             TrackSelect        { "Track" }
  Option+Select|            TrackSelect        { "Track" }

  Arm                       GoSubZone "TrackRecArm"
  Shift+Arm                 Reaper 40490       // Track: Arm all tracks for recording
  Option+Arm                Reaper 40491       // Track: Unarm all tracks for recording
      
  SoloClear                 Reaper 40340       // Track: Unsolo all tracks
  MuteClear                 Reaper 40339       // Track: Unmute all tracks
        
  Shift+Fader|              TrackPan
  Fader|                    TrackVolume
  FaderTouch+Fader|         TrackVolume
  FaderTouch|               TrackTouch

  Bypass                    Reaper 8           { 20 0 0 255 0 0 } // Track: Toggle FX bypass for selected tracks
  Shift+Bypass              Reaper 40344       { 20 0 0 255 0 0 } // Track: Toggle FX bypass on all tracks


// ===========================================
// TRACK NAVIGATION
// ===========================================
  Track               Reaper %dummyAction%    // Dummy Action

  / Plugin              NoAction
  / Plugin              MapSelectedTrackFXToMenu
  / Shift+Plugin        MapTrackFXMenusSlotToWidgets

  / Send                NoAction
  / Send                MapSelectedTrackSendsToWidgets
  / Shift+Send          MapTrackSendsSlotToWidgets

  / Pan                 NoAction
  / Pan                 MapSelectedTrackReceivesToWidgets
  / Shift+Pan           MapTrackReceivesSlotToWidgets
ZoneEnd

RecArm:

Zone "TrackRecArm"
    Select|           TrackRecordArm     { 20 0 0 255 0 0 }
    Arm               LeaveZone
ZoneEnd

[MikeLacey]

Are there any plans for a Linux version?

Is anyone thinking of working on this?

[Funkybot]

Originally Posted by Navelpluisje

So the subzones will use the same navigators as the 'parent' zone from where they were called?

And how far is SubZones now working? I used the mcu zip from this forum as a guide, but do not seem to be able to go to a subzone.

My Track:

Zone "Track"
  IncludedSubZones
    "TrackRecArm"
  IncludedSubZonesEnd

  // Some display stuff
  ScribbleLine1_|           TrackNameDisplay {% Left %}
  ScribbleLine2_|           TrackVolumeDisplay
  ScribbleLine3_|           TrackPanDisplay
  ScribbleLine4_|           NoAction

  Mute|                     TrackMute
  Solo|                     TrackSolo
  Select|                   TrackUniqueSelect  { "Track" }
  Shift+Select|             TrackSelect        { "Track" }
  Option+Select|            TrackSelect        { "Track" }

  Arm                       GoSubZone "TrackRecArm"
  Shift+Arm                 Reaper 40490       // Track: Arm all tracks for recording
  Option+Arm                Reaper 40491       // Track: Unarm all tracks for recording
      
  SoloClear                 Reaper 40340       // Track: Unsolo all tracks
  MuteClear                 Reaper 40339       // Track: Unmute all tracks
        
  Shift+Fader|              TrackPan
  Fader|                    TrackVolume
  FaderTouch+Fader|         TrackVolume
  FaderTouch|               TrackTouch

  Bypass                    Reaper 8           { 20 0 0 255 0 0 } // Track: Toggle FX bypass for selected tracks
  Shift+Bypass              Reaper 40344       { 20 0 0 255 0 0 } // Track: Toggle FX bypass on all tracks


// ===========================================
// TRACK NAVIGATION
// ===========================================
  Track               Reaper %dummyAction%    // Dummy Action

  / Plugin              NoAction
  / Plugin              MapSelectedTrackFXToMenu
  / Shift+Plugin        MapTrackFXMenusSlotToWidgets

  / Send                NoAction
  / Send                MapSelectedTrackSendsToWidgets
  / Shift+Send          MapTrackSendsSlotToWidgets

  / Pan                 NoAction
  / Pan                 MapSelectedTrackReceivesToWidgets
  / Shift+Pan           MapTrackReceivesSlotToWidgets
ZoneEnd

RecArm:

Zone "TrackRecArm"
    Select|           TrackRecordArm     { 20 0 0 255 0 0 }
    Arm               LeaveZone
ZoneEnd

SubZones aren’t working yet. You probably want to hold off on checking out 2.0 until they are implemented because of what will be your extensive use of them.

[Navelpluisje]

Originally Posted by Funkybot

SubZones aren’t working yet. You probably want to hold off on checking out 2.0 until they are implemented because of what will be your extensive use of them.

Yeah, I think that's not a bad idea. Will use them a lot I think.

[MixMonkey]

I put together a simple way of turning the audio on and off whilst scrubbing (thanks to @chinpou for the source! )

First off, two simple one line lua scripts:

Audio On:

scrubon = reaper.SNM_SetIntConfigVar("scrubmode", 3)

Audio Off:

scruboff = reaper.SNM_SetIntConfigVar("scrubmode", 2)

Create a Cycle Action using the SWS Cycle Editor:


Assign the Cycle Action to the Scrub button, along with a dummy toggle to work the LED:

    Scrub      Reaper "_S&M_DUMMY_TGL1"      //Operate Scrub button LED
    Scrub      Reaper "_S&M_CYCLACTION_1"    //Turn scrub audio on/off

Now I can use the jog wheel (which moves the edit cursor by default) to scrub audio when I want

[Funkybot]

Nice stuff Mixmonkey and Chinpou!

[Navelpluisje]

Originally Posted by MixMonkey

I put together a simple way of turning the audio on and off whilst scrubbing (thanks to @chinpou for the source! )

First off, two simple one line lua scripts:

Audio On:

scrubon = reaper.SNM_SetIntConfigVar("scrubmode", 3)

Audio Off:

scruboff = reaper.SNM_SetIntConfigVar("scrubmode", 2)

Create a Cycle Action using the SWS Cycle Editor:


Assign the Cycle Action to the Scrub button, along with a dummy toggle to work the LED:

    Scrub      Reaper "_S&M_DUMMY_TGL1"      //Operate Scrub button LED
    Scrub      Reaper "_S&M_CYCLACTION_1"    //Turn scrub audio on/off

Now I can use the jog wheel (which moves the edit cursor by default) to scrub audio when I want

You can make the cycle action toggle. This way you do not need the dummy toggle anymore

[Puck]

Originally Posted by MixMonkey

I put together a simple way of turning the audio on and off whilst scrubbing (thanks to @chinpou for the source! )

First off, two simple one line lua scripts:

Audio On:

scrubon = reaper.SNM_SetIntConfigVar("scrubmode", 3)

Audio Off:

scruboff = reaper.SNM_SetIntConfigVar("scrubmode", 2)

Create a Cycle Action using the SWS Cycle Editor:


Assign the Cycle Action to the Scrub button, along with a dummy toggle to work the LED:

    Scrub      Reaper "_S&M_DUMMY_TGL1"      //Operate Scrub button LED
    Scrub      Reaper "_S&M_CYCLACTION_1"    //Turn scrub audio on/off

Now I can use the jog wheel (which moves the edit cursor by default) to scrub audio when I want

Nicely done!!


Requires Ultraschall API, right?

[MixMonkey]

Originally Posted by Navelpluisje

You can make the cycle action toggle. This way you do not need the dummy toggle anymore

Thanks Much better!, dummy toggles are unreliable.

[MixMonkey]

Originally Posted by Puck

Requires Ultraschall API, right?

Not sure, I have these as UserPlugins:

reaper_csurf_integrator.dylib
reaper_js_ReaScriptAPI64.dylib
reaper_reapack-x86_64.dylib
reaper_sws-x86_64.dylib

[Geoff Waddington]

Haha, in the "You learn something new every day" department...

I'm sure you folks have run into this, but because of the way the Console 1 hardware and EuCon software is implemented, this is new to me, aka -- I was getting away with it before

Mapped the UAD Fairchild 660 to test GoFXSlot from FXMenu and all of the controls received feedback just fine, but for some, turning the rotary did nothing.

Took me a while to realize, the parameters that didn't work were all stepped value types -- the Fairchild 660 Input control is actually stepped, not continuous, that threw me off at first

Ok, so we actually need stepped values for those.

Here is what we are dealing with:

Headroom - 7 steps
Meter - 3 steps
Time Constant - 6 steps
Input Gain - around 20 steps -- uggh

Think it's time to write some software that outputs the step values needed

The trick will be keeping it reasonable, for instance, we don't want the Output, which is continuous, to generate a humongous list of values.

Here's my first thoughts on the matter of a pragmatic solution.

First step is to build a Zone file in the normal way, and try it out.

Note any controls that don't work, these are the ones likely to need steps.

Use the Reaper Action "CSI Toggle Write Params to /CSI/Zones/ZoneRawFXFiles when FX inserted".

This will be re-written, such that, after having inserted the FX, you can twiddle any controls that you noticed fail in your original Zone construction, and CSI will generate a list of the step values needed.

Maybe improve it a bit to actually write those steps into the generated Raw Zone file.

Totally open to suggestions on this one, floor is open for discussion...

[Funkybot]

Originally Posted by Geoff Waddington

Totally open to suggestions on this one, floor is open for discussion...

I'm not sure anyone uses this, but having a list like this handy is helpful, but not as good as an automated solution:

https://github.com/GeoffAWaddington/...eference-table

In terms of an automated solution, I'd love a simple: "CSI: Toggle learn stepped FX parameters" action where we could:

1. Run the action
2. This opens a ReaConsole window
3. Focus an FX and turn the plugin parameter to minimum, then step through to maximum
4. The ReaConsole window writes something like this that could be copied/pasted into zones:

FXParam 0 [ 0.0 0.05 0.10 0.15 0.20 0.25 0.30 0.35 0.40 0.45 0.50 0.55 0.60 0.65 0.70 0.75 0.80 0.85 0.90 0.95 1.0 ]

[MixMonkey]

Originally Posted by Geoff Waddington

Took me a while to realize, the parameters that didn't work were all stepped value types -- the Fairchild 660 Input control is actually stepped, not continuous, that threw me off at first

That's just bad luck The great majority of plugin parameters that are stepped will still work with a standard, accelerated encoder. You've just come across one of the ones that won't. Unfortunately, this probably applies to the rest of the UAD series (assuming UAD standardise their approach, which isn't guaranteed either)

Ok, so we actually need stepped values for those.

Here is what we are dealing with:

Headroom - 7 steps
Meter - 3 steps
Time Constant - 6 steps
Input Gain - around 20 steps -- uggh

Think it's time to write some software that outputs the step values needed

The trick will be keeping it reasonable, for instance, we don't want the Output, which is continuous, to generate a humongous list of values.

Here's my first thoughts on the matter of a pragmatic solution.

First step is to build a Zone file in the normal way, and try it out.

Note any controls that don't work, these are the ones likely to need steps.

Use the Reaper Action "CSI Toggle Write Params to /CSI/Zones/ZoneRawFXFiles when FX inserted".

This will be re-written, such that, after having inserted the FX, you can twiddle any controls that you noticed fail in your original Zone construction, and CSI will generate a list of the step values needed.

Maybe improve it a bit to actually write those steps into the generated Raw Zone file.

Totally open to suggestions on this one, floor is open for discussion...

That sounds nice But you'll only need something that sophisticated if the plug in author hasn't divided up the steps evenly throughout the 0.0 - 1.0 range. If he has, it's simple. I did a table a while back and some of it is built into the configurator.

[MixMonkey]

Also, before I forget. If you're trying to do stepped values on a rotary encoder, if you get any of the step values wrong the encoder will get 'stuck'. Make a note of where it 'sticks' and try adjusting the step value before/after that step and try again.

[Geoff Waddington]

Originally Posted by Funkybot

I'm not sure anyone uses this, but having a list like this handy is helpful, but not as good as an automated solution:

https://github.com/GeoffAWaddington/...eference-table

In terms of an automated solution, I'd love a simple: "CSI: Toggle learn stepped FX parameters" action where we could:

1. Run the action
2. This opens a ReaConsole window
3. Focus an FX and turn the plugin parameter to minimum, then step through to maximum
4. The ReaConsole window writes something like this that could be copied/pasted into zones:

FXParam 0 [ 0.0 0.05 0.10 0.15 0.20 0.25 0.30 0.35 0.40 0.45 0.50 0.55 0.60 0.65 0.70 0.75 0.80 0.85 0.90 0.95 1.0 ]

Thanks, that table did the trick !

And we already have new a feature to add post 2.0

[Funkybot]

Originally Posted by MixMonkey

But you'll only need something that sophisticated if the plug in author hasn't divided up the steps evenly throughout the 0.0 - 1.0 range.

This is such a pain in the ass when it happens, that an automated solution in CSI would be a huge time saver. Your trick about using Patchwork has bailed me out a bunch of times, but it's time consuming and tedious. Sometimes the worst part of creating fx.zons.

[Geoff Waddington]

Originally Posted by MixMonkey

That's just bad luck The great majority of plugin parameters that are stepped will still work with a standard, accelerated encoder. You've just come across one of the ones that won't. Unfortunately, this probably applies to the rest of the UAD series (assuming UAD standardise their approach, which isn't guaranteed either)


That sounds nice But you'll only need something that sophisticated if the plug in author hasn't divided up the steps evenly throughout the 0.0 - 1.0 range. If he has, it's simple. I did a table a while back and some of it is built into the configurator.

The table Funkybot provided did the trick, at least for now.

[Geoff Waddington]

Originally Posted by MixMonkey

Also, before I forget. If you're trying to do stepped values on a rotary encoder, if you get any of the step values wrong the encoder will get 'stuck'. Make a note of where it 'sticks' and try adjusting the step value before/after that step and try again.

Cool, noted.

[MixMonkey]

Originally Posted by Geoff Waddington

Cool, noted.

For me, if it's only a few steps (<5, say) I much prefer a push that just cycles round the steps. It feels a lot more positive than a rotary.

[MixMonkey]

Originally Posted by Funkybot

TYour trick about using Patchwork has bailed me out a bunch of times, but it's time consuming and tedious.

I agree . Utterly soul destroying.

[Geoff Waddington]

Originally Posted by MixMonkey

For me, if it's only a few steps (<5, say) I much prefer a push that just cycles round the steps. It feels a lot more positive than a rotary.

Yeah, it's a tradeoff, on the Fairchild both the Meter switch (3 steps) and the Time Constant switch (6 steps) are on rotaries, so it's more visually representative, but totally get your point.

[MixMonkey]

Originally Posted by Geoff Waddington

One last thing that indicates this discussion has been at least somewhat productive, MCUTrackPan will be redesigned thusly, such that RotaryPush is available for other tasks:

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

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd

    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan

Quick question about this. Does the RotaryPush definition replace my existing .mst definition or is it in addition to it?

At the moment I have:

Widget RotaryPush1
	Press 90 20 7f 90 20 00
WidgetEnd

[Geoff Waddington]

Originally Posted by MixMonkey

Quick question about this. Does the RotaryPush definition replace my existing .mst definition or is it in addition to it?

At the moment I have:

Widget RotaryPush1
	Press 90 20 7f 90 20 00
WidgetEnd

Sorry, my bad, that's a typo, Toggle is history, your definition is correct.