Control Surface Integration (CSI) Technical Feature Discussion

[Funkybot]

Originally Posted by Geoff Waddington

New build is up.

CSI Support Files.zip

CSI Exp.zip

Added support for .mst Step Size, Encoder Steps, and Acceleration Values.

Well on our way to auto mapping for FX !

As I started setting up my .mst I thought to myself, "I really hope this works with MFTEncoder", then continued on full steam ahead. It looks like it doesn't. I did make a backup though so no great loss.

In case it is supposed to work with MFTEncoder, here are the updates I made in the .mst:

StepSize
    Rotary 0.003
StepSizeEnd

EncoderSteps
    Rotary  [ < 3f 3e 3d 3c 3b 3a 39 38 36 33 2f > 41 42 43 44 45 46 47 48 4a 4d 51 ]  
EncoderStepsEnd

AccelerationValues
    Rotary    0.001 0.002 0.003 0.004 0.005 0.006 0.0075 0.01 0.02 0.035 0.05
AccelerationValuesEnd

...

Widget RotaryA1 Rotary
	MFTEncoder b0 00 7f
	FB_Fader7Bit b0 00 00
WidgetEnd

...one thing that stuck out while creating that: I thought you wanted to get away from brackets with the new syntax but you're still using them for the EncoderSteps.

Here's what CSI's input log shows when I turn said encoder...

IN <- MFTwister b0  00  45 
IN <- MFTwister b0  00  47 
IN <- MFTwister b0  00  46 
IN <- MFTwister b0  00  43 
IN <- MFTwister b0  00  45 
IN <- MFTwister b0  00  47 
IN <- MFTwister b0  00  48 
IN <- MFTwister b0  00  43 
IN <- MFTwister b0  00  44 
IN <- MFTwister b0  00  43 
IN <- MFTwister b0  00  43

It looks like the it no longer recognizes the widget in the .mst using this new syntax. I suspect that's due to he widget type.

If it's not supposed to work with MFTEncoder yet, any chance that will be ready soon? If not, no worries, I saved a backup of my prior .mst file just in case.

[Geoff Waddington]

Originally Posted by Funkybot

As I started setting up my .mst I thought to myself, "I really hope this works with MFTEncoder", then continued on full steam ahead. It looks like it doesn't. I did make a backup though so no great loss.

In case it is supposed to work with MFTEncoder, here are the updates I made in the .mst:

StepSize
    Rotary 0.003
StepSizeEnd

EncoderSteps
    Rotary  [ < 3f 3e 3d 3c 3b 3a 39 38 36 33 2f > 41 42 43 44 45 46 47 48 4a 4d 51 ]  
EncoderStepsEnd

AccelerationValues
    Rotary    0.001 0.002 0.003 0.004 0.005 0.006 0.0075 0.01 0.02 0.035 0.05
AccelerationValuesEnd

...

Widget RotaryA1 Rotary
	MFTEncoder b0 00 7f
	FB_Fader7Bit b0 00 00
WidgetEnd

...one thing that stuck out while creating that: I thought you wanted to get away from brackets with the new syntax but you're still using them for the EncoderSteps.

Here's what CSI's input log shows when I turn said encoder...

IN <- MFTwister b0  00  45 
IN <- MFTwister b0  00  47 
IN <- MFTwister b0  00  46 
IN <- MFTwister b0  00  43 
IN <- MFTwister b0  00  45 
IN <- MFTwister b0  00  47 
IN <- MFTwister b0  00  48 
IN <- MFTwister b0  00  43 
IN <- MFTwister b0  00  44 
IN <- MFTwister b0  00  43 
IN <- MFTwister b0  00  43

It looks like the it no longer recognizes the widget in the .mst using this new syntax. I suspect that's due to he widget type.

If it's not supposed to work with MFTEncoder yet, any chance that will be ready soon? If not, no worries, I saved a backup of my prior .mst file just in case.

Sorry man, should have mentioned that it only works with Encoder so far.

MFTEncoder is a beast unto itself, as you know.

I was hoping to do the shakedown cruise with Encoder and then apply the principles to MFTEncoder.

The [] are there to maintain easy backward compatibility for now, they will be removed once we prove the concept.

Just looked at the code, may be able to remove MFTEncoder entirely once this is all working.

It's a fair bit of coding to do these things, so wanted to make sure everything worked properly before making the changes.

[UNdark]

Originally Posted by Funkybot

This is one of the things I called out in our PM's, but this line in particular sticks out to me as being potentially problematic.

Plugin      Reaper //_BR_SHOW_FX_ENV_SEL_TRACK       // SWS/BR: Show...

You're telling CSI "hey, there's a Reaper action coming" then there's a set of slashes before the action name "_BR_SHOW_FX_ENV_SEL_TRACK". So you left it kind of open. The action isn't commented out, because the parser will expect a Reaper action, but that action is not actually defined.

