Control Surface Integration (CSI) Technical Feature Discussion

[MixMonkey]

Originally Posted by Geoff Waddington

That's a relief, I was nowhere near code that should have affected that

Please describe the offset bug in detail, I'll tackle that next.

Simple really, the channel start position that you set in the prefs to arrange the order of your surfaces (in terms of track layout) also impacts the sends and receives that are displayed using SelectedTrackSend.

In my case, the surface order and (channel start positions) are:
XT#1 (0) / MCU (8) / XT#2 (16) / XT#3 (24)

With that arrangement, if I only have a SelectedTrackSend/Receive Zone defined for the MCU (but not the XT) the MCU will display sends starting from send 9 on the selected track. In previous versions of CSI, the MCU would display sends from send 1 and I could bank to sends 9-16 and beyond if needed.

Currently, the only way to get at sends 1-8 is to define a SelectedTrackSend Zone for the XT and then I get sends 1-8 on XT#1, sends 9-16 on the MCU, sends 17-24 on XT#2 and sends 25-32 on XT#3.

Depending on how you look at it, this is either a bug or a feature.

The reason I only want to use the MCU for sends is that:
i) I rarely use more than 8 and if I do I can bank on the MCU.
ii) I only use the MCU sends to write automation and the MCU is nearer to me than XT#1. All the rest of the time I use the SelectedTrackSends displayed on the C4.

For me it would make more sense for the channel start position to only affect the send layout if SelectedTrackSend was defined for more than one surface.

[MT4U]

Originally Posted by MixMonkey

Simple really, the channel start position that you set in the prefs to arrange the order of your surfaces (in terms of track layout) also impacts the sends and receives that are displayed using SelectedTrackSend.

In my case, the surface order and (channel start positions) are:
XT#1 (0) / MCU (8) / XT#2 (16) / XT#3 (24)

With that arrangement, if I only have a SelectedTrackSend/Receive Zone defined for the MCU (but not the XT) the MCU will display sends starting from send 9 on the selected track. In previous versions of CSI, the MCU would display sends from send 1 and I could bank to sends 9-16 and beyond if needed.

Currently, the only way to get at sends 1-8 is to define a SelectedTrackSend Zone for the XT and then I get sends 1-8 on XT#1, sends 9-16 on the MCU, sends 17-24 on XT#2 and sends 25-32 on XT#3.

Depending on how you look at it, this is either a bug or a feature.

The reason I only want to use the MCU for sends is that:
i) I rarely use more than 8 and if I do I can bank on the MCU.
ii) I only use the MCU sends to write automation and the MCU is nearer to me than XT#1. All the rest of the time I use the SelectedTrackSends displayed on the C4.

For me it would make more sense for the channel start position to only affect the send layout if SelectedTrackSend was defined for more than one surface.

Do you mean something like a surface "property" like UseMeForSends (or not), UseMeForFXMenu, etc.?

[Geoff Waddington]

Originally Posted by MixMonkey

Simple really, the channel start position that you set in the prefs to arrange the order of your surfaces (in terms of track layout) also impacts the sends and receives that are displayed using SelectedTrackSend.

In my case, the surface order and (channel start positions) are:
XT#1 (0) / MCU (8) / XT#2 (16) / XT#3 (24)

With that arrangement, if I only have a SelectedTrackSend/Receive Zone defined for the MCU (but not the XT) the MCU will display sends starting from send 9 on the selected track. In previous versions of CSI, the MCU would display sends from send 1 and I could bank to sends 9-16 and beyond if needed.

Currently, the only way to get at sends 1-8 is to define a SelectedTrackSend Zone for the XT and then I get sends 1-8 on XT#1, sends 9-16 on the MCU, sends 17-24 on XT#2 and sends 25-32 on XT#3.

Depending on how you look at it, this is either a bug or a feature.

The reason I only want to use the MCU for sends is that:
i) I rarely use more than 8 and if I do I can bank on the MCU.
ii) I only use the MCU sends to write automation and the MCU is nearer to me than XT#1. All the rest of the time I use the SelectedTrackSends displayed on the C4.

