Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Thinking about .mst/.ost files.

We purposefully made surface definition files a dark and scary place to push folks, including us , to build our systems with Zones as opposed to surface files.

Now that folks are used to doing things the CSI "way", we can improve .mst/.ost definition.

I'd like to propose that we add some new constructs:

Buttons
Channel
MasterChannel
Row


They would act almost like Home with its IncludedZones, except instead of IncludedZones, we would have IncludedWidgets.

We could then devise a syntax that would free us from the "|" character.

This is the equivalent of what just happened with GoSubZone PanWidth. You don't need to say PanWidth6 anymore (just PanWidth), you already have context.

Since the Channel container will provide the "Channelness" -- Channel Number, TrackNavigator, etc., the contained Widgets can now lose the trailing number, so you would have:

Fader
Rotary
RotaryPush
Mute
Solo
etc.

We would also need a syntax to express the range, here's the basic concept:

Channel 8
    Widget Mute
	Press 90 10 7f 90 10 00 90 17 7f 90 17 00
	FB_TwoState 90 10 7f 90 10 00 90 17 7f 90 17 00
    WidgetEnd
ChannelEnd

This will clean up file definition considerably.

When it come to FX definition, we can add the trailing number to specify, say, a certain Rotary, Rotary5. The FX Zone parser will quietly perform the conversion and read that as the Rotary on Channel 5 and make the appropriate link.


Same goes for Row definition.

It will also be possible to have Widgets appear in more than one container.

For instance, an obvious one is the Rotary/RotaryPush pair.

As well as being defined as Pan/Width controls in the vertical (Channel) direction, they could also be defined as a Row in the horizontal direction.

You could the use the Row for say, SelectedTrack FX controls.

Some thoughts on a nice sunny Friday afternoon with a -13, and a -22 windchill, I'm just staying inside enjoying the sunlight

[Freex]

Originally Posted by Geoff Waddington

100% correct !!!

And if you GoSubZone SelectedTrackFXMenu from SelectedTrackSend you jump directly to SelectedTrackFXMenu and an automatic LeaveZone is sent to SelectedTrackSend to deactivate it.

That way, when you LeaveZone you jump right back to the Included Zones, Buttons, Tracks and MasterTrack.

No stack issues

The secret is in allowing only one SubZone to be Activated at any one time.

That way, when you LeaveZone from the last one you bounce directly Home.

Would this still aloow us to have sends, returns, and FXmenu plus anthign else in the furture (inputs etc) splayed at the same time on the C4 or the similar?

[Puck]

Originally Posted by Geoff Waddington

You never could go to an included Zone.

Included Zones are just components of the enclosing Zone.

They Activate/Deactivate, Bank, etc., in lock step with the enclosing Zone.

They behave as one Zone.

SubZones cover all the rest, as you say.

I see where I was mistaken now. Thanks!

[MixMonkey]

Originally Posted by Freex

Would this still aloow us to have sends, returns, and FXmenu plus anthign else in the furture (inputs etc) splayed at the same time on the C4 or the similar?

Yes, because in the C4 context they're not SubZones. They would be IncludedZones in the C4 Home Zone.

[Geoff Waddington]

Originally Posted by Freex

Would this still aloow us to have sends, returns, and FXmenu plus anthign else in the furture (inputs etc) splayed at the same time on the C4 or the similar?

Yes, your Zone definitions would look something like this, really rough, just for illustration:

Zone Home
    IncludedZones
        "Buttons"
        "Track"
        "MasterTrack"
    IncludedZonesEnd
    SubZones
       "BunchOfC4Rows"
    SubZonesEnd
ZoneEnd

Zone BunchOfC4Rows
    IncludedZones
        "SendsZone"
        "FXMenuZone"
        "ReceivesZone"
    IncludedZonesEnd
ZoneEnd

[edit] @MixMonkey said it better

[Funkybot]