If you meant to comment out the whole line, then comment out the whole line by putting a single forward slash at the start like this.

/ Plugin      Reaper _BR_SHOW_FX_ENV_SEL_TRACK       // SWS/BR: Show...

I would advise strongly against commenting out the line halfway through. That's not the correct syntax for commenting. Might not even do any harm, but it's definitely not helping from a troubleshooting perspective.

I'll follow that advise - cheers!

[Geoff Waddington]

Originally Posted by Funkybot

As I started setting up my .mst I thought to myself, "I really hope this works with MFTEncoder", then continued on full steam ahead. It looks like it doesn't. I did make a backup though so no great loss.

StepSize
    Rotary 0.003
StepSizeEnd

EncoderSteps
    Rotary  < 3f 3e 3d 3c 3b 3a 39 38 36 33 2f > 41 42 43 44 45 46 47 48 4a 4d 51  
EncoderStepsEnd

AccelerationValues
    Rotary    0.001 0.002 0.003 0.004 0.005 0.006 0.0075 0.01 0.02 0.035 0.05
AccelerationValuesEnd

...

Widget RotaryA1 Rotary
	MFTEncoder b0 00 7f
	FB_Fader7Bit b0 00 00
WidgetEnd

Looking at this, I think it's worthwhile redesigning this new feature.

It's way too easy to screw up, and get the number of Rotary steps and Acceleration values not to agree.

For the same reason, I think we should eliminate this notation:

    Rotary   [ < 41-47 > 01-07 ]

Propose we do the following to improve the whole situation, including readability, at the slight expense of a one time verbosity in the case of contiguous ranges:

StepSize
    Rotary 0.001
StepSizeEnd

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

Had to shorten the values slightly, as the forum was screwing up the formatting, but you get the idea.

Where there used to be ranges, things will now need to be stated explicitly:

StepSize
    Rotary 0.003
StepSizeEnd

AccelerationValues
    Rotary Dec 41     42    43    44    45    46    47  
    Rotary Inc 01     02    03    04    05    06    07  
    Rotary Val 0.0006 0.001 0.002 0.003 0.008 0.04  0.08 
AccelerationValuesEnd

I think this is better, any thoughts ?

[MixMonkey]

Originally Posted by Geoff Waddington

I think this is better, any thoughts ?

Looks good!

[Funkybot]

Totally agree. That new syntax looks cleaner and helps explain the relationship between each encoder value and the acceleration value that corresponds to it.

[Geoff Waddington]

You will just need this for any accelerated encoder, including MFTEncoder:

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

By giving it a Widget class, you are telling CSI that the following values are defined at the top of the .mst file and will be used for this Widget, unless they are overridden in the EZFXZone:

StepSize
    Rotary 0.001
StepSizeEnd

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

If you want to use the older style, just include the acceleration range as before (or indicate MFTEncoder), and define acceleration and step values in the Zone.

[Funkybot]

So the MFTEncoder will still hang out, but we can eliminate an it if we choose using the new syntax? Sounds good to me!

[Geoff Waddington]

Originally Posted by Funkybot

So the MFTEncoder will still hang out, but we can eliminate an it if we choose using the new syntax? Sounds good to me!

Yes, exactly !

[Puck]

Originally Posted by Geoff Waddington

You will just need this for any accelerated encoder, including MFTEncoder:

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

By giving it a Widget class, you are telling CSI that the following values are defined at the top of the .mst file and will be used for this Widget, unless they are overridden in the EZFXZone:

StepSize
    Rotary 0.001
StepSizeEnd

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

If you want to use the older style, just include the acceleration range as before (or indicate MFTEncoder), and define acceleration and step values in the Zone.

Looks good to me!

Just curious if you can use the new style mst and also override the default acceleration in a zone?

Nevermind that. A little quick on the draw with the question that you clearly answered in the post I quoted

[Geoff Waddington]

New build is up.

CSI Support Files.zip

CSI Exp.zip

As per our redesign discussion.

StepSize
    Rotary 0.003
StepSizeEnd

AccelerationValues
    Rotary Dec 41     42    43    44    45    46    47  
    Rotary Inc 01     02    03    04    05    06    07  
    Rotary Val 0.0006 0.001 0.002 0.003 0.008 0.04  0.08 
AccelerationValuesEnd

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

[Funkybot]

Working great here with the MFTwister and this...

StepSize
    Rotary 0.003
StepSizeEnd

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

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

It's really nice to be able to tweak the acceleration globally. I decided that last value had been a little too high and tamed that back a bit.

The only thing I'm iffy on terms of feedback on the syntax is the first row of the widget. There's nothing that screams to me "this is the widget name" and "this is the widget class".

So it reads a little silly going left to right. Might this be better?

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

That way, from top to bottom, it's WidgetName, WidgetClass (if any), Widget Type and Address, Feedback. Just helps break it up and makes it easier to explain.

[Geoff Waddington]

