Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

New build is up.

CSI Exp.zip

Released constraint that all three - Rotary, UpperDisplay, Lower Display - must be present for shorthand FX Zone definition.

[Funkybot]

Originally Posted by Geoff Waddington

New build is up.

CSI Exp.zip

Released constraint that all three - Rotary, UpperDisplay, Lower Display - must be present for shorthand FX Zone definition.

No change here unfortunately.

Pressing the GoFXSlot button on the MFTwister correctly activates the mapping on the iPad, but the FX mapping isn't happening on the MIDI device for some reason.

Now that I think about it, this worked earlier today without issue on both surfaces. When I had named the widgets Rotary1-8, everything worked on both surfaces. It's only since the RotaryA1-A8 mapping was implemented that it stopped. Sorry for not calling that earlier. That would've ruled out the need for the last build.

[Geoff Waddington]

Originally Posted by Funkybot

No change here unfortunately.

Pressing the GoFXSlot button on the MFTwister correctly activates the mapping on the iPad, but the FX mapping isn't happening on the MIDI device for some reason.

Now that I think about it, this worked earlier today without issue on both surfaces. When I had named the widgets Rotary1-8, everything worked on both surfaces. It's only since the RotaryA1-A8 mapping was implemented that it stopped. Sorry for not calling that earlier. That would've ruled out the need for the last build.

No worries, the last build was a needed improvement, so it was worth doing.

Please post the generated Zone.

Also perhaps rename everything to Rotary1, DisplayUpper1, etc. and post those results, probably a cut paste error in my code.

[Funkybot]

Originally Posted by Geoff Waddington

No worries, the last build was a needed improvement, so it was worth doing.

Please post the generated Zone.

Also perhaps rename everything to Rotary1, DisplayUpper1, etc. and post those results, probably a cut paste error in my code.

Ignore that last post. I just rolled back to confirm and it wasn't working. I was just using the iPad for testing and didn't check the Twister.

But if I add this to the Twister .mst, it works...

Widget DisplayUpper1
	FB_C4DisplayUpper 0 0
WidgetEnd

Widget DisplayUpper2
	FB_C4DisplayUpper 0 1
WidgetEnd

Widget DisplayUpper3
	FB_C4DisplayUpper 0 2
WidgetEnd

Widget DisplayUpper4
	FB_C4DisplayUpper 0 3
WidgetEnd

Widget DisplayUpper5
	FB_C4DisplayUpper 0 4
WidgetEnd

Widget DisplayUpper6
	FB_C4DisplayUpper 0 5
WidgetEnd

Widget DisplayUpper7
	FB_C4DisplayUpper 0 6
WidgetEnd

Widget DisplayUpper8
	FB_C4DisplayUpper 0 7
WidgetEnd

Widget DisplayLower1
	FB_C4DisplayLower 0 0
WidgetEnd

Widget DisplayLower2
	FB_C4DisplayLower 0 1
WidgetEnd

Widget DisplayLower3
	FB_C4DisplayLower 0 2
WidgetEnd

Widget DisplayLower4
	FB_C4DisplayLower 0 3
WidgetEnd

Widget DisplayLower5
	FB_C4DisplayLower 0 4
WidgetEnd

Widget DisplayLower6
	FB_C4DisplayLower 0 5
WidgetEnd

Widget DisplayLower7
	FB_C4DisplayLower 0 6
WidgetEnd

Widget DisplayLower8
	FB_C4DisplayLower 0 7
WidgetEnd

...so I think you were right, but the latest fix didn't take for some reason.

[Geoff Waddington]

Originally Posted by Funkybot

Ignore that last post. I just rolled back to confirm and it wasn't working. I was just using the iPad for testing and didn't check the Twister.

But if I add this to the Twister .mst, it works...

Widget DisplayUpper1
	FB_C4DisplayUpper 0 0
WidgetEnd

Widget DisplayUpper2
	FB_C4DisplayUpper 0 1
WidgetEnd

Widget DisplayUpper3
	FB_C4DisplayUpper 0 2
WidgetEnd

Widget DisplayUpper4
	FB_C4DisplayUpper 0 3
WidgetEnd

Widget DisplayUpper5
	FB_C4DisplayUpper 0 4
WidgetEnd

Widget DisplayUpper6
	FB_C4DisplayUpper 0 5
WidgetEnd

Widget DisplayUpper7
	FB_C4DisplayUpper 0 6
WidgetEnd

Widget DisplayUpper8
	FB_C4DisplayUpper 0 7
WidgetEnd

Widget DisplayLower1
	FB_C4DisplayLower 0 0
WidgetEnd

Widget DisplayLower2
	FB_C4DisplayLower 0 1
WidgetEnd

Widget DisplayLower3
	FB_C4DisplayLower 0 2
WidgetEnd

Widget DisplayLower4
	FB_C4DisplayLower 0 3
WidgetEnd

Widget DisplayLower5
	FB_C4DisplayLower 0 4
WidgetEnd

Widget DisplayLower6
	FB_C4DisplayLower 0 5
WidgetEnd

Widget DisplayLower7
	FB_C4DisplayLower 0 6
WidgetEnd

Widget DisplayLower8
	FB_C4DisplayLower 0 7
WidgetEnd

...so I think you were right, but the latest fix didn't take for some reason.

Please post the generated Zone along with the .mst and .ost files that work.

Also please post the non working RotaryA flavour generated Zone as well as the accompanying .ost and .mst files.

It may be something subtle.

[Funkybot]

Disregard.

I think it got it going. Really need to get some sleep. Got in crazy late and was up too early. Apologies.

Note: it does still require display widgets in the .mst in the latest build. So that appears to be a bug. Without the DisplayUpper/DisplayLower widgets, it still won't work on the Twister.

Scroll down to see Display widgets in the .mst.

StepSize
    RotaryWidgetClass 0.001
StepSizeEnd

AccelerationValues
    RotaryWidgetClass Dec 3f     3e    3d    3c    3b    3a    39     38    36    33    2f      
    RotaryWidgetClass Inc 41     42    43    44    45    46    47     48    4a    4d    51
    RotaryWidgetClass Val 0.001  0.002 0.003 0.004 0.005 0.006 0.0075 0.01  0.02  0.03  0.04