Geoff, that seems like it should work. The .mst/.ost parser would need to be smart enough to notice what's changing though right? Sometimes it's the first two bytes (like with faders broadcasting on different channels), other times it may be the middle two bytes.

Just trying to poke holes here...are there any surfaces that don't have incremental increases to like parameters and would there be some way of handling that should it arise? Example: Mute1 is B0 01 7f, Mute2 B0 04 7f. Why would that exist? Could be a user wanting to reconfigure the device layout on a different page.

BTW I'm not telling Luis he's gotta rewrite the SCE-24.mst.

[Funkybot]

I'd also just add this as a note of caution: I don't think .mst creation is hard at all. It's been, to-date, the most stable part of CSI from a syntax perspective and the 1:1 ratio between widgets and hardware controls makes it very easy to grasp.

There are .mst files out there for just about every commonly used device going back to the CSI alphas and it's really a once-and-done type of affair. I think device mapping generally doesn't warrant much attention because we have maps for so many devices already and once you do a device, you never have to touch it again.

I do fear that completely changing the .mst syntax risks opening a can of worms unless replacement .mst files are available early on. The new approach would be faster when writing the files, and offer other benefits, but otherwise, if the .mst files stayed the same and we just threw them all up on the Wiki, I think users would be nuts to roll their own.

[Geoff Waddington]

Originally Posted by Funkybot

Geoff, that seems like it should work. The .mst/.ost parser would need to be smart enough to notice what's changing though right? Sometimes it's the first two bytes (like with faders broadcasting on different channels), other times it may be the middle two bytes.

Yes, that's already basically built into the Widget type, it would require slight modification.

Originally Posted by Funkybot

Just trying to poke holes here...are there any surfaces that don't have incremental increases to like parameters and would there be some way of handling that should it arise? Example: Mute1 is B0 01 7f, Mute2 B0 04 7f. Why would that exist? Could be a user wanting to reconfigure the device layout on a different page.

For those, we could implement a comma separated values approach, like stepped values.

Originally Posted by Funkybot

BTW I'm not telling Luis he's gotta rewrite the SCE-24.mst.

Now that is a good point

[Geoff Waddington]

Originally Posted by Funkybot

I'd also just add this as a note of caution: I don't think .mst creation is hard at all. It's been, to-date, the most stable part of CSI from a syntax perspective and the 1:1 ratio between widgets and hardware controls makes it very easy to grasp.

There are .mst files out there for just about every commonly used device going back to the CSI alphas and it's really a once-and-done type of affair. I think device mapping generally doesn't warrant much attention because we have maps for so many devices already and once you do a device, you never have to touch it again.

I do fear that completely changing the .mst syntax risks opening a can of worms unless replacement .mst files are available early on. The new approach would be faster when writing the files, and offer other benefits, but otherwise, if the .mst files stayed the same and we just threw them all up on the Wiki, I think users would be nuts to roll their own.

A bunch more valid points.

Was really just throwing it out there to see what happened

OK, back to SubZone design...

[MixMonkey]

Originally Posted by Funkybot

I'd also just add this as a note of caution: I don't think .mst creation is hard at all. It's been, to-date, the most stable part of CSI from a syntax perspective and the 1:1 ratio between widgets and hardware controls makes it very easy to grasp.

+1, particularly the 1:1 relationship making it easier to understand.

[Mavriq]

A little off the current topic but:

On the Page Settings dialog there are a couple of settings:

"Bank with other checked pages". That is kind of cryptic. Perhaps would be better worded "Synchronize Banking"?

And

"Reaper GUI Follows Surfaces" could be "Scroll Reaper on Bank".

[Geoff Waddington]

Originally Posted by gvanbrunt

A little off the current topic but:

On the Page Settings dialog there are a couple of settings:

"Bank with other checked pages". That is kind of cryptic. Perhaps would be better worded "Synchronize Banking"?

And

"Reaper GUI Follows Surfaces" could be "Scroll Reaper on Bank".

We used to call it Synchronize Banking (or something close), but some people found it confusing, it always seemed more natural to me

