Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by EnkelMagnus

That sendOSC thingie is just the thing i need for project i've been thinking of for a long time but found no easy way to do it.

For ease of use i would want Websockets but i think it would be a fun challenge to see if i can implement that myself.

We are working through the use cases for SendOSCMessage.

Specifically, how would you use it ?

[Geoff Waddington]

CSI now writes separate files for each FX, just like FX Zones.

They are placed in:

    CSI/Zones/ZoneStepSizes

so you must have that folder in your Zones folder, the support files will be updated to contain it, when we get this working.

CSI preprocesses .stp files, just like it preprocesses .zon files.

For those who don't use this feature, the load time penalty of attempting to process the nonexistent .stp files is in the order a few microseconds.

For those who do use this feature, it is on the order of the .zon preprocessing, here are the results on my M1 mini:

Preprocessing 142 Zone files
32586 microseconds

Preprocessing 103 Step Size files
23001 microseconds

Funkybot, I got the same strange behaviour you did, whereby, after a scan, some scanning still happened on the next project load.

It reported processing 124 Zone files, but on subsequent loads, the preprocessor only read 103, and reprocessed 21.

I traced it to specific plugins.

I can see the file being written and no errors are reported, but somehow, the .stp file fails to write.

I tried various thing, eliminating all but those files, not writing the params, etc., but can't figure it out.

I'm going to sleep on it, but regardless, tomorrow I'll post a version that scans when you do this:

Version 2.0

AutoScan

MidiSurface "XTouch Universal" 12 11 
MidiSurface "SCE24" 11 10 
OSCSurface "iPhone" 8000 9000 168.192.2.1

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

CSI now always attempts to read the .stp files, so you turn on scanning, perform a pass, then turn it off.

Working really well here, so far, other than that anomaly with certain files

[MixMonkey]

Originally Posted by d. gauss

yes, please! (and readelay)

ReaEQ, ReaComp and ReaDelay FX.zon files. ReaDelay has controls for 4 Taps. I've tweaked the parameter acceleration as best I could. Hopefully it's still ok on the X-Touch (I have a Mackie) .

The scaling of the controls on these plugins is challenging, to say the least, so you may need to play with the acceleration values to get something acceptable to you.

Some rotary pushes will Toggle between two parameters (eg Freq and Q in ReaEQ) and some are simple buttons, whose function can be revealed by pushing "Flip"

I haven't mapped parameters to the faders because these plugins really don't lend themselves to it, but feel free to have a go if you like

[jacksoonbrowne]

Originally Posted by Geoff Waddington

We are working through the use cases for SendOSCMessage.

Specifically, how would you use it ?

I for one could use it for the X32/MIDAS.
Specifically in home.zon, "OnInitialization".

I would like to be able to send specific OSC commands to initialize the X32/MIDAS for CSI.

This would require about 10 to 20 SendOSCMessage's.

Some examples would be:

OnInitialization SendOSCMessage "/select/scene s, X32-CSI Config"
OnInitialization SendOSCMessage "/select/assignableBank i, 2"

[UNdark]

Originally Posted by Geoff Waddington

Ok, to be sure I understand you, do you want to cancel modifiers upon Zone deactivation ?

So, if we introduced a new Action UnlatchModifiers, would that do it ?

    ...
    OnZoneDeactivation UnlatchModifiers
    ...

Geoff, that would be exactly the perfect working use !! Thank you

[jacksoonbrowne]

Hi Geoff,

I have now have Play/Stop/Rewind working for the X32 (other transport widgets still to come).

Initially I couldn't get it to work so I pared down my files to bare minimum.

X32.ost

Widget Widget_Play
    Control    /-stat/userpar/17/value
WidgetEnd

Widget Widget_Stop	
    Control    /-stat/userpar/18/value
WidgetEnd

Widget Widget_Rewind
    Control    /-stat/userpar/19/value
WidgetEnd

Home.zon

Zone "Home"
    OnInitialization 		Reaper  "_CSI Toggle Show Raw Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Output to Surfaces"
    IncludedZones
        "Transport"
    IncludedZonesEnd
ZoneEnd

Transport.zon

Zone "Transport"
    Widget_Play      Play
    Widget_Stop      Stop
    Widget_Rewind    Rewind
ZoneEnd

This still didn't work.

-----------------------------

What I found is it works with Buttons zone as opposed to Transport zone.
This is what finally worked.

X32.ost

Widget Widget_Play
    Control    /-stat/userpar/17/value
WidgetEnd

Widget Widget_Stop	
    Control    /-stat/userpar/18/value
WidgetEnd

Widget Widget_Rewind
    Control    /-stat/userpar/19/value
WidgetEnd

Home.zon

Zone "Home"
    OnInitialization 		Reaper  "_CSI Toggle Show Raw Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Output to Surfaces"
    IncludedZones
        "Buttons"
    IncludedZonesEnd
ZoneEnd

Buttons.zon

Zone "Buttons"
    Widget_Play      Play
    Widget_Stop      Stop
    Widget_Rewind    Rewind
ZoneEnd

Thoughts why "Transport.zon" fails and "Buttons.zon" works?

I will try modifying

void Zone::AddNavigatorsForZone(string zoneName, vector<Navigator*> &navigators)
{
    if(zoneName == "Buttons")
        navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
    else if(zoneName == "MasterTrack")
        navigators.push_back(zoneManager_->GetMasterTrackNavigator());
    else if(zoneName == "Track" || zoneName == "VCA" || zoneName == "Folder" || zoneName == "TrackSend" || zoneName == "TrackReceive" || zoneName == "TrackFXMenu" )
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSurface()->GetPage()->GetNavigatorForChannel(i + zoneManager_->GetSurface()->GetChannelOffset()));
    else if(zoneName == "SelectedTrack" || zoneName == "SelectedTrackSend" || zoneName == "SelectedTrackReceive" || zoneName == "SelectedTrackFXMenu")
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
}

