Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by Mr. Green

question to all:
What does SetShowFXWindows do?

If SetShowFXWindows is on, when an FX gets mapped, the FX GUI window also shows.

Originally Posted by Mr. Green

also, do we have gain reduction feedback from Reaper? I'd like to tie that into the Console1 GR meter.

We had a prototype working, it's on the to do list.

[Mr. Green]

Originally Posted by Geoff Waddington

If SetShowFXWindows is on, when an FX gets mapped, the FX GUI window also shows.



We had a prototype working, it's on the to do list.

I've managed to get that prototype working here. Definitely responding. Looks to be about 6db low at comparative gr levels compared to it's plugin gui. Rolls over a few times when falling below 0.

edit - is there a way I can narrow it's data range?

[Geoff Waddington]

Originally Posted by Mr. Green

I've managed to get that prototype working here. Definitely responding. Looks to be about 6db low at comparative gr levels compared to it's plugin gui. Rolls over a few times when falling below 0.

edit - is there a way I can narrow it's data range?

Yeah, it's definitely unfinished, isn't much more you can do... until it gets worked on.

[Geoff Waddington]

Originally Posted by MixMonkey

Great! I'll give it a try

I'm currently wrestling with adding modifier support to the Configurator (the feature-complete goal line keeps moving everytime I get near it)

A couple of things would make it easier

i) If the modifier+SomeButton GoZone SomeFXZone could be made to work, I could forget about adding modifiers to individual parameters and just add them to the buttons controlling FX Zone switching. Result is exactly the same as adding to individual parameters except the modifier latches, meaning you only need one hand.

And/or

ii) If the modified FX Zone definitions worked if placed in a separate FX Zone file from the Parent Zone (like any other FX Zone) At the moment the definitions only work if placed in the Parent Zone.

At the moment the only way I can make it work is by adding the modified definitions to an existing FXZone file, which isn't great for re-loading because the Configurator only displays one zone at a time (and I'd kinda like it to stay that way)

I FINALLY think I understand what you are saying:

You don't mean that

modifier+SomeButton GoZone SomeFXZone

says "when modifier + SomeButton is pushed go to SomeFXZone", you mean treat all of the things in this Zone as shifted, is that right ?

If so, there are no plans to do that right now.

Doesn't a latching Shift (planned) do what you need ?

[Geoff Waddington]

Thinking about doing Latched Modifiers, MCU, C4 etc. have no lights on Shift/Control/etc. to tell you a modifier is latched, we will have to improvise.

Suggest the rude solo on MCU for ANY modifier latched.

Maybe the Split lights for 3 of the modifiers on the C4.

Or, if you have both, rude Solo for Shift, and the rest on the C4...

What say you folks ?

[MixMonkey]

Originally Posted by Geoff Waddington

I FINALLY think I understand what you are saying:

You don't mean that

modifier+SomeButton GoZone SomeFXZone

says "when modifier + SomeButton is pushed go to SomeFXZone", you mean treat all of the things in this Zone as shifted, is that right ?

If so, there are no plans to do that right now.

Doesn't a latching Shift (planned) do what you need ?

Nearly. I do mean "when modifier + SomeButton is pushed go to SomeFXZone"

If that worked, the Zone accessed via modifier+SomeButton could contain completely different parameters to those accessed via SomeButton (as you would expect).

The end result is that you can consider the parameters accessed by modifier+SomeButton "Shifted" (if you want), but really it just does what modifiers always do- make the available buttons go further. Once the Zone is accessed the parameters are inherently 'latched'

I think it's easier to access more parameters in this way than build the modified definitions into the Zone itself.

[CraigGE]

Originally Posted by AbbeH

Hello!
I'm just starting getting my xtouch mini to work with csi much thanks to CraigGE's zon and mst.

Hi AbbeH, I'm really glad you found my original files useful. I know Geoff has already replied to you but I thought you might be interested in a copy of my latest edition mst and zon files. See my signature for the download from the stash - they do work for me but are still a work-in-progress.