I like "Scroll Reaper on Bank" better too.

What's everyone else think ?

[Funkybot]

Does it also do the opposite? By that I mean, is that what controls when the surface banks to the select a track in reaper?

[MixMonkey]

Originally Posted by Funkybot

Does it also do the opposite? By that I mean, is that what controls when the surface banks to the select a track in reaper?

Isn't that ScrollLink?

[Geoff Waddington]

We originally split the number of sends, fx, etc., out in the config panel.

The thought was that you could have an 8 channel surface split into 4 sends and 4 tracks, but I don't think anyone ever used it that way.

Too confusing.

Everyone just overlays all 8, at least as far as I know.

It would be nice to just have num channels and offset in the config panel, much less intimidating for a new user.

The sends, fx, etc. would just get their value from num channels.

Would also make for a cleaner config panel.

Any objections ?

[Geoff Waddington]

Originally Posted by MixMonkey

Isn't that ScrollLink?

ScrollLink scrolls the Reaper mixer to keep it in synch with the surface banking.

SynchronizeBanking sends and receives banking commands to any other pages that have this checked. Useful for switching between Pages whilst maintaining your spot banking wise.

[MixMonkey]

Originally Posted by Geoff Waddington

We originally split the number of sends, fx, etc., out in the config panel.

The thought was that you could have an 8 channel surface split into 4 sends and 4 tracks, but I don't think anyone ever used it that way.

Too confusing.

Everyone just overlays all 8, at least as far as I know.

It would be nice to just have num channels and offset in the config panel, much less intimidating for a new user.

The sends, fx, etc. would just get their value from num channels.

Would also make for a cleaner config panel.

Any objections ?

...and if there are more sends/FXMenu slots than the number of channels on the surface, we can bank accordingly?

[Geoff Waddington]

Originally Posted by MixMonkey

...and if there are more sends/FXMenu slots than the number of channels on the surface, we can bank accordingly?

Yes, just like Tracks.

Much more consistent, yes ?

[MixMonkey]

Originally Posted by Geoff Waddington

Yes, just like Tracks.

Much more consistent, yes ?

Yes

[Geoff Waddington]

Ok, so everyone is cool with removing num sends and num fx from the surface config panel ?

And changing those Page strings for Scroll and Synch as per Geoff's suggestions ?

[MixMonkey]

Originally Posted by Geoff Waddington

Ok, so everyone is cool with removing num sends and num fx from the surface config panel ?

And changing those Page strings for Scroll and Synch as per Geoff's suggestions ?

Works for me

[Funkybot]

Works for me!

[Puck]

No objection here.

[Puck]

Here's a little proof of concept gif:

https://drive.google.com/file/d/1Hi6...ew?usp=sharing

[jacksoonbrowne]

Some consoles like the X32 have different fader curves than reaper.

Can it be possible to have CSI have a "MAP" somewhere that if present would apply to a specific widget?

Something like: TRACK| MAP VOLUME 0.0=INF,0.75=-0DB,1.0=10DB

[Puck]

Originally Posted by Puck

Here's a little proof of concept gif:

https://drive.google.com/file/d/1Hi6...ew?usp=sharing