For me it would make more sense for the channel start position to only affect the send layout if Send was defined for more than one surface.

Ah, got it.

This is either a bug or a feature, as you say, and is a result of SelectedTrackSend/SelectedTrackReceive/SelectedTrackFXMenu now having the capability to span surfaces.

I can look into how hard it is to improve this, but it is a bit complicated I suspect

[MixMonkey]

Originally Posted by MT4U

Do you mean something like a surface "property" like UseMeForSends (or not), UseMeForFXMenu, etc.?

Well, we already have that in a way. If you don't want to use a surface for sends, you don't define a SelectedTrackSends Zone for it. The problem is, if you take that approach you won't be able to access the first 8 (say) sends on any surface apart from the one with channel start position 0.

[MixMonkey]

Originally Posted by Geoff Waddington

Ah, got it.

This is either a bug or a feature, as you say, and is a result of SelectedTrackSend/SelectedTrackReceive/SelectedTrackFXMenu now having the capability to span surfaces.

I can look into how hard it is to improve this, but it is a bit complicated I suspect

How about a simple offset for SelectedTrack Zones? That way we could cancel out the effect of the channel start position.

Instead of the sends starting on the surface with channel start position 0, put a simple check box on the surface section in the prefs, which when ticked causes CSI to read that surface's channel start position and offset the sends/receives/FX to the right by that amount.

Reminds me of the ToggleScrollLink offset in many ways, which allowed your selected track to appear in the centre of the surfaces rather than at the far left end.

[Geoff Waddington]

Originally Posted by MixMonkey

How about a simple offset for SelectedTrack Zones? That way we could cancel out the effect of the channel start position.

Instead of the sends starting on the surface with channel start position 0, put a simple check box on the surface section in the prefs, which when ticked causes CSI to read that surface's channel start position and offset the sends/receives/FX to the right by that amount.

Yeah, trying to keep config options to a minimum where possible.

CSI currently assigns Sends etc. on a per Surface basis.

What we need to do is make it more like Tracks, which are assigned on a per Page basis.

That way, only the surfaces which have SelectedTrack Zones would request assignments, and things would work out fine.

Now I just have to figure out the coding bit

[Geoff Waddington]

New build is up.

CSI 3.0.1

Link is below in blue.

There is now a Wiki that includes the Change Log.

Folks, please let me know what you think of this new approach, and please suggest any improvements you would like to see.

Change Log

3.0.1 -- May 26, 2023

Fix for slamming faders
Faders no longer zero when switching Zones. This means there should be no more Fader "slamming".

New Action -- ClearZone
ClearZone deactivates the current Zone and zeros all Widgets in the current Zone. Very handy if you have an 8 channel surface like an MCU, X Touch etc., that you use to map FX using FXMenu.

Typical usage:

Zone "VST: UAD Harrison 32C (Universal Audio, Inc.)" "Har32C"

	Plugin      		ClearZone
When you press Plugin you will be returned to the FXMenu.

[MixMonkey]

Originally Posted by Geoff Waddington

Yeah, trying to keep config options to a minimum where possible.

CSI currently assigns Sends etc. on a per Surface basis.

What we need to do is make it more like Tracks, which are assigned on a per Page basis.

That way, only the surfaces which have SelectedTrack Zones would request assignments, and things would work out fine.

Now I just have to figure out the coding bit

Much better idea!, not a priority The hardware sends issue is more important.

[Funkybot]

Originally Posted by Geoff Waddington

New build is up.

CSI 3.0.1

Link is below in blue.

There is now a Wiki that includes the Change Log.

Folks, please let me know what you think of this new approach, and please suggest any improvements you would like to see.

Change Log

3.0.1 -- May 26, 2023

Fix for slamming faders
Faders no longer zero when switching Zones. This means there should be no more Fader "slamming".

New Action -- ClearZone
ClearZone deactivates the current Zone and zeros all Widgets in the current Zone. Very handy if you have an 8 channel surface like an MCU, X Touch etc., that you use to map FX using FXMenu.