Hope this helps.

[Geoff Waddington]

Originally Posted by MixMonkey

Nearly. I do mean "when modifier + SomeButton is pushed go to SomeFXZone"

If that worked, the Zone accessed via modifier+SomeButton could contain completely different parameters to those accessed via SomeButton (as you would expect).

The end result is that you can consider the parameters accessed by modifier+SomeButton "Shifted" (if you want), but really it just does what modifiers always do- make the available buttons go further. Once the Zone is accessed the parameters are inherently 'latched'

I think it's easier to access more parameters in this way than build the modified definitions into the Zone itself.

Ok, so there would have to be 2 FX Zones, one for the shifted and one for the non-shifted, is that right ?

If so, there's a challenge -- we load FX by the name of the FX in the slot of interest.

We can't have 2 Zones with the same name, so we would have to figure out what to do there.

I will have to think about this a bit...

Other than perhaps ease of definition, I think what we have is fine as long as we add Latching Modifiers to relieve the 2 hands issue.

Feel free to convince me otherwise

[Geoff Waddington]

Originally Posted by CraigGE

Hi AbbeH, I'm really glad you found my original files useful. I know Geoff has already replied to you but I thought you might be interested in a copy of my latest edition mst and zon files. See my signature for the download from the stash - they do work for me but are still a work-in-progress.

Hope this helps.

Thanks for your effort !!

Mind if I include these in the build ?

[MixMonkey]

Originally Posted by Geoff Waddington

Ok, so there would have to be 2 FX Zones, one for the shifted and one for the non-shifted, is that right ?

If so, there's a challenge -- we load FX by the name of the FX in the slot of interest.