To include

void Zone::AddNavigatorsForZone(string zoneName, vector<Navigator*> &navigators)
{
    if(zoneName == "Transport")
        navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
    if(zoneName == "Buttons")
        navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
    else if(zoneName == "MasterTrack")
        navigators.push_back(zoneManager_->GetMasterTrackNavigator());
    else if(zoneName == "Track" || zoneName == "VCA" || zoneName == "Folder" || zoneName == "TrackSend" || zoneName == "TrackReceive" || zoneName == "TrackFXMenu" )
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSurface()->GetPage()->GetNavigatorForChannel(i + zoneManager_->GetSurface()->GetChannelOffset()));
    else if(zoneName == "SelectedTrack" || zoneName == "SelectedTrackSend" || zoneName == "SelectedTrackReceive" || zoneName == "SelectedTrackFXMenu")
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
}

Later today or tomorrow ....

[Geoff Waddington]

Originally Posted by jacksoonbrowne

I for one could use it for the X32/MIDAS.
Specifically in home.zon, "OnInitialization".

I would like to be able to send specific OSC commands to initialize the X32/MIDAS for CSI.

This would require about 10 to 20 SendOSCMessage's.

Some examples would be:

OnInitialization SendOSCMessage "/select/scene s, X32-CSI Config"
OnInitialization SendOSCMessage "/select/assignableBank i, 2"

Cool, thanks for the examples.

Since we support only int32, do we need the s and i parameters ?

could we just use:

OnInitialization SendOSCMessage "/select/scene" "X32-CSI Config"
OnInitialization SendOSCMessage "/select/assignableBank" 2
OnInitialization SendOSCMessage "/some/floatingpoint" 3.7

[Geoff Waddington]

Originally Posted by UNdark

Geoff, that would be exactly the perfect working use !! Thank you

Cool, will be in next build in a few hours, changed the Action name:

    ...
    OnZoneDeactivation ClearModifiers
    ...

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

I have now have Play/Stop/Rewind working for the X32 (other transport widgets still to come).

Initially I couldn't get it to work so I pared down my files to bare minimum.

X32.ost

Widget Widget_Play
    Control    /-stat/userpar/17/value
WidgetEnd

Widget Widget_Stop	
    Control    /-stat/userpar/18/value
WidgetEnd

Widget Widget_Rewind
    Control    /-stat/userpar/19/value
WidgetEnd

Home.zon

Zone "Home"
    OnInitialization 		Reaper  "_CSI Toggle Show Raw Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Output to Surfaces"
    IncludedZones
        "Transport"
    IncludedZonesEnd
ZoneEnd

Transport.zon

Zone "Transport"
    Widget_Play      Play
    Widget_Stop      Stop
    Widget_Rewind    Rewind
ZoneEnd

This still didn't work.

-----------------------------

What I found is it works with Buttons zone as opposed to Transport zone.
This is what finally worked.

X32.ost

Widget Widget_Play
    Control    /-stat/userpar/17/value
WidgetEnd

Widget Widget_Stop	
    Control    /-stat/userpar/18/value
WidgetEnd

Widget Widget_Rewind
    Control    /-stat/userpar/19/value
WidgetEnd

Home.zon

Zone "Home"
    OnInitialization 		Reaper  "_CSI Toggle Show Raw Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Input from Surfaces"
    OnInitialization 		Reaper  "_CSI Toggle Show Output to Surfaces"
    IncludedZones
        "Buttons"
    IncludedZonesEnd
ZoneEnd

Buttons.zon

Zone "Buttons"
    Widget_Play      Play
    Widget_Stop      Stop
    Widget_Rewind    Rewind
ZoneEnd

Thoughts why "Transport.zon" fails and "Buttons.zon" works?

I will try modifying

void Zone::AddNavigatorsForZone(string zoneName, vector<Navigator*> &navigators)
{
    if(zoneName == "Buttons")
        navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
    else if(zoneName == "MasterTrack")
        navigators.push_back(zoneManager_->GetMasterTrackNavigator());
    else if(zoneName == "Track" || zoneName == "VCA" || zoneName == "Folder" || zoneName == "TrackSend" || zoneName == "TrackReceive" || zoneName == "TrackFXMenu" )
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSurface()->GetPage()->GetNavigatorForChannel(i + zoneManager_->GetSurface()->GetChannelOffset()));
    else if(zoneName == "SelectedTrack" || zoneName == "SelectedTrackSend" || zoneName == "SelectedTrackReceive" || zoneName == "SelectedTrackFXMenu")
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
}

To include

void Zone::AddNavigatorsForZone(string zoneName, vector<Navigator*> &navigators)
{
    if(zoneName == "Transport")
        navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
    if(zoneName == "Buttons")
        navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
    else if(zoneName == "MasterTrack")
        navigators.push_back(zoneManager_->GetMasterTrackNavigator());
    else if(zoneName == "Track" || zoneName == "VCA" || zoneName == "Folder" || zoneName == "TrackSend" || zoneName == "TrackReceive" || zoneName == "TrackFXMenu" )
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSurface()->GetPage()->GetNavigatorForChannel(i + zoneManager_->GetSurface()->GetChannelOffset()));
    else if(zoneName == "SelectedTrack" || zoneName == "SelectedTrackSend" || zoneName == "SelectedTrackReceive" || zoneName == "SelectedTrackFXMenu")
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
}

Later today or tomorrow ....

You answered your own question, but it may not be a good idea.

All architectures, CSI included, try to strike a balance between flexibility and complexity.

CSI used to be totally free form, you defined navigators, you could use anything as an IncludedZone, etc.

We changed that to make it easier for users.

We hardwired some Zones and their relationships, based on our years of experience using CSI in the real world, boots on the ground sense.

We could do what you want, make a separate Transport Zone, but why stop there ?

Why not make a Function keys Zone, an Automation Zone, a bunch of other Zones too ?