(obviously I'm just guessing at the API, we can send and address and then string arguments or whatever)

EDIT: LOL I think I quoted myself and then posted when I meant to edit. Nevermind me, I'll be heading to bed.

[airon]

Seen this yet ?

Building a surface in Cubase 12

Is that cool or what. When he's assigning functions at the 5 minute mark, look at how easy that layout is to read. Damn, perhaps this is a good inspiration for the Cockos boys as well.

[Geoff Waddington]

Originally Posted by airon

Seen this yet ?

Building a surface in Cubase 12

Is that cool or what. When he's assigning functions at the 5 minute mark, look at how easy that layout is to read. Damn, perhaps this is a good inspiration for the Cockos boys as well.

Yup, I would steal as many licks as possible from that, and would add the ability to have more than one surface open at a time, so that you could be editing in real time and seeing the results immediately (with a refresh) on all surfaces !

So, go for it UI folks, I will add the necessary APIs.

It's just a matter of defining OSC strings at both ends.

We can come up with a simple vocabulary quite quickly, I'm sure.

[Puck]

Originally Posted by Geoff Waddington

Yup, I would steal as many licks as possible from that, and would add the ability to have more than one surface open at a time, so that you could be editing in real time and seeing the results immediately (with a refresh) on all surfaces !

So, go for it UI folks, I will add the necessary APIs.

It's just a matter of defining OSC strings at both ends.

We can come up with a simple vocabulary quite quickly, I'm sure.

Multiple surfaces might be a bit tricky. In CSI, you need to create zones separately for each surface anyhow. But I can keep it in mind as we build this thing to be robust. I think we can get fairly close to what the new Cubase does. But I don't if the path I'm heading down is the best path in the long run.

Are you both commenting because you saw my gif?

[Geoff Waddington]

Originally Posted by Puck

Multiple surfaces might be a bit tricky. In CSI, you need to create zones separately for each surface anyhow. But I can keep it in mind as we build this thing to be robust. I think we can get fairly close to what the new Cubase does. But I don't if the path I'm heading down is the best path in the long run.

Are you both commenting because you saw my gif?

I was commenting on the video, it's a very good piece of kit, well thought out.

As far as multiple surfaces, I'm envisioning multiple Windows open simultaneously, each representing one surface, something like that.

Then, hitting save all pushes those Zone definitions to CSI, whereupon it writes them to disk and calls for an all surfaces refresh.

Very close to realtime editing.

[Geoff Waddington]

Just had an OO geek aha moment.

For those interested:

Home is actually a specialization of an FX Zone

FX Zones have Widget/Action pairs and possibly SubZones.

Home has the above plus IncludedZones.

This is so that different sections can have different Navigators, but still be operational simultaneously.

So that's from a design standpoint. There can also be other Zones that have Included Zones -- like the C4 example a few posts back, but Home is unique.

From an implementation/lifecycle standpoint, Home is the only Zone that stays around for the life of the session. It also has fixed SubZones (Sends, FXMenu, etc.).

Those thoughts make it easier to reduce the definition space a bit more, simplifies things just a tad, design wise...

[Puck]

Originally Posted by Geoff Waddington

I was commenting on the video, it's a very good piece of kit, well thought out.

As far as multiple surfaces, I'm envisioning multiple Windows open simultaneously, each representing one surface, something like that.

Then, hitting save all pushes those Zone definitions to CSI, whereupon it writes them to disk and calls for an all surfaces refresh.

Very close to realtime editing.

I can see how that would work!



Also definitely no design work done yet. This was just so I can prove to myself and others that we can:

- drag stuff around
- transfer data when we set params on top of widgets
- with one button, send all osc messages with included param mapping info back to CSI

I’ll come up with something that’s a combo of Funkybots mock-up and Cubase’s midi mapping UI.

Then we can all have input here.

It would behoove us to start chatting about the API so I don’t design myself into a hole

[Puck]

Originally Posted by Geoff Waddington

Just had an OO geek aha moment.

Love this! They don’t come often enough for me lol

[MixMonkey]

Originally Posted by Geoff Waddington

So that's from a design standpoint. There can also be other Zones that have Included Zones -- like the C4 example a few posts back, but Home is unique.

From an implementation/lifecycle standpoint, Home is the only Zone that stays around for the life of the session. It also has fixed SubZones (Sends, FXMenu, etc.).

I have an 'MCU' Home Zone and a 'C4' Home Zone. What distinguishes them are the IncludedZones, that is to say the Zones that are active together when in the Home Zone.

The MCU Home Zone has Buttons, Channel (Track), MasterTrack and SelectedTrack.

The C4 Home Zone has C4_Buttons, C4_Blank, SelectedTrackSend, SelectedTrackReceive and SelectedTrackFXMenu.

Will the new architecture support these two 'different' Home Zones?

Also, we were discussing not having the number of sends, receives and FX menu items defined in the prefs but instead just deriving them from the number of channels. The C4 has always been defined with 0 channels as it doesn't take part in track banking, but had sends and FX Menu items defined as 8. How does this fit in now?

[Mavriq]

Originally Posted by airon

Seen this yet ?

Building a surface in Cubase 12

Is that cool or what. When he's assigning functions at the 5 minute mark, look at how easy that layout is to read. Damn, perhaps this is a good inspiration for the Cockos boys as well.

When I talked about adding a GUI for creating Surface Templates, that's is what I had in mind for the "mst" part of the GUI. The toughest part is deciding what "GUI widget" package to use. I like ImGui, but it really doesn't "track" with the OS's default controls. It has to support every OS that Reaper does as well. I'm still researching.

The other part that is much more difficult is how to do the zon files. CSI is so powerful as it offers so many options. Starting with the FX Zones is def a good starting point, and I think that is actually not too difficult to do.

[Geoff Waddington]

Originally Posted by MixMonkey

I have an 'MCU' Home Zone and a 'C4' Home Zone. What distinguishes them are the IncludedZones, that is to say the Zones that are active together when in the Home Zone.

The MCU Home Zone has Buttons, Channel (Track), MasterTrack and SelectedTrack.

The C4 Home Zone has C4_Buttons, C4_Blank, SelectedTrackSend, SelectedTrackReceive and SelectedTrackFXMenu.

Will the new architecture support these two 'different' Home Zones?

Of course, you are free to design your Home Zone, as before.

Originally Posted by MixMonkey

Also, we were discussing not having the number of sends, receives and FX menu items defined in the prefs but instead just deriving them from the number of channels. The C4 has always been defined with 0 channels as it doesn't take part in track banking, but had sends and FX Menu items defined as 8. How does this fit in now?

It really points out that num Channels is a bad name for it, it really means number of slots.

The number is still necessary, it will be used for FXMenu, Sends, etc. banking.

Because the C4 doesn't have a Track Zone definition, it won't participate in Track banking.

[MixMonkey]

Originally Posted by Geoff Waddington

Of course, you are free to design your Home Zone, as before.
It really points out that num Channels is a bad name for it, it really means number of slots.
The number is still necessary, it will be used for FXMenu, Sends, etc. banking.
Because the C4 doesn't have a Track Zone definition, it won't participate in Track banking.

Thanks for confirming that I thought that would be the case but just wanted to make sure

[Mavriq]

If we do make the change and "push the channel definition" into the mst (remove the |), we could move the "# of channels setting" there as well no? Or is it something that is derived now that we have specific number of channels in the mst?

That just leaves the offset in there. Could that be moved to a zone file somehow? something like ReceiveBank "8" or the like on the offset controllers zon file?

[MixMonkey]

Originally Posted by gvanbrunt

If we do make the change and "push the channel definition" into the mst (remove the |), we could move the "# of channels setting" there as well no? Or is it something that is derived now that we have specific number of channels in the mst?

This could work, the number of channels is specific to an individual type of surface and that is defined in the .mst.

That just leaves the offset in there. Could that be moved to a zone file somehow? something like ReceiveBank "8" or the like on the offset controllers zon file?

I don't think it will work with the offset. In this situation you can have many controllers of the same type all using the same Zone files but with different offsets.

[Geoff Waddington]

Speaking of all of this banking/offset stuff...

I think the easy way to do Send/Receive/FXMenu banking is to follow the Track Navigation lead.

Any surfaces that have Track Zones participate in banking, which we will now call Track Banking.

You can see where this is going

Any surfaces that have TrackSend Zones participate in TrackSend Banking.

So TrackSends will span surfaces if more than one surface has TrackSend Zones defined, just like the original Track spans surfaces if more than one surface has Track Zones defined.

Same for the other types -- Receives, etc.

Make sense ?