Yes, there would be 2 (or more) FX Zones and they would have different names (in just the same way as additional FX Zones (that contain a Parent Zone definition) accessed by completely different buttons do.

In this context the 'shift' applies only to access a different Zone, not to anything that Zone contains.

[Freex]

Excuse my naivety, is there not a way to have extra sheets on the configuration for the modifiers that, if you don't use them, auto to NoAction.

So all fx files would be a standard format.

SomeButton/Rotary FXParam
SomeButton/Rotary2 FXParam
........

Shift+SomeButton/Rotary FXParam
Shift+SomeButton/Rotary2 FXParam
........

Option+SomeButton/Rotary FXParam
Option+SomeButton/Rotary2 FXParam
........

Control+SomeButton/Rotary FXParam
Control+SomeButton/Rotary2 FXParam
........

Alt+SomeButton/Rotary FXParam
Alt+SomeButton/Rotary2 FXParam
.........

RawFXParams
..........

[Freex]

Originally Posted by MixMonkey

Yes, there would be 2 (or more) FX Zones and they would have different names (in just the same way as additional FX Zones (that contain a Parent Zone definition) accessed by completely different buttons do.

In this context the 'shift' applies only to access a different Zone, not to anything that Zone contains.

I'm think this would be a pain in the neck to keep track of, but.
What if you could write all the zones(main/subs/mods) separately and name them with -1,-s1,-o1,-c1,-a1, -2,-s2, -o2, -c2, -a2 on the ends.


Then in the actual fxzone, have

Vst...........
On selection/focus........

Zone includes...
-1,
-s1,
-o1,
-c1,
-a1,
-2,
-s2,
-o2,
-c2,
-a2

ZoneEnd

[MixMonkey]

Originally Posted by Freex

Excuse my naivety, is there not a way to have extra sheets on the configuration for the modifiers that, if you don't use them, auto to NoAction.

So all fx files would be a standard format.

What about combinations of modifiers? Include them as well? and the four extra zones that are already there?

I'm really trying to avoid having the Configurator load more than one Zone at a time. It's easy enough to get it to save a modifiered(is that a word?)Zone, but as you've discovered they only work if they're part of the ParentZone.

[Geoff Waddington]

Originally Posted by MixMonkey

Yes, there would be 2 (or more) FX Zones and they would have different names (in just the same way as additional FX Zones (that contain a Parent Zone definition) accessed by completely different buttons do.

In this context the 'shift' applies only to access a different Zone, not to anything that Zone contains.

So this would be a way to "drill down" faster ?

instead of having to press someButton to get to SubZone1, and then press someButton again to get to SubZone2, you could get directly to SubZone2 by pressing Shift+someButton ?

[Mr. Green]

Hey guys,
Just wanted to thank you all for your help - and Geoff in particular for his amazing endeavor!

Gonna give you guys a break for a while (from me). ;-)

I have to - you know - work and make money n stuff.

In the meantime, I've got a Console 1 Universal Control setup here that's working pretty well for my needs - enough to test it in the field anyway. I don't know how well it would fit into the workflow of other mix guys, but for any who might be interested here's the link...

https://stash.reaper.fm/36963/CSI%20...%20Control.zip

Of course any suggestions/corrections would be welcome.
Can't wait to see how much further it can go.

[MixMonkey]

Originally Posted by Geoff Waddington

So this would be a way to "drill down" faster ?

Yes, if you want to use it that way, but really it just makes a limited number of surface buttons (I have four that I use to access FX Zones) go much further. If I had 16 free buttons I wouldn't bother with modifiers at all.

In all honesty, 4 x 32 Widgets on a C4 is plenty. Plus you can access other parameter zones from within Zones (like the original soft-synth example that started all this)

I thought Freex made a good case for bringing modifiers in, they just suffer from some limitations that makes it difficult with the Configurator in it's present form.

[Geoff Waddington]

Originally Posted by MixMonkey

but really it just makes a limited number of surface buttons (I have four that I use to access FX Zones) go much further. If I had 16 free buttons I wouldn't bother with modifiers at all.

Please describe this workflow a bit more -- when you say 4 buttons, how do you use them ?

[MixMonkey]

Originally Posted by Geoff Waddington

Please describe this workflow a bit more -- when you say 4 buttons, how do you use them ?

Sure thing. That's the problem with CSI, Geoff, it's just too darn versatile. I doubt two people are going to end up using it in exactly the same way.

I use Marker, ChanStrip, Track and Function on the C4 to exclusively access different parameter Zones in the currently focussed FX.

Originally I used the whole of the C4 Surface for a focussed FX, but now with sends and the FX menu available, I 'm building maps that leave a couple of rows free, so the sends and the FX menu don't get overwritten by the FX parameters.

Each of the four buttons access a group of the single FX's parameters, so in something like Sonnox Oxford Dynamics, one button calls up the comp, another the limiter, another the gate and the last the expander. That's 8 x 2 Rotaries/Pushes for each Zone/button.

In things like the Relab480, I put the primary reverb parameters in one zone and use the others for the ER delays and filters etc.

I always map the same controls to the same widget across plugins eg in compressor plugins Threshold is always D1, Ratio D2, Attack D3, Release D4. In EQ plugins RowD is Gain, RowC Freq. You get the idea, muscle memory and all that.

The ParentZone is always assigned to the Marker button, the Zone name is always the plugin name, say VST3: Oxford Dynamics (Sonnox).The Zone file name is a legal character derived version of this. ChanStrip is always VST3: Oxford Dynamics (Sonnox)-2, Track is always VST3: Oxford Dynamics (Sonnox)-3 and Function is always VST3: Oxford Dynamics (Sonnox)-4. It's the easiest way to ensure all Zones across all plugins have a unique name and it matches up with the file name.

I have to say so far most plugins fit into the number of Zones/Widgets available. The modifiers just expand the number available beyond a reasonable doubt I'm not bothered about latching- as you point out, there are no indicators on the modifiers to show its status. I only mentioned it because it happens implicitly in the modifier+SomeButton GoZone scenario. Once the new Zone is accessed, you don't have to keep the modifier+SomeButton held down to stay in the Zone- it's latched by default.

There's no difference whether you access more parameters by building modifier definitions into the ParentZone or accessing them using modifier+SomeButton GoZone SomeAdditionalFXZone (if it worked) or by just having more buttons like Marker, ChanStrip, Track and Function to access additional FX Zones.

It's just a lot harder to build the modifier definitions into the ParentZone (and be able to reload them) in the Configurator.

[Mr. Green]

Originally Posted by Mr. Green

Hey guys,
Just wanted to thank you all for your help - and Geoff in particular for his amazing endeavor!

Gonna give you guys a break for a while (from me). ;-)

I have to - you know - work and make money n stuff.

In the meantime, I've got a Console 1 Universal Control setup here that's working pretty well for my needs - enough to test it in the field anyway. I don't know how well it would fit into the workflow of other mix guys, but for any who might be interested here's the link...

https://stash.reaper.fm/36963/CSI%20...%20Control.zip

Of course any suggestions/corrections would be welcome.
Can't wait to see how much further it can go.

lol - I've already had to go back and fix something in it.

[Geoff Waddington]

Originally Posted by MixMonkey

Sure thing. That's the problem with CSI, Geoff, it's just too darn versatile. I doubt two people are going to end up using it in exactly the same way.

I use Marker, ChanStrip, Track and Function on the C4 to exclusively access different parameter Zones in the currently focussed FX.

Originally I used the whole of the C4 Surface for a focussed FX, but now with sends and the FX menu available, I 'm building maps that leave a couple of rows free, so the sends and the FX menu don't get overwritten by the FX parameters.

Each of the four buttons access a group of the single FX's parameters, so in something like Sonnox Oxford Dynamics, one button calls up the comp, another the limiter, another the gate and the last the expander. That's 8 x 2 Rotaries/Pushes for each Zone/button.

In things like the Relab480, I put the primary reverb parameters in one zone and use the others for the ER delays and filters etc.

I always map the same controls to the same widget across plugins eg in compressor plugins Threshold is always D1, Ratio D2, Attack D3, Release D4. In EQ plugins RowD is Gain, RowC Freq. You get the idea, muscle memory and all that.

The ParentZone is always assigned to the Marker button, the Zone name is always the plugin name, say VST3: Oxford Dynamics (Sonnox).The Zone file name is a legal character derived version of this. ChanStrip is always VST3: Oxford Dynamics (Sonnox)-2, Track is always VST3: Oxford Dynamics (Sonnox)-3 and Function is always VST3: Oxford Dynamics (Sonnox)-4. It's the easiest way to ensure all Zones across all plugins have a unique name and it matches up with the file name.

I have to say so far most plugins fit into the number of Zones/Widgets available. The modifiers just expand the number available beyond a reasonable doubt I'm not bothered about latching- as you point out, there are no indicators on the modifiers to show its status. I only mentioned it because it happens implicitly in the modifier+SomeButton GoZone scenario. Once the new Zone is accessed, you don't have to keep the modifier+SomeButton held down to stay in the Zone- it's latched by default.

There's no difference whether you access more parameters by building modifier definitions into the ParentZone or accessing them using modifier+SomeButton GoZone SomeAdditionalFXZone (if it worked) or by just having more buttons like Marker, ChanStrip, Track and Function to access additional FX Zones.

It's just a lot harder to build the modifier definitions into the ParentZone (and be able to reload them) in the Configurator.

Very cool !

Might I humbly suggest the following.

If you're like me you tend to use Shift and Control, but Option and Alt not so much, especially with FX.

So, if you are willing to give those 2 up, you could get 2 latching modifier keys complete with lights by doing the following:

Marker becomes Latching Shift complete with light.

ChanStrip comes Latching Control/Command complete with light.

Now you have 6 buttons for SubZones:
Track, Shift, Option
Function, Control, Alt

Just a thought

[MixMonkey]

Originally Posted by Geoff Waddington

Very cool !

Might I humbly suggest the following.

If you're like me you tend to use Shift and Control, but Option and Alt not so much, especially with FX.

So, if you are willing to give those 2 up, you could get 2 latching modifier keys complete with lights by doing the following:

Marker becomes Latching Shift complete with light.

ChanStrip comes Latching Control/Command complete with light.

Now you have 6 buttons for SubZones:
Track, Shift, Option
Function, Control, Alt

Just a thought

Thanks for the suggestion but the issue really wasn't regarding latching or non-latching modifiers. It was how to build modifier support into the Configurator, with save and reload on a single sheet. Maybe I'll think of another way to make it work, but I'll probably leave it out for now.

I've never needed to use modifiers in the FX context. I prefer it all straight up in front of me. It makes more sense to me to call an additional Zone for more parameters than use modifiers, particularly since we can overlay Zones, with control over what shows through and what doesn't.

[Geoff Waddington]

Originally Posted by MixMonkey

Thanks for the suggestion but the issue really wasn't regarding latching or non-latching modifiers. It was how to build modifier support into the Configurator, with save and reload on a single sheet. Maybe I'll think of another way to make it work, but I'll probably leave it out for now.

Fair enough.

Originally Posted by MixMonkey

I've never needed to use modifiers in the FX context. I prefer it all straight up in front of me. It makes more sense to me to call an additional Zone for more parameters than use modifiers, particularly since we can overlay Zones, with control over what shows through and what doesn't.

Cool, what are you using Shift/Option/Control/Alt for now ?

If they are unused, you would have 8 buttons total.

[Mr. Green]

Hey Geoff,
I'm running into an issue here:
I'm noticing - in particular when I copy a plugin to another track - the parameters in the Console 1 plugin often do not match with the hardware until each knob is individually moved, "latching" things in place. Is there a setting somewhere in the midi or plugins settings I need to adjust to address this?

[arseny]

I apologize, if this is already been answered: I couldn't get familiar with the search function in this forum.

Is there a way to controll FX parameters with SSL Nucleus v1?
Does CSI work on Mac as well?

Thanks!

[Freex]

Originally Posted by arseny

I apologize, if this is already been answered: I couldn't get familiar with the search function in this forum.

Is there a way to controll FX parameters with SSL Nucleus v1?
Does CSI work on Mac as well?

Thanks!

As it uses HUI and MCU protocols, yes, the you'll be able to use it. But you'll probably have to create the surface .mst file. You can use the MCU.mst to get you started. Then adjust it where necessary.

Yes it works on mac.

Once you're up an running with basic control, you can create fx.zon files to allow you to control fx.

[arseny]

Originally Posted by Freex

As it uses HUI and MCU protocols, yes, the you'll be able to use it. But you'll probably have to create the surface .mst file. You can use the MCU.mst to get you started. Then adjust it where necessary.

Yes it works on mac.

Once you're up an running with basic control, you can create fx.zon files to allow you to control fx.

Thanks, Freex!!! I almost already wanted to sell the Nuc!

How do i create .mst file? Any tutorials on this topic?
Sorry for the noob questions.

[Geoff Waddington]

Originally Posted by arseny

I apologize, if this is already been answered: I couldn't get familiar with the search function in this forum.

Is there a way to controll FX parameters with SSL Nucleus v1?
Does CSI work on Mac as well?

Thanks!

If you haven't set up your Nucleus at all yet, here is an excellent (a bit dated) video
https://www.solid-state-logic.co.jp/...r_tutorial.pdf

Once that checks out, in CSI you will need 2 surfaces
MCU.mst -- with Midi ports set up like in the video
MCUXT.mst -- with Midi ports set up like in the video

Then you could just use the stock MCU folder for both.

Let me know how you make out.

[Geoff Waddington]

Originally Posted by Mr. Green

Hey Geoff,
I'm running into an issue here:
I'm noticing - in particular when I copy a plugin to another track - the parameters in the Console 1 plugin often do not match with the hardware until each knob is individually moved, "latching" things in place. Is there a setting somewhere in the midi or plugins settings I need to adjust to address this?

Thanks, will check it out.

[arseny]

Originally Posted by Geoff Waddington

If you haven't set up your Nucleus at all yet, here is an excellent (a bit dated) video
https://www.solid-state-logic.co.jp/...r_tutorial.pdf

Once that checks out, in CSI you will need 2 surfaces
MCU.mst -- with Midi ports set up like in the video
MCUXT.mst -- with Midi ports set up like in the video

Then you could just use the stock MCU folder for both.

Let me know how you make out.

Thanks, Geoff!
I've already set it up like in the PDF. So, the Nuc & Reaper are working together.
In order to install CSI, should I look here: https://github.com/malcolmgroves/rea...i/Installation
?

[Geoff Waddington]

Originally Posted by arseny

Thanks, Geoff!
I've already set it up like in the PDF. So, the Nuc & Reaper are working together.
In order to install CSI, should I look here: https://github.com/malcolmgroves/rea...i/Installation
?

Cool, should point out that you should uninstall the stock Reaper setup, I'm pretty sure you already knew that

There is a readme and a very short How it works doc included, have a look at those, the link info is a bit outdated.

If you have any questions, please ask away, the timing is perfect, it will help the doc endeavour.

[arseny]

Originally Posted by Geoff Waddington

Cool, should point out that you should uninstall the stock Reaper setup, I'm pretty sure you already knew that

There is a readme and a very short How it works doc included, have a look at those, the link info is a bit outdated.

If you have any questions, please ask away, the timing is perfect, it will help the doc endeavour.

No, didn't know, that I have to uninstall the stock setup, but I'll do it :-) Thanks for pointing it out.
Under the CODE tab I've downloaded the reaper_csi-master.zip
Unfortunately there's nothing in the README.md and no How it works doc file. Or I am searching at the wrong place? Thanks so much for your time.