Originally Posted by Funkybot

Working great here with the MFTwister and this...

StepSize
    Rotary 0.003
StepSizeEnd

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

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

It's really nice to be able to tweak the acceleration globally. I decided that last value had been a little too high and tamed that back a bit.

The only thing I'm iffy on terms of feedback on the syntax is the first row of the widget. There's nothing that screams to me "this is the widget name" and "this is the widget class".

So it reads a little silly going left to right. Might this be better?

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

That way, from top to bottom, it's WidgetName, WidgetClass (if any), Widget Type and Address, Feedback. Just helps break it up and makes it easier to explain.

Great, glad it's working, thanks for testing !!

Yeah, I hear ya' on the syntax.

It's too tricky to code the way you suggest and maintain backward compatibility though.

Don't forget this file very rarely gets modified, is there perhaps another way ?

Maybe simply call it RotaryClass ?

StepSize
    RotaryClass 0.003
StepSizeEnd

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

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

[Funkybot]

I'd lean towards keeping as-is then - wasn't a big deal. Though, calling it RotaryClass is indeed more clear. Let some others weigh in if anyone feels strongly about it one way or the other.

I can just explain on the wiki either way.

[MixMonkey]

Originally Posted by Geoff Waddington

Great, glad it's working, thanks for testing !!

Yeah, I hear ya' on the syntax.

It's too tricky to code the way you suggest and maintain backward compatibility though.

Don't forget this file very rarely gets modified, is there perhaps another way ?

Maybe simply call it RotaryClass ?

RotaryClass sounds a lot better to me, gives an idea of what its function is, ie a kind of meta data.

[Geoff Waddington]

Maybe even RotaryWidgetClass ?

[MixMonkey]

Originally Posted by Geoff Waddington

Maybe even RotaryWidgetClass ?

Even better

[Geoff Waddington]

Ok, RotaryWidgetClass will be in next build.

Also, the other day we were talking about adding similar tags to act as hints for the auto FX map generator.

Turns out those are totally unnecessary.

We can do that internally when CSI parses Encoder, FB_TwoState, etc.

We already have context, it's built into whatever CSI generates for a given Widget line.

Matter of fact there are 2 internal Widget types that can be used as hints for the auto FX mapping, generatorClass, and feedbackClass.

These will be very helpful in determining how to match Widgets to FX parameters.

[Geoff Waddington]

Any ideas on how to take all of this new info and automatically determine a reasonable tick count for a given pairing of an accelerated Widget/FX param step list ?

[Funkybot]

Originally Posted by Geoff Waddington

Ok, RotaryWidgetClass will be in next build.

Also, the other day we were talking about adding similar tags to act as hints for the auto FX map generator.

Turns out those are totally unnecessary.

We can do that internally when CSI parses Encoder, FB_TwoState, etc.

We already have context, it's built into whatever CSI generates for a given Widget line.

Matter of fact there are 2 internal Widget types that can be used as hints for the auto FX mapping, generatorClass, and feedbackClass.

These will be very helpful in determining how to match Widgets to FX parameters.

Just thinking this through...what if you don't want widgets used in FX.zon's? Example: you own an X-Touch Universal, and you only want to map the following in EZFX.zon's:

1. Fader
2. Rotary
3. RotaryPush

...wouldn't you need some way to tell CSI, "only map these particular widgets to FX and nothing else"? Otherwise, you could end up with things assigned to the function buttons, or the Global View buttons, etc.

So for that reason, maybe it makes sense to still have classes flagged in the .mst file for things like:

AbsoluteControlWidgetClass
ButtonWidgetClass

Similarly, the MFTwister has 64 rotary encoders and 64 buttons once you get into the 4 banks of controls. Someone might want to only designate the bank 1 widgets for EZFXZon mapping and not have buttons mapped on the bank 2 widgets.

So I think the user should have some way of flagging which widgets to include versus having CSI assume that any buttons should get brought in and used because it's able to parse them.

[Geoff Waddington]

Originally Posted by Funkybot

Just thinking this through...what if you don't want widgets used in FX.zon's? Example: you own an X-Touch Universal, and you only want to map the following in EZFX.zon's:

1. Fader
2. Rotary
3. RotaryPush

...wouldn't you need some way to tell CSI, "only map these particular widgets to FX and nothing else"? Otherwise, you could end up with things assigned to the function buttons, or the Global View buttons, etc.

So for that reason, maybe it makes sense to still have classes flagged in the .mst file for things like:

AbsoluteControlWidgetClass
ButtonWidgetClass

Similarly, the MFTwister has 64 rotary encoders and 64 buttons once you get into the 4 banks of controls. Someone might want to only designate the bank 1 widgets for EZFXZon mapping and not have buttons mapped on the bank 2 widgets.

So I think the user should have some way of flagging which widgets to include versus having CSI assume that any buttons should get brought in and used because it's able to parse them.