Typical usage:

Zone "VST: UAD Harrison 32C (Universal Audio, Inc.)" "Har32C"

	Plugin      		ClearZone
When you press Plugin you will be returned to the FXMenu.

I like this approach! Makes it much easier for me to keep up to date with releases, particularly when I haven't even had a chance yet to test a build or two like these last ones.

[Geoff Waddington]

Originally Posted by Funkybot

I like this approach! Makes it much easier for me to keep up to date with releases, particularly when I haven't even had a chance yet to test a build or two like these last ones.

Not sure, but I think this means we don't need the Change Log in the main Wiki anymore.

You could still edit the new Change Log to improve clarity, etc.

What do you think ?

[Funkybot]

Originally Posted by Geoff Waddington

Not sure, but I think this means we don't need the Change Log in the main Wiki anymore.

You could still edit the new Change Log to improve clarity, etc.

What do you think ?

I'd be curious as to the thoughts of others but the same thing occurred to me. Then I kind of landed on, it's probably still helpful to have in the main wiki since folks may already be there looking for other things and maybe I'll just copy and paste for now.

[Nick Morris]

Originally Posted by Geoff Waddington

And Sends and Receives were working prior to this change ?

sends and receives have never worked properly in CSI

[Funkybot]

Originally Posted by Nick Morris

sends and receives have never worked properly in CSI

Do you mean hardware sends/receives? If you weren't using hardware sends/receives, they've worked a-ok!

[Nick Morris]

Originally Posted by Funkybot

Do you mean hardware sends/receives? If you weren't using hardware sends/receives, they've worked a-ok!

Yeah probably, I always use hardware I/O so that would make sense

[MT4U]

Originally Posted by Geoff Waddington

Zone "VST: UAD Harrison 32C (Universal Audio, Inc.)" "Har32C"

Plugin ClearZone
When you press Plugin you will be returned to the FXMenu.
[/code]

Testing ClearZone here.
Environment: Extender in tracks 1-8, X-Touch in 9-16.

1) Press the Plug-In button and my SelectedTrackFXMenu is displayed starting with the Extender, and over both surfaces.

2) Select an FX Slot and both surfaces get mapped with their corresponding FX SubZones.

So far, so good. ClearZone is mapped to plug-in button inside the X-Touch FX SubZone for the selected plug-in.

3) Press the Plug-in button on the X-Touch and this happens:
- a) X-Touch goes back to the SelectedTrackFXMenu -not with the zone's defined color- but with the track colors (This happens if there are more than 8 Plug-ins, if there are less than 9, all X-Touch displays get turned off).
- b) Extender stays stuck on the mapped FX, no way out but GoHome or maybe use something like Shift+RecordArm1 with another ClearZone action mapped on the Extender itself.

4) If I press the Plug-in button again then both surfaces return to the Track Zone, so another Plug-in button press is the only way so far to get to the SelectedTrackFXMenu that doesn't involve having to press buttons on every surface.

I believe that since ClearZone is not broadcasted, another alternative I can find right now is to have SelectedTrackFXMenu restrained to the X-Touch so as to be able to select another Plug-in from the SelectedTrackFXMenu and if there are more than 8, just use paging.

I can't seem to find any difference between ClearZone and LeaveSubZone, so I was wondering if one of them could be Global, or there could be some AllSurfacesClearZone so the SelectedTrackFXMenu works properly when mapped across more than 1 surface.

***** EDIT *****
I found another way around it.
Instead of ClearZone, I used this in every FX SubZone:

  Plugin                      AllSurfacesGoHome  
  Plugin                      GoAssociatedZone SelectedTrackFXMenu

This has always been possible, but I've been avoiding it due to the all the fader shaking, but with 3.0.1 it's smooth. It just takes a little bit longer, though that maybe due to the scripts I run OnZoneActivation and my old 6700K processor

[Geoff Waddington]

Originally Posted by MT4U

Testing ClearZone here.
Environment: Extender in tracks 1-8, X-Touch in 9-16.