[Geoff Waddington]

Originally Posted by arseny

No, didn't know, that I have to uninstall the stock setup, but I'll do it :-) Thanks for pointing it out.
Under the CODE tab I've downloaded the reaper_csi-master.zip
Unfortunately there's nothing in the README.md and no How it works doc file. Or I am searching at the wrong place? Thanks so much for your time.

Just use the link below in my signature

[MixMonkey]

Originally Posted by Freex

I'm think this would be a pain in the neck to keep track of, but.
What if you could write all the zones(main/subs/mods) separately and name them with -1,-s1,-o1,-c1,-a1, -2,-s2, -o2, -c2, -a2 on the ends.

I think you mean:

IncludedZones
ShiftZone
OptionZone
ControlZone
etc
IncludedZonesEnd

This would be a good and workable solution, but unfortunately, like SomeModifier+SomeButton GoZone SomeFXZone, it doesn't work

Originally Posted by Geoff Waddington

Cool, what are you using Shift/Option/Control/Alt for now ?

If they are unused, you would have 8 buttons total.

I had tried this in the past and it didn't work, but I now think that may have been because the C4 mst definitions for the modifiers were wrong. I'll try it again as this sounds like a great solution! (and the buttons are even next to the ones I already use)

[Freex]

Originally Posted by MixMonkey