AccelerationValuesEnd

//////////////////////////////////////Side Buttons//////////////////////////////////////////////////

Widget BankA
    Press B3 00 7f
WidgetEnd

Widget BankB
    Press B3 01 7f
WidgetEnd

Widget BankC
    Press B3 02 7f
WidgetEnd

Widget BankD
    Press B3 02 7f
WidgetEnd

Widget BankALeft
    AnyPress B3 09 7f
WidgetEnd

Widget BankARight
    AnyPress B3 0c 7f
WidgetEnd

Widget BankBLeft
    AnyPress B3 0f 7f
WidgetEnd

Widget BankBRight
    AnyPress B3 12 7f
WidgetEnd

Widget BankCLeft
    AnyPress B3 15 7f
WidgetEnd

Widget BankCRight
    AnyPress B3 18 7f
WidgetEnd

Widget BankDLeft
    AnyPress B3 1b 7f
WidgetEnd

Widget BankDRight
    AnyPress B3 1e 7f
WidgetEnd

//////////////////////////////////////Bank 1//////////////////////////////////////////////////


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

Widget RotaryPushA2
    Press b1 01 7f b1 01 00
    FB_MFT_RGB b1 01 7f
WidgetEnd

Widget RotaryPushA3
    Press b1 02 7f b1 02 00
    FB_MFT_RGB b1 02 7f
WidgetEnd 

Widget RotaryPushA4
    Press b1 03 7f b1 03 00
    FB_MFT_RGB b1 03 7f
WidgetEnd

Widget RotaryPushA5
    Press b1 04 7f b1 04 00
    FB_MFT_RGB b1 04 7f
WidgetEnd

Widget RotaryPushA6
    Press b1 05 7f b1 05 00
    FB_MFT_RGB b1 05 7f
WidgetEnd

Widget RotaryPushA7
    Press b1 06 7f b1 06 00
    FB_MFT_RGB b1 06 7f
WidgetEnd

Widget RotaryPushA8
    Press b1 07 7f b1 07 00
    FB_MFT_RGB b1 07 7f
WidgetEnd

Widget RotaryA1 RotaryWidgetClass
    Encoder b0 00 7f
    FB_Fader7Bit b0 00 00
WidgetEnd

Widget RotaryA2 RotaryWidgetClass
    Encoder b0 01 7f
    FB_Fader7Bit b0 01 00
WidgetEnd

Widget RotaryA3 RotaryWidgetClass
    Encoder b0 02 7f
    FB_Fader7Bit b0 02 00
WidgetEnd

Widget RotaryA4 RotaryWidgetClass
    Encoder b0 03 7f
    FB_Fader7Bit b0 03 00
WidgetEnd

Widget RotaryA5 RotaryWidgetClass
    Encoder b0 04 7f
    FB_Fader7Bit b0 04 00
WidgetEnd

Widget RotaryA6 RotaryWidgetClass
    Encoder b0 05 7f
    FB_Fader7Bit b0 05 00
WidgetEnd

Widget RotaryA7 RotaryWidgetClass
    Encoder b0 06 7f
    FB_Fader7Bit b0 06 00
WidgetEnd

Widget RotaryA8 RotaryWidgetClass
    Encoder b0 07 7f
    FB_Fader7Bit b0 07 00
WidgetEnd

Widget DisplayUpperA1
	FB_C4DisplayUpper 0 0
WidgetEnd

Widget DisplayUpperA2
	FB_C4DisplayUpper 0 1
WidgetEnd

Widget DisplayUpperA3
	FB_C4DisplayUpper 0 2
WidgetEnd

Widget DisplayUpperA4
	FB_C4DisplayUpper 0 3
WidgetEnd

Widget DisplayUpperA5
	FB_C4DisplayUpper 0 4
WidgetEnd

Widget DisplayUpperA6
	FB_C4DisplayUpper 0 5
WidgetEnd

Widget DisplayUpperA7
	FB_C4DisplayUpper 0 6
WidgetEnd

Widget DisplayUpperA8
	FB_C4DisplayUpper 0 7
WidgetEnd

Widget DisplayLowerA1
	FB_C4DisplayLower 0 0
WidgetEnd

Widget DisplayLowerA2
	FB_C4DisplayLower 0 1
WidgetEnd

Widget DisplayLowerA3
	FB_C4DisplayLower 0 2
WidgetEnd

Widget DisplayLowerA4
	FB_C4DisplayLower 0 3
WidgetEnd

Widget DisplayLowerA5
	FB_C4DisplayLower 0 4
WidgetEnd

Widget DisplayLowerA6
	FB_C4DisplayLower 0 5
WidgetEnd

Widget DisplayLowerA7
	FB_C4DisplayLower 0 6
WidgetEnd

Widget DisplayLowerA8
	FB_C4DisplayLower 0 7
WidgetEnd

[ivanmihaljevic]

Any news on the SelectedTrackReceiveBank bug fix?

[Geoff Waddington]

Originally Posted by ivanmihaljevic

Any news on the SelectedTrackReceiveBank bug fix?

Working on Generate FX Zone from TCPFX right now.

The SelectedTrackReceiveBank bug will be handled in the next round of bug fixes, along with other outstanding bugs.

[Funkybot]

Now that the auto-mapping is working, I had a chance to try out some Arturia plugins. These are the ones with almost 3,000 declared automation parameters per plugin (insanity on their part).

The ZoneStepSizes.txt file is not reading their stepped params correctly. At least, not on Windows. Actual results, with comments:

