Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by ramses

Ok, so the C1 is not affected by these new improvements, if I understand you correctly? So, no way of using stepped values and being able to go from low-high and then back high-low? I need both in order to be able to lay out some plugins properly on the C1, if I remember correctly. Also, no way to determine what amount of "turning" will return the next step? Sorry if I'm being unclear.

Stepped values are only for encoders and buttons, not rotary faders like on the C1.

[Geoff Waddington]

Originally Posted by Funkybot

Hi Geoff, was this fix meant to include stepped values? They're not working at all here. The values just aren't moving at all. So I twist the encoder on the "3-position Mode" knob and nothing's happening. The knob is not moving at all. One time I made it jump to minimum, but then it wouldn't move from there.

Things I've tried include:

Acceleration+Steps:

Rotary15 FXParam "10" "Mode" [ (0.001,0.0015,0.002,0.0025,0.005,0.0075,0.0125,0.0215,0.033,0.05,0.075) 0.0 0.5 1.0 ]

Steps Only:

Rotary15 FXParam "10" "Mode" [ 0.0 0.5 1.0 ]

Acceleration Only:

Rotary15 FXParam "10" "Mode" [ (0.001,0.0015,0.002,0.0025,0.005,0.0075,0.0125,0.0215,0.033,0.05,0.075) ]

Nothing Extra:

Rotary15 FXParam "10" "Mode"

Oops, didn't post this important info -- Acceleration only works with deltas, not stepped parameters.

As @MixMonkey posted: "Not sure if we even need to accelerate through stepped parameters now we have such fine control over the step size and acceleration without using SNL."

I think this is the correct behaviour, but I could be missing something

[Funkybot]

Originally Posted by Geoff Waddington

Oops, didn't post this important info -- Acceleration only works with deltas, not stepped parameters.

As @MixMonkey posted: "Not sure if we even need to accelerate through stepped parameters now we have such fine control over the step size and acceleration without using SNL."

I think this is the correct behaviour, but I could be missing something

I couldn't get stepped parameters working at all with encoders though. Like, the parameter doesn't move at all. There was a regression from yesterday.

Turning the encoder assigned to this currently does nothing in the latest build:

Rotary15 FXParam "10" "Mode" [ 0.0 0.5 1.0 ]

Even without acceleration, I'd expect CW turns to step up through the values and stop at the last step, and CCW turns to step down, stopping at the first step.

[Funkybot]

Originally Posted by Geoff Waddington

As @MixMonkey posted: "Not sure if we even need to accelerate through stepped parameters now we have such fine control over the step size and acceleration without using SNL."

I think this is the correct behaviour, but I could be missing something

I'm also not sure I agree we don't need acceleration for stepped values. Why? The resolution is way too fine over here. A tiny, tiny movement of the encoder results in a jumps through the values. It's very awkward.

Imagine two knobs:

1. Standard knob with no steps
2. Three-step knob

For knob #1, I fine tune the movement of the knob so some fast turns move it fast, and slow encoder turns move it in very fine .001 steps. For knob #2, every .001 step results in a .33 value jump, which is a very big difference in the feel. It's very difficult to hit the middle step, and the feel of the two knobs couldn't be any more different. One knob has a nice acceleration from slow to fast, the second knob's response is set to always super fast. A 10-position knob means a relatively small turn will burn through all 10 values from low to high. You have to make tiny, tiny movements to hit the middle values.

When I use Fader7Bit and set the MFTwister to transmit standard CCs, I have to rotate knob #2 about a third of the way to get to jump to 33%. I'd like a way to approximate that same feel with encoders and stepped values.

[MixMonkey]

Originally Posted by Geoff Waddington

New build is up.

Hopefully this fixes at least some of the accelerated encoder issues.

No luck with stepped parameters here. No response to turning the control when steps are defined in the FX.zon.

[MixMonkey]

Originally Posted by Funkybot

I'm also not sure I agree we don't need acceleration for stepped values. Why? The resolution is way too fine over here. A tiny, tiny movement of the encoder results in a jumps through the values. It's very awkward.

Imagine two knobs:

1. Standard knob with no steps
2. Three-step knob

For knob #1, I fine tune the movement of the knob so some fast turns move it fast, and slow encoder turns move it in very fine .001 steps. For knob #2, every .001 step results in a .33 value jump, which is a very big difference in the feel. It's very difficult to hit the middle step, and the feel of the two knobs couldn't be any more different. One knob has a nice acceleration from slow to fast, the second knob's response is set to always super fast. A 10-position knob means a relatively small turn will burn through all 10 values from low to high. You have to make tiny, tiny movements to hit the middle values.

When I use Fader7Bit and set the MFTwister to transmit standard CCs, I have to rotate knob #2 about a third of the way to get to jump to 33%. I'd like a way to approximate that same feel with encoders and stepped values.

The acceleration for continuous controllers recently introduced doesn't really have a bearing on stepped parameters, because it is assigning a delta for each message it's receiving from the surface.

For a stepped parameter control the 'delta' are the individual steps- which may be inconsistent in size. The only way to accelerate the response of a stepped parameter list is to 'jump' entries in the list as the control is turned faster.

I think the easiest (maybe) way of matching the stepped control to an accelerated, continuous one would be to be able to specify the number of encoder ticks per step for each parameter, much like the way we specifiy a minimum delta.

The 3 position knob feels 'fast' because 1 encoder tick = 1 step. If you could set it to be 10 encoder ticks per step, it would feel a lot slower.

Let's hold off on the acceleration until stepped parameters are back to normal (old) operation. Then maybe try being able to set the number of encoder ticks per step and see if this is sufficient.

For myself, accelerating through stepped parameters was only needed when using SNL and we only had those because we couldn't specify a minimum delta, now we can

[Funkybot]

Originally Posted by MixMonkey

The 3 position knob feels 'fast' because 1 encoder tick = 1 step. If you could set it to be 10 encoder ticks per step, it would feel a lot slower.

We definitely think similarly. I was playing around with this in last nights build...