I think you mean:

IncludedZones
ShiftZone
OptionZone
ControlZone
etc
IncludedZonesEnd

This would be a good and workable solution, but unfortunately, like SomeModifier+SomeButton GoZone SomeFXZone, it doesn't work

I had initially thought of using them that way, but it would mean that if you had a subFXzone, the shift from the mainFXzone would be splayed over it too, which could cause problems if it was MainFXzone specific, such as with EQs.

So to get around that I was think if you could have

VST_ FabFilter Pro-Q 3 _FabFilter.zon

Zone "VST: FabFilter Pro-Q 3 (FabFilter)" "Fab-Q3"

IncludedZones
VST_ FabFilter Pro-Q 3 _FabFilter-1.zon
VST_ FabFilter Pro-Q 3 _FabFilter-1shift.zon
VST_ FabFilter Pro-Q 3 _FabFilter-1option.zon
etc...
VST_ FabFilter Pro-Q 3 _FabFilter-2.zon
VST_ FabFilter Pro-Q 3 _FabFilter-2shift.zon
VST_ FabFilter Pro-Q 3 _FabFilter-2option.zon
etc...
EndIncludedZone

But I'm not sure if it would be any better.

If it did work, then a possible way around things for the Configurator would be to have a box that you select main, Shift, Option etc. and it puts Shift+/option+/etc... at the start of the definitions and on the end of the file name.
You would then create all your zone files in Config... and rename with 1,2...
So you'd never overwrite.
Then at the end you would manually write the ZoneFXIncludes file, and only the main and subs would need to have the GoZone button definitions as the ModZones would be non latching.