"VST: Chorus DIMENSION-D (Arturia)" 0 0.000000              // On/Off - should be a toggle, shows as continuous
"VST: Chorus DIMENSION-D (Arturia)" 1 0.000000              // Stereo Mode  - should be a toggle, shows as continuous
"VST: Chorus DIMENSION-D (Arturia)" 2 0.000000 0.333333     // Dimension mode - should be 4 steps, one 1 step captured, stops after the 1st
"VST: Chorus DIMENSION-D (Arturia)" 3 0.000000              // Dimension mode 4 - should be a toggle
"VST: Chorus DIMENSION-D (Arturia)" 4 0.000000 0.500000     // Output mix - should be continuous, came up as stepped
"VST: Chorus DIMENSION-D (Arturia)" 5 0.000000              // LFO Shape - technically stepped but works here as continuous
"VST: Chorus DIMENSION-D (Arturia)" 6 0.000000 0.333333     // Dynamic color - should be 4 steps, only the first 2 step values captures
"VST: Chorus DIMENSION-D (Arturia)" 7 0.000000 0.700000     // Width - should be continuous - has 2 step values

If you want to try to reproduce, here is a direct link to the demo download for Mac:

https://dl.arturia.net/products/chor...1_3_0_4061.pkg

Expected results (this works if I manually edit the ZoneStepSizes.txt file):

"VST: Chorus DIMENSION-D (Arturia)" 0 0.000000 1.000000
"VST: Chorus DIMENSION-D (Arturia)" 1 0.000000 1.000000
"VST: Chorus DIMENSION-D (Arturia)" 2 0.000000 0.333333 0.666666 1.000000
"VST: Chorus DIMENSION-D (Arturia)" 3 0.000000 1.000000
"VST: Chorus DIMENSION-D (Arturia)" 4 0.000000 
"VST: Chorus DIMENSION-D (Arturia)" 5 0.000000
"VST: Chorus DIMENSION-D (Arturia)" 6 0.000000 0.333333 0.666666 1.000000
"VST: Chorus DIMENSION-D (Arturia)" 7 0.000000

This happened with all the Arturia plugins I've tried so far. Just using that as one example.

[Funkybot]

I should point out: otherwise, this works insanely great! I've been doing quick maps to test this out on a variety of plugins across a number of developers and it's working very, very well. Looks like a few developers seem to list toggles as continuous parameters, but that's no biggie. Otherwise, not running into issues with this outside of Arturia.

Once this can map more than one row of a C4/Twister, this is going to be really, really slick.

[Geoff Waddington]

Originally Posted by Funkybot

I should point out: otherwise, this works insanely great! I've been doing quick maps to test this out on a variety of plugins across a number of developers and it's working very, very well.

Once this can map more than one row of a C4/Twister, this is going to be really, really slick.

Haha, just wait for a couple of hours, got an even better one for ya'

[Geoff Waddington]

New build is up.

CSI Support Files.zip

CSI Exp.zip

Implemented BuildSelectedTrackTCPFXZone.

First draft, but have to admit, I’m totally psyched !

Prerequisites:

A SelectedTrackTCPFX Associated Zone:

Zone "SelectedTrackTCPFX"
	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

You may substitute RotaryA1, etc., for Rotary1, but the Zone must contain one of:
Rotary1
RotaryA1
RotaryB1
RotaryC1
RotaryD1
Fader1

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

Mappings to be able to execute all of the steps:

    GlobalView                  Global
    MidiTracks                  GoSelectedTrackTCPFX
    Inputs                      NoAction
    AudioTracks                 NoAction
    AudioInstrument             NoAction
    Aux                         NoAction
    Busses                      NoAction
    Outputs                     NoAction
    User                        BuildSelectedTrackTCPFXZone

Ok, do this in exactly this order (at least for now)

Open the Mixer.

Find and select a Track with no FX and insert the one you want to map.

Right click on the FX and at the very bottom of the menu choose Rename FX instance — this will be the alias for the FX.

Close the Mixer.

Resize the Selected Track in the TCP view so you can see what you are doing.

Hit the button mapped to GoSelectedTrackTCPFX.

Add whatever params you wish to map for the FX to the TCPFXParams on the Track, and alias them as needed.

You will see the progress on your surface.

Hit the button mapped to BuildSelectedTrackTCPFXZone.

Check the TCPFXGeneratedZones folder for a very pleasant surprise

[Funkybot]

Hi Geoff, very cool. Use Reaper itself to be the mapping front-end. Only downside to this approach: Reaper doesn't allow you to re-order the TCP FX Params best I can tell. It just puts them in the order they appear on the automation list. But a user could do that after the fact by editing the text file.

I've successfully mapped 4 FX so far:

A few things:

1. FXParamAliasesCache.txt didn't get updated for the first 2 FX I mapped that had aliased params - it did for the third and forth. No idea why it didn't take for the others. Maybe I had the file open or something. I'll keep an eye on that.

2. It still just creates a single row of Rotaries despite what's defined in the zone. Probably a known limitation for now while you get things working but wanted to make you aware just in case.

Example: here's my SelectedTrackTCPFX.zon