Rotary15 FXParam "10" "Mode" [ 0.0 0.0 0.0 0.0 0.0 0.5 0.5 0.5 0.5 0.5 0.5 1.0 1.0 1.0 1.0 1.0 1.0 ]

...it did help. But that's not a great longterm solution (syntax wise), especially when you get to 11 step parameters. If we could condense the syntax, that would be awesome. Something like this where the number in the parenthesis, when combined with stepped parameters, meant 10 encoder ticks before leaving each step.

Rotary15 FXParam "10" "Mode" [ (10) 0.0 0.5 1.0 ]

Note: I agree step 1 is getting the basic functionality working. Just thinking out loud and ahead.

[MixMonkey]

Originally Posted by Funkybot

We definitely think similarly. I was playing around with this in last nights build...

Rotary15 FXParam "10" "Mode" [ 0.0 0.0 0.0 0.0 0.0 0.5 0.5 0.5 0.5 0.5 0.5 1.0 1.0 1.0 1.0 1.0 1.0 ]

I tried that with old encoder, but it didn't work there. To be honest, with anything up to about 5 steps, press works better for me. I usually assign both the encoder and the press to same parameter when stepping.

Rotary15 FXParam "10" "Mode" [ (10) 0.0 0.5 1.0 ]

This is how I saw it as well, with (10) representing the number of ticks per step.

[Cragster]

Originally Posted by MixMonkey

Here's my C4.zon:


In the CSI prefs for the C4, 'Auto Map Sends' and 'Auto Map FX Menu' are enabled.

Hey mixmonkey. Any chance i could get a peek at your main surface zone file too ? If you remember im trying to get a 2nd surface setup for just fx. im sure im not doing something right. its either one surface or the other. i tried checking the "sync pages" box in csi setup and i have the "auto map fx menu" box checked as well for the fx surface. the FX surface is dead unless i gopage to it.and then when i gopage to it then my main surface is dead. im off to work so no hurry on the reply.ill give another try with it tomorrow. thank you
here is what i have
Main surface (i slashed out the send and fx lines so they can be active in the the other surface??) should i get rid of the fx and send zones in this ?

Zone Home
/OnTrackSelection MapSelectedTrackSendsToWidgets
/OnTrackSelection MapSelectedTrackFXToMenu
IncludedZones
"Buttons|"
"Channel|1-8"
"MasterChannel|"
IncludedZonesEnd
ZoneEnd

Zone "Buttons|"
Shift Shift 
Option Option 
Control Control 
Alt Alt 
Blank1 Reaper "_S&M_SHOWNOTESHELP" // NOTES WINDOW
Blank2 Reaper "40016" // PREFERENCES
Blank3 Reaper "40605" // ACTION LIST
Blank4 Reaper "40454" // EDIT VIEW
Blank5 Reaper "40455" // MIXER VIEW
/Send ToggleMapSelectedTrackSends
/Send Reaper "40293"
Pan Reaper "_dc1079a3ffd4a1438942a677566f9ed3" // FOLDER/CHILDRE
/Plugin ToggleMapSelectedTrackFXMenu
/Plugin Reaper "_S&M_TOGLFXCHAIN"
Shift+Plugin GoZone FocusedFXParameter
Option+Plugin GoPage FX
EQ GoPage Edit
ChannelLeft TrackBank "-1"
ChannelRight TrackBank "1"
BankLeft TrackBank "-8"
BankRight TrackBank "8"
TimeDisplay TimeDisplay
smpteBeats CycleTimeDisplayModes
Rewind Rewind
FastForward FastForward
Stop Stop
Play Play
Record Reaper "1013"
F1 Reaper "40495" // RECORD MONITOR MODE
F2 Reaper "40702" // CREATE NEW TRACK  
F3 Reaper "40701" // CREATE NEW TRACK/INSERT VIRTUAL INSTRU
F4 Reaper "40005" // REMOVE TRACK 
F5 Reaper "40062" // DUPLICATE TRACK 
F6 Reaper "41817" // CONTINUOUS SCROLLING
F7 Reaper "40042" // GO TO START
F8 Reaper "40296" // SELECT ALL TRACKS
F1L2 Reaper "40293" // VIEW ROUTING/SENDS FOR SEL TRACK
F2L2 Reaper "1042" // FOLDER COLLAPSE STATE
F3L2 Reaper "_S&M_TOGLFXCHAIN" // SHOW FX WINDOW FOR SEL TRACK
F4L2 Reaper "_S&M_FXBYPSEL" // BYPASS FX FOR SEL TRACK
F5L2 Reaper "_S&M_SELFXNEXT" // NEXT FX FOR SEL TRACK
F6L2 Reaper "40344" // BYPASS FX FOR ALL TRACKS
F7L2 Reaper "40549" // SHOW FX ABOVE MIXER
F8L2 Reaper "_BR_NORMALIZE_LOUDNESS_ITEMS" // NORMALIZE  
Read TrackAutoMode "1"
Shift+Read GlobalAutoMode "1"
Write TrackAutoMode "3"
Shift+Write GlobalAutoMode "3"
Trim TrackAutoMode "0"
Shift+Trim GlobalAutoMode "0"
Touch TrackAutoMode "2"
Shift+Touch GlobalAutoMode "2"
Latch TrackAutoMode "4"
Shift+Latch GlobalAutoMode "4"
Save Reaper "40026" 
Shift+Save Reaper "40022" // SAVE PROJECT AS 
Undo Reaper "40029"
Shift+Undo Reaper "40030" // REDO
Flip Reaper "40346"
Normal Reaper "40173" // GO TO NEXT MARKER
Marker Reaper "40157" // INSERT MARKER
Loop CycleTimeline
nameValue GoZone Home
Shift+nameValue GoPage Home
Click Reaper "40364" METRONOME
Solo Reaper "40340" // UNSOLO ALL TRACKS
Mode ToggleScrollLink 4
Zoom Reaper "40113" // ZOOM SEL TRACK
Up Reaper "40111" // ZOOM IN VERTICAL
Down Reaper "40112" // ZOOM OUT VERTICAL
Left Reaper "1011" // ZOOM OUT HORIZONTAL
Right Reaper "1012" // ZOOM IN HORIZONTAL
JogWheelRotaryCW Reaper "41667" // NORMAL JOG RIGHT
JogWheelRotaryCCW Reaper "41666" // NORMAL JOG LEFT
Shift+JogWheelRotaryCW Reaper "_SWS_MOVECUR5MSRIGHT" // SLOW JOG
Shift+JogWheelRotaryCCW Reaper "_SWS_MOVECUR5MSLEFT" // SLOW JOG
Control+JogWheelRotaryCW Reaper "40103" // CREATE JOG TIMESEL R
Control+JogWheelRotaryCCW Reaper "40102" // CREATE JOG TIMESEL L
/MasterFader MasterTrackVolume
ZoneEnd