1) Press the Plug-In button and my SelectedTrackFXMenu is displayed starting with the Extender, and over both surfaces.

2) Select an FX Slot and both surfaces get mapped with their corresponding FX SubZones.

So far, so good. ClearZone is mapped to plug-in button inside the X-Touch FX SubZone for the selected plug-in.

3) Press the Plug-in button on the X-Touch and this happens:
- a) X-Touch goes back to the SelectedTrackFXMenu -not with the zone's defined color- but with the track colors (This happens if there are more than 8 Plug-ins, if there are less than 9, all X-Touch displays get turned off).
- b) Extender stays stuck on the mapped FX, no way out but GoHome or maybe use something like Shift+RecordArm1 with another ClearZone action mapped on the Extender itself.

4) If I press the Plug-in button again then both surfaces return to the Track Zone, so another Plug-in button press is the only way so far to get to the SelectedTrackFXMenu that doesn't involve having to press buttons on every surface.

I believe that since ClearZone is not broadcasted, another alternative I can find right now is to have SelectedTrackFXMenu restrained to the X-Touch so as to be able to select another Plug-in from the SelectedTrackFXMenu and if there are more than 8, just use paging.

I can't seem to find any difference between ClearZone and LeaveSubZone, so I was wondering if one of them could be Global, or there could be some AllSurfacesClearZone so the SelectedTrackFXMenu works properly when mapped across more than 1 surface.

***** EDIT *****
I found another way around it.
Instead of ClearZone, I used this in every FX SubZone:

  Plugin                      AllSurfacesGoHome  
  Plugin                      GoAssociatedZone SelectedTrackFXMenu

This has always been possible, but I've been avoiding it due to the all the fader shaking, but with 3.0.1 it's smooth. It just takes a little bit longer, though that maybe due to the scripts I run OnZoneActivation and my old 6700K processor

The colour issue is due to your OnDeactivation setup in the FX Zone.

I ran into this and had to set it to the FXMenu colour to get what I wanted.

Wondering if ClearZone should be global to make it equivalent to the other Zone Activation Actions ?

[edit] Looking at the code, I now think it should be renamed ClearFXSlot, and be changed to act globally, and even perhaps query the colour of FXMenu and take care of that issue as well by automatically restoring the FXMenu colour.

[MT4U]

Originally Posted by Geoff Waddington

[edit] Looking at the code, I now think it should be renamed ClearFXSlot, and be changed to act globally, and even perhaps query the colour of FXMenu and take care of that issue as well by automatically restoring the FXMenu colour.

Sounds perfect. What would the ClearFXSlot action do if the FX Zone was mapped through FocusedFX?

[Geoff Waddington]

Originally Posted by MT4U

Sounds perfect. What would the ClearFXSlot action do if the FX Zone was mapped through FocusedFX?

Nothing

I envision it only being used for FXMenu.

Focused FX is a thing unto itself, it's probably more effective to approach anything in the "Focused" world separately.

[MT4U]

Originally Posted by Geoff Waddington

Nothing

As expected. That would be great.

[Geoff Waddington]

New build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Replaced ClearZone with ClearFXSlot.

Useful for getting back to TrackFXMenu or SelectedTrackFXMenu from GoFXSlot.

I added it to my X Touch prologue, so it automatically gets added to any auto generated Zone.

Zone FXPrologue
	OnZoneActivation	SetXTouchDisplayColors Cyan
	OnZoneDeactivation	RestoreXTouchDisplayColors
	Plugin      		ClearFXSlot
ZoneEnd

Please check it out, and, if we like it, I'll release it to production.

[MT4U]

Originally Posted by Geoff Waddington

New build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Replaced ClearZone with ClearFXSlot.

Useful for getting back to TrackFXMenu or SelectedTrackFXMenu from GoFXSlot.

I added it to my X Touch prologue, so it automatically gets added to any auto generated Zone.

Zone FXPrologue
	OnZoneActivation	SetXTouchDisplayColors Cyan
	OnZoneDeactivation	RestoreXTouchDisplayColors
	Plugin      		ClearFXSlot
ZoneEnd

