Control Surface Integration (CSI) Project Development, Features, Ideas, Discussion

[Puck]

Originally Posted by MixMonkey

Not quite sure I see the distinction between Latching and Toggling. Surely if a button has an indicator and a feedback definition, you get feedback, if it doesn't, you don't

As far as the layout goes, it looks fine. I think for the purposes of confusion reduction in these examples, it might be better to use F1, F2 etc as buttons. My Zoom example was poor because the button name and its purpose was the same thing.

Edit: I suppose this would require the assignment of a button to be optional. Since this use case was geared towards surfaces with a limited amount of buttons.


If this is to replace SubZones, we also need to cater for the use case of "stepping through" the modified Zones using a pair of buttons. What you've described covers the "direct access" SubZone model. This was the primary reason I thought Zone definition of the modifiers might be a good idea, although I totally admit I'm still thinking all this through

Agreed on both counts!

I suppose the stepping through use case would just be the order in which the user laid out the modifiers in the zone and you could next/prev and loop around at the end?

Could this really be the replacement for subzones? Technically, since subzones is already a used term and this could be made to work like subzones, couldn’t we just call them subzones and they just work differently under the hood (presumably much better from a programming standpoint)

[Geoff Waddington]

Originally Posted by MixMonkey

Not quite sure I see the distinction between Latching and Toggling. Surely if a button has an indicator and a feedback definition, you get feedback, if it doesn't, you don't

Right, I should have said, if the button doesn't send a release, you need Toggle.

Originally Posted by MixMonkey

If this is to replace SubZones, we also need to cater for the use case of "stepping through" the modified Zones using a pair of buttons. What you've described covers the "direct access" SubZone model. This was the primary reason I thought Zone definition of the modifiers might be a good idea, although I totally admit I'm still thinking all this through

Buried in a one line post a few back, I'm now thinking we still need GoSubZone as well as Surface modifiers.

[Geoff Waddington]

Originally Posted by Puck

Agreed on both counts!

I suppose the stepping through use case would just be the order in which the user laid out the modifiers in the zone and you could next/prev and loop around at the end?

Could this really be the replacement for subzones? Technically, since subzones is already a used term and this could be made to work like subzones, couldn’t we just call them subzones and they just work differently under the hood (presumably much better from a programming standpoint)

In a one line post a few back, I say we still need both SubZones and Surface modifiers.

[MixMonkey]

Originally Posted by Geoff Waddington

Buried in a one line post a few back, I'm now thinking we still need GoSubZone as well as Surface modifiers.

Can GoSubZone be made to work? I wondered whether modifiers was an easier option.

[Geoff Waddington]

Originally Posted by MixMonkey

Can GoSubZone be made to work? I wondered whether modifiers was an easier option.

Yup, GoSubZone will work, it's just a bit complicated

[Puck]

Is the reason we need both because GoSubZone inherits the navigation of the parent zone and surface modifiers wouldn’t do that?

Haha actually I assume it’s more technical than that because you probably would have just said it.

[MixMonkey]

Originally Posted by Geoff Waddington

Yup, GoSubZone will work, it's just a bit complicated

Awesome! SubZones are the missing piece for me at the moment, particularly in FX Zones.

[Funkybot]

Outside of stepping through FX SubZones, is there a preferred use-case, or rather a functional distinction as to when a user would want to use a surface modifier versus a GoSubZone? The piece I'm struggling with is "why both?" If from the "Buttons" zone I could call a "Scrub" SubZone, and a "Zoom" SubZone, and a "NavigateTracks" SubZone that all change the jogwheel behavior, then isn't that functionally the same as having surface modifiers that do that? And if yes, then what value add are surface modifiers other than easier syntax?

What I'm getting at is, I think we agree that SubZones are a necessary evil, but assuming they were working, would we also need surface modifiers or would they just be duplicating SubZone functionality? Would it make sense to build out SubZones first, then afterwards, see if we still need Surface Modifiers?