Zone "Channel|"
	TrackNavigator
	VUMeter|  TrackOutputMeterMaxPeakLR
	/VUMeter|  TrackOutputMeterAverageLR
	DisplayUpper|  TrackNameDisplay
	DisplayLower|  TrackPanDisplay
	TrackTouch+DisplayLower|  TrackVolumeDisplay
	RotaryPush| GoZone PanWidth|
	Rotary| TrackPan "0"
	RecordArm|  TrackRecordArm
	Solo|  TrackSolo
	Mute| TrackMute
	Select|  TrackUniqueSelect
	Shift+Select|  TrackRangeSelect
	Control+Select|  TrackSelect
	Shift+Control+Select| TogglePin
	Option+Select| TrackFolderDive
     Alt+Select| TrackUniqueSelect
     Alt+Select| Reaper "41665"
	Fader|  TrackVolume
	TrackTouch+Fader|  TrackVolume
	FaderTouch|  TrackTouch
ZoneEnd

Zone "Pan|1-8"
	TrackNavigator
	Rotary| TrackPan "0"
	RotaryPush| GoZone PanWidth|
ZoneEnd

Zone "PanWidth|1-8"
	TrackNavigator
	Rotary| TrackPanWidth "1"
	RotaryPush| GoZone Pan|
ZoneEnd

Zone "Send|1-8"
      SelectedTrackNavigator
      DisplayUpper| TrackSendNameDisplay
      TrackTouch+DisplayUpper| TrackSendVolumeDisplay
      Mute| TrackSendMute
      Fader| TrackSendVolume
      Rotary| TrackSendPan
      RotaryPush| NoAction
      TrackTouch+Fader| TrackSendVolume
      FaderTouch| TrackTouch
ZoneEnd

Zone "MasterChannel|"
	MasterTrackNavigator
     MasterChannelMeterLeft MasterTrackOutputMeter 0
     MasterChannelMeterRight MasterTrackOutputMeter 1
	MasterFader TrackVolume
	MasterFaderTouch TrackTouch
ZoneEnd

Zone "FXMenu|1-8"
      SelectedTrackNavigator
      DisplayUpper| FXNameDisplay |
      DisplayLower| NoAction
      Rotary| NoAction
      RotaryPush| GoFXSlot |
ZoneEnd

Zone "FocusedFXParameter"
      Fader1 FocusedFXParam
      FaderTouch1 TrackTouch
      DisplayUpper1 FocusedFXParamNameDisplay
      DisplayLower1 FocusedFXParamValueDisplay
      DisplayUpper2 NoAction
      DisplayLower2 NoAction
      DisplayUpper3 NoAction
      DisplayLower3 NoAction
      DisplayUpper4 NoAction
      DisplayLower4 NoAction
      DisplayUpper5 NoAction
      DisplayLower5 NoAction
      DisplayUpper6 NoAction
      DisplayLower6 NoAction
      DisplayUpper7 NoAction
      DisplayLower7 NoAction
      DisplayUpper8 NoAction
      DisplayLower8 NoAction
ZoneEnd