Zone "SelectedTrackTCPFX"

     DisplayUpperA1         TCPFXParamNameDisplay 0
     DisplayLowerA1         TCPFXParamValueDisplay 0
     RotaryA1               TCPFXParam 0

     DisplayUpperA2         TCPFXParamNameDisplay 1
     DisplayLowerA2         TCPFXParamValueDisplay 1
     RotaryA2               TCPFXParam 1

     DisplayUpperA3         TCPFXParamNameDisplay 2
     DisplayLowerA3         TCPFXParamValueDisplay 2
     RotaryA3               TCPFXParam 2

     DisplayUpperA4         TCPFXParamNameDisplay 3
     DisplayLowerA4         TCPFXParamValueDisplay 3
     RotaryA4               TCPFXParam 3

     DisplayUpperA5         TCPFXParamNameDisplay 4
     DisplayLowerA5         TCPFXParamValueDisplay 4
     RotaryA5               TCPFXParam 4

     DisplayUpperA6         TCPFXParamNameDisplay 5
     DisplayLowerA6         TCPFXParamValueDisplay 5
     RotaryA6               TCPFXParam 5

     DisplayUpperA7         TCPFXParamNameDisplay 6
     DisplayLowerA7         TCPFXParamValueDisplay 6
     RotaryA7               TCPFXParam 6

     DisplayUpperA8         TCPFXParamNameDisplay 7
     DisplayLowerA8         TCPFXParamValueDisplay 7
     RotaryA8               TCPFXParam 7

     DisplayUpperB1         TCPFXParamNameDisplay 8
     DisplayLowerB1         TCPFXParamValueDisplay 8
     RotaryB1               TCPFXParam 8

     DisplayUpperB2         TCPFXParamNameDisplay 9
     DisplayLowerB2         TCPFXParamValueDisplay 9
     RotaryB2               TCPFXParam 9

     DisplayUpperB3         TCPFXParamNameDisplay 10
     DisplayLowerB3         TCPFXParamValueDisplay 10
     RotaryB3               TCPFXParam 10

     DisplayUpperB4         TCPFXParamNameDisplay 11
     DisplayLowerB4         TCPFXParamValueDisplay 11
     RotaryB4               TCPFXParam 11

     DisplayUpperB5         TCPFXParamNameDisplay 12
     DisplayLowerB5         TCPFXParamValueDisplay 12
     RotaryB5               TCPFXParam 12

     DisplayUpperB6         TCPFXParamNameDisplay 13
     DisplayLowerB6         TCPFXParamValueDisplay 13
     RotaryB6               TCPFXParam 13

     DisplayUpperB7         TCPFXParamNameDisplay 14
     DisplayLowerB7         TCPFXParamValueDisplay 14
     RotaryB7               TCPFXParam 14

     DisplayUpperB8         TCPFXParamNameDisplay 15
     DisplayLowerB8         TCPFXParamValueDisplay 15
     RotaryB8               TCPFXParam 15
ZoneEnd

Here's the fx.zon that got produced...

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXRotariesA 0 1 2 3 4 5 6 7 8 9 10 11 12 15 28 29
ZoneEnd

I was hoping for...

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXRotariesA 0 1 2 3 4 5 6 7 
        FXRotariesB 8 9 10 11 12 15 28 29
ZoneEnd

Since Reaper orders the mappings based on FXParam # number anyway, for small FX, you'd be better off just using the AutoFXMapping. There's really no benefit to this approach for plugins less than 16 params. But for larger FX, where you only want to map 8 or 16 out of hundreds of params, this approach is preferable for obvious reasons.

[Funkybot]

Note: if I do this manually, it works!

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
ZoneEnd

...so I think the creation process just needs to figure out how to produce that output. The output itself already works as-is.

[Funkybot]

More thoughts:

We had discussed months ago, the idea of using an FXMapTemplate.txt file for Auto-Mapping. I think this implementation looks to be 80% (or more) of the way there.

I'm not sure how the internals of this work, but I think what might make sense:

1. Rename SelectedTrackTCPFX.zon to something like "FXMapTemplate.zon"

2. Instead of looking at the .mst for widgets named Rotary1, RotaryA1, DisplayUpper1, etc., scan the FXMapTemplate file for the widget list and groupings (by "grouping" I mean, FXParam 0, FXParamValueDisplay 0, FXParamNameDisplay 0 are one grouping).

3. Create a widget index based in CSI's memory based on what's in the FXZoneTemplate file.

4. Assign the params in order based on the FXMapTemplate (might even need just a single list in the final output zone and have the assignment happen on load).

This way, if I only want to map to the A and B rows, and have it stop before C and D rows of the Twister, I can. If MixMonkey wants to map A-D rows for his C4, he can. X-Touch users just want to map 8 rotaries, they can. Each surface would have a different FXMapTemplate.zon that made sense for that surface.

Then do the same thing for the AutoMapping generation! The output .zon's could just look like this:

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXParamsList 0 1 2 3 4 5 6 7 8 9 10 11 12 15 28 29
ZoneEnd

Just my random thought on this approach.

[Geoff Waddington]

Originally Posted by Funkybot

Hi Geoff, very cool. Use Reaper itself to be the mapping front-end. Only downside to this approach: Reaper doesn't allow you to re-order the TCP FX Params best I can tell. It just puts them in the order they appear on the automation list. But a user could do that after the fact by editing the text file.

Yup, known limitation.

Originally Posted by Funkybot

1. FXParamAliasesCache.txt didn't get updated for the first 2 FX I mapped that had aliased params - it did for the third and forth. No idea why it didn't take for the others. Maybe I had the file open or something. I'll keep an eye on that.

Make sure you hit GoSelectedTrackTCPFX before you start naming aliases.

Originally Posted by Funkybot

2. It still just creates a single row of Rotaries despite what's defined in the zone. Probably a known limitation for now while you get things working but wanted to make you aware just in case.

Yup, baby steps...

Originally Posted by Funkybot

Since Reaper orders the mappings based on FXParam # number anyway, for small FX, you'd be better off just using the AutoFXMapping. There's really no benefit to this approach for plugins less than 16 params. But for larger FX, where you only want to map 8 or 16 out of hundreds of params, this approach is preferable for obvious reasons.

Well except you lose the alias capabilities.

Also, it's useful even for something as "simple" as the UAD Ampeg SVT, where the front panel controls (Volume, Treble, Bass, etc.) start up around param 14 or so.

[Geoff Waddington]

Originally Posted by Funkybot

More thoughts:

We had discussed months ago, the idea of using an FXMapTemplate.txt file for Auto-Mapping. I think this implementation looks to be 80% (or more) of the way there.

I'm not sure how the internals of this work, but I think what might make sense:

1. Rename SelectedTrackTCPFX.zon to something like "FXMapTemplate.zon"

Well, except that you don't have to use it just for mapping, it's useful as it stands, if you like the workflow of defining TCPFX, saving the project and just using the generic SelectedTrackTCPFX Zone.

Maybe it's best to have both.

Originally Posted by Funkybot

2. Instead of looking at the .mst for widgets named Rotary1, RotaryA1, DisplayUpper1, etc., scan the FXMapTemplate file for the widget list and groupings (by "grouping" I mean, FXParam 0, FXParamValueDisplay 0, FXParamNameDisplay 0 are one grouping).

3. Create a widget index based in CSI's memory based on what's in the FXZoneTemplate file.