Note: I do like the idea of Surface Modifiers from an ease of use perspective so don't take this as me lobbying against them. I think it's an easier concept for newbies to grasp but I'm not seeing where it adds functionality that SubZones wouldn't provide.

[MixMonkey]

Originally Posted by Funkybot

Outside of stepping through FX SubZones, is there a preferred use-case, or rather a functional distinction as to when a user would want to use a surface modifier versus a GoSubZone? The piece I'm struggling with is "why both?" If from the "Buttons" zone I could call a "Scrub" SubZone, and a "Zoom" SubZone, and a "NavigateTracks" SubZone that all change the jogwheel behavior, then isn't that functionally the same as having surface modifiers that do that? And if yes, then what value add are surface modifiers other than easier syntax?

I don't think there is a difference. For me, they're interchangeable.

[Geoff Waddington]

Originally Posted by Puck

Is the reason we need both because GoSubZone inherits the navigation of the parent zone and surface modifiers wouldn’t do that?

Haha actually I assume it’s more technical than that because you probably would have just said it.

Nah, it's just finicky to get set up correctly, that's all, we'll get there, don't worry

[Geoff Waddington]

Originally Posted by Funkybot

Outside of stepping through FX SubZones, is there a preferred use-case, or rather a functional distinction as to when a user would want to use a surface modifier versus a GoSubZone? The piece I'm struggling with is "why both?" If from the "Buttons" zone I could call a "Scrub" SubZone, and a "Zoom" SubZone, and a "NavigateTracks" SubZone that all change the jogwheel behavior, then isn't that functionally the same as having surface modifiers that do that? And if yes, then what value add are surface modifiers other than easier syntax?

What I'm getting at is, I think we agree that SubZones are a necessary evil, but assuming they were working, would we also need surface modifiers or would they just be duplicating SubZone functionality? Would it make sense to build out SubZones first, then afterwards, see if we still need Surface Modifiers?

Note: I do like the idea of Surface Modifiers from an ease of use perspective so don't take this as me lobbying against them. I think it's an easier concept for newbies to grasp but I'm not seeing where it adds functionality that SubZones wouldn't provide.

Yeah, it was more for the easier syntax thing, but it does add other syntactic complexity -- e.g. the means of defining Surface modifiers, so there is that -- let's leave it alone for now...

[Cragster]

Originally Posted by Funkybot

Navelpluisje, have you been keeping up with the CSI v2 discussions around loading zones with custom names? Do you have any in your Faderport setup? You'd likely be the perfect person to weigh in to make sure we're not leaving out anything critical or just getting more involved in discussions around potential solutions/workarounds.

Does this mean custom zones will not work in V2 ?
Like JogwheelHack
FXParam
Or any zone that's not a usual suspect?
Thanks

[MixMonkey]

Originally Posted by Cragster

Does this mean custom zones will not work in V2 ?

Not until SubZones are implemented.

[Cragster]

Originally Posted by MixMonkey

Not until SubZones are implemented.

Thanks . That was kinda answered for me in the posts after the one I quoted. CSI moves fast sometimes I cant keep up lol. Thanks again

[mattrglenn]

Originally Posted by Geoff Waddington

Glad to hear it's working !

CSI now determines what banks by the presence of a Zone named "Track", along with Channel count, so if your surface has one Channel, enter the number one for Channel count in the config.

If you also want it to participate in banking define a "Track" Zone for that surface.

The whole offset thing should work out after that, if it still doesn't, please let me know.

If you do not want it to participate in banking use another Zone for the Track controls -- e.g. my Console 1 has 1 entered for the Channel count, but the Track controls are in a Zone called "SelectedTrack".


Much work to be done on the v 2.0 documentation

Just circling back to this from a while ago…

Thanks Geoff — I think I might have mis-characterized the problem. I did a bit more testing and the TrackBank functionality is working just fine, as long as I do it from my surface. The problem only seems to pop up when I click to a track with my mouse.

To test, I set up a test session with 16 tracks. My X-touch settings are as follows:

• Number of Channels = 8
• Channel Start Position = 0