and here is 2nd surface i want to use just for fx (I took out the channel zone-this is the icon platformM+ .just a simple surface 8 faders rotarys and a few buttons. sorry evrythong is a bit jumbled.im just starting with this. some thing are slashed out cause they werent working

Zone Home
OnTrackSelection MapSelectedTrackSendsToWidgets
OnTrackSelection MapSelectedTrackFXToMenu
IncludedZones
"Buttons|"
/"MasterChannel|"
IncludedZonesEnd
ZoneEnd

Zone "Buttons|"
ChannelLeft TrackBank "-1"
ChannelRight TrackBank "1"
BankLeft TrackBank "-8"
BankRight TrackBank "8"
Read MapSelectedTrackFXMenu
Read Reaper "_S&M_TOGLFXCHAIN"
Write ToggleMapSelectedTrackSends
Write Reaper "40293" 
Mixer GoPage Home
Loop NoAction
Rewind NoAction
FastForward NoAction
Stop NoAction
Play NoAction
Record NoAction
Zoom NoAction
/JogWheelRotaryCW Reaper "41667" // NORMAL JOG RIGHT
/JogWheelRotaryCCW Reaper "41666" // NORMAL JOG LEFT
/Shift+JogWheelRotaryCW Reaper "_SWS_MOVECUR5MSRIGHT" // SLOW JO
/Shift+JogWheelRotaryCCW Reaper "_SWS_MOVECUR5MSLEFT" // SLOW JO
/Control+JogWheelRotaryCW Reaper "40103" // CREATE JOG TIMESEL R
/Control+JogWheelRotaryCCW Reaper "40102" // CREATE JOG TIMESEL 
/MasterFader MasterTrackVolume
ZoneEnd

Zone "Send|1-8"
      SelectedTrackNavigator
      DisplayUpper| TrackSendNameDisplay
      TrackTouch+DisplayUpper| TrackSendVolumeDisplay
      Mute| TrackSendMute
      Fader| TrackSendVolume
      Rotary| TrackSendPan
      RotaryPush| NoAction
      TrackTouch+Fader| TrackSendVolume
      FaderTouch| TrackTouch
ZoneEnd

/Zone "MasterChannel|"
	/MasterTrackNavigator
     /MasterChannelMeterLeft MasterTrackOutputMeter 0
     /MasterChannelMeterRight MasterTrackOutputMeter 1
	/MasterFader TrackVolume
	/MasterFaderTouch TrackTouch
ZoneEnd

Zone "FXMenu|1-8"
      SelectedTrackNavigator
      DisplayUpper| FXNameDisplay |
      DisplayLower| NoAction
      Rotary| NoAction
      RotaryPush| GoFXSlot |
      RotaryPush| Reaper "_S&M_SHOWFXCHAIN|"
ZoneEnd

Zone "FocusedFXParameter"
      Fader1 FocusedFXParam
      FaderTouch1 TrackTouch
      DisplayUpper1 FocusedFXParamNameDisplay
      DisplayLower1 FocusedFXParamValueDisplay
      DisplayUpper2 NoAction
      DisplayLower2 NoAction
      DisplayUpper3 NoAction
      DisplayLower3 NoAction
      DisplayUpper4 NoAction
      DisplayLower4 NoAction
      DisplayUpper5 NoAction
      DisplayLower5 NoAction
      DisplayUpper6 NoAction
      DisplayLower6 NoAction
      DisplayUpper7 NoAction
      DisplayLower7 NoAction
      DisplayUpper8 NoAction
      DisplayLower8 NoAction
ZoneEnd

anyway just trying to set these 2 surfaces up to- main surface control normal mixing and 2nd surface control fx. once i get that going then i can go through all the buttons on both and remap them accordingly.

thanks you for your help so far

[MixMonkey]

Originally Posted by Cragster

Hey mixmonkey. Any chance i could get a peek at your main surface zone file too ?

Sure

Zone Home
    OnTrackSelection MapSelectedTrackSendsToWidgets
    IncludedZones
        "Buttons|"
        "Channel|1-8"
        "MasterTrack|"
    IncludedZonesEnd
ZoneEnd


Zone "Buttons|"
    Track                               NoAction
    Send                                ToggleMapSelectedTrackSends
    Pan                                 NoAction
    Plugin                              NoAction
    EQ                                  NoAction
    Instrument                          NoAction
    BankLeft                            TrackBank "-8"
    BankRight                           TrackBank "8"
    ChannelLeft                         TrackBank "-1"
    ChannelRight                        TrackBank "1"
    Flip                                NoAction
    GlobalView                          NoAction
    nameValue                           NoAction
    smpteBeats                          CycleTimeDisplayModes
    TimeDisplay                         TimeDisplay
    F1                                  NoAction
    F2                                  NoAction
    F3                                  NoAction
    F4                                  NoAction
    F5                                  NoAction
    F6                                  NoAction
    F7                                  NoAction
    F8                                  NoAction
    MidiTracks                          NoAction
    Inputs                              NoAction
    AudioTracks                         NoAction
    AudioInstrument                     NoAction
    Aux                                 NoAction
    Busses                              NoAction
    Outputs                             NoAction
    User                                NoAction
    Shift                               Shift
    Option                              Option
    Control                             Control
    Alt                                 Alt     
    Read                                TrackAutoMode "1"
    Write                               TrackAutoMode "3"
    Trim                                TrackAutoMode "0"
    Touch                               TrackAutoMode "2"
    Latch                               TrackAutoMode "4"
    Group                               Reaper "42023"              //Set track automation mode to latch preview
    Shift+Read                          GlobalAutoMode "1"
    Shift+Write                         GlobalAutoMode "3"
    Shift+Trim                          GlobalAutoMode "0"
    Shift+Touch                         GlobalAutoMode "2"
    Shift+Latch                         GlobalAutoMode "4"  
    Shift+Group                         Reaper "42024"              //Set all tracks automation mode to latch preview   
    Save                                ToggleLearnMode
    Undo                                NoAction
    Cancel                              NoAction
    Enter                               NoAction
    Marker                              Reaper "40157"              //Insert marker at current position
    Hold+Marker                         Reaper "40614"              //Edit marker near cursor
    Nudge                               Reaper "_S&M_CYCLACTION_1"  //Show track receives T/W Recall mix visibility and selection
    Cycle                               CycleTimeline
    Drop                                ToggleVCAMode
    Replace                             NoAction
    Click                               Reaper "40364"              //Toggle metronome
    Hold+Click                          Reaper "40363"              //Show metronome settings
    Solo                                ToggleScrollLink 17
    Rewind                              Reaper "40172"              //Go to next marker/project end      
    FastForward                         Reaper "40173"              //Go to previous marker/project start
    Stop                                Stop
    Play                                Play
    Record                              Record
    JogWheelRotaryCW                    Reaper "40647"              //Move cursor right to grid division
    JogWheelRotaryCCW                   Reaper "40646"              //Move cursor left to grid division
    Scrub                               NoAction
    Left                                TrackBank "-8"      
    Right                               TrackBank "8"
    Up                                  TrackBank "1"
    Down                                TrackBank "-1"
    Zoom                                ForceScrollLink
    ZoneEnd


Zone "Channel|"
    TrackNavigator
    VUMeter|                            TrackOutputMeter
    DisplayUpper|                       TrackNameDisplay
    DisplayLower|                       TrackPanDisplay
    TrackTouch+DisplayLower|            TrackVolumeDisplay
    RotaryPush|                         GoZone PanWidth|
    Rotary|                             TrackPan "0"
    RecordArm|                          TrackRecordArm
    Solo|                               TrackSolo
    Mute|                               TrackMute
    Select|                             TrackUniqueSelect
    Shift+Select|                       TrackRangeSelect
    Control+Select|                     TrackSelect
    Shift+Control+Select|               TogglePin
    Fader|                              TrackVolume
    TrackTouch+Fader|                   TrackVolume
    FaderTouch|                         TrackTouch
    Hold+Select|                        TrackUniqueSelect
    Hold+Select|                        Reaper "41665"
    Hold+Select|                        TrackToggleVCASpill
ZoneEnd


Zone "MasterTrack|"
    MasterTrackNavigator
    MasterFader                         TrackVolume
    TrackTouch+MasterFader              TrackVolume
    MasterFaderTouch                    TrackTouch
    Control+MasterFader                 FocusedFXParam
    Control+TrackTouch+MasterFader      FocusedFXParam
    Control+MasterFaderTouch            TrackTouch
ZoneEnd


Zone "Send|1-8"
    SelectedTrackNavigator
    DisplayUpper|                       TrackSendNameDisplay
    DisplayLower|                       TrackSendVolumeDisplay
    Mute|                               TrackSendMute
    Fader|                              TrackSendVolume
    TrackTouch+Fader|                   TrackSendVolume   
    FaderTouch|                         TrackTouch
ZoneEnd 


Zone "PanWidth|1-8"
    TrackNavigator
    Rotary|                             TrackPanWidth 1
    DisplayLower|                       TrackPanWidthDisplay
    TrackTouch+DisplayLower|            TrackVolumeDisplay
    RotaryPush|                         GoZone Home
ZoneEnd

For the main surface, Auto Map Sends is disabled, but Sends are available on a button (ToggleMapSelectedTrackSends) This maps the selected track Sends to the faders (for finer control and automation if needed)

Synch Zones Across Surfaces is disabled.

[ramses]

Originally Posted by Geoff Waddington

Stepped values are only for encoders and buttons, not rotary faders like on the C1.

I humbly disagree. Using stepped values, I've mapped, for example, the ReaComp to have usable, reasonable attack times in conjuction with my C1. If I don't map it using stepped values, the attack times are far to crude, unpredictable and out of range (just turning the knob without holding the shift button). They don't fit me. It works, but it does not live up to the potential of the CSI. I need control over the initial transient, fine-grained control, and I need to be able to set the attack time like I want to, not being constrained by the existing 7bit step-size logic.

Perhaps something else can be done for the 7bit faders on the C1. Perhaps it is in the works. And, if it is, I'm absolutely prepared to wait patiently. I hope you can see where I'm coming from.

Perhaps I'm doing something wrong, but I really don't think so. For example, could you tell me what attack-times you're getting with ReaComp just turning the attack knob (from zero) on the C1, in milliseconds,?

Sorry to bother you with this, but I think it is important.

[Geoff Waddington]

Originally Posted by MixMonkey

The acceleration for continuous controllers recently introduced doesn't really have a bearing on stepped parameters, because it is assigning a delta for each message it's receiving from the surface.

For a stepped parameter control the 'delta' are the individual steps- which may be inconsistent in size. The only way to accelerate the response of a stepped parameter list is to 'jump' entries in the list as the control is turned faster.

I think the easiest (maybe) way of matching the stepped control to an accelerated, continuous one would be to be able to specify the number of encoder ticks per step for each parameter, much like the way we specifiy a minimum delta.

The 3 position knob feels 'fast' because 1 encoder tick = 1 step. If you could set it to be 10 encoder ticks per step, it would feel a lot slower.

Yup, agree.

[Geoff Waddington]

Originally Posted by Funkybot

Rotary15 FXParam "10" "Mode" [ (10) 0.0 0.5 1.0 ]

Love this !!

[Geoff Waddington]

Originally Posted by ramses

I humbly disagree. Using stepped values, I've mapped, for example, the ReaComp to have usable, reasonable attack times in conjuction with my C1. If I don't map it using stepped values, the attack times are far to crude, unpredictable and out of range (just turning the knob without holding the shift button). They don't fit me. It works, but it does not live up to the potential of the CSI. I need control over the initial transient, fine-grained control, and I need to be able to set the attack time like I want to, not being constrained by the existing 7bit step-size logic.

Perhaps something else can be done for the 7bit faders on the C1. Perhaps it is in the works. And, if it is, I'm absolutely prepared to wait patiently. I hope you can see where I'm coming from.

Perhaps I'm doing something wrong, but I really don't think so. For example, could you tell me what attack-times you're getting with ReaComp just turning the attack knob (from zero) on the C1, in milliseconds,?

Sorry to bother you with this, but I think it is important.

Yup, totally agree there should be a way for the C1 rotaries to used stepped values.

It's on the list

[Geoff Waddington]

As much as it seems like all hell broke loose, we actually have made very good progress

Propose the following for discussion:

Widgets

Widget RotaryA
	Encoder b0 16 7f
WidgetEnd

Widget RotaryB
	Encoder b0 17 2f b0 17 41
WidgetEnd

Widget RotaryC
	Encoder b0 18 7f [ > 41-51 < 3f-2f  ]
WidgetEnd

Widget RotaryD
	Encoder b0 19 7f [ > 41 43 45 47 49 < 3f 3e 3d 3c 3b ]
WidgetEnd

RotaryA is the stock MCU style which uses standard acceleration and therefore the delta value it emits changes with acceleration. This is the one we've used since the beginning.

RotaryB is used for oddballs and Widgets you wish to "decelerate", you state increment (e.g. 2f) and decrement (e.g. 41)
This type has no acceleration, it puts out a constant delta, can be useful sometimes
It is also useful as a tick count generator for stepped value step sizes (explained below)

RotaryC and RotaryD are for use in tandem with actions that support custom accelerated delta values.

Actions

RotaryA FXParam "10" "Mode" [ (0.003) 0.0-0.5 ]

RotaryB FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

RotaryC FXParam "12" "Mode" [ (0.1,0.2,0.3,0.4,0.5) ]

RotaryD FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) ]