Yup, agree 100%, the post was all about how to categorize, not whether or not to use them.

Remember our discussions a while back about EWidgets ?

Widget GlobalView // not eligible

EWidget Rotary1   // eligible

[Funkybot]

Originally Posted by Geoff Waddington

Any ideas on how to take all of this new info and automatically determine a reasonable tick count for a given pairing of an accelerated Widget/FX param step list ?

I'm going to approach this from a syntax perspective, because I think the values themselves will vary per surface type and there will be no one right answer.

The MFTwister sends out a LOT of messages when it's set to Velocity Sensitive. I love it. But you need a LOT of ticks at low step counts as not to blow right past the param value you're trying to get to. So if there's a low step count, I may want 20 ticks to go by. And if there's a really high number of steps, I may want only 3 ticks to go by.

So I'm thinking you could implement something like this:

FXParamStepCountValues
    FXParamStepTicks  25 25 25 25 20 20 20 15 15  15  15  10  10  10  5   5   5   5   3
    FXParamStepCount  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20+ 
FXParamStepCountValuesEnd

And if you're on an MCU, you probably want to reduce that top set of numbers. So maybe that would be defined in the .mst like this:

FXParamStepCountValues
    FXParamStepTicks  9  9  8  8  7  6  5  5  3    
    FXParamStepCount  2  3  4  5  6  7  8  9  10+
FXParamStepCountValuesEnd

[Funkybot]

Originally Posted by Geoff Waddington

Yup, agree 100%, the post was all about how to categorize, not whether or not to use them.

Remember our discussions a while back about EWidgets ?

Widget GlobalView // not eligible

EWidget Rotary1   // eligible

Ah ok...I was confused and thinking EWidget would break existing .mst's so you were looking for something that could be appended at the end to do the same thing like with Encoders.

Something like...

Widget Fader1 AbsoluteWidgetClass
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
WidgetEnd

[Geoff Waddington]

Originally Posted by Funkybot

Ah ok...I was confused and thinking EWidget would break existing .mst's so you were looking for something that could be appended at the end to do the same thing like with Encoders.

Something like...

Widget Fader1 AbsoluteWidgetClass
	Fader14Bit e0 7f 7f
	FB_Fader14Bit e0 7f 7f
WidgetEnd

CSI will be upgraded to treat Widget and EWidget the same, except that EWidgets will cause CSI to set the eligible flag on the Widget, super simple.

[jakeman19]

Originally Posted by Geoff Waddington

New build is up.

CSI Support Files.zip

CSI Exp.zip

As per our redesign discussion.

StepSize
    Rotary 0.003
StepSizeEnd

AccelerationValues
    Rotary Dec 41     42    43    44    45    46    47  
    Rotary Inc 01     02    03    04    05    06    07  
    Rotary Val 0.0006 0.001 0.002 0.003 0.008 0.04  0.08 
AccelerationValuesEnd

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

Geoff, I know you now have a x-touch and for the most part the programming as of late you've tested on the x-touch. I just downloaded the new CSI Exp and support files.
Am I going to enjoy all these new changes even though I use a MCU?
Cross referencing the x-touch and MCU Buttons.zon or others I see differences.

Or if anyone else wants to chime in.

Jd

[Geoff Waddington]

Originally Posted by Funkybot

I'm going to approach this from a syntax perspective, because I think the values themselves will vary per surface type and there will be no one right answer.

The MFTwister sends out a LOT of messages when it's set to Velocity Sensitive. I love it. But you need a LOT of ticks at low step counts as not to blow right past the param value you're trying to get to. So if there's a low step count, I may want 20 ticks to go by. And if there's a really high number of steps, I may want only 3 ticks to go by.

Right, so maybe I'm missing something, but wouldn't you also set the step size smaller on the MFT, since it sends a lot of messages compared to an MCU encoder?

My thought is that you can use that information coupled with the number of steps to get the tick count.

Example 1 -- 3 steps
MCU gets a fairly high tick count because there are few steps and MCU step size is medium.

MFT gets a very high tick count because there are few steps and MFT step size is small.

Example 2 -- 7 steps
MCU gets a medium tick count because there are now more steps and MCU step size is still medium.

MFT gets a high tick count because there are now more steps and MFT step size is still small.

Seems like with the info available, we can make a pretty good calculation...

[Geoff Waddington]

Originally Posted by jakeman19

Geoff, I know you now have a x-touch and for the most part the programming as of late you've tested on the x-touch. I just downloaded the new CSI Exp and support files.
Am I going to enjoy all these new changes even though I use a MCU?
Cross referencing the x-touch and MCU Buttons.zon or others I see differences.

Or if anyone else wants to chime in.

Jd

Yes, all surfaces will get the advantages, important to note it is only for EZFXZones right now.

Once we get it working properly, we will upgrade all Zones.

[Funkybot]

Originally Posted by Geoff Waddington