I start out with track 1 selected. The surface shows tracks 1-8. If I click on any track between 9 and 16, CSI automatically banks the surface to channels 9-16. So far so good.

If I start out with track 16 selected and click on track 1, however, the surface banks to show tracks 2-9. If I start on track 16 and select track 3, the surface banks to 4-11. Again, this is only an issue when I click to the earlier tracks — using the bank button on the surface works as-expected. I get the same result with a much larger test session, too. When clicking to a track in a LATER bank in the session, the surface follows correctly; when clicking to an EARLIER bank, the bank is offset by 1.

Setting the Channel Start Position to -1 allows me to compensate for the issue, but obviously introduces other problems (namely, I can't bank to the last track in the session at all and need to add a blank one at the end).

Hopefully this makes sense!

[Geoff Waddington]

Originally Posted by mattrglenn

Just circling back to this from a while ago…

Thanks Geoff — I think I might have mis-characterized the problem. I did a bit more testing and the TrackBank functionality is working just fine, as long as I do it from my surface. The problem only seems to pop up when I click to a track with my mouse.

To test, I set up a test session with 16 tracks. My X-touch settings are as follows:

• Number of Channels = 8
• Channel Start Position = 0

I start out with track 1 selected. The surface shows tracks 1-8. If I click on any track between 9 and 16, CSI automatically banks the surface to channels 9-16. So far so good.

If I start out with track 16 selected and click on track 1, however, the surface banks to show tracks 2-9. If I start on track 16 and select track 3, the surface banks to 4-11. Again, this is only an issue when I click to the earlier tracks — using the bank button on the surface works as-expected. I get the same result with a much larger test session, too. When clicking to a track in a LATER bank in the session, the surface follows correctly; when clicking to an EARLIER bank, the bank is offset by 1.

Setting the Channel Start Position to -1 allows me to compensate for the issue, but obviously introduces other problems (namely, I can't bank to the last track in the session at all and need to add a blank one at the end).

Hopefully this makes sense!

Thanks for testing !

Now I see, yup, looks like a bug, will investigate.

[MixMonkey]

Think I've come across a little bug in the last two builds.

The Surface menu in the OSC section seems to have stopped working. Went back a couple of builds to the one from 9/5/2020 and it's working again.

[Geoff Waddington]

Originally Posted by MixMonkey

Think I've come across a little bug in the last two builds.

The Surface menu in the OSC section seems to have stopped working. Went back a couple of builds to the one from 9/5/2020 and it's working again.

Thanks, yup, found that here too a day or so ago, fixed it, will be in next build.

[chinpou]

Have you considered creating Rotary|CW / Rotary|CCW widgets? Trying to determine the wisest way to program my Nudge zone and I'd love to either

a) push the rotary under "Frame" to GoZone my Jogwheel and use it with modifiers to nudge an item's position, left & right trim, and contents by 1 frame or

b) use modifiers with the rotary under "Frame" to nudge item position, left & right trim, and contents by 1 frame.

Edit: read back on some of the recent dev convo and it looks like in 2.0 I'll be able to do option A with GoSubZones, I think

[Geoff Waddington]

Back to surface modifiers...

One of the things that keeps CSI an R&D effort is the ongoing struggle of fully supporting each controller in a natural and intuitive way, whilst still allowing complete integration with CSI

So let's take a couple of examples.

There are 6 automation buttons on an MCU, X-Touch, etc.

There are also 6 Reaper automation states.

If we re-purpose Group to mean Latch Preview, we have a fairly natural representation.

And if we add Shift variants for global, things work fairly well.




Now let's look at the up/down/left/right buttons.

Intuitively, they want to associate with Marker, Nudge, Scrub, and Zoom.

In effect, Marker, Nudge, Scrub, and Zoom represent natural surface modifiers for the up/down/left/right buttons.

Trouble is, if we promote them to full fledged modifiers, they are meaningless on surfaces that do not support those buttons.

Alternatively, we have discussed adding per surface modifiers definitions, but they have their own syntactic and conceptual challenges.

I'm suggesting a third approach, riffing off the MCU PanWidth Action.