We have overridden RotaryA's natural delta, delta now 0.003, and we have constrained it's range (0.0-0.5).

It takes 10 ticks for RotaryB to go to the next step.
If you omit (10) it defaults to 1.

RotaryC and RotaryD use acceleration delta steps provided by Widget input.

RotaryD is also constrained to an acceleration range 0.0-0.3.


Overall

Range defaults to 0.0-1.0.

Delta defaults to 0 - the Action will use encoder generated delta if Delta is 0.

It's a start

[MixMonkey]

Originally Posted by Geoff Waddington

As much as it seems like all hell broke loose, we actually have made very good progress

Propose the following for discussion:

Widgets

Widget RotaryA
	Encoder b0 16 7f
WidgetEnd

Widget RotaryB
	Encoder b0 17 2f b0 17 41
WidgetEnd

Widget RotaryC
	Encoder b0 18 7f [ > 41-51 < 3f-2f  ]
WidgetEnd

Widget RotaryD
	Encoder b0 19 7f [ > 41 43 45 47 49 < 3f 3e 3d 3c 3b ]
WidgetEnd

RotaryA is the stock MCU style which uses standard acceleration and therefore the delta value it emits changes with acceleration. This is the one we've used since the beginning.

RotaryB is used for oddballs and Widgets you wish to "decelerate", you state increment (e.g. 2f) and decrement (e.g. 41)
This type has no acceleration, it puts out a constant delta, can be useful sometimes
It is also useful as a tick count generator for stepped value step sizes (explained below)