Oh, wait, when a new surface comes along with a new concept, we'll have to introduce a new Zone for that too.

You see the dilemma.

So, we decided to lump all of the non TrackNavigator stuff into the humongous "Buttons" Zone and give it a SelectedTrackNavigator.

Is it ideal, no, of course not.

Is it the best balanced tradeoff ?

We think so, that's why it is the way it is

But if there is a convincing argument for change, let's hear it.

[Geoff Waddington]

Meanwhile, back at the .mst file...

Thinking this through a bit more, perhaps we could do this to simplify the Widget definitions, reduce redundancy, and give CSI some auto Zone generation information with this approach:

StepSize
    Rotary 0.003
    JogWheel 0.005
StepSizeEnd

EncoderSteps
    Rotary > 01-0f < 41-4f
    JogWheel > 01-07 < 41-47
EncoderStepsEnd

AccelerationValues
    Rotary   0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
    JogWheel 0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
AccelerationValuesEnd

Widget Fader1 MotorizedFader
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
	Touch 90 68 7f 90 68 00
WidgetEnd

Widget Rotary1 Rotary
	Encoder b0 10 7f
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1 RotaryPush
	Press 90 20 7f
WidgetEnd

Widget Shift PressRelease
	Press 90 46 7f 90 46 00
	FB_TwoState 90 46 7f 90 46 00
WidgetEnd

Widget LoMidGain RotaryFader
	Fader7Bit b0 58 7f
	FB_Fader7Bit b0 58 7f
WidgetEnd

Widget Preset PressOnly
	AnyPress b0 3a 7f 
	FB_TwoState b0 3a 7f b0 3a 00
WidgetEnd

Existing .mst files would continue to parse just fine, this would be optional, so nothing out there would break.

[AtmanActive]

Originally Posted by Geoff Waddington

StepSize
    Rotary 0.003
    JogWheel 0.005
StepSizeEnd

EncoderSteps
    Rotary > 01-0f < 41-4f
    JogWheel > 01-07 < 41-47
EncoderStepsEnd

AccelerationValues
    Rotary   0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
    JogWheel 0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
AccelerationValuesEnd

Widget Fader1 MotorizedFader
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
	Touch 90 68 7f 90 68 00
WidgetEnd

Widget Rotary1 Rotary
	Encoder b0 10 7f
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1 RotaryPush
	Press 90 20 7f
WidgetEnd

Widget Shift PressRelease
	Press 90 46 7f 90 46 00
	FB_TwoState 90 46 7f 90 46 00
WidgetEnd

Widget LoMidGain RotaryFader
	Fader7Bit b0 58 7f
	FB_Fader7Bit b0 58 7f
WidgetEnd

Widget Preset PressOnly
	AnyPress b0 3a 7f 
	FB_TwoState b0 3a 7f b0 3a 00
WidgetEnd

The problem I have with reading these, unless I read Wiki up and down few times, is that I'm missing sigils or IDE colouring to be able to distuinguish what is what in that text.
For example, the word "Rotary" on line 2: is that a variable ($Rotary) where users will be writing their own names, or is that a keyword that will be hardcoded and have a special meaning?

I understand that you want to make it as easy as possible for non-programmers, but, as luck would have it, you are doing exactly that: making a programming language.

SQL has this elegantly solved, in my humble opinion, where keywords are written in all caps while variables are in lowcase, but still, the parser would accept both, so lazybugs are included too. Like, for example:

SELECT rotary FROM controls WHERE channel=1

Beautiful.

If only Reaper Forum's phpBB would allow/include coloured code syntax, that could be easily solved.

[jacksoonbrowne]

Originally Posted by Geoff Waddington

You answered your own question, but it may not be a good idea.

All architectures, CSI included, try to strike a balance between flexibility and complexity.

CSI used to be totally free form, you defined navigators, you could use anything as an IncludedZone, etc.

We changed that to make it easier for users.

We hardwired some Zones and their relationships, based on our years of experience using CSI in the real world, boots on the ground sense.

We could do what you want, make a separate Transport Zone, but why stop there ?

Why not make a Function keys Zone, an Automation Zone, a bunch of other Zones too ?

Oh, wait, when a new surface comes along with a new concept, we'll have to introduce a new Zone for that too.

You see the dilemma.

So, we decided to lump all of the non TrackNavigator stuff into the humongous "Buttons" Zone and give it a SelectedTrackNavigator.

Is it ideal, no, of course not.

Is it the best balanced tradeoff ?

We think so, that's why it is the way it is

But if there is a convincing argument for change, let's hear it.

Thanks Geoff, makes good sense

So, we decided to lump all of the non TrackNavigator stuff into the humongous "Buttons" Zone and give it a SelectedTrackNavigator.

The CSI Wiki did not IMHO document this knowledge in a way that would maybe should be more obvious

Cheers,
Roy

[Geoff Waddington]

Originally Posted by AtmanActive

The problem I have with reading these, unless I read Wiki up and down few times, is that I'm missing sigils or IDE colouring to be able to distuinguish what is what in that text.
For example, the word "Rotary" on line 2: is that a variable ($Rotary) where users will be writing their own names, or is that a keyword that will be hardcoded and have a special meaning?

I understand that you want to make it as easy as possible for non-programmers, but, as luck would have it, you are doing exactly that: making a programming language.

SQL has this elegantly solved, in my humble opinion, where keywords are written in all caps while variables are in lowcase, but still, the parser would accept both, so lazybugs are included too. Like, for example:

SELECT rotary FROM controls WHERE channel=1

Beautiful.

If only Reaper Forum's phpBB would allow/include coloured code syntax, that could be easily solved.

Excellent point, maybe this is better:

StepSize
    Rotary 0.003
    JogWheel 0.005
StepSizeEnd

EncoderSteps
    Rotary > 01-0f < 41-4f
    JogWheel > 01-07 < 41-47
EncoderStepsEnd