Right now we use this bastardized beast in the .mst file to handle things:

Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
	Toggle 90 20 7f
WidgetEnd

This ties Rotary1 directly to RotaryPush1 -- Toggle 90 20 7f is RotaryPush1.

A cleaner solution might be keeping them separate and then implementing a Zone file something like this:

Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd

    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan

This way RotaryPush simply toggles an internal variable -- aka sets the state of the MCUTrackPan operation.

The secret sauce is in the MCUTrackPan Action itself -- it takes into account the state of the internal variable set by ToggleMCUTrackPan.

This decouples things in a very nice way -- it eliminates the monstrous .mst definition and at the same time frees up Rotary
and RotaryPush to be used "normally" in other Zones.

If we use the same approach for the other surface modifiers just mentioned we get:

    Marker ToggleMCUMarker
    Nudge  ToggleMCUNudge
    Scrub  ToggleMCUScrub
    Zoom   ToggleMCUZoom

    Up     MCUUp
    Down   MCUDown
    Left   MCULeft
    Right  MCURight

Once again the secret sauce is in the the MCU up/down/left/right variants themselves.

They notice the state of the Marker, Nudge, Scrub, Zoom state variables and act accordingly.

Also, internally, the ToggleMCUMarker, ToggleMCUNudge, ToggleMCUScrub, and ToggleMCUZoom are associated "radio button style" -- they are mutually exclusive.

Seems like a more optimal way to handle these sorts of things, what say you folks ?

[MixMonkey]

Originally Posted by Geoff Waddington

Seems like a more optimal way to handle these sorts of things, what say you folks ?

Sorry, but I find this approach extremely reductionist considering the colossal size of the Reaper Action set.

Sure, it would cover PanWidth, Zoom, Nudge, Marker and Scrub, but what about all the other, highly personalised ways people interact with Reaper and the large variety of surfaces that exist?

Would it not be possible to expand the existing global modifier arrangement of Shift, Option, Control and Alt and create additional Modifiers, say Mod1 to Mod32?

Then people could assign whatever buttons they liked to them, for pretty much whatever purpose they liked, just like they can with the existing Modifiers. The Modifiers would still be global in scope, but because there are now more than 4, modifiers that are used in one Zone or surface don't have to be used in another unless it's desired.

[Geoff Waddington]

Originally Posted by MixMonkey

Sorry, but I find this approach extremely reductionist considering the colossal size of the Reaper Action set.

Sure, it would cover PanWidth, Zoom, Nudge, Marker and Scrub, but what about all the other, highly personalised ways people interact with Reaper and the large variety of surfaces that exist?

Would it not be possible to expand the existing global modifier arrangement of Shift, Option, Control and Alt and create additional Modifiers, say Mod1 to Mod32?

Then people could assign whatever buttons they liked to them, for pretty much whatever purpose they liked, just like they can with the existing Modifiers. The Modifiers would still be global in scope, but because there are now more than 4, modifiers that are used in one Zone or surface don't have to be used in another unless it's desired.

Totally, totally get where you are coming from on this.

It's a game of flexibility vs usability



For you, me, Funkybot, and many others keeping everything separate allows max flexibility.

On the other hand, some "ready to go" bundles are easier to understand and use for some folks.

I guess the real question is "Do those folks really use the bundled components", or do they expect an "out of the box" solution anyway, in which case, flexibility is the way to go.

Wasn't sure I agreed the modifiers should be global, but then I considered something like an extender, and global modifiers make perfect sense

Decisions, decisions

I certainly hope we can do better than Mod1 to Mod32

I say we should allow named modifiers.

If we allow modifiers to be global and there is a duplicate modifier definition in 2 different surface files, I guess "he who parses last" wins ?

Now we face another issue.

What happens if we have a modifier definition used in surface 1 that is defined in surface 2, and surface 1 loads before surface 2 ?

I guess we could just go on faith that it would eventually get defined.

If not, there would be no harm, except that the Actions in Surface 1 that used modifiers from another surface that never get resolved would just never get called [edit 3] I guess that's no different than what happens today if you define a Shift Action, but have no Shift button defined