So the actual Parent Zone file would be more of an index.

That may be a little convoluted, i don't know.

Personally I quite like the non latching on the modifiers as you're always thrown back to the mainzone, or subzone, great for EQs slopes and shapes.

But as you've said, the great "problem" with CSI is it's so flexible.

[Geoff Waddington]

Originally Posted by Mr. Green

uh-oh - I think I may have just run into that alpha-tester stuff you're looking for. Lots of Reaper-crashing. Definitely CSI related. Details to follow...

edit: edit: So the crashing I was experiencing appears to have been resulting from a missing "FocusedFXTrackNavigator" from one of the fx zon files.

Thanks, nasty null pointer bug fixed in next build.

[MixMonkey]

Originally Posted by Freex

I had initially thought of using them that way, but it would mean that if you had a subFXzone, the shift from the mainFXzone would be splayed over it too, which could cause problems if it was MainFXzone specific, such as with EQs.

So to get around that I was think if you could have

Zone "VST: FabFilter Pro-Q 3 (FabFilter)" "Fab-Q3"

IncludedZones
VST_ FabFilter Pro-Q 3 _FabFilter-1.zon
VST_ FabFilter Pro-Q 3 _FabFilter-1shift.zon
VST_ FabFilter Pro-Q 3 _FabFilter-1option.zon
etc...
VST_ FabFilter Pro-Q 3 _FabFilter-2.zon
VST_ FabFilter Pro-Q 3 _FabFilter-2shift.zon
VST_ FabFilter Pro-Q 3 _FabFilter-2option.zon
etc...
EndIncludedZone