RotaryC and RotaryD are for use in tandem with actions that support custom accelerated delta values.

Actions

RotaryA FXParam "10" "Mode" [ (0.003) 0.0-0.5 ]

RotaryB FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

RotaryC FXParam "12" "Mode" [ (0.1,0.2,0.3,0.4,0.5) ]

RotaryD FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) ]

We have overridden RotaryA's natural delta, delta now 0.003, and we have constrained it's range (0.0-0.5).

It takes 10 ticks for RotaryB to go to the next step.
If you omit (10) it defaults to 1.

RotaryC and RotaryD use acceleration delta steps provided by Widget input.

RotaryD is also constrained to an acceleration range 0.0-0.3.


Overall

Range defaults to 0.0-1.0.

Delta defaults to 0 - the Action will use encoder generated delta if Delta is 0.

It's a start

I expect I'm missing something, but how do I use RotaryD with stepped parameters?

[Geoff Waddington]

Originally Posted by MixMonkey

I expect I'm missing something, but how do I use RotaryD with stepped parameters?

You don't

You setup the stepped values list for a nice feel at medium/high speeds, and for fine work you use the one, the only, brand new "Delta Chopper" from RonCo !!

I've been thinking we really want to have a nice feel overall at normal speeds, then "gear down" for ultra fine work.

So, the new proposal is, whenever Shift is engaged, the tick count value = tick count value * 10.

I think this fits better with the way we really work...

[MixMonkey]

Originally Posted by Geoff Waddington

You don't

But I have to commit to a single style of Encoder definition in the .mst and that has to work with both parameter types, continuous and stepped

[Geoff Waddington]

Originally Posted by MixMonkey

But I have to commit to a single style of Encoder definition in the .mst and that has to work with both parameter types, continuous and stepped

See, there's always somethin'

Back to the drawing board

[Geoff Waddington]

Originally Posted by MixMonkey

But I have to commit to a single style of Encoder definition in the .mst and that has to work with both parameter types, continuous and stepped

Hmmm...

Thinking about this, RotaryB is your friend here.

[Funkybot]

Why shouldn't this be allowed:

Widget RotaryD
	Encoder b0 19 7f [ > 41 43 45 47 49 < 3f 3e 3d 3c 3b ]
WidgetEnd

Combined with...

RotaryD FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

???

I'm thinking the widget defines the capabilities (this is an encoder with no acceleration, this is an encoder with an acceleration range, this is an encoder with acceleration values) but the action should actually dictate what CSI does with the encoder. So in the above example, step through those values for every 10 encoder clicks (ignores acceleration - knows to do this based on action syntax). It shouldn't care what type of underlying encoder it is just "move to next step up after 10 positive clicks, or next step down after 10 decrements."

[Geoff Waddington]

The more I think about RotaryC and RotaryD, the less I like them.

Here's one issue.

Say the rotary has 4 levels of acceleration, 0, 33%, 67%, and 100%.

If you have an acceleration data values list in the Action that contains 5 delta values for acceleration, you may get some pretty funky behaviour (dead zones, jumps, etc.) as you try to map 4 to 5.

Maybe apply KISS and only support:
RotaryA type (delta based) Shift multiplies delta by 0.1 for fine work
RotaryB type (step based) Shift multiplies tick count by 10 for fine work

Much simpler.

You can use either widget type, it's all in the Action.

Is that sufficient ?

[Geoff Waddington]

Originally Posted by Funkybot

Why shouldn't this be allowed:

Widget RotaryD
	Encoder b0 19 7f [ > 41 43 45 47 49 < 3f 3e 3d 3c 3b ]
WidgetEnd

Combined with...

RotaryD FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

???

I'm thinking the widget defines the capabilities (this is an encoder with no acceleration, this is an encoder with an acceleration range, this is an encoder with acceleration values) but the action should actually dictate what CSI does with the encoder. So in the above example, step through those values for every 10 encoder clicks (ignores acceleration - knows to do this based on action syntax). It shouldn't care what type of underlying encoder it is just "move to next step up after 10 positive clicks, or next step down after 10 decrements."

Yup, you're making the same basic decoupling argument just made in the previous post (cross post)

[MixMonkey]

Originally Posted by Geoff Waddington

See, there's always somethin'

Back to the drawing board

Sorry

Hmmm...

Thinking about this, RotaryB is your friend here.

....but then you give up the lovely acceleration you've just implemented.

Thinking about the way the encoders originally worked (TypeA). At that time they must have still been sending out the range of values they do now, but CSI was just ignoring the changes and getting on with things. You even had a proto-acceleration model based on the rate that the ticks were received.

For parameters with a stepped definition, do the same thing now. Ignore the fact that different messages are being received according to how fast the control is turned and just let the ticks step through the values. If a ticks per step definition can be worked into it, great.

About Shift. Two hands = bad.