Seems like with the info available, we can make a pretty good calculation...

I'm following everything you say up until right there, where you lose me every time.

I'm not getting what you're trying to calculate. Are you trying to calculate one set number that CSI can use for all surfaces by default when this information doesn't otherwise exist in an .mst? Like a default value? If yes, then, just build the default around what feels good for you on the X-Touch.

But my assumption would be that there's got to be some way for the user to customize those values in the .mst similar to what I described. I don't think it will be possible to come up with a fixed table that will work well for everything. Someone would always want to tweak it.

Sorry if I'm totally not understanding the question and something simple is flying right over my head.

[Geoff Waddington]

Let me try this another way:

FXParamStepCountValues
    FXParamStepTicks  25 25 25 25 20 20 20 15 15  15  15  10  10  10  5   5   5   5   3
    FXParamStepCount  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20+ 
FXParamStepCountValuesEnd

This table says the tick values go from 25 to 3, based on step counts.

It uses these values because the MFT puts out a lot of messages for a small amount of rotation.

Because the MFT puts out a lot of messages for a small amount of rotation, you would also set the step size accordingly -- let's say 0.001.


And if you're on an MCU, you probably want to reduce that top set of numbers. So maybe that would be defined in the .mst like this:

FXParamStepCountValues
    FXParamStepTicks  9  9  8  8  7  6  5  5  3    
    FXParamStepCount  2  3  4  5  6  7  8  9  10+
FXParamStepCountValuesEnd

This table says the tick values go from 9 to 3, based on step counts.

It uses these values because the MCU puts out fewer messages for the same amount of rotation.

Because the MCU puts out fewer messages for the same amount of rotation, you would also set the step size accordingly -- let's say 0.003.

Now let's do a little math:

The highest tick count for the MFT is 25, and the MFT step size is 0.001.

The highest tick count for the MCU is 9, and the MCU step size is 0.003.

Let's normalize those step sizes by multiplying by 1000.

So we have:

MFT highest value = 25
MFT step size = 1

MCU highest value = 9
MCU step size = 3

Now let's multiply:

MFT -- 25 X 1 = 25

MCU -- 9 X 3 = 27

The tables are approximately the same, if you account for step size.

They represent the same mathematical relationship.

So, if we can get a table that works for a set of step counts for an MFT, we can use the step size difference and automatically generate the proper table for the MCU, does that make sense ?

In other words, we only need one set of step count tables, and the step size for a particular Widget does the rest.

Of course, you can always override to taste, but I'm thinking we can get very close automatically.

[jacksoonbrowne]

Hi Geoff,

Here's better cleaned code (I think) implementation of using same receiveOnPort and sendToPort port (needed for X32 baby step 1)

These changes should not break anything where receiveOnPort and sendToPort are different.


control_surface_integrater.cpp ---> modify