Then there are the use cases of stringing together multiple modifiers, my head is starting to spin

Pondering...

[edit] Or maybe duplicate modifiers in 2 surfaces just means 2 different ways to engage the same modifier from different places...
And maybe we allow only one "extra" modifier beyond Touch, Shift, Control, Alt, Option -- that still opens up a ton of possibilities without the head spin...

[edit 2] Man, I'm sure glad I got the X-touch, just staring at it makes me think harder

[MixMonkey]

Originally Posted by Geoff Waddington

Totally, totally get where you are coming from on this.

It's a game of flexibility vs usability

Yes, it's partly that, but also about relieving us (well, mainly you) of trying to second guess how peeps will use CSI.

For you, me, Funkybot, and many others keeping everything separate allows max flexibility.

On the other hand, some "ready to go" bundles are easier to understand and use for some folks.

I guess the real question is "Do those folks really use the bundled components", or do they expect an "out of the box" solution anyway, in which case, flexibility is the way to go.

I think most people will begin with a bundled solution to get started, then very quickly start pulling it apart and customising it (they are Reaper users after all)

Wasn't sure I agreed the modifiers should be global, but then I considered something like an extender, and global modifiers make perfect sense

The reason for keeping the modifiers global was twofold. Firstly, the system that is currently in place is simple, predicatable and rock solid. Let's just expand it. Secondly, it avoids the Broadcast/Receive paradigm. If you want a modifier to operate in a particular Zone, make a definition for it. If you don't, don't. If you have 32 to play with there's plenty of scope to avoid using them where you don't want them, unlike only having 4.

I certainly hope we can do better than Mod1 to Mod32

I say we should allow named modifiers.

You could, but it's easier to keep track of what you've used if they're generic, but that might just be me If you allow names, people will just name them the same as the button that they've assigned to it. So button "Marker" becomes modifier "Marker" and maybe that's ok. It certainly makes the syntax easier:

Marker    Marker
Marker+Right    Reaper "40173" //Go to next marker

If we allow modifiers to be global and there is a duplicate modifier definition in 2 different surface files, I guess "he who parses last" wins ?

When you say "duplicate modifier definition", do you mean assigning the same modifier to different buttons on two surfaces? I do that at the moment. Or do you mean having different actions assigned to same modifier+Button definition? I do that too Pretty hard to avoid when there's only 4 modifiers...

Now we face another issue.

What happens if we have a modifier definition used in surface 1 that is defined in surface 2, and surface 1 loads before surface 2 ?

I'm pretty sure that happens at the moment. I use modifiers in my XT Zones that are definied in the MCU Zone. They seem to work ok.

Then there are the use cases of stringing together multiple modifiers, my head is starting to spin