AccelerationValues
    Rotary   0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
    JogWheel 0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
AccelerationValuesEnd

Widget Fader1 MotorizedFader
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
	Touch 90 68 7f 90 68 00
WidgetEnd

Widget Rotary1 Rotary
	Encoder b0 10 7f
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1 RotaryPush
	Press 90 20 7f
WidgetEnd

Widget Shift PressRelease
	Press 90 46 7f 90 46 00
	FB_TwoState 90 46 7f 90 46 00
WidgetEnd

Widget LoMidGain RotaryFader
	Fader7Bit b0 58 7f
	FB_Fader7Bit b0 58 7f
WidgetEnd

Widget Preset PressOnly
	AnyPress b0 3a 7f 
	FB_TwoState b0 3a 7f b0 3a 00
WidgetEnd

Widget JogWheel JogWheel
	Press b0 3c 7f
WidgetEnd

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Thanks Geoff, makes good sense



The CSI Wiki did not IMHO document this knowledge in a way that would maybe should be more obvious

Cheers,
Roy

Actually, you've got me questioning that now

One of the things I noticed in the video, I think MixMonkey also alluded to this, is that the "Buttons" Zone is indeed, overwhelming.

Maybe we should recode the method you mention like this:

void Zone::AddNavigatorsForZone(string zoneName, vector<Navigator*> &navigators)
{
    if(zoneName == "MasterTrack")
        navigators.push_back(zoneManager_->GetMasterTrackNavigator());
    else if(zoneName == "Track" || zoneName == "VCA" || zoneName == "Folder" || zoneName == "TrackSend" || zoneName == "TrackReceive" || zoneName == "TrackFXMenu" )
        for(int i = 0; i < zoneManager_->GetNumChannels(); i++)
            navigators.push_back(zoneManager_->GetSurface()->GetPage()->GetNavigatorForChannel(i + zoneManager_->GetSurface()->GetChannelOffset()));
    else 
            navigators.push_back(zoneManager_->GetSelectedTrackNavigator());
}

That way, you would be free to break up the IncludedZones any way you want.

Further, once again alluding to the video, and MixMonkey's and Funkybot's observations, maybe CSI should ship with IncludedZones and AssociatedZones folders as well as an FX folder.

Putting all of this together you would end up with a folder structure like this, much more organized:

X-Touch
    Home
    IncludedZones
        MasterTrack
        Track
        Transport
        Automation
        FunctionKeys
        Modifiers
        Banking
        JogWheel
        etc
        SubZones
           Marker
    AssociatedZones
       SelectedTrackSend
       SelectedTrackReceive
       SelectedTrackFXMenu
       TrackSend
       TrackReceive
       TrackFXMenu
       VCA
       Folder
    FX
      //organized however you would like

All of these are non breaking changes, and I'm coming around to your (and others) way of thinking.

[Geoff Waddington]

One of the things I noticed in the video was confusion over the Encoder assignment section.

I just grabbed what someone suggested from their own customization.

I now want to revisit that.

    Track            GoTrack // just deactivates others
    Pan              GoFolder
    EQ               GoVCA
    Send             GoSelectedTrackSend
    Plugin           GoSelectedTrackFXMenu
    Instrument       GoSelectedTrackReceive 
    Shift+Send       GoTrackSend
    Shift+Plugin     GoTrackFXMenu
    Shift+Instrument GoTrackReceive

Of course, that's just one possible customization.

This would free up the whole row after Global View.

[edit] Hmmm...

Another option would be to add a modifier, I know, MCU/X-Touch specific, but there are an awful lot of MCU type surfaces out there.

Let's call it Track.

We could use these now that VCA and Folders are Zones

    nameValue			Track
    AssignmentDisplay		TrackStatusDisplay

Then we could do this without messing things up by having Shift latched:

    Track            GoTrack // just deactivates others
    Pan              GoFolder
    EQ               GoVCA
    Send             GoSelectedTrackSend
    Plugin           GoSelectedTrackFXMenu
    Instrument       GoSelectedTrackReceive 
    Track+Send       GoTrackSend
    Track+Plugin     GoTrackFXMenu
    Track+Instrument GoTrackReceive

[MixMonkey]

Originally Posted by Geoff Waddington

Meanwhile, back at the .mst file...

Thinking this through a bit more, perhaps we could do this to simplify the Widget definitions, reduce redundancy, and give CSI some auto Zone generation information with this approach:

StepSize
    Rotary 0.003
    JogWheel 0.005
StepSizeEnd

EncoderSteps
    Rotary > 01-0f < 41-4f
    JogWheel > 01-07 < 41-47
EncoderStepsEnd

AccelerationValues
    Rotary   0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
    JogWheel 0.001 0.005 0.010 0.015 0.025 0.050 0.1 0.25 0.5
AccelerationValuesEnd

Widget Fader1 MotorizedFader
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
	Touch 90 68 7f 90 68 00
WidgetEnd

Widget Rotary1 Rotary
	Encoder b0 10 7f
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1 RotaryPush
	Press 90 20 7f
WidgetEnd

Widget Shift PressRelease
	Press 90 46 7f 90 46 00
	FB_TwoState 90 46 7f 90 46 00
WidgetEnd

Widget LoMidGain RotaryFader
	Fader7Bit b0 58 7f
	FB_Fader7Bit b0 58 7f
WidgetEnd

Widget Preset PressOnly
	AnyPress b0 3a 7f 
	FB_TwoState b0 3a 7f b0 3a 00
WidgetEnd

Existing .mst files would continue to parse just fine, this would be optional, so nothing out there would break.

This looks good

Having the encoder output, default acceleration and default step size defined in a single place is great!

I'm a little unclear as to why you need to specify a widget type? This seems to be completely defined by the widget definition itself. For instance, a fader with feedback is inherently a motorised fader, a button with a release definition is PressRelease, a rotary generating absolute values is a fader etc.

[EnkelMagnus]