4. Assign the params in order based on the FXMapTemplate (might even need just a single list in the final output zone and have the assignment happen on load).

This way, if I only want to map to the A and B rows, and have it stop before C and D rows of the Twister, I can. If MixMonkey wants to map A-D rows for his C4, he can. X-Touch users just want to map 8 rotaries, they can. Each surface would have a different FXMapTemplate.zon that made sense for that surface.

Then do the same thing for the AutoMapping generation! The output .zon's could just look like this:

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXParamsList 0 1 2 3 4 5 6 7 8 9 10 11 12 15 28 29
ZoneEnd

Just my random thought on this approach.

All good ideas, more or less along the lines I'm thinking for expansion.

[Funkybot]

Originally Posted by Geoff Waddington

All good ideas, more or less along the lines I'm thinking for expansion.

The added benefit to having a single FXParamList like this and then having it mapped according to some version of a template.zon file (e.g. SelectedTrackTCPFX.zon) is that the resulting FX.zon's would also then become portable from one surface to another completely different surface since they don't include any reference to widget names.

So if we started with an output file from this process that looked like this...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXParamsList 0 1 2 3 4 5 6 7 8 9 10 11 12 15 28 29
ZoneEnd

And then CSI just mapped those thusly according to my SelectedTrackTCPFX.zon file to effectively create this mapping (i.e. CSI isn't creating a zon file for this - but it's effectively what's happening behind the scenes)...

Zone "VST: Blackhole (Eventide)" "Blackhole"

     DisplayUpperA1         FXParamNameDisplay 0
     DisplayLowerA1         FXParamValueDisplay 0
     RotaryA1               FXParam 0

     DisplayUpperA2         FXParamNameDisplay 1
     DisplayLowerA2         FXParamValueDisplay 1
     RotaryA2               FXParam 1

     DisplayUpperA3         FXParamNameDisplay 2
     DisplayLowerA3         FXParamValueDisplay 2
     RotaryA3               FXParam 2

     DisplayUpperA4         FXParamNameDisplay 3
     DisplayLowerA4         FXParamValueDisplay 3
     RotaryA4               FXParam 3

     DisplayUpperA5         FXParamNameDisplay 4
     DisplayLowerA5         FXParamValueDisplay 4
     RotaryA5               FXParam 4

     DisplayUpperA6         FXParamNameDisplay 5
     DisplayLowerA6         FXParamValueDisplay 5
     RotaryA6               FXParam 5

     DisplayUpperA7         FXParamNameDisplay 6
     DisplayLowerA7         FXParamValueDisplay 6
     RotaryA7               FXParam 6

     DisplayUpperA8         FXParamNameDisplay 7
     DisplayLowerA8         FXParamValueDisplay 7
     RotaryA8               FXParam 7

     DisplayUpperB1         FXParamNameDisplay 8
     DisplayLowerB1         FXParamValueDisplay 8
     RotaryB1               FXParam 8

     DisplayUpperB2         FXParamNameDisplay 9
     DisplayLowerB2         FXParamValueDisplay 9
     RotaryB2               FXParam 9

     DisplayUpperB3         FXParamNameDisplay 10
     DisplayLowerB3         FXParamValueDisplay 10
     RotaryB3               FXParam 10

     DisplayUpperB4         FXParamNameDisplay 11
     DisplayLowerB4         FXParamValueDisplay 11
     RotaryB4               FXParam 11

     DisplayUpperB5         FXParamNameDisplay 12
     DisplayLowerB5         FXParamValueDisplay 12
     RotaryB5               FXParam 12

     DisplayUpperB6         FXParamNameDisplay 15
     DisplayLowerB6         FXParamValueDisplay 15
     RotaryB6               FXParam 15

     DisplayUpperB7         FXParamNameDisplay 28
     DisplayLowerB7         FXParamValueDisplay 28
     RotaryB7               FXParam 28

     DisplayUpperB8         FXParamNameDisplay 29
     DisplayLowerB8         FXParamValueDisplay 29
     RotaryB8               FXParam 29
ZoneEnd

...then that same starting .zon file would effectively create this on an X-Touch/MCU...

Zone "VST: Blackhole (Eventide)" "Blackhole"

     DisplayUpper1         FXParamNameDisplay 0
     DisplayLower1         FXParamValueDisplay 0
     Rotary1               FXParam 0

     DisplayUpper2         FXParamNameDisplay 1
     DisplayLower2         FXParamValueDisplay 1
     Rotary2               FXParam 1

     DisplayUpper3         FXParamNameDisplay 2
     DisplayLower3         FXParamValueDisplay 2
     Rotary3               FXParam 2

     DisplayUpper4         FXParamNameDisplay 3
     DisplayLower4         FXParamValueDisplay 3
     Rotary4               FXParam 3

     DisplayUpper5         FXParamNameDisplay 4
     DisplayLower5         FXParamValueDisplay 4
     Rotary5               FXParam 4

     DisplayUpper6         FXParamNameDisplay 5
     DisplayLower6         FXParamValueDisplay 5
     Rotary6               FXParam 5

     DisplayUpper7         FXParamNameDisplay 6
     DisplayLower7         FXParamValueDisplay 6
     Rotary7               FXParam 6

     DisplayUpper8         FXParamNameDisplay 7
     DisplayLower8         FXParamValueDisplay 7
     Rotary8               FXParam 7

ZoneEnd

...so the mappings become surface agnostic. CSI is just kind of populating the FX list into a template file. Just front-load the fx.zon's with most important params for mapping and share your zones with the world. It wouldn't matter if you called your widgets Rotary1 or RotaryA1, it would work regardless.

[Geoff Waddington]

Originally Posted by Funkybot

The added benefit to having a single FXParamList like this and then having it mapped according to some version of a template.zon file (e.g. SelectedTrackTCPFX.zon) is that the resulting FX.zon's would also then become portable from one surface to another completely different surface since they don't include any reference to widget names.

So if we started with an output file from this process that looked like this...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXParamsList 0 1 2 3 4 5 6 7 8 9 10 11 12 15 28 29
ZoneEnd

And then CSI just mapped those thusly according to my SelectedTrackTCPFX.zon file to effectively create this mapping (i.e. CSI isn't creating a zon file for this - but it's effectively what's happening behind the scenes)...

...so the mappings become surface agnostic. CSI is just kind of populating the FX list into a template file. Just front-load the fx.zon's with most important params for mapping and share your zones with the world. It wouldn't matter if you called your widgets Rotary1 or RotaryA1, it would work regardless.

It seems like a laudable goal, but we've tried this many times over the last 6 years and always end up at a place where these kinds of concepts don't actually translate that well between surfaces.

The original idea, 6 years ago, was to be able to define a Zone and have it usable amongst all surfaces, it just refused to work.

Maybe I'm jaded because of that experience...

[MixMonkey]

Originally Posted by Geoff Waddington

New build is up.

CSI Support Files.zip

CSI Exp.zip

Implemented BuildSelectedTrackTCPFXZone.

First draft, but have to admit, I’m totally psyched !

Working nicely here! Excellent stuff Geoff!

Thinking about moving this forward, it might be better to think in terms of a person with a single surface (say an XTouch) and focus on extracting the maximum amount of utility from those 8 Rotaries/Pushes/Displays. I think this is going to benefit more people than immediately pursuing separate multi row controllers.

To that end:
i)How about a way of banking successive groups of 8 parameters?

ii) The first thing people will want to do is re-order the controls. How about printing the Raw FX Zone data (commented out) at the end of the generated Zone? That way, when they open the text file, they have a ready made guide to the parameter indicies.