....
    if(tokens.size() > 1) // ignore comment lines and blank lines
    {
        if(tokens[0] == MidiSurfaceToken && tokens.size() == 4)
            midiSurfaces[tokens[1]] = new Midi_ControlSurfaceIO(tokens[1], GetMidiInputForPort(atoi(tokens[2].c_str())), GetMidiOutputForPort(atoi(tokens[3].c_str())));
        else if (tokens[0] == OSCSurfaceToken && tokens.size() == 5)
            oscSurfaces[tokens[1]] = new OSC_ControlSurfaceIO(tokens[1], tokens[2], tokens[3], tokens[4]);
....

control_surface_integrater.cpp ---> add

OSC_ControlSurfaceIO::OSC_ControlSurfaceIO(string surfaceName, string rxOnPort, string txToPort, string txToIpAddress) : name_(surfaceName)
{
    shared_ptr<oscpkt::UdpSocket> inSocket= GetInputSocketForPort(surfaceName, stoi(rxOnPort));;
    shared_ptr<oscpkt::UdpSocket> outSocket;

    if (rxOnPort != txToPort)
    {
        // WHEN INPUT AND OUTPUT SOCKETS ARE NOT THE SAME
         outSocket = GetOutputSocketForAddressAndPort(surfaceName, txToIpAddress, stoi(txToPort));
         memcpy((void*)&inSocket_,  (void*)&inSocket,  sizeof(shared_ptr<oscpkt::UdpSocket>));
         memcpy((void*)&outSocket_, (void*)&outSocket, sizeof(shared_ptr<oscpkt::UdpSocket>));
    }
    else
    {
        // WHEN INPUT AND OUTPUT SOCKETS ARE THE SAME -- DO MAGIC :)
        struct addrinfo hints;
        struct addrinfo* ptr;
        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_family = AF_INET;      // IPV4
        hints.ai_socktype = SOCK_DGRAM; // UDP
        hints.ai_flags = 0x00000001;    // socket address is intended for bind
        getaddrinfo(txToIpAddress.c_str(), txToPort.c_str(), &hints, &ptr);
        memcpy(&(inSocket->remote_addr), (void*)(ptr->ai_addr), ptr->ai_addrlen);

        memcpy((void*)&inSocket_,  (void*)&inSocket, sizeof(shared_ptr<oscpkt::UdpSocket>));
        memcpy((void*)&outSocket_, (void*)&inSocket, sizeof(shared_ptr<oscpkt::UdpSocket>));
        outputSockets_[surfaceName] = outSocket_;
    }
 }

control_surface_integrater.h ---> add

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class OSC_ControlSurfaceIO
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
{
    ....
public:
    OSC_ControlSurfaceIO(string name, string rxOnPort, string txToPort, string ipAddress);
    ....

Cheers,
Roy

[Geoff Waddington]

Originally Posted by jacksoonbrowne

Hi Geoff,

Here's better cleaned code (I think) implementation of using same receiveOnPort and sendToPort port (needed for X32 baby step 1)

These changes should not break anything where receiveOnPort and sendToPort are different.

Thanks, will be in next build.

[edit] On closer inspection, not sure this type of code doesn't circumvent shared pointer semantics, could be disastrous:

memcpy((void*)&outSocket_, (void*)&inSocket, sizeof(shared_ptr<oscpkt::UdpSocket>));

I've changed all those shared pointers to regular pointers, since they have app lifetime, and checked it in.

It will be in next build, could you verify I got things right here:

OSC_ControlSurfaceIO::OSC_ControlSurfaceIO(string surfaceName, string receiveOnPort, string transmitToPort, string transmitToIpAddress) : name_(surfaceName)
{
    if (receiveOnPort != transmitToPort)
    {
        inSocket_  = GetInputSocketForPort(surfaceName, stoi(receiveOnPort));;
        outSocket_ = GetOutputSocketForAddressAndPort(surfaceName, transmitToIpAddress, stoi(transmitToPort));
    }
    else
    {
        // WHEN INPUT AND OUTPUT SOCKETS ARE THE SAME -- DO MAGIC :)
        oscpkt::UdpSocket* inSocket = GetInputSocketForPort(surfaceName, stoi(receiveOnPort));;

        struct addrinfo hints;
        struct addrinfo* addressInfo;
        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_family = AF_INET;      // IPV4
        hints.ai_socktype = SOCK_DGRAM; // UDP
        hints.ai_flags = 0x00000001;    // socket address is intended for bind
        getaddrinfo(transmitToIpAddress.c_str(), transmitToPort.c_str(), &hints, &addressInfo);
        memcpy(&(inSocket->remote_addr), (void*)(addressInfo->ai_addr), addressInfo->ai_addrlen);

        inSocket_  = inSocket;
        outSocket_ = inSocket;
        outputSockets_[surfaceName] = outSocket_;
    }
 }

[Geoff Waddington]

New build is up.

CSI Support Files.zip

CSI Exp.zip

Changed Rotary to RotaryWidgetClass.

Changed JogWheel to JogWheelWidgetClass.

Added EWidget support.

Added X32 OSC socket support.

[Puck]

Originally Posted by Geoff Waddington

Because the MFT puts out a lot of messages for a small amount of rotation, you would also set the step size accordingly -- let's say 0.001.

Are you getting this bit from the the default acceleration values?

[Funkybot]

Originally Posted by Geoff Waddington

Let me try this another way:

FXParamStepCountValues
    FXParamStepTicks  25 25 25 25 20 20 20 15 15  15  15  10  10  10  5   5   5   5   3
    FXParamStepCount  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20+ 
FXParamStepCountValuesEnd

This table says the tick values go from 25 to 3, based on step counts.

It uses these values because the MFT puts out a lot of messages for a small amount of rotation.

Because the MFT puts out a lot of messages for a small amount of rotation, you would also set the step size accordingly -- let's say 0.001.


And if you're on an MCU, you probably want to reduce that top set of numbers. So maybe that would be defined in the .mst like this:

FXParamStepCountValues
    FXParamStepTicks  9  9  8  8  7  6  5  5  3    
    FXParamStepCount  2  3  4  5  6  7  8  9  10+
FXParamStepCountValuesEnd

This table says the tick values go from 9 to 3, based on step counts.

It uses these values because the MCU puts out fewer messages for the same amount of rotation.

Because the MCU puts out fewer messages for the same amount of rotation, you would also set the step size accordingly -- let's say 0.003.

Now let's do a little math:

The highest tick count for the MFT is 25, and the MFT step size is 0.001.

The highest tick count for the MCU is 9, and the MCU step size is 0.003.

Let's normalize those step sizes by multiplying by 1000.

So we have:

MFT highest value = 25
MFT step size = 1

MCU highest value = 9
MCU step size = 3

Now let's multiply:

MFT -- 25 X 1 = 25

MCU -- 9 X 3 = 27

The tables are approximately the same, if you account for step size.

They represent the same mathematical relationship.

So, if we can get a table that works for a set of step counts for an MFT, we can use the step size difference and automatically generate the proper table for the MCU, does that make sense ?

In other words, we only need one set of step count tables, and the step size for a particular Widget does the rest.

Of course, you can always override to taste, but I'm thinking we can get very close automatically.

So what you're proposing is a formula like this...

StepSize * X = 25

...then once CSI determines the value of X, that will be used to say, "this is how many ticks we will count before moving to the next stepped param in a list". That may provide a good starting value. If we can have that AND the ability to create a custom scale that based on the StepCount in the .mst then I'd say, go for it!

You've got an X-Touch and it's probably the most popular surface, so I'd say dial in the default so it feels good on that. Then, for the rest of us, if it's too slow, too fast, or doesn't scale well across large parameter counts, then we can edit our .mst's to customize it.

The UAD Fairchild Input control has something like 20 steps, and the 1176 Ratio param has 10 or 11 (from memory), so those may be good params to help dial in the default against 3-step params. Trying to find a happy middle so turning the Fairchild Input knob doesn't become a chore, and trying to hit middle position in a 3-way toggle isn't too easy to blow past.

But I think the key for me is "StepCount" scaling. If you've got a 20 step param like the Fairchild's Input gain, you really don't want more than like 3 ticks to go from step to step. If we counted 9 ticks per step and it took 180 ticks to go from one end of the knob to another, that may not be responsive enough. Whereas that may be perfect for a 3-step param. That's why I keep harping on and on about that ability to customize it based on count size.

Hope that's helpful.

[Funkybot]

I would be remiss if I didn't mention that stepped params are almost a complete non-issue and map very well to absolute controls when available. Stick 'em on a motorized fader, or an MFTwister in absolute mode, and they work beautifully. It's only when they're mapped to encoder widgets that they become tricky.

Maybe any auto-mapping system could try to account for that and do something like:

2 or 3 steps = assign to a Press widget if any
4 or more steps = first try to assign to Fader widget if any, if none, then try to assign to an encoder widget

The Twister in absolute mode was really elegant in how much it simplified things at the expense of resolution.

[Geoff Waddington]

Originally Posted by Puck

Are you getting this bit from the the default acceleration values?

No, acceleration has nothing to do with this.

[Geoff Waddington]

Originally Posted by Funkybot

So what you're proposing is a formula like this...

StepSize * X = 25

...then once CSI determines the value of X, that will be used to say, "this is how many ticks we will count before moving to the next stepped param in a list".

That's true, if and only if there are are 2 steps in the step count, as per your step count table example entry for 2 steps -- 25 ticks.

I sense we are getting somewhere, so let's continue.

I would would rather start with the most sensitive encoder to get better math, the MFT looks like a good candidate.

Let's say this is the hypothetical one and only base table we will use, just for illustration purposes:

    FXParamStepTicks  25 25 25 25 20 20 20 15 15  15  15  10  10  10  5   5   5   5   3
    FXParamStepCount  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20+

We want to know what tick count we should use for an FX param that has 10 steps.

We look it up and find out the base tick count is 15.

If the surface is an MFT, we look up the step size and find out it's 0.001, all good, we use a tick count of 15.

But, if we have an MCU with a step size of 0.003, we know we need to divide by 3, so instead of 15, we get a tick count of 5.

So, by using only one table as a base reference and incorporating step size into the equation, we can get the same effect as using many tables.

Let's do another.

We want to know what tick count we should use for an FX param that has 14 steps.

We look it up in the table and get 10 ticks.

For an MFT we just use 10 ticks.

For an MCU we have to remember to divide by 3, so we get 3 ticks.

This is essentially what you are proposing, but we get there with only one base reference table.

So, I would ask that you come up with the base table, since the MFT is the most sensitive.

Then, based on step size, each surface will come up with a value very close to correct -- your example for the MCU table:

    FXParamStepTicks  9  9  8  8  7  6  5  5  5    
    FXParamStepCount  2  3  4  5  6  7  8  9  10+

In the above table, the tick count value for a 10 step parameter is 5, the exact same result we got above using the base table, and taking step size into account:

I'm saying we can get the same (or at least sufficiently close to the same) results with only one table, if we utilize step size.

This is reasonable, because that's exactly what you do anyway.

You set the step size for the MFT low (0.001) because it is so sensitive.

You set the step size for the MCU higher (0.003) because it is less sensitive.

We can use that to scale the whole step size/tick count table and get the same results you do with many tables, with only one base table.

[Funkybot]

It’s starting to click now. I say just go ahead and build it out as you just described. If it just works, that will be awesome. And if it’s less than ideal in some circumstances, it can be tweaked (maybe as simply as adjusting the steep size).

[Geoff Waddington]

Originally Posted by Funkybot

It’s starting to click now. I say just go ahead and build it out as you just described. If it just works, that will be awesome. And if it’s less than ideal in some circumstances, it can be tweaked (maybe as simply as adjusting the steep size).

Cool, can you provide the table you use for the MFT, we'll use that as the base table.

Do you typically use a step size of 0.001 for the MFT, sounds like that would be about right.

[Funkybot]

Originally Posted by Geoff Waddington

Cool, can you provide the table you use for the MFT, we'll use that as the base table.

Do you typically use a step size of 0.001 for the MFT, sounds like that would be about right.

Currently using a stepsize of 0.001.

Here's my stepped param list from the FX Configurator I use for the Twister. Tick count is in the parens. It's probably not a perfect scaled response, but I found it works well enough.

# of Steps: [ values ]
2:    [ 0.00 1.00 ]                                                                                                                                            
3:    [ (25) 0.00 0.50 1.00 ]                                                                                                                                       
4:    [ (25) 0.00 0.33 0.67 1.00 ]                                                                                                                                  
5:    [ (25) 0.00 0.25 0.50 0.75 1.00 ]                                                                                                                             
6:    [ (20) 0.00 0.20 0.40 0.60 0.80 1.00 ]                                                                                                                        
7:    [ (20) 0.00 0.17 0.33 0.50 0.67 0.83 1.00 ]                                                                                                                   
8:    [ (20) 0.00 0.14 0.29 0.43 0.57 0.71 0.86 1.00 ]                                                                                                              
9:    [ (20) 0.00 0.13 0.25 0.38 0.50 0.63 0.75 0.88 1.00 ]                                                                                                         
10:   [ (15) 0.00 0.11 0.22 0.33 0.44 0.56 0.67 0.78 0.89 1.00 ]                                                                                                    
11:   [ (15) 0.00 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90 1.00 ]                                                                                               
12:   [ (15) 0.00 0.09 0.18 0.27 0.36 0.45 0.55 0.64 0.73 0.82 0.91 1.00 ]                                                                                          
13:   [ (15) 0.00 0.08 0.17 0.25 0.33 0.42 0.50 0.58 0.67 0.75 0.83 0.92 1.00 ]                                                                                     
14:   [ (10) 0.00 0.08 0.15 0.23 0.31 0.38 0.46 0.54 0.62 0.69 0.77 0.85 0.92 1.00 ]                                                                                
15:   [ (10) 0.00 0.07 0.14 0.21 0.29 0.36 0.43 0.50 0.57 0.64 0.71 0.79 0.86 0.93 1.00 ]                                                                           
16:   [ (10) 0.00 0.07 0.13 0.20 0.27 0.33 0.40 0.47 0.53 0.60 0.67 0.73 0.80 0.87 0.93 1.00 ]                                                                      
17:   [ (5)  0.00 0.06 0.13 0.19 0.25 0.31 0.38 0.44 0.50 0.56 0.63 0.69 0.75 0.81 0.88 0.94 1.00 ]                                                                 
18:   [ (5)  0.00 0.06 0.12 0.18 0.24 0.29 0.35 0.41 0.47 0.53 0.59 0.65 0.71 0.76 0.82 0.88 0.94 1.00 ]                                                            
19:   [ (5)  0.00 0.06 0.11 0.17 0.22 0.28 0.33 0.39 0.44 0.50 0.56 0.61 0.67 0.72 0.78 0.83 0.89 0.94 1.00 ]                                                       
20:   [ (5)  0.00 0.05 0.11 0.16 0.21 0.26 0.32 0.37 0.42 0.47 0.53 0.58 0.63 0.68 0.74 0.79 0.84 0.89 0.95 1.00 ]                                                  
21:   [ (3)  0.00 0.05 0.10 0.15 0.20 0.25 0.30 0.35 0.40 0.45 0.50 0.55 0.60 0.65 0.70 0.75 0.80 0.85 0.90 0.95 1.00 ]                                             
22:   [ (3)  0.00 0.05 0.10 0.14 0.19 0.24 0.29 0.33 0.38 0.43 0.48 0.52 0.57 0.62 0.67 0.71 0.76 0.81 0.86 0.90 0.95 1.00 ]                                        
23:   [ (3)  0.00 0.05 0.09 0.14 0.18 0.23 0.27 0.32 0.36 0.41 0.45 0.50 0.55 0.59 0.64 0.68 0.73 0.77 0.82 0.86 0.91 0.95 1.00 ]                                   
24:   [ (3)  0.00 0.04 0.09 0.13 0.17 0.22 0.26 0.30 0.35 0.39 0.43 0.48 0.52 0.57 0.61 0.65 0.70 0.74 0.78 0.83 0.87 0.91 0.96 1.00 ]                              
25:   [ (3)  0.00 0.04 0.08 0.13 0.17 0.21 0.25 0.29 0.33 0.38 0.42 0.46 0.50 0.54 0.58 0.63 0.67 0.71 0.75 0.79 0.83 0.88 0.92 0.96 1.00 ]