What happens at the moment? Shift+Control+Option+Alt works ok (and every other combo I've tried) What's the difference between having 4 modifiers and 32?

[MixMonkey]

Originally Posted by Geoff Waddington

[edit] Or maybe duplicate modifiers in 2 surfaces just means 2 different ways to engage the same modifier from different places...

..yep, it does and sometimes you want it and sometimes you don't.

And maybe we allow only one "extra" modifier beyond Touch, Shift, Control, Alt, Option -- that still opens up a ton of possibilities without the head spin...

If add more you could forget about SubZones, just saying

[edit 2] Man, I'm sure glad I got the X-touch, just staring at it makes me think harder

...and you've got illuminated Function buttons, perfect for modifiers!

[Geoff Waddington]

Originally Posted by MixMonkey

What happens at the moment? Shift+Control+Option+Alt works ok (and every other combo I've tried) What's the difference between having 4 modifiers and 32?

Yup, but internally they are represented by 5 positions, Touch, Shift, Option, Control, Alt, no matter how you define them in your Zone file -- e.g. Alt+Shift turns into Shift+Alt, because Shift is in position 2, and Alt is in position 5.

If we allow named ones, which are seductive syntactically, we have no idea how many there are and what position they should occupy, so our existing modifier strategy breaks.

This is an argument for Mod1 - Mod32

There is also the separate issue of "radio button" style modifiers.

As far as replacing SubZones, that is only true if you have the luxury of a lot of modifiers.

With SubZones you can use one button to string SubZone navigations together, and you are more likely to need said SubZones on surfaces with less controls and modifiers.

[Funkybot]

Random thought: when I first started down the road of editing zone files, I just assumed incorrectly that any button could be combined with any other to act as a modifier. So I tried stuff like...

Zoom+Up    Reaper "123"

...I didn't know any better.

Getting more on topic: I'm still thinking subzones, if implemented, would negate the need for the ToggleMCUZoom and ToggleMCUScrub type actions and surface modifiers. I'd just have this in my code...

Zoom    GoSubZone "Zoom"
Scrub   GoSubZone "Scrub"

...with those zones appropriately defined and a way to get back home. And I'm thinking Geoff would just include those SubZones and mapping in the MCU and X-Touch zone files, so they were pre-configured for new users who would just expect those buttons to work out of the box, but may want to tinker once they know more. The other benefit of that approach is it's not MCU-centric and more flexible. I'm thinking Faderport users, OSC surfaces, etc.

[Puck]

We’re dancing around something pretty cool here.

I’m not sure what that is exactly yet, but I know we’ll get there.

With regard to usability versus flexibility/customization:

The plan is to have some sort of repository for surfaces/starter zones after we get 2.0 to a good place yeah? To me, this would be the ultimate out of the box solution for new users.

….

I know when I heard the term surface modifiers and radio button style I assumed they’d be one surface and only one active at a time. It’d be nice to be able to define them ourselves per zone but I’m not really pushing for any of this.

In terms of complicated fx zones: the above would be great for replacing the subzone use case where you aren’t stepping through them. You wouldn’t have to have multiple fx zone files either for all your “subzones” they would be contained in one file. Just some thoughts.

[Geoff Waddington]

Originally Posted by Funkybot

Random thought: when I first started down the road of editing zone files, I just assumed incorrectly that any button could be combined with any other to act as a modifier. So I tried stuff like...

Zoom+Up    Reaper "123"

...I didn't know any better.

Getting more on topic: I'm still thinking subzones, if implemented, would negate the need for the ToggleMCUZoom and ToggleMCUScrub type actions and surface modifiers. I'd just have this in my code...

Zoom    GoSubZone "Zoom"
Scrub   GoSubZone "Scrub"

...with those zones appropriately defined and a way to get back home. And I'm thinking Geoff would just include those SubZones and mapping in the MCU and X-Touch zone files, so they were pre-configured for new users who would just expect those buttons to work out of the box, but may want to tinker once they know more. The other benefit of that approach is it's not MCU-centric and more flexible. I'm thinking Faderport users, OSC surfaces, etc.

Yup, I would say the more we discuss Surface modifiers, the stronger the case gets for not implementing them, and the stronger the case gets for implementing SubZones to accomplish the same thing, simultaneously giving us a better:

internal coding model
more understandable/usable Ux.

As well, SubZones satisfy the need for custom Zones.

I would say rigor mortis has set in on the old grey mare named Surface Modifiers

[Geoff Waddington]

Originally Posted by Puck

We’re dancing around something pretty cool here.

I’m not sure what that is exactly yet, but I know we’ll get there.

With regard to usability versus flexibility/customization:

The plan is to have some sort of repository for surfaces/starter zones after we get 2.0 to a good place yeah? To me, this would be the ultimate out of the box solution for new users.

Yup, agree totally !

Originally Posted by Puck

I know when I heard the term surface modifiers and radio button style I assumed they’d be one surface and only one active at a time. It’d be nice to be able to define them ourselves per zone but I’m not really pushing for any of this.

Thanks for reminding me, SubZones are automatically radio button style, it's inherent in the design

Originally Posted by Puck

In terms of complicated fx zones: the above would be great for replacing the subzone use case where you aren’t stepping through them. You wouldn’t have to have multiple fx zone files either for all your “subzones” they would be contained in one file. Just some thoughts.

Yeah, pretty sure the complexity outweighs the usability here

[Geoff Waddington]

One last thing that indicates this discussion has been at least somewhat productive, MCUTrackPan will be redesigned thusly, such that RotaryPush is available for other tasks:

Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd

    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan

[MixMonkey]

Originally Posted by Geoff Waddington

Yup, I would say the more we discuss Surface modifiers, the stronger the case gets for not implementing them, and the stronger the case gets for implementing SubZones to accomplish the same thing, simultaneously giving us a better:

internal coding model
more understandable/usable Ux.

As well, SubZones satisfy the need for custom Zones.

I would say rigor mortis has set in on the old grey mare named Surface Modifiers

Cool, let's do SubZones then Extending the existing Modifier architecture was only really a 'thing' if it was quick and easy to implement. It didn't need to have named modifiers or combinations.

[Funkybot]

Originally Posted by Geoff Waddington

One last thing that indicates this discussion has been at least somewhat productive, MCUTrackPan will be redesigned thusly, such that RotaryPush is available for other tasks:

Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd

    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan

I like this.

I think SubZones are the best way forward but it's important to try to fully vet alternative approaches and ideas.

[MixMonkey]

Originally Posted by Funkybot

I think SubZones are the best way forward but it's important to try to fully vet alternative approaches and ideas.

SubZones are definitely where people will really get into customising how CSI behaves.

[Geoff Waddington]

Originally Posted by MixMonkey

SubZones are definitely where people will really get into customising how CSI behaves.

Yup, definitely agree, and it follows that now the community can likely come up with a real solid "starter set" for everything except SubZones and FX Zones.

[Geoff Waddington]

New build is up.

CSI Exp.zip

.ost should work again in the config panel.

Possible fix for the Reaper Banking Synchronize bug.

Revamped MCUTrackPan as per discussion:

Widget RotaryPush1
	Press 90 20 7f
WidgetEnd

Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
	Toggle 90 20 7f
WidgetEnd

Zone "Track"
    DisplayUpper|            	TrackNameDisplay
    Fader|Touch+DisplayLower| 	TrackVolumeDisplay
    DisplayLower|      		MCUTrackPanDisplay
    Fader|                   	TrackVolume 
    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPanWidth
    RecordArm|                  TrackRecordArm
    Solo|                       TrackSolo
    Mute|                       TrackMute
    Select|                     TrackUniqueSelect
    Shift+Select|               TrackRangeSelect
    Control+Select|             TrackSelect
ZoneEnd

[MixMonkey]

Originally Posted by Geoff Waddington

Yup, definitely agree, and it follows that now the community can likely come up with a real solid "starter set" for everything except SubZones and FX Zones.

Absolutely, possibly include a simple SubZone, say Zoom, to function as an example so that the syntax/Zone arrangement is laid out. Same goes for FX.

[MixMonkey]

Originally Posted by Geoff Waddington

New build is up.

CSI Exp.zip

.ost should work again in the config panel.

Possible fix for the Reaper Banking Synchronize bug.

Revamped MCUTrackPan as per discussion:

.ost surface menu working again. Banking seems to work correctly now when clicking on track with mouse

Will try out the MCUTrackPan when back in studio

[Funkybot]

Are we thinking SubZones for Zoom, Scrub, and Nudge? Any other buttons on the MCU we think need a corresponding SubZone? Flip?

[Geoff Waddington]

Originally Posted by MixMonkey

.ost surface menu working again. Banking seems to work correctly now when clicking on track with mouse

Will try out the MCUTrackPan when back in studio

Good news, thanks for testing !

[Geoff Waddington]

Originally Posted by Funkybot

Are we thinking SubZones for Zoom, Scrub, and Nudge? Any other buttons on the MCU we think need a corresponding SubZone?

Yup, was also thinking Marker:

Up -- add marker

Left/Right -- prev/next marker

Down -- delete current marker

[edit] Just saw your edit Flip is another good one.