That's the same as my example and even though the modified zones are included with the ParentZone they're only active when the modifier key is pressed, but it's academic as it doesn't work

If it did work, then a possible way around things for the Configurator would be to have a box that you select main, Shift, Option etc. and it puts Shift+/option+/etc... at the start of the definitions and on the end of the file name.
You would then create all your zone files in Config... and rename with 1,2...
So you'd never overwrite.
Then at the end you would manually write the ZoneFXIncludes file, and only the main and subs would need to have the GoZone button definitions as the ModZones would be non latching.

That was my plan exactly and I even have the modifier checkbox system up and working. You put in a new name (eg usually pluginfilename-Shift), tick the Shift checkbox and it writes a new Zone with the Shifted definitions.

Unfortunately, those Shifted definitions don't work unless they are contained within the ParentZone itself. Putting them in a separate Zone and using IncludedZones...IncludedZonesEnd doesn't work.

An alternative (and better) solution would be to use the modifier on the GoZone button rather than the individual definitions and access more parameters that way. But that doesn't work either.

[Freex]

Was you're example not to have the mods go to zones, if that was the case surely that wouldn't work when you came to having a sub zone, as the ModZone would be for the MainZone and not the SubZone?

My example was to only have GoZone in the "main" and "subs" and then the ModZone would be picked up by them.

I guess then INDEX would be MAIN and SUB,
Then MAIN would have it's included ModZones
amd SUB would have it's included ModZones.