Please check it out, and, if we like it, I'll release it to production.

Hi. Just tested it. FXMenu colors are back to normal. Still working exclusively on the surface where the button was pressed. The rest stay in FXSlot.

[Geoff Waddington]

Originally Posted by MT4U

Hi. Just tested it. FXMenu colors are back to normal. Still working exclusively on the surface where the button was pressed. The rest stay in FXSlot.

Do the other surfaces have FxMenu Zones, that's the way it works, it goes back to FXMenu Zones, if present.

[MT4U]

Originally Posted by Geoff Waddington

Do the other surfaces have FxMenu Zones, that's the way it works, it goes back to FXMenu Zones, if present.

Yup. In fact, I get to the FXSlot by pressing a button on another surface (the extender) since there are less than 9 on the chain and the X-Touch starts in track 9.

[Geoff Waddington]

Originally Posted by MT4U

Yup. In fact, I get to the FXSlot by pressing a button on another surface (the extender) since there are less than 9 on the chain and the X-Touch starts in track 9.

Ah, I think I see the problem, stay tuned...

[Geoff Waddington]

New build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Possible fix for ClearFXSlot multi Surface bug.

[MT4U]

Originally Posted by Geoff Waddington

New build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Possible fix for ClearFXSlot multi Surface bug.

All good on the multi front! Thanks a lot, Geoff.

This is great for surfaces without dedicated buttons other than the tracks (Extenders).

[Geoff Waddington]

Ok, ClearZone is history.

Should we now add clear Zone Actions for the remaining Zones ?

FX Parameter Zone
Focused FX Zone
Selected Track FX Zones

We don't need anything for Associated Zones, they are "radio buttoned" already.

[MixMonkey]

Originally Posted by Geoff Waddington

Ok, ClearZone is history.

Should we now add clear Zone Actions for the remaining Zones ?

FX Parameter Zone
Focused FX Zone
Selected Track FX Zones

We don't need anything for Associated Zones, they are "radio buttoned" already.

These all sound like a good idea.

FX Parameter Zone because it's very easy to move to a different track unaware that the focused fx parameter is still controlling the track you just left.

Would ClearFocusedFXZone go some way to solving the Focused FX unmapping issue?

Does SelectedTrackFX still work?

[Geoff Waddington]

Originally Posted by MixMonkey

These all sound like a good idea.

FX Parameter Zone because it's very easy to move to a different track unaware that the focused fx parameter is still controlling the track you just left.

Would ClearFocusedFXZone go some way to solving the Focused FX unmapping issue?

Does SelectedTrackFX still work?

Cool.

Being able to selectively clear Zones would provide workarounds for any anomalous behaviour

I don't have a Console 1, C4, or working SCE24 right now so I can't check thoroughly, but the GoSelectedTrackFX code executes properly.

Note that this is not an Associated Zone, so the Action is named GoSelectedTrackFX.

[MixMonkey]

Originally Posted by Geoff Waddington

Note that this is not an Associated Zone, so the Action is named GoSelectedTrackFX.

Ok, let me check that out and get back to you.

On a related note, is it a lot of work to create a GoFXSlot1 (2,3,etc) command? So that a particular FX slot could be loaded automatically on track selection, but the FX menu remain usable.

[Geoff Waddington]

Originally Posted by MixMonkey

Ok, let me check that out and get back to you.

On a related note, is it a lot of work to create a GoFXSlot1 (2,3,etc) command? So that a particular FX slot could be loaded automatically on track selection, but the FX menu remain usable.

Kind of in between FXMenu and GoSelectedTrackFX ?

Need to understand the use case a bit more.

[MixMonkey]

Originally Posted by Geoff Waddington

Kind of in between FXMenu and GoSelectedTrackFX ?

Need to understand the use case a bit more.

The attraction of GoSelectedTrackFX is less that it maps all the FX on a track, but that it is capable of doing so OnTrackSelection, no further button pushes necessary. The disadvantages of GoSelectedTrackFX, clearly, are that you have to be very careful with your FX mapping to avoid collisions and this renders it almost useless with auto FX mapping.