[MixMonkey]

Originally Posted by Geoff Waddington

The more I think about RotaryC and RotaryD, the less I like them.

Here's one issue.

Say the rotary has 4 levels of acceleration, 0, 33%, 67%, and 100%.

If you have an acceleration data values list in the Action that contains 5 delta values for acceleration, you may get some pretty funky behaviour (dead zones, jumps, etc.) as you try to map 4 to 5.

Maybe apply KISS and only support:
RotaryA type (delta based) Shift multiplies delta by 0.1 for fine work
RotaryB type (step based) Shift multiplies tick count by 10 for fine work

Much simpler.

You can use either widget type, it's all in the Action.

Is it sufficient ?

You can't put the choice between delta and step in the .mst. It has to be in the .zon (in one form or another) otherwise you'll end up in the ridiculous situation of having to permanently designate controls to be either step or delta and assign parameters to them accordingly.

[Funkybot]

Originally Posted by Geoff Waddington

The more I think about RotaryC and RotaryD, the less I like them.

Here's one issue.

Say the rotary has 4 levels of acceleration, 0, 33%, 67%, and 100%.

If you have an acceleration data values list in the Action that contains 5 delta values for acceleration, you may get some pretty funky behaviour (dead zones, jumps, etc.) as you try to map 4 to 5.

Maybe apply KISS and only support:
RotaryA type (delta based) Shift multiplies delta by 0.1 for fine work
RotaryB type (step based) Shift multiplies tick count by 10 for fine work

Much simpler.

Is it sufficient ?

Not sure I get that. Are you talking the action (.zon) or surface definition (.mst)?

I feel like your prior post was spot on with the 4 widget types in the .mst. I just feel like the syntax of the action should dictate what to do with that widget. I don't know why mixing and matching shouldn't be possible.

Let's say I have this widget with acceleration, I should be able to do each of the following:

Widget RotaryA
	Encoder b0 18 7f [ > 41-51 < 3f-2f  ]
WidgetEnd

Action Example 1:
RotaryA FXParam "10" "Mode" [ (0.003) 0.0-0.5 ]

Ignore acceleration, every encoder step moves the VST parameter up or down by .003. A value of 41 to 51 moves 0.003 up. A value of 34 to 2f moves 0.003 down. Upper lower parameter bounds defined as 0.0 to 0.5. No issues.


Action Example 2:
RotaryA FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

Ignore acceleration, CSI moves to next step based on number of encoder clicks up or down. 10 steps up moves from 0.0 to 0.5 (or 0.5 to 1.0). 10 steps down does the opposite. No problem.


Action Example 3:
RotaryA FXParam "12" "Mode" [ (0.1,0.2,0.3,0.4,0.5) ]

Now we're creating custom acceleration ranges like last night. No change to behavior from last night's build. I create a custom acceleration curve. No issue here either.

Action Example 4:
RotaryA FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) ]

Ok, this one i don't get. Is the 0.0-0.3 the acceleration range? If so, why do I need the data in the parenthesis? Or is it the min max parameter ranges.

Now, what if your encoder doesn't have acceleration defined in the .mst but the action is Example 3 or 4? Keep it simple. Ignore any acceleration.

[Geoff Waddington]

Originally Posted by MixMonkey

Sorry

....but then you give up the lovely acceleration you've just implemented.

Thinking about the way the encoders originally worked (TypeA). At that time they must have still been sending out the range of values they do now, but CSI was just ignoring the changes and getting on with things. You even had a proto-acceleration model based on the rate that the ticks were received.

For parameters with a stepped definition, do the same thing now. Ignore the fact that different messages are being received according to how fast the control is turned and just let the ticks step through the values. If a ticks per step definition can be worked into it, great.

About Shift. Two hands = bad.

Yup, all true, the examples were terribly concocted

Get the point on Shift for sure.

[Geoff Waddington]

Originally Posted by MixMonkey

You can't put the choice between delta and step in the .mst. It has to be in the .zon (in one form or another) otherwise you'll end up in the ridiculous situation of having to permanently designate controls to be either step or delta and assign parameters to them accordingly.

Once again, terrible illustration, meant the example Actions associated with RotaryA and RotaryB, not the Widgets themselves, my bad.

[MixMonkey]

Originally Posted by Geoff Waddington

Once again, terrible illustration, meant the example Actions associated with RotaryA and RotaryB, not the Widgets themselves, my bad.

Aaah, I see Thought it was strange you would propose such an appalling regression

[Geoff Waddington]

Originally Posted by Funkybot

I feel like your prior post was spot on with the 4 widget types in the .mst. I just feel like the syntax of the action should dictate what to do with that widget. I don't know why mixing and matching shouldn't be possible.

Yup, terrible illustration on my part, mixing and matching allowed.

[Funkybot]

Originally Posted by Geoff Waddington

Yup, terrible illustration on my part, mixing and matching allowed.

Oh sweet. Then I fully endorse your proposal! Though I'm still not entirely clear what the last action did:

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) ]

So if the 0.0 to 0.3 are the acceleration range, then why the parenthesis?

[Geoff Waddington]

Originally Posted by Funkybot

Oh sweet. Then I fully endorse your proposal! Though I'm still not entirely clear what the last action did:

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) ]

So if the 0.0 to 0.3 are the acceleration range, then why the parenthesis?

It says use acceleration values, but only the first 3.

Turns out that's not one of my better ideas , see next post

[Geoff Waddington]

OK, another try:

3 Rotary types

RotaryA
RotaryB
RotaryC/D only differ in how acceleration values are specified

opt = optional

Action [] defintion

Delta based: [ value range (opt) -> acceleration delta values (opt) -> delta (opt) ]

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) (0.003) ]


Step based: [ value range (opt) -> acceleration delta values (opt) -> tick count (opt) -> step values (required) ].

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (10,7,5,2,1) (10) 0.0 0.33 0.67 1.0 ]

Notice how with the Step based the acceleration values go down, meaning less ticks needed to jump to next step value.