iii) It would be great if it was possible to add additional rows of parameters to the generated Zone that corresponded to Modifiers. Something like:

Zone "VST: SomePlugin" "SPlug"
	FXRotaries       0 1 2  3  4  5  6  7 
        Shift+FXRotaries 8 9 10 11 12 15 16 18
ZoneEnd

....in combination with being able to to bank groups of 8 parameters, that would make those 8 rotaries pretty powerful

[Geoff Waddington]

Originally Posted by MixMonkey

Working nicely here! Excellent stuff Geoff!

Thinking about moving this forward, it might be better to think in terms of a person with a single surface (say an XTouch) and focus on extracting the maximum amount of utility from those 8 Rotaries/Pushes/Displays. I think this is going to benefit more people than immediately pursuing separate multi row controllers.

To that end:
i)How about a way of banking successive groups of 8 parameters?

ii) The first thing people will want to do is re-order the controls. How about printing the Raw FX Zone data (commented out) at the end of the generated Zone? That way, when they open the text file, they have a ready made guide to the parameter indicies.

iii) It would be great if it was possible to add additional rows of parameters to the generated Zone that corresponded to Modifiers. Something like:

Zone "VST: SomePlugin" "SPlug"
	FXRotaries       0 1 2  3  4  5  6  7 
        Shift+FXRotaries 8 9 10 11 12 15 16 18
ZoneEnd

....in combination with being able to to bank groups of 8 parameters, that would make those 8 rotaries pretty powerful

Agree totally !

The one thing I hadn't considered was writing out the param aliases, great idea, will implement !

Yup, struggling with how to map banks, modifiers, multiple rows, etc.

Still thinking...

[Geoff Waddington]

Ok, let's synthesize todays' thoughts.

First off, let's remember we can always "make our money the old fashioned way, by earning it" !

CSI allows for very complex Zone definitions, as long as you are willing to roll up your sleeves.

This is not that.

It's a way to quickly generate Zones with minimal futzing around.

Let's drop the banking idea, you almost always want to navigate FX Zones a page at a time conceptually, that's how most people use SubZones.

If you think of it there is really little difference between row based devices (C4, SCE24) and modifier based devices (MCU), they both just provide a means to view different pages of the FX layout.

Let's make it more concrete.

Let's limit the max layout to 4 rows -- e.g. a C4 allows for 32 parameters, that's plenty for the simple, quick FX Zone definition method.

Ok so in effect:

A
B
C
D

is equivalent to:

Shift
Option
Control
Alt

First off, I really like Funkybot's idea of separating the SelectedTrackTCPFX Zone from FXTemplate Zones.

I also like MixMonkey's modifiers idea.

Now we just need a way to author said Zones.

I propose we add one more major Action -- there will be a few ancillary ones, but that's just deets.

The new Action is SaveTCPFXRow.

Leaving out those ancillary deets, the basic workflow is:

Do what we have now, but don't push BuildSelectedTrackTCPFXZone.

Instead push SaveTCPFXRow -- this will have flavours -- either A, B, C, D or Shift, Option, Control, Alt.

Remove the TCPFX panel definitions and start again, defining the next row.

When done, push SaveTCPFXRow.

When you have finished defining all 4 rows (or however many you wish), finally push BuildSelectedTrackTCPFXZone.

The output will look something like Funkybot verified as operational:

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
ZoneEnd

It's a start, the floor is open...

[Funkybot]

That all sounds great to me! 4 rows is a fine limitation.

I'd recommend doing this via Reaper action versus CSI actions though. I wasn't clear on which type you meant, but I think Reaper actions are the way to go because it doesn't require giving up surface real-estate for it.

[Geoff Waddington]

Originally Posted by Funkybot

That all sounds great to me! 4 rows is a fine limitation.

I'd recommend doing this via Reaper action versus CSI actions though. I wasn't clear on which type you meant, but I think Reaper actions are the way to go because it doesn't require giving up surface real-estate for it.

Good point, although the only way I know of registering Reaper Actions requires shortcut key definitions, which are in short supply, maybe we can find some.

As far as surface real-estate, I was thinking:

    User         BuildSelectedTrackTCPFXZone
    Shift+User   SaveTCPFXRow Shift
    Option+User  SaveTCPFXRow Option
    Control+User SaveTCPFXRow Control
    Alt+User     SaveTCPFXRow Alt

and

    User         BuildSelectedTrackTCPFXZone
    Shift+User   SaveTCPFXRow A
    Option+User  SaveTCPFXRow B
    Control+User SaveTCPFXRow C
    Alt+User     SaveTCPFXRow D