The FX menu avoids these issues but lacks the ability to load a single FX on track selection automatically. I would imagine that FX would be a channel strip of some kind, which may very well be preceeded or followed by other plugins. These other plugins would be available from the FX menu and the whole shebang would be compatible with auto FX mapping.

[Geoff Waddington]

Originally Posted by MixMonkey

The attraction of GoSelectedTrackFX is less that it maps all the FX on a track, but that it is capable of doing so OnTrackSelection, no further button pushes necessary. The disadvantages of GoSelectedTrackFX, clearly, are that you have to be very careful with your FX mapping to avoid collisions and this renders it almost useless with auto FX mapping.

The FX menu avoids these issues but lacks the ability to load a single FX on track selection automatically. I would imagine that FX would be a channel strip of some kind, which may very well be preceeded or followed by other plugins. These other plugins would be available from the FX menu and the whole shebang would be compatible with auto FX mapping.

Got it.

One feature I would like to add to auto mapping is a means to determine the category of FX -- Compressor, EQ, etc., and have different layouts for each type, thereby reducing auto map collisions substantially for surfaces like C4, Console 1, SCE24, etc.

[MT4U]

Originally Posted by Geoff Waddington

Got it.

One feature I would like to add to auto mapping is a means to determine the category of FX -- Compressor, EQ, etc., and have different layouts for each type, thereby reducing auto map collisions substantially for surfaces like C4, Console 1, SCE24, etc.

Interesting. In my mind there's been an idea for a time about mapping "standard" FX.

For example, a compressor will have (generally) attack, release, threshold, etc and the FX mapping for compressors in general could be pre-made.

Then the problem would be identifying those standard parameters in the particular FX, since there is no real standard in FX parameter naming, but once the threshold, attack, etc. have been identified then they could go straight to our pre-defined mapping.

If we could have some kind of web service for storing and sharing FX Parameter classifications... Just dreaming here...

[Geoff Waddington]

Originally Posted by MT4U

Interesting. In my mind there's been an idea for a time about mapping "standard" FX.

For example, a compressor will have (generally) attack, release, threshold, etc and the FX mapping for compressors in general could be pre-made.

Then the problem would be identifying those standard parameters in the particular FX, since there is no real standard in FX parameter naming, but once the threshold, attack, etc. have been identified then they could go straight to our pre-defined mapping.

If we could have some kind of web service for storing and sharing FX Parameter classifications... Just dreaming here...

We're dreaming the same dream

[Equitone]

Hi,
Just downloaded latest version of CSI, and my original ini file (V2) no longer works. I normally set up my ini files manually, as the setup is tricky using a screen reader. Could someone help by letting me know the new format of the ini file.
Thanks as always

[MT4U]

Originally Posted by Equitone

Hi,
Just downloaded latest version of CSI, and my original ini file (V2) no longer works. I normally set up my ini files manually, as the setup is tricky using a screen reader. Could someone help by letting me know the new format of the ini file.
Thanks as always

Hi there.

This is a standard ini for an X-Touch, maybe it will help.

Version 3.0

MidiSurface "X-Touch" 7 8 

Page "HomePage"
"X-Touch" 8 0 "X-Touch.mst" "X-Touch" "X-Touch"

[Funkybot]

Hi all, just a reminder that we've been asked to keep any device setup related discussion in the appropriate thread, which is here:

https://forum.cockos.com/showthread.php?t=278718

The goal for this thread is strictly meant to be around development: feature requests, bug reports, etc.

[Geoff Waddington]

New build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Added

ClearFocusedFXParam
ClearFocusedFX   
ClearSelectedTrackFX

Please check them out, and, if they pass, they will be added to production.

[Equitone]

Originally Posted by Funkybot

Hi all, just a reminder that we've been asked to keep any device setup related discussion in the appropriate thread, which is here:

https://forum.cockos.com/showthread.php?t=278718

The goal for this thread is strictly meant to be around development: feature requests, bug reports, etc.

Profuse apologies FB. landed in the wrong forum. Won't happen again.