I'd personally prefer not to have the ModZones as GoZones, I think it could become a rabbits warren,



At the minute we can define MAIN and SUBS and navigate them with GoZone

If ModZones could be "included (by simply using IncludeZones" in those Zones, then you'd have better directions and pathways.

MAIN_________________>>>>GoZone SUB
(ModZones of MAIN)


SUB__________________>>>>GoZone MAIN
(ModZones of SUB)

All the ModZones of MAIN "Keep" you in MAIN and throw you back to MAIN

All the ModZones of SUBS "Keep" you in SUBS and throw you back to SUBS


So to use an analogy,
GoZone takes you to a new County,
ModZone take you to a new Town in your current County.

Two different functions.

I guess it's down to Geoff to solve this one for us

[MixMonkey]

Originally Posted by Freex

Was you're example not to have the mods go to zones, if that was the case surely that wouldn't work when you came to having a sub zone, as the ModZone would be for the MainZone and not the SubZone?

If you want Shifted functions in a SubZone, include a Shifted Zone in it. I was discussing a single Zone for clarity.

I'm afraid this is all academic because the IncludedZones..IncludedZones construct doesn't work with modified definitions.

[Geoff Waddington]

Originally Posted by MixMonkey

An alternative (and better) solution would be to use the modifier on the GoZone button rather than the individual definitions and access more parameters that way. But that doesn't work either.

Took me a while, finally had the Aha moment

Was tracing through the debugger and Shift+SomeButton GoZone someZone indeed works perfectly.

Why the heck doesn't this work ?

Because you can't let go of "Shift" fast enough

When you GoZone, you Activate the Zone and all the actions in it but -- wait for it -- since the Shift key is still pressed it will attempt to Activate the Shift versions of everything -- of which there are none

What you need are Shifted versions of each Action in addition to the Shifted Zone behaviour.

Great -- except that now you have to press Shift for every button in the Zone --- completely defeats the purpose

CSI is incredibly flexible -- aka -- also extremely hackable

Just do this, I think it will work:

Zone Parent
        Shift+someButton GoZone ChildZone
ZoneEnd

Zone ChildZone
        someButton someAction
        Shift+someButton someAction
        anotherButton anotherAction
        Shift+anotherButton anotherAction
ZoneEnd

Now when you Shift GoZone, the activation will work.

Once the Zone is activated, the normal buttons are mapped exactly the same, so they will work without the shift being pressed.

Try it out, let me know what happens.

[MixMonkey]

Originally Posted by Geoff Waddington

Took me a while, finally had the Aha moment

Was tracing through the debugger and Shift+SomeButton GoZone someZone indeed works perfectly.

Why the heck doesn't this work ?

Because you can't let go of "Shift" fast enough

When you GoZone, you Activate the Zone and all the actions in it but -- wait for it -- since the Shift key is still pressed it will attempt to Activate the Shift versions of everything -- of which there are none

What you need are Shifted versions of each Action in addition to the Shifted Zone behaviour.

Great -- except that now you have to press Shift for every button in the Zone --- completely defeats the purpose

CSI is incredibly flexible -- aka -- also extremely hackable

Just do this, I think it will work:

Zone Parent
        Shift+someButton GoZone ChildZone
ZoneEnd

Zone ChildZone
        someButton someAction
        Shift+someButton someAction
        anotherButton anotherAction
        Shift+anotherButton anotherAction
ZoneEnd

Now when you Shift GoZone, the activation will work.

Once the Zone is activated, the normal buttons are mapped exactly the same, so they will work without the shift being pressed.

Try it out, let me know what happens.

This works! Although I'm still coming to terms with what it means for Zone definitions vis a vis Configurator.

It would seem I have to add a Modifier+ definition to go with every existing unshifted definition in the child Zone. I can do that, but it would be nice to be able to declare it at the start of the ChildZone and have it apply to every definition within the Zone