[MixMonkey]

Originally Posted by Geoff Waddington

OK, another try:

3 Rotary types

RotaryA
RotaryB
RotaryC/D only differ in how acceleration values are specified

opt = optional

Action [] defintion

Delta based: [ value range (opt) -> acceleration delta values (opt) -> delta (opt) ]

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (0.1,0.2,0.3,0.4,0.5) (0.003) ]


Step based: [ value range (opt) -> acceleration delta values (opt) -> tick count (opt) -> step values (required) ].

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (10,7,5,2,1) (10) 0.0 0.33 0.67 1.0 ]

Notice how with the Step based the acceleration values go down, meaning less ticks needed to jump to next step value.

Ok, for the avoidance of confusion, the three Rotary types A,B,C/D can be either delta or stepped, depending on how the action is defined?
(obviously there would be no point in defining acceleration characteristics for a Rotary type that doesn't support them)

In your two examples 'RotaryA' isn't specifiying Rotary type A is it?

In the second example, 0.0-0.3 seems to define a value range, which should be inherent in a step action. Also, if you define acceleration values in the step based action, you don't need a tick size. The acceleration values are the tick size.

So:

RotaryA FXParam "13" "Mode" [ (10,7,5,2,1) 0.0 0.33 0.67 1.0 ]

....at the slowest turn rate, one step takes 10 encoder ticks, then 7 at the next slowest turn rate and so on until at the fast turn rate, 1 step only takes 1 encoder tick.

[Funkybot]

1. I'm not sure I understand the newly proposed approach. May just need to see more examples.

2. I thought this combo was easy to explain and read while offering a enough flexibility to get the job done...

Widget SomeEncoder //option 1
	Encoder b0 16 7f
WidgetEnd

Widget SomeEncoder //option 2
	Encoder b0 17 2f b0 17 41
WidgetEnd

Widget SomeEncoder //option 3
	Encoder b0 18 7f [ > 41-51 < 3f-2f  ]
WidgetEnd

Widget SomeEncoder //option 4
	Encoder b0 19 7f [ > 41 43 45 47 49 < 3f 3e 3d 3c 3b ]
WidgetEnd

With..

SomeEncoder FXParam "10" "Mode" [ (0.003) 0.0-0.5 ]

SomeEncoder FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

SomeEncoder FXParam "12" "Mode" [ (0.1,0.2,0.3,0.4,0.5) ]

...what are the benefits of the newly proposed approach over this one? Other than seeming to be more complicated? lol

[Geoff Waddington]

Originally Posted by MixMonkey

Ok, for the avoidance of confusion, the three Rotary types A,B,C/D can be either delta or stepped, depending on how the action is defined?
(obviously there would be no point in defining acceleration characteristics for a Rotary type that doesn't support them)

Correct.

Originally Posted by MixMonkey

In the second example, 0.0-0.3 seems to define a value range, which should be inherent in a step action.

Yes, but you might not want to use all of the step values, for testing, or whatever other reason.

Originally Posted by MixMonkey

So:

RotaryA FXParam "13" "Mode" [ (10,7,5,2,1) 0.0 0.33 0.67 1.0 ]

....at the slowest turn rate, one step takes 10 encoder ticks, then 7 at the next slowest turn rate and so on until at the fast turn rate, 1 step only takes 1 encoder tick.

Once again a terrible illustration, the scale values are a divisor not an absolute value, here's a better example:

RotaryA FXParam "13" "Mode" [ 0.0-0.3 (1,2,3,5,10) (10) 0.0 0.33 0.67 1.0 ]

So:
10/1 = 10 ticks
10/2 = 5 ticks
10/3 = 3 ticks
10/5 = 2 ticks
10/10 = 1 tick

to proceed to the next step.

[Geoff Waddington]

Originally Posted by Funkybot

1. I'm not sure I understand the newly proposed approach. May just need to see more examples.

2. I thought this combo was easy to explain and read while offering a enough flexibility to get the job done...

Widget SomeEncoder //option 1
	Encoder b0 16 7f
WidgetEnd

Widget SomeEncoder //option 2
	Encoder b0 17 2f b0 17 41
WidgetEnd

Widget SomeEncoder //option 3
	Encoder b0 18 7f [ > 41-51 < 3f-2f  ]
WidgetEnd

Widget SomeEncoder //option 4
	Encoder b0 19 7f [ > 41 43 45 47 49 < 3f 3e 3d 3c 3b ]
WidgetEnd

Yes, but I call it 3 different types:
1) original
2) define inc/dec explicitly
3) supports acceleration -- 2 types of definition -- range or discrete values

Originally Posted by Funkybot

With..

SomeEncoder FXParam "10" "Mode" [ (0.003) 0.0-0.5 ]

SomeEncoder FXParam "11" "Mode" [ (10) 0.0 0.5 1.0 ]

SomeEncoder FXParam "12" "Mode" [ (0.1,0.2,0.3,0.4,0.5) ]

...what are the benefits of the newly proposed approach over this one? Other than seeming to be more complicated? lol

These examples are missing lots of optional parameters.

I'll post some more examples.

[MixMonkey]

Originally Posted by Geoff Waddington

Yes, but you might not want to use all of the step values, for testing, or whatever other reason.

This still seems to be unecessary, unless its prescence makes parsing easier. If I don't want steps, I leave them out of the list.

the scale values are a divisor not an absolute value, here's a better example:

Again, if it's easier to have it as a divisor, fair enough. Otherwise just have an absolute value- much easier to understand.

[Geoff Waddington]

Originally Posted by MixMonkey

This still seems to be unecessary, unless its prescence makes parsing easier. If I don't want steps, I leave them out of the list.

Yes, it's easier to leave in than program out, so laziness rules here

Originally Posted by MixMonkey

Again, if it's easier to have it as a divisor, fair enough. Otherwise just have an absolute value- much easier to understand.

100% correct -- absolute value it is

[Funkybot]

Originally Posted by Geoff Waddington

100% correct -- absolute value it is