Originally Posted by Geoff Waddington

We are working through the use cases for SendOSCMessage.

Specifically, how would you use it ?

I have a X-Touch Mini.

Problem:
It has no display.
What does the buttons and encoders map to?
What page am i on?

Solution:
Make a virtual screen that can recieve OSC.
Send Page name ,parameter names, knob fumction names to vistrual screen.
Problem solved.

It should be easy to install for the user. I've thought up incredibly complex soultions that required the user to install all kinds of Reaper extensions, plugins and auxiliary programs only to realize they wouldn't even work without CSI being able to send OSC.

Solution: Make a webpage that recieves OSC. No installation what so ever! Just have a browser window open and it just works (hopefully)! Wepages can't recieve UDP. You could do polling i believe but i'm allergic to that and it adds compexity. Or make a helper program that translates from UDP to Websockets but that needs to be compiled and installed on several platforms (i don't have a Mac). With a webpage it just works.

I'd just be sending Strings. I imagine something like:

Zone "VST: UAD Teletronix LA-2A Silver (Universal Audio, Inc.)" "LA2ASlv"
PageNameScreen SendOSC PluginName
RotaryScreen| SendOSC ParameterName
Knob1Screen SendOSC "Bypass"
DownButtonScreen SendOSC "Page2"
Threshold FXParam "0"
Output FXParam "1"
Meter FXParam "4"
Attack FXParam "3"
Ratio FXParam "2"
InvertFB+Compressor FXParam "6" "Bypass" [ 0.0 1.0 ]
WetDry FXParam "7"
ZoneEnd

[MixMonkey]

Originally Posted by Geoff Waddington

One of the things I noticed in the video was confusion over the Encoder assignment section.

I just grabbed what someone suggested from their own customization.

I now want to revisit that.

    Track            GoTrack // just deactivates others
    Pan              GoFolder
    EQ               GoVCA
    Send             GoSelectedTrackSend
    Plugin           GoSelectedTrackFXMenu
    Instrument       GoSelectedTrackReceive 
    Shift+Send       GoTrackSend
    Shift+Plugin     GoTrackFXMenu
    Shift+Instrument GoTrackReceive

Of course, that's just one possible customization.

This would free up the whole row after Global View.

That's a better idea and a good compromise on removing the TrackSend/Receive/FX Zones altogether. Users are unlikely to Shift+Press by accident and then wonder where the hell they are You do lose the LED indication that would differentiate SelectedTrack from Track but that's probably ok.

[MixMonkey]

Originally Posted by EnkelMagnus

I have a X-Touch Mini.

Problem:
It has no display.
What does the buttons and encoders map to?
What page am i on?

Solution:
Just build a TouchOSC layout that mirrors the functionality you have on the X-Touch Mini (ie identical Widget names and Zones) and then you have a display that mirrors the physical surface (with a touch screen thrown in for free)

[Geoff Waddington]

Originally Posted by MixMonkey

This looks good

Having the encoder output, default acceleration and default step size defined in a single place is great!

I'm a little unclear as to why you need to specify a widget type? This seems to be completely defined by the widget definition itself. For instance, a fader with feedback is inherently a motorised fader, a button with a release definition is PressRelease, a rotary generating absolute values is a fader etc.

It's a hint for automap FX down the road.

[MixMonkey]

Originally Posted by Geoff Waddington

It's a hint for automap FX down the road.

Got it

[Geoff Waddington]

Originally Posted by MixMonkey

That's a better idea and a good compromise on removing the TrackSend/Receive/FX Zones altogether. Users are unlikely to Shift+Press by accident and then wonder where the hell they are You do lose the LED indication that would differentiate SelectedTrack from Track but that's probably ok.

Actually, please re read the post for the edit, I like that even better

[MixMonkey]

If someone with a X-Touch could give these Cockos FX.zon a whirl and give some feedback, I'd be most grateful
https://forum.cockos.com/showpost.ph...ostcount=19843

[MixMonkey]

Originally Posted by Geoff Waddington

Actually, please re read the post for the edit, I like that even better

Yeah, specialised modifier positioned right next to the buttons themselves. Cool

Maybe use the assignment display to indicate ALL the Zones, not just Track, VCA and Folder.

[Geoff Waddington]

Originally Posted by MixMonkey

Yeah, specialised modifier positioned right next to the buttons themselves. Cool

Maybe use the assignment display to indicate ALL the Zones, not just Track, VCA and Folder.

The idea is that the display indicates the state of the Track modifier.


So, if the display is "tr" you would know the Send button is for GoTrackSend.

If the display is "Sl" you would know the Send button is for GoSelectedTrackSend.

I really like it

[MixMonkey]

Originally Posted by Geoff Waddington

The idea is that the display indicates the state of the Track modifier.


So, if the display is "tr" you would know the Send button is for GoTrackSend.

If the display is "Sl" you would know the Send button is for GoSelectedTrackSend.

I really like it

I see, that makes sense.

[EnkelMagnus]

Originally Posted by MixMonkey

Solution:
Just build a TouchOSC layout that mirrors the functionality you have on the X-Touch Mini (ie identical Widget names and Zones) and then you have a display that mirrors the physical surface (with a touch screen thrown in for free)

That's not a bad idea at all. However i think my solution has some advantages.

For one it would be free. I want my virtual screen on the computer monitor not on a pad. I only have a really old one that i'm not even sure works anymore.

Now it just so happens i bought TouchOSC for desktop by mistake! "Doh!"
So i could try it. But my solution would be easier to setup not needing two files for every page and whatnot.

[MixMonkey]

Originally Posted by EnkelMagnus

Now it just so happens i bought TouchOSC for desktop by mistake! "Doh!"
So i could try it.

I think the Desktop version of TouchOSC allows it to be run 'locally' on computer (though I haven't tried this)

But my solution would be easier to setup not needing two files for every page and whatnot.

That's why you build the TouchOSC definitions to be identical to the X-Touch Mini's, so you only need one set of files (the other is a simple duplicate)

I have an X-Touch Mini too, so I'll give it a try and see what the pitfalls are

[Funkybot]

This is exactly what I do for my MIDI Fighter Twister. It’s a great solution. Just use all the same widget names as the hardware and add any desired display widgets with broadcast and receive functionality turned on. Then point both surfaces to the same zone folder.

[d. gauss]

Originally Posted by MixMonkey

If someone with a X-Touch could give these Cockos FX.zon a whirl and give some feedback, I'd be most grateful
https://forum.cockos.com/showpost.ph...ostcount=19843

will do. thanks!

[Puck]

I don't know if this is still needed but I tried the AutoStep build.

As far as I know the instructions were:

1. Install the build
2. Put "AutoScan" in your .ini

Was that all I supposed to do?

Here are the results from that:

Processing 97 Zone files
11002 microseconds

Reading AutoStepSizes.txt
78 microseconds

Processed 82 FX Zones, MaxNumParams = 100
103462376 microseconds

Writing AutoStepSizes.txt
2391 microseconds

Processing 97 Zone files
10465 microseconds

Reading AutoStepSizes.txt
33498 microseconds

Processed 91 FX Zones, MaxNumParams = 100
27483673 microseconds

Writing AutoStepSizes.txt
0 microseconds

Windows 10
i7 4790k
16 GB ram

It didn't crash or anything, but it did seem to try the process twice.

It appears to be missing some. I have one JSFX in that folder so that accounts for one. But I'm not sure which other ones it missed. OR is it just that I have a few FX zones that don't have any step or toggle parameters?

[Puck]

To touch base on something from way back regarding track visibility.

It appears you don't need the mixer window open at all so that is nice.

However, it still follows the mixer visibility. So if you are using actions to show/hide tracks to your liking AND you work from the TCP window, you will need to show/hide tracks from both the TCP and MCP for everything to jive correctly. That doesn't bother me at all because I was already doing that, I've always preferred the TCP and MCP be in lock step.

[Geoff Waddington]

Originally Posted by Puck

I don't know if this is still needed but I tried the AutoStep build.

As far as I know the instructions were:

1. Install the build
2. Put "AutoScan" in your .ini

Was that all I supposed to do?

Here are the results from that:

Processing 97 Zone files
11002 microseconds

Reading AutoStepSizes.txt
78 microseconds

Processed 82 FX Zones, MaxNumParams = 100
103462376 microseconds

Writing AutoStepSizes.txt
2391 microseconds

Processing 97 Zone files
10465 microseconds

Reading AutoStepSizes.txt
33498 microseconds

Processed 91 FX Zones, MaxNumParams = 100
27483673 microseconds

Writing AutoStepSizes.txt
0 microseconds

Windows 10
i7 4790k
16 GB ram

It didn't crash or anything, but it did seem to try the process twice.

It appears to be missing some. I have one JSFX in that folder so that accounts for one. But I'm not sure which other ones it missed. OR is it just that I have a few FX zones that don't have any step or toggle parameters?

Just wait a few minutes, there's a new build coming

Don't forget to get the new support files too !

[Geoff Waddington]

Originally Posted by Puck

To touch base on something from way back regarding track visibility.

It appears you don't need the mixer window open at all so that is nice.

However, it still follows the mixer visibility. So if you are using actions to show/hide tracks to your liking AND you work from the TCP window, you will need to show/hide tracks from both the TCP and MCP for everything to jive correctly. That doesn't bother me at all because I was already doing that, I've always preferred the TCP and MCP be in lock step.

Yup, we removed the mixer open constraint.

You can now follow the TCP by doing this:

Version 2.0

//AutoScan

MidiSurface "XTouch Universal" 12 11 
MidiSurface "SCE24" 11 10 
OSCSurface "iPhone" 8000 9000 168.192.2.1

Page "HomePage" FollowTCP
"XTouch Universal" 8 0 "X-Touch.mst" "X-Touch"

[Geoff Waddington]

New builds are up.

CSI Support Fles.zip

Completely revamped the Zone file structure for the X-Touch, have a look, I really like how the Included Zones turned out.


CSI AutoStep.zip

As per our discussions, make sure you get the support files, you need to have the ZoneStepSizes folder present.


CSI Exp.zip

new Actions

ClearModifiers
GoTrack
TrackModeDisplay
Track

ClearModifiers -- clears all of the modifiers -- oops, just realized as I was typing, forgot to clear the new Track modifier, will be fixed in next build.

GoTrack -- like GoSelectedTrack, effectively the same as GoHome.

Track -- new modifier -- means Track or SelectedTrack context.

TrackModeDisplay - displays above on the MCU assignment display.

You can now use more Included Zones than Buttons, MasterTrack, Tracks -- all will get SelectedTrackNavigator, see X-Touch support files for examples, it's a lot cleaner.

Check the Automation Zone — Global automation now uses the Track modifier.

[Funkybot]

Originally Posted by Geoff Waddington

New builds are up.

CSI Support Fles.zip

Completely revamped the Zone file structure for the X-Touch, have a look, I really like how the Included Zones turned out.


CSI AutoStep.zip

As per our discussions, make sure you get the support files, you need to have the ZoneStepSizes folder present.


CSI Exp.zip

new Actions

ClearModifiers
GoTrack
TrackModeDisplay
Track

ClearModifiers -- clears all of the modifiers -- oops, just realized as I was typing, forgot to clear the new Track modifier, will be fixed in next build.

GoTrack -- like GoSelectedTrack, effectively the same as GoHome.

Track -- new modifier -- means Track or SelectedTrack context.

TrackModeDisplay - displays above on the MCU assignment display.

You can now use more Included Zones than Buttons, MasterTrack, Tracks -- all will get SelectedTrackNavigator, see X-Touch support files for examples, it's a lot cleaner.

Check the Automation Zone — Global automation now uses the Track modifier.

Checked out the X-Touch files. It looks like now there are more zone files/folders to maintain and the additional complexity of a folder structure.

I feel like this is getting away from being easier and moving into more complex territory. In the old build, there was one zone for all non-track buttons: it was called "Buttons". Now surface buttons can be split out between: Buttons, EncoderAssign, Automation, Modifiers, Metronome, Transport, and Banking. And SubZones go into a folder called SubZones, but you have to go looking to see "Subfolder of what?" Then poke around until you see "oh, subfolder of buttons" - which isn't clear from the folder hierarchy. How will users know which "button-like" zone contains the button they're trying to customize? What will happen when users have the same button assigned in multiple button-like zones? I really think this is going to be a step back in terms of usability if it goes into the main builds. KISS rule: your non-Track buttons are in the buttons.zon, don't put them elsewhere.

The older method was much simpler IMO. Surface files all in one folder, buttons all in one place, no folder hierarchy of any kind to maintain, no hunting for buttons. In my head, less is simpler. More is more complex. This seems like it introduces 2 or 3x greater complexity to CSI, which is going to make it harder for new users to pick up, harder to explain and lead to bugs or unwanted behaviors.

[Geoff Waddington]

Originally Posted by Funkybot

Checked out the X-Touch files. It looks like now there are more zone files/folders to maintain and the additional complexity of a folder structure.

I feel like this is getting away from being easier and moving into more complex territory. In the old build, there was one zone for all non-track buttons: it was called "Buttons". Now surface buttons can be split out between: Buttons, EncoderAssign, Automation, Modifiers, Metronome, Transport, and Banking. And SubZones go into a folder called SubZones, but you have to go looking to see "Subfolder of what?" Then poke around until you see "oh, subfolder of buttons" - which isn't clear from the folder hierarchy. How will users know which "button-like" zone contains the button they're trying to customize? What will happen when users have the same button assigned in multiple button-like zones? I really think this is going to be a step back in terms of usability if it goes into the main builds. KISS rule: your non-Track buttons are in the buttons.zon, don't put them elsewhere.

The older method was much simpler IMO. Surface files all in one folder, buttons all in one place, no folder hierarchy of any kind to maintain, no hunting for buttons. In my head, less is simpler. More is more complex. This seems like it introduces 2 or 3x greater complexity to CSI, which is going to make it harder for new users to pick up, harder to explain and lead to bugs or unwanted behaviors.

Interesting, I find each section is much more clear with the separated Zones.

Maybe we could keep the single Buttons Zone, and just leave a lot of space between the sections, maybe that's what I saw during the video, a sense of being overwhelmed because of the mashup.

At any rate, you now have the option to do whatever you would like.

I'll let it settle for a day or so, hear what others think, then maybe put it back in one Buttons Zone, just with a lot better use of white space. Maybe that's the trick.

[Funkybot]

Yeah, I feel pretty strongly that "everything in one" is ultimately simpler. See below.

Zone "Buttons"
    SubZones
        "Zoom"
    SubZonesEnd
    
//  Encoder Assign Buttons

    Track                       GoTrack
    Pan                         GoVCA
    EQ                          GoFolder
    Send                        GoSelectedTrackSend
    Track+Send                  GoTrackSend
    Plugin                      GoSelectedTrackFXMenu
    Track+Plugin                GoTrackFXMenu
    Instrument                  GoSelectedTrackReceive
    Track+Instrument            GoTrackReceive


//  Display Section

    nameValue                   Track
    AssignmentDisplay           TrackModeDisplay 
    TimeDisplay                 MCUTimeDisplay
    smpteBeats                  CycleTimeDisplayModes

 
//  View Buttons
 
    GlobalView                  GoHome
    GlobalView                  Reaper _S&M_WNCLS4          // Closes all(!) FX chain windows
    GlobalView                  Reaper _S&M_WNCLS3          // Closes all(!) floating FX windows  
    MidiTracks                  NoAction
    Inputs                      NoAction
    AudioTracks                 NoAction
    AudioInstrument             NoAction
    Aux                         NoAction
    Busses                      NoAction
    Outputs                     NoAction
    User                        NoAction
           
// Function Buttons

    F1                          ToggleEnableFocusedFXParamMapping
    F2                          ToggleEnableFocusedFXMapping
    F3                          ToggleScrollLink
    F4                          NoAction
    F5                          NoAction
    F6                          NoAction
    F7                          NoAction
    F8                          NoAction
    
//  Modifiers

    Flip                        Flip
    Shift                       Shift
    Option                      Option
    Control                     Control
    Alt                         Alt     

// Automation Buttons

    Read                        TrackAutoMode 1
    Write                       TrackAutoMode 3
    Trim                        TrackAutoMode 0
    Touch                       TrackAutoMode 2
    Latch                       TrackAutoMode 4
    Group                       TrackAutoMode 5
    Shift+Read                  GlobalAutoMode 1
    Shift+Write                 GlobalAutoMode 3
    Shift+Trim                  GlobalAutoMode 0
    Shift+Touch                 GlobalAutoMode 2
    Shift+Latch                 GlobalAutoMode 4  
    Shift+Group                 GlobalAutoMode 5   

//  Utility Buttons

    Save                        SaveProject
    Undo                        Undo
    Hold+Undo                   Reaper 40072                // View: Show undo history window
    Shift+Undo                  Redo
    Cancel                      NoAction
    Enter                       NoAction
    
//  Transport Section

    Marker                      Reaper 40157                // Insert marker at current or edit position
    Shift+Marker                Reaper 40613                // Delete marker near cursor
    Nudge                       NoAction
    Cycle                       CycleTimeline
    Drop                        Reaper 1157                 // Toggle snapping
    Replace                     Reaper 1155                 // Cycle ripple editing mode
    Click                       Reaper 40364                // Toggle metronome
    Shift+Click                 Reaper _SWS_AWCOUNTRECTOG   // Toggle count-in before recording
    Hold+Click                  Reaper 40363                // Show metronome settings
    Rewind                      Rewind   
    FastForward                 FastForward
    Stop                        Stop
    Hold+Stop                   Reaper 40042                // Go to start of project
    Play                        Play
    Record                      Record    
    Solo                        ClearAllSolo
    Option+Solo                 Reaper 40745                // Solo in front (dim solo)  

//  Banking 

    BankLeft                    TrackBank -8
    BankRight                   TrackBank 8
    ChannelLeft                 TrackBank -1
    ChannelRight                TrackBank 1

//  Navigation and Zoom
    
    Up                          Reaper 40111                // Zoom in vertical                   
    Property+Up                 NoFeedback                  // Turns off the button light                             
    Down                        Reaper 40112                // Zoom out vertical                    
    Property+Down               NoFeedback                  // Turns off the button light                                     
    Right                       Reaper 1012                 // Zoom in horizontal                    
    Property+Right              NoFeedback                  // Turns off the button light                    
    Left                        Reaper 1011                 // Zoom out horizontal                    
    Property+Left               NoFeedback                  // Turns off the button light                     
    Zoom                        GoSubZone "Zoom"

//  Jogwheel

    JogWheelRotaryCW            Reaper 40839                // Move edit cursor forward one measure (no seek)                    
    JogWheelRotaryCCW           Reaper 40840                // Move edit cursor back one measure (no seek)                        
    Shift+JogWheelRotaryCW      Reaper 40285                // Track: Go to next track                    
    Shift+JogWheelRotaryCCW     Reaper 40286                // Track: Go to previous track        
    Option+JogWheelRotaryCW     Reaper 40173                // Go to next marker or project end      
    Option+JogWheelRotaryCCW    Reaper 40172                // Go to previous marker or project start
    
ZoneEnd

EDIT: I think Track+ as a modifier for global automation modes is confusing (global is the opposite of a "track" as used in the Encoder Assign section) so I changed those to Shift.

I also have Zoom here assigned to a Zoom SubZone I use which looks like this. Could be changed to just Zoom In Vertically and Shift+Zoom to zoom out. But I think a Zoom zone is much better IMO.

Zone "Zoom"
     Up                       Reaper 40111   // Zoom in vertical
     Property+Up              NoFeedback
     Shift+Up                 Reaper 40113   // Toggle track height to maximum
     Property+Shift+Up        NoFeedback
     Down                     Reaper 40112   // Zoom out vertical
     Property+Down            NoFeedback
     Shift+Down               Reaper 40727   // Minimize all tracks
     Property+Shift+Down      NoFeedback
     Right                    Reaper 1012    // Zoom in horizontal
     Property+Right           NoFeedback
     Left                     Reaper 1011    // Zoom out horizontal
     Property+Left            NoFeedback 

     JogWheelRotaryCW         Reaper 1012    // Zoom in horizontal
     Shift+JogWheelRotaryCW   Reaper 40111   // Zoom in vertical
     JogWheelRotaryCCW        Reaper 1011    // Zoom out horizontal
     Shift+JogWheelRotaryCCW  Reaper 40112   // Zoom out vertical    
     
     Zoom                     LeaveSubZone
ZoneEnd

[Geoff Waddington]

Originally Posted by Funkybot

Yeah, I feel pretty strongly that "everything in one" is ultimately simpler. See below.

Yeah, maybe better use of whitespace is the way to go.

Originally Posted by Funkybot

YEDIT: I think Track+ as a modifier for global automation modes is confusing (global is the opposite of a "track" as used in the Encoder Assign section) so I changed those to Shift.

Yeah, terminology here -- if automation is not global, it applies to the Selected Track -- ergo, global automation = track automation in CSI terminology, but I certainly get your point.

BTW, if you have Track engaged, Shift will not work for Global automation, you have to disengage Track first.

Maybe it's an issue of nomenclature, maybe the 2 display entries should be "SL" for Selected Track and "GL" for Global/Track.

Originally Posted by Funkybot

I also have Zoom here assigned to a Zoom SubZone I use which looks like this. Could be changed to just Zoom In Vertically and Shift+Zoom to zoom out. But I think a Zoom zone is much better IMO.

How does that square with having everything in "Buttons" ?

Why have a separate Zone ?

Last fine point, we can use the new Decrease/Increase "modifiers" with JogWheel as opposed to CW and CCW types.

[Funkybot]

Originally Posted by Geoff Waddington

How does that square with having everything in "Buttons" ?

Why have a separate Zone ?

Because Zoom can be mean: zoom vertical, zoom horizontal, or toggle track height, I think it makes sense to have it as a separate zone. Otherwise, what would the Zoom button do? Zoom In? Ok, horizontal or vertical? Let's say vertical. Then Shift+Zoom, zooms out to be consistent with markers, but then what? Option+Zoom to zoom in horizontal?

When I first started getting my head around CSI, I tried doing this, which wasn't allowed, but I think you may be more open to today. Zoom as a modifier. Might be worth reconsidering...

    Zoom           Zoom
    Zoom+Up        Reaper 40111                // Zoom in vertical        
    Zoom+Down      Reaper 40112                // Zoom out vertical    
    Zoom+Left      Reaper 1011                 // Zoom out horizontal 
    Zoom+Right     Reaper 1012                 // Zoom in horizontal

...the way the X-Touch is designed, with Zoom in the middle of the arrows, Zoom looks like it was meant to be a modifier (from a surface-perspective). So this might make a lot of sense now. Then you could also add in Zoom+Jogwheel combos.

Also gets rid of the SubZone and does a better job keeping everything in one place.

Last fine point, we can use the new Decrease/Increase "modifiers" with JogWheel as opposed to CW and CCW types.

I actually checked the X-touch.mst to see how Jogwheel was currently setup and matched it. But I agree, would be good to merge Jogwheel into one widget and use the new modifiers.