That's one of the deets I was referring to.

[Funkybot]

How would you build a Shift+RowC for example?

[MixMonkey]

Originally Posted by Geoff Waddington

CSI allows for very complex Zone definitions, as long as you are willing to roll up your sleeves.

This is not that.
It's a way to quickly generate Zones with minimal futzing around.

Agreed.

Let's drop the banking idea, you almost always want to navigate FX Zones a page at a time conceptually, that's how most people use SubZones.

I suspect we mean different things by "banking". I was referring to navigating a page of 8 parameters at a time. I think you do too

If you think of it there is really little difference between row based devices (C4, SCE24) and modifier based devices (MCU), they both just provide a means to view different pages of the FX layout.

I think if we are going to get modifiers involved they should function the same as the rest of CSI, ie in addition to any page of parameters on either type of device.

Let's limit the max layout to 4 rows -- e.g. a C4 allows for 32 parameters, that's plenty for the simple, quick FX Zone definition method.

Agree. Ideally, modifiers would be in addition to this, but if you want to cap at 32, that's fine.

Ok so in effect:

A
B
C
D

is equivalent to:

Shift
Option
Control
Alt[

I really wouldn't use modifiers if they're not going to function in the same manner as the rest of CSI. Pick another way to navigate the 4 x 8 groups if the cap is 32.

First off, I really like Funkybot's idea of separating the SelectedTrackTCPFX Zone from FXTemplate Zones.

Me too Much less confusing.

I also like MixMonkey's modifiers idea.

I only like @mixmonkeys modifier idea if it's in addition to the 4 x 8 groups

Now we just need a way to author said Zones.

I propose we add one more major Action -- there will be a few ancillary ones, but that's just deets.

The new Action is SaveTCPFXRow.

Leaving out those ancillary deets, the basic workflow is:

Do what we have now, but don't push BuildSelectedTrackTCPFXZone.

Instead push SaveTCPFXRow -- this will have flavours -- either A, B, C, D or Shift, Option, Control, Alt.

Remove the TCPFX panel definitions and start again, defining the next row.

When done, push SaveTCPFXRow.

When you have finished defining all 4 rows (or however many you wish), finally push BuildSelectedTrackTCPFXZone.

The output will look something like Funkybot verified as operational:

Zone "VST: Blackhole (Eventide)" "Black-hole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
ZoneEnd

Sounds good! Build it up row by row. Would it be possible to clear for the next row by removing and re-inserting the plugin?

[Geoff Waddington]

Originally Posted by Funkybot

How would you build a Shift+RowC for example?

You wouldn't using this method -- you just exceeded the 32 param limit.

Don't know if you're a Seinfeld fan, but "No Shift for you -- two weeks !"

[MixMonkey]

Originally Posted by Geoff Waddington

You wouldn't using this method -- you just exceeded the 32 param limit.

Don't know if you're a Seinfeld fan, but "No Shift for you -- two weeks !"

Shift Na*i

[Funkybot]

Originally Posted by Geoff Waddington

You wouldn't using this method -- you just exceeded the 32 param limit.

Don't know if you're a Seinfeld fan, but "No Shift for you -- two weeks !"

Not to be overly technical but imagine a 3 row surface like the SCE-24:

A
B
C
Shift+C

Or, more realistically, I want to map the 16 encoders of the MFTwister twice:

A
B
ShiftA
ShiftB

...I get that's not what you were thinking but figure it's better to raise these use-cases now versus later in case there's a way to make that possible. If it's overthinking it, no worries.

[Geoff Waddington]

Originally Posted by MixMonkey

I suspect we mean different things by "banking". I was referring to navigating a page of 8 parameters at a time. I think you do too

Correct.

Originally Posted by MixMonkey

I think if we are going to get modifiers involved they should function the same as the rest of CSI, ie in addition to any page of parameters on either type of device.

Hmmm... maybe.

Originally Posted by MixMonkey

Agree. Ideally, modifiers would be in addition to this, but if you want to cap at 32, that's fine.

Well.. perhaps.

Originally Posted by MixMonkey

I really wouldn't use modifiers if they're not going to function in the same manner as the rest of CSI. Pick another way to navigate the 4 x 8 groups if the cap is 32.

OK, Ok, you've convinced me

Originally Posted by MixMonkey

Sounds good! Build it up row by row. Would it be possible to clear for the next row by removing and re-inserting the plugin?

Yes, I believe so.

[Geoff Waddington]

Originally Posted by Funkybot

Not to be overly technical but imagine a 3 row surface like the SCE-24:

A
B
C
Shift+C

Or, more realistically, I want to map the 16 encoders of the MFTwister twice:

A
B
ShiftA
ShiftB

...I get that's not what you were thinking but figure it's better to raise these use-cases now versus later in case there's a way to make that possible. If it's overthinking it, no worries.

I actually think there is an even better solution.

I know of no common surfaces where the encoders lack a push top switch.

Riffing off of MixMonkey's modifiers are verboten here statement because they're inconsistent, I thought of the following.

We use the push top to Toggle between Pan and Width.

Why not just count up the rows and use the push top to cycle through them ?

That's more consistent.

That would eliminate any cap as well, the sky's the limit.

On a multi row surface, that really opens up the possibilities.

[MixMonkey]

Originally Posted by Geoff Waddington

I actually think there is an even better solution.

I know of no common surfaces where the encoders lack a push top switch.

Riffing off of MixMonkey's modifiers are verboten here statement because they're inconsistent, I thought of the following.

We use the push top to Toggle between Pan and Width.

Why not just count up the rows and use the push top to cycle through them ?

That's more consistent.

That would eliminate any cap as well, the sky's the limit.

On a multi row surface, that really opens up the possibilities.

Whilst it undoubtably expands the number of avaiable parameters, I was kinda hoping to get the push in the mix as a switch.

The push works on Pan/Width because it's a simple toggle. It's not nearly as ergonomic when you're stepping through 3 or more choices. The advantage of a modifier arrangement in the MCU case is that you can, in an EQ for example, have gain, frequency and Q all on the same rotary and flip between them by pressing momentary modifier keys. That's 8 full bands out of 8 rotaries.

[Geoff Waddington]

Originally Posted by MixMonkey

Whilst it undoubtably expands the number of avaiable parameters, I was kinda hoping to get the push in the mix as a switch.

The push works on Pan/Width because it's a simple toggle. It's not nearly as ergonomic when you're stepping through 3 or more choices. The advantage of a modifier arrangement in the MCU case is that you can, in an EQ for example, have gain, frequency and Q all on the same rotary and flip between them by pressing momentary modifier keys. That's 8 full bands out of 8 rotaries.

OK, so you're reversing your position ?

Modifiers are OK for this usage ?

If so I agree, and indeed it was the EQ example I was envisioning.

[Funkybot]

Originally Posted by Geoff Waddington

OK, so you're reversing your position ?

Modifiers are OK for this usage ?

Will this work like FX.zon's classic outside of the top rows? Maybe we're over thinking this. Maybe we use this for quick and dirty maps, limit 4 rows. If you need more, want to add shift, then do that manually by editing the zone files yourself. Focus on just getting autofx zones created quickly, or using TCPFXZone method to get a basic mapping created quickly, then manually adding to these yourself.


So CSI produces only this.

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
ZoneEnd

And if I want to change it, I can add to the bottom using classic fx zone syntax...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29


Shift+RotaryA        FXParam 13
RotaryPushA          FXparam 14
Shift+RotaryPushA    FXParam 16

...

ZoneEnd

Or allow this, where users can edit this file manually for modifiers...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
        Shift+FXRotariesA 13 14 16 17 18 19 20 21

ZoneEnd

Either approach will require editing files manually to get the more advanced features, but again, if we focus the design on "simple and automatic," that will cover most use-cases and the manual options would be for more advanced users who can edit a zone file.

[MixMonkey]

Originally Posted by Geoff Waddington

OK, so you're reversing your position ?

It hasn't changed

Modifiers are OK for this usage ?

They're fine as long as they behave the same as they do in the rest of CSI. Each parameter can have a Shift/Option/Control/Alt version and the modifier combos. If that doesn't fit into the TCPFX architecture then it's better not to use them.

[Geoff Waddington]

Originally Posted by Funkybot

Will this work like FX.zon's classic outside of the top rows? Maybe we're over thinking this. Maybe we use this for quick and dirty maps, limit 4 rows. If you need more, want to add shift, then do that manually by editing the zone files yourself. Focus on just getting autofx zones created quickly, or using TCPFXZone method to get a basic mapping created quickly, then manually adding to these yourself.


So CSI produces only this.

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
ZoneEnd

And if I want to change it, I can add to the bottom using classic fx zone syntax...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29


Shift+RotaryA        FXParam 13
RotaryPushA          FXparam 14
Shift+RotaryPushA    FXParam 16

...

ZoneEnd

Or allow this, where users can edit this file manually for modifiers...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
        Shift+FXRotariesA 13 14 16 17 18 19 20 21

ZoneEnd

Either approach will require editing files manually to get the more advanced features, but again, if we focus the design on "simple and automatic," that will cover most use-cases and the manual options would be for more advanced users who can edit a zone file.

Yes, the rest of the Zone can be defined any way you want.

[MixMonkey]

Originally Posted by Funkybot

Or allow this, where users can edit this file manually for modifiers...

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
        Shift+FXRotariesA 13 14 16 17 18 19 20 21
ZoneEnd

This is how I envisioned it working, as a simple edit after the fact. The modifier added to a row name and a set of parameter numbers.

[Geoff Waddington]

Originally Posted by MixMonkey

It hasn't changed


They're fine as long as they behave the same as they do in the rest of CSI. Each parameter can have a Shift/Option/Control/Alt version and the modifier combos. If that doesn't fit into the TCPFX architecture then it's better not to use them.

Ok, I think we're in "violent agreement" again

If you have a row based surface you use the A, B, C, D method.

You can see the results of all mappings simultaneously, because you have multiple rows.

If you have an MCU based surface the 4 rows are simulated by the modifiers.

You can't see the mappings simultaneously, of course, but you can access them easily via the modifiers.

Did I explain it any better ?

[Geoff Waddington]

Originally Posted by MixMonkey

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
        Shift+FXRotariesA 13 14 16 17 18 19 20 21
ZoneEnd

This is how I envisioned it working, as a simple edit after the fact. The modifier added to a row name and a set of parameter numbers.

Not the way I'm envisioning it.

If you want modifier behaviour with row based surfaces, you have to manually define it.

Basically the choices are this type for multi row surfaces:

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
        FXRotariesC ...
        FXRotariesD ...
ZoneEnd

or this type for single row surfaces:

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotaries 0 1 2 3 4 5 6 7
	FXRotariesShift 8 9 10 11 12 15 28 29
	FXRotariesOption ...
	FXRotariesControl ...
	FXRotariesAlt ...
ZoneEnd

like that.

It boils down to 2 ways to express an 8x4 matrix, our cap of 32 for the quick and easy method -- well actually 40 for the modifiers method

[MixMonkey]

Originally Posted by Geoff Waddington

Not the way I'm envisioning it.

If you want modifier behaviour with row based surfaces, you have to manually define it.

Basically the choices are this type for multi row surfaces:

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotariesA 0 1 2 3 4 5 6 7
	FXRotariesB 8 9 10 11 12 15 28 29
        FXRotariesC ...
        FXRotariesD ...
ZoneEnd

or this type for single row surfaces:

Zone "VST: Blackhole (Eventide)" "Blackhole"
	FXRotaries 0 1 2 3 4 5 6 7
	FXRotariesShift 8 9 10 11 12 15 28 29
	FXRotariesOption ...
ZoneEnd

like that.

That's cool So here's a 32 parameter limit for this method and on a single row device, the three 'hidden' rows will be accessed by Shift, Option and Control but that's as far as the modifier behaviour goes. Can pushes be switches?