Control Surface Integration (CSI) Technical Feature Discussion

[Puck]

Dumb windows user question:

Why is there a mac osx folder in the support files?

I was under the impression that the support files were all the same.

(shooting some footage right now)

[MT4U]

Originally Posted by Funkybot

Those aren't parameter steps, that's encoder acceleration.

I thought as much. Am I correct to assume that this acceleration parameters go instead of the steps, like never on the same line?

[Funkybot]

Originally Posted by MT4U

I thought as much. Am I correct to assume that this acceleration parameters go instead of the steps, like never on the same line?

I wouldn't combine them. I use either acceleration for continuous [i.e. non-stepped] parameters that I'm assigning to an encoder. And when it comes to stepped-params, I'm not going to use acceleration, I'm going to use a fixed delta value, followed by the param steps.

So like an 1176 plugin might show this for the [continuous] Input gain.

RtrA1 FXParam 0 [ (0.001,0.001,0.01,0.05,0.1,0.15,0.25,0.5) ]

But when it comes to stepped params, I'm not going to use acceleration, I'm going to usually set a delta value (the integer value in the parenthesis) followed by the step values for the stepped param.

So taking that same 1176 plugin example, I'd do something like this for the ratio buttons...

RtrA3 FXParam 4 [ (5) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 ]

In that case, the ratio button has 11 steps, and for that particular surface, I want them to change with every 5 'encoder ticks' CSI receives (the number in parenthesis). Obviously, the "(5)" is optional. If you wanted each tick to step through the params, you'd omit that.

Hope that helps explain!

[Geoff Waddington]

Originally Posted by Puck

Dumb windows user question:

Why is there a mac osx folder in the support files?

I was under the impression that the support files were all the same.

(shooting some footage right now)

You are right, the support files are all the same.

I don't see a mac osx folder in the support files, but I'm on a Mac, maybe it's hidden on Mac but visible on Windows.

What is in it ?

[MT4U]

Originally Posted by Funkybot

I wouldn't combine them. I use either acceleration for continuous [i.e. non-stepped] parameters that I'm assigning to an encoder. And when it comes to stepped-params, I'm not going to use acceleration, I'm going to use a fixed delta value, followed by the param steps.

So like an 1176 plugin might show this for the [continuous] Input gain.

RtrA1 FXParam 0 [ (0.001,0.001,0.01,0.05,0.1,0.15,0.25,0.5) ]

But when it comes to stepped params, I'm not going to use acceleration, I'm going to usually set a delta value (the integer value in the parenthesis) followed by the step values for the stepped param.

So taking that same 1176 plugin example, I'd do something like this for the ratio buttons...

RtrA3 FXParam 4 [ (5) 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 ]

In that case, the ratio button has 11 steps, and for that particular surface, I want them to change with every 5 'encoder ticks' CSI receives (the number in parenthesis). Obviously, the "(5)" is optional. If you wanted each tick to step through the params, you'd omit that.

Hope that helps explain!

If it didn’t I’d have to go back to the acoustic guitar and a tape recorder :-). Clear as water.
Thanks a lot!!!

[Puck]

Originally Posted by Geoff Waddington

You are right, the support files are all the same.

I don't see a mac osx folder in the support files, but I'm on a Mac, maybe it's hidden on Mac but visible on Windows.

What is in it ?

Now I’m away from my pc but I can explain

Top level had

CSI
Mac_OSX

Drilling into CSI was as normal

Drilling into Mac_osx revealed another identical CSI folder structure.

[Geoff Waddington]

Originally Posted by Puck

Now I’m away from my pc but I can explain

Top level had

CSI
Mac_OSX

Drilling into CSI was as normal

Drilling into Mac_osx revealed another identical CSI folder structure.

Just verified this, downloaded on my Windows machine and see exactly what you see.

Obviously Mac hides these, you can delete or ignore them.

Will try to clean this up at some point, although it is totally innocuous since Windows users would typically ignore the folder and Mac users wouldn't even see it

[Puck]

Originally Posted by Geoff Waddington

Just verified this, downloaded on my Windows machine and see exactly what you see.

Obviously Mac hides these, you can delete or ignore them.

Will try to clean this up at some point, although it is totally innocuous since Windows users would typically ignore the folder and Mac users wouldn't even see it

Totally fine!

It’s just now that I was recording a video I didn’t want to speak to the reason why it was there without actually knowing! Great to know that Mac users won’t even see that. Thanks!

Expect some rough cuts within the week for your critiques.

[jakeman19]

Originally Posted by Geoff Waddington

New build is up.

CSI Exp.zip

Ok folks you asked for it

A trial balloon to help the twitchy Track selection behaviour.

If you have Single select mode active -- often mapped as Control+Select|, you still get twitches when you deselect a Track.

But it helps with the Shift+Select| and Control+Select| scenarios.

Lord knows what else it broke

Please check all the Track selection, Track removal, Selecting a new Track with "SelectedTrackFX" Zone active, deleting FX on a selected Track, and a million other scenarios I have forgotten about

Also be aware this has the potential to cause major crashes.

Once again, you asked for it...

Geoff,

How about when one is on the home zone, when I add or remove a FX from any Track the faders twitch.

Jd

[jacksoonbrowne]

Hi Geoff,

Still working on the X32.

I have the following working

• Master Fader
• Master Mute
• Track Faders
• Track Solos
• Track Mutes

"Select| TrackUniqueSelectWithChannelNumber |" is still not working for me yet but I will leave that code for later.

I am next going to implement transport controls.
This will require that an X32 "scene" be specially configured for using the X32 with CSI.
Once I am on my way I will be able to provide a sample X32 "scene for CSI"

Cheers,
Roy Wallingford

[Funkybot]

Geoff, this might be helpful for X-Touch colored scribble strips. They can work in MCU mode by sending sysex:

https://forum.cockos.com/showpost.ph...7&postcount=43

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

Still working on the X32.

I have the following working

• Master Fader
• Master Mute
• Track Faders
• Track Solos
• Track Mutes

"Select| TrackUniqueSelectWithChannelNumber |" is still not working for me yet but I will leave that code for later.

I am next going to implement transport controls.
This will require that an X32 "scene" be specially configured for using the X32 with CSI.
Once I am on my way I will be able to provide a sample X32 "scene for CSI"

Cheers,
Roy Wallingford

Excellent !!

[Geoff Waddington]

New builds are up.

CSI Support Files.zip

CSI Exp.zip

Preliminary Track colour support for X-Touch in MCU mode.

Make sure you get the new X-Touch.mst file from the support files, as well as the dll/dylib from CSI Exp.zip.

It's a bit buggy, just want to make sure the basics work for everyone.

It does not refresh properly yet, just bank away and come back to see changes.

I have firmware version 1.21 here, it may need that or later, dunno.

The colour translations need some tuning as well.

[Funkybot]

Very cool! Wish I had an X-Touch!

[Funkybot]

Originally Posted by Geoff Waddington

New builds are up.

CSI Support Files.zip

CSI Exp.zip

Preliminary Track colour support for X-Touch in MCU mode.

Make sure you get the new X-Touch.mst file from the support files, as well as the dll/dylib from CSI Exp.zip.

It's a bit buggy, just want to make sure the basics work for everyone.

It does not refresh properly yet, just bank away and come back to see changes.

I have firmware version 1.21 here, it may need that or later, dunno.

The colour translations need some tuning as well.

Geoff,

Looking at the new .mst (I was curious), it looks like only DisplayUpper1 uses the new widget. The others still use the old MCU widget. Should they all be using FB_XTouchDisplayUpper?

Widget DisplayUpper1
	FB_XTouchDisplayUpper 0
WidgetEnd

Widget DisplayUpper2
	FB_MCUDisplayUpper 1
WidgetEnd

Widget DisplayUpper3
	FB_MCUDisplayUpper 2
WidgetEnd

Widget DisplayUpper4
	FB_MCUDisplayUpper 3
WidgetEnd

Widget DisplayUpper5
	FB_MCUDisplayUpper 4
WidgetEnd

Widget DisplayUpper6
	FB_MCUDisplayUpper 5
WidgetEnd

Widget DisplayUpper7
	FB_MCUDisplayUpper 6
WidgetEnd

Widget DisplayUpper8
	FB_MCUDisplayUpper 7
WidgetEnd

[Geoff Waddington]

Originally Posted by Funkybot

Geoff,

Looking at the new .mst (I was curious), it looks like only DisplayUpper1 uses the new widget. The others still use the old MCU widget. Should they all be using FB_XTouchDisplayUpper?

Widget DisplayUpper1
	FB_XTouchDisplayUpper 0
WidgetEnd

Widget DisplayUpper2
	FB_MCUDisplayUpper 1
WidgetEnd

Widget DisplayUpper3
	FB_MCUDisplayUpper 2
WidgetEnd

Widget DisplayUpper4
	FB_MCUDisplayUpper 3
WidgetEnd

Widget DisplayUpper5
	FB_MCUDisplayUpper 4
WidgetEnd

Widget DisplayUpper6
	FB_MCUDisplayUpper 5
WidgetEnd

Widget DisplayUpper7
	FB_MCUDisplayUpper 6
WidgetEnd

Widget DisplayUpper8
	FB_MCUDisplayUpper 7
WidgetEnd

Haha, I was waiting for someone to pick up on that

The way the SysEx colour message is defined you set the colours of all 8 channels in one message.

So, in a very strange twist, if you change the colour of the Track on channel 6 and don't use the banking trick, the other way you can refresh is to change the name of the Track currently on channel 1

I'm trying to figure out an elegant way to do this, at that point we may require all the display feedback types to line up.

But, as you can see, since you set all 8 in one message, there would have to be unwanted communication between the display widgets to see where their colleagues were currently set in order to change just one.

It's pretty ugly from a modular point of view

[Navelpluisje]

Originally Posted by Geoff Waddington

Haha, I was waiting for someone to pick up on that

The way the SysEx colour message is defined you set the colours of all 8 channels in one message.

So, in a very strange twist, if you change the colour of the Track on channel 6 and don't use the banking trick, the other way you can refresh is to change the name of the Track currently on channel 1

I'm trying to figure out an elegant way to do this, at that point we may require all the display feedback types to line up.

But, as you can see, since you set all 8 in one message, there would have to be unwanted communication between the display widgets to see where their colleagues were currently set in order to change just one.

It's pretty ugly from a modular point of view

If it is a fixed list of colours, would it make sense to use names in stead of numbers to make easier to read?

[Geoff Waddington]

Originally Posted by Navelpluisje

If it is a fixed list of colours, would it make sense to use names in stead of numbers to make easier to read?

Do you mean names in the source code ?

If so, I just hacked it together to try it out

The numbers you see in the .mst file are channel numbers, not colours.

[Navelpluisje]

Originally Posted by Geoff Waddington

Do you mean names in the source code ?

If so, I just hacked it together to try it out

The numbers you see in the .mst file are channel numbers, not colours.

Ah, never mind

Mixed it up with the zon files. Not quite sure if it is rgb, but it didn’t look like it is. So using names in the zon files would probably make some sense , in stead of numbers

[Geoff Waddington]

Originally Posted by Navelpluisje

Ah, never mind

Mixed it up with the zon files. Not quite sure if it is rgb, but it didn’t look like it is. So using names in the zon files would probably make some sense , in stead of numbers

Yes, if we choose to support custom channel colours as opposed to automatic Track colours only -- not useful for Zones with | syntax, but might work for FX Zones.

[Funkybot]

Originally Posted by Geoff Waddington

Yes, if we choose to support custom channel colours as opposed to automatic Track colours only -- not useful for Zones with | syntax, but might work for FX Zones.

What if it wasn't quite so hard-coded but you allowed the curly brackets to appended to display actions and if the widget supported track colors, it could be automatic.

Example:

Zone "Track"
    DisplayUpper|     TrackNameDisplay { "Track" }
ZoneEnd

Not sure if that's feasible. Just trying to think of ways where X-Touch users could have their cake and eat it too (automatic track colors plus maximum flexibility for re-coloring in other zones).

Got the idea from this page:

https://github.com/GeoffAWaddington/.../Track-Colours

[Geoff Waddington]

Originally Posted by Funkybot

What if it wasn't quite so hard-coded but you allowed the curly brackets to appended to display actions and if the widget supported track colors, it could be automatic.

Example:

Zone "Track"
    DisplayUpper|     TrackNameDisplay { "Track" }
ZoneEnd

Not sure if that's feasible. Just trying to think of ways where X-Touch users could have their cake and eat it too (automatic track colors plus maximum flexibility for re-coloring in other zones).

Got the idea from this page:

https://github.com/GeoffAWaddington/.../Track-Colours

Wouldn't work.

The Faderports allow setting of individual channel colours, the X-Touch in MCU mode sets all 8 at once.

[xeonblack]

Originally Posted by Geoff Waddington

New builds are up.

CSI Support Files.zip

CSI Exp.zip

Preliminary Track colour support for X-Touch in MCU mode.

Make sure you get the new X-Touch.mst file from the support files, as well as the dll/dylib from CSI Exp.zip.

It's a bit buggy, just want to make sure the basics work for everyone.

It does not refresh properly yet, just bank away and come back to see changes.

I have firmware version 1.21 here, it may need that or later, dunno.

The colour translations need some tuning as well.

On firmware 1.22 for Xtouch Universal, by default the track color in Reaper is gray, and on the surface it is red, thanks again for your work!

[Geoff Waddington]

Originally Posted by xeonblack

On firmware 1.22 for Xtouch Universal, by default the track color in Reaper is gray, and on the surface it is red, thanks again for your work!

Thanks, yes, that was the colour translation tuning I was mentioning.

Glad you see the same thing I see here.

The other one I noticed is what is red in Reaper is Magenta on the X-Touch, so a bit more tuning there.

Please let me know of any other wrong colour translations.

[xeonblack]

Originally Posted by Geoff Waddington

Thanks, yes, that was the colour translation tuning I was mentioning.

Glad you see the same thing I see here.

The other one I noticed is what is red in Reaper is Magenta on the X-Touch, so a bit more tuning there.

Please let me know of any other wrong colour translations.

Red colour in Reaper on firmware 1.22 for X-Touch is black.

[Geoff Waddington]

Originally Posted by xeonblack

Red colour in Reaper on firmware 1.22 for X-Touch is black.

Thanks, I can now get this under certain conditions here too.

[Geoff Waddington]

Arrgghhh !

Dumb design decisions 101.

ToggleSynchPageBanking
ToggleScrollLink
ForceScrollLink

are bogus and will be removed.

I was working through some X-Touch colour translation bugs and got really frustrated

As you may know, CSI remembers bank position on Save.

So, I was banked to 0, but when I opened up Reaper, the surface auto banked to Track 7.

I double checked the .rpp file, all good, the bank was saved as 0.

WTF is going on here ?

Finally realized, Track 7 was selected, it was hard to determine that because it was white, and therefore the selection was not obvious.

Scroll Link auto banked the surface, not good.

To me it seemed the surface was ignoring the duly saved bank offset -- in this case 0.

Then it struck me those 3 Actions have no business in Zones, they are Page level.

It would be easy for 2 different surfaces to have one of those toggles in each surface's OnInitialization in their Home Zone, resulting in a double negative -- uggghh, good luck trying try to track down that Zone bug

So there are 2 issues:

1) Those options must be at a Page level.

2) This one is a bit more subtle
Since the TCP/MCP tends to contain many more Tracks than a surface, it's really easy to get into a mess like I just experienced -- Tracks 1 - 25 are visible on my nice big monitor, but since Track 7 is selected, the surface jumps to Track 7 being leftmost.

This is disconcerting and counterintuitive because Tracks 1 - 8 are clearly visible on the monitor and the banking value was recalled from the .rpp file -- it was 0.

So the user is left in the WTF state I just experienced.

The floor is open, let's rethink this whole thing so as not to drive others folks nuts, our fine community deserves better than what I just put myself through trying to figure out what was going on

[Geoff Waddington]

New build is up.

CSI Exp.zip

X-Touch colour mapping much improved.

There are only 7 colours available with this X-Touch mode:

White
Red
Green
Blue
Yellow
Cyan
Magenta

For best results set the colours to the outer edges of the wheel, as close as possible to the centre of the arc of the aforementioned colours, except for White, of course, set that anywhere towards the centre.

[MixMonkey]

Originally Posted by Geoff Waddington

The floor is open, let's rethink this whole thing so as not to drive others folks nuts, our fine community deserves better than what I just put myself through trying to figure out what was going on

I'm not feeling a major problem here

Make sure you always start up with ScrollLink turned off, then your saved banking position will be respected. If you feel the need to prevent ToggleScrollLink being used with OnInitialization, so be it.

I don't think ToggleScrollLink should be removed from Zones, it's far too useful to be able to switch it on and off at will.

ForceScrollLink can be got rid of, using ToggleScrollLink twice works better if you need to force a surface bank after running a script (which was why ForceScrollLink was added in the first place)

All this is really just a symptom of CSI becoming more complex and flexible, with the inevitable feature interactions this creates

[Geoff Waddington]

Originally Posted by MixMonkey

I'm not feeling a major problem here

Make sure you always start up with ScrollLink turned off, then your saved banking position will be respected. If you feel the need to prevent ToggleScrollLink being used with OnInitialization, so be it.

I don't think ToggleScrollLink should be removed from Zones, it's far too useful to be able to switch it on and off at will.

ForceScrollLink can be got rid of, using ToggleScrollLink twice works better if you need to force a surface bank after running a script (which was why ForceScrollLink was added in the first place)

All this is really just a symptom of CSI becoming more complex and flexible, with the inevitable feature interactions this creates

Yes, I meant remove from use via OnInitialization, that's the one that could cause havoc if it were in 2 surfaces Home Zone files.

I have always thought ScrollLink should default to false (off) on startup, glad you agree.

I think SynchPage banking should default to true (on), my feeling is that you usually want to be at the same place navigation wise when you switch Pages -- do we even need it -- do you ever want to bank Pages separately, need a real use case here to convince me that it's a needed feature.

Yup, as CSI gets more complex this sort of stuff is bound to happen, we just have to be vigilant and keep tweaking and tweaking and tweaking...

[MixMonkey]

Originally Posted by Geoff Waddington

Y
I think SynchPage banking should default to true (on), my feeling is that you usually want to be at the same place navigation wise when you switch Pages -- do we even need it -- do you ever want to bank Pages separately, need a real use case here to convince me that it's a needed feature.

Whilst I'm not speaking from a position of great experience regarding Pages ( I haven't got past one yet ), it strikes me that as it's been sold as a way of completely reconfiguring CSI on the fly, some bright spark is bound to try and use it to switch between two (or more) completely different corners of their workflow, each with their own banking positions. Let's not kill that flexibility just yet

[Geoff Waddington]

Originally Posted by MixMonkey

Whilst I'm not speaking from a position of great experience regarding Pages ( I haven't got past one yet ), it strikes me that as it's been sold as a way of completely reconfiguring CSI on the fly, some bright spark is bound to try and use it to switch between two (or more) completely different corners of their workflow, each with their own banking positions. Let's not kill that flexibility just yet

Fair enough, just trying to reduce needless complexity.

Needed complexity is just fine though

So, let's say we:
Remove ForceScrollLink
Discourage use of ToggleScrollLink via OnInitialization
Default Scroll Linking to off.

Those moves would satisfy the use cases I ran into today.

Any objections ?

[MixMonkey]

Originally Posted by Geoff Waddington

Fair enough, just trying to reduce needless complexity.

Needed complexity is just fine though

So, let's say we:
Remove ForceScrollLink
Discourage use of ToggleScrollLink via OnInitialization
Default Scroll Linking to off.

Those moves would satisfy the use cases I ran into today.

Any objections ?

Nope, none from me

[xeonblack]

Originally Posted by Geoff Waddington

New build is up.

CSI Exp.zip

X-Touch colour mapping much improved.

There are only 7 colours available with this X-Touch mode:

White
Red
Green
Blue
Yellow
Cyan
Magenta

For best results set the colours to the outer edges of the wheel, as close as possible to the centre of the arc of the aforementioned colours, except for White, of course, set that anywhere towards the centre.

Tested this, everything workd fine on firmware 1.22 for X-Touch Universal. When I add new tracks, their default color is black, and in order to see their color, I need to update the data for the surface.

[Geoff Waddington]

Originally Posted by xeonblack

Tested this, everything workd fine on firmware 1.22 for X-Touch Universal. When I add new tracks, their default color is black, and in order to see their color, I need to update the data for the surface.

Yup, that's next on the list.

[Geoff Waddington]

Last call for:

Removing ForceScrollLink

Default Scroll Linking to off

Any objections ?

[iNX]

Really nice with color, wish it can in futur provide all colors

[Funkybot]

Originally Posted by Geoff Waddington

Last call for:

Removing ForceScrollLink

Default Scroll Linking to off

Any objections ?

Other than having to update the wiki? No other objections!

[Funkybot]

I've made a bunch of updates to the Feedback Processors page to finally start documenting these. Looking for some help with a few of the processors:

• FB_VUMeter - Not MCUVUMeter - what's the use-case/surface for this VUMeter type?
• FB_GainReductionMeter - Is this for the Console One?
• FB_QConLiteDisplayUpper - Do these next 4 just work like MCUDisplay widgets only for the QConLite surface? Is Channel # required after the syntax? I couldn't find an .mst for this.
• FB_QConLiteDisplayUpperMid
• FB_QConLiteDisplayLowerMid
• FB_QConLiteDisplayLower

https://github.com/GeoffAWaddington/...ack-Processors

[iNX]

Originally Posted by iNX

Really nice with color, wish it can in futur provide all colors

This colors represent my folder containing my different instruments. I set a script to open the folder when I click on select button. But I would like to move the track display on the surface to move the first childre track on the channel 1 on my XTouch (like the channel button). How can I do this?