Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by MixMonkey

Not sure I understand the problem here. Is this something that only affects OSC? Surely the hardware connections are the same on different pages, because you've set them the same?

It's more fundamental than that.

Right now you can have different Pages with different Midi ports for the same Surface, different IP addresses for the same OSC device, etc.

It's just fundamentally incorrect to rely on convention here.

The definition of the IO should be per surface, period.

The definition of the .mst files and Zone folder for a given Surface can and should be Page context specific.

[Geoff Waddington]

Originally Posted by Puck

However, the reason I stumbled upon this a few months back is:

I was trying to copy Eucon's Track list. So my intention was to flip to a second page with significantly more channels to have a bird's eye view of your tracks.

Interesting argument for allowing different channel counts and starting positions for the same Surface on different Pages

[Puck]

Originally Posted by Geoff Waddington

Hmmm...

You have 0 channels on both surfaces...

Interesting new tidbit:

Making the channel counts both 8 and 8 resulted in the same behavior.

However what I've noticed now is that the state of this bug is more severe. After testing with my files, going back into Reaper will silently crash until I restart my computer. I even tried deleting my CSI.ini file and still got the crash until I restarted. Crazy!

But I know we are talking about how to remedy the issue already

[Geoff Waddington]

Originally Posted by Puck

Interesting new tidbit:

Making the channel counts both 8 and 8 resulted in the same behavior.

However what I've noticed now is that the state of this bug is more severe. After testing with my files, going back into Reaper will silently crash until I restart my computer. I even tried deleting my CSI.ini file and still got the crash until I restarted. Crazy!

But I know we are talking about how to remedy the issue already

Thanks for testing !

Yup, we really have to solve this !

[MixMonkey]

Originally Posted by Geoff Waddington

It's more fundamental than that.

Right now you can have different Pages with different Midi ports for the same Surface, different IP addresses for the same OSC device, etc.

It's just fundamentally incorrect to rely on convention here.

The definition of the IO should be per surface, period.

The definition of the .mst files and Zone folder for a given Surface can and should be Page context specific.

I see It makes sense to me to separate the 'hardware' side of CSI (surfaces, ports etc) which are fixed in a true, physical sense, from the 'software' side of CSI (.mst, .ost and .zon) which can be altered by Pages.

[Geoff Waddington]

OK, seems clear what we must do:

1) Midi ports, IP addresses and ports MUST be defined once only per Surface !

2) We are free to define .mst files and Zone Folders on a per Page basis.

3) We must decide whether to define channel count and starting position per Surface or per Page.

[Geoff Waddington]

Originally Posted by MixMonkey

I see It makes sense to me to separate the 'hardware' side of CSI (surfaces, ports etc) which are fixed in a true, physical sense, from the 'software' side of CSI (.mst, .ost and .zon) which can be altered by Pages.

Yes, exactly !

The only fluid part is channel count/starting position which could be in either, although by definition, that would require different .mst files

[MixMonkey]

Originally Posted by Geoff Waddington

Yes, exactly !

The only fluid part is channel count/starting position which could be in either, although by definition, that would require different .mst files

Channel count and starting position are software, no?

[Geoff Waddington]

Originally Posted by MixMonkey

Channel count and starting position are software, no?

Starting position is definitely software.

Channel count depends on if you are talking Midi (hardware) or OSC (software).

I mean, theoretically you could have an 8 channel midi device defined with less than 8 channels on a given Page, but who would want to waste hardware channels ?

But your point is well taken.

[Geoff Waddington]

Thanks for the discussion, MixMonkey and Puck.

I think for max flexibility, we should allow channel count and starting position to be defined per Page.

After all, channel count relies on the correct accompanying .mst (or .ost) file and starting position is clearly software.

Suggest we add a third window on the far left of the Config panel for defining surface params.

So the workflow is, from left to right:

1) define Surface hardware -- midi ports, IP adresses and ports
2) define Page(s)
3) define Surfaces within Pages — channel count, starting position, .mst and zone Folder

What do you think folks ?

[MixMonkey]

Originally Posted by Geoff Waddington

I mean, theoretically you could have an 8 channel midi device defined with less than 8 channels on a given Page, but who would want to waste hardware channels ?

How about defining an eight channel surface with a single track volume fader (selected track) and seven sends (also selected track)?

[MixMonkey]

Originally Posted by Geoff Waddington

Thanks for the discussion, MixMonkey and Puck.

I think for max flexibility, we should allow channel count and starting position to be defined per Page.

After all, channel count relies on the correct accompanying .mst file and starting position is clearly software.

Suggest we add a third window on the far left of the Config panel for defining surface params.

So the workflow is, from left to right:

1) define Surface hardware
2) define Page(s)
3) define Surfaces within Pages — channel count, starting position, .mst and zone Folder

What do you think folks ?

Yep, works for me

[Geoff Waddington]

Originally Posted by MixMonkey

How about defining an eight channel surface with a single track volume fader (selected track) and seven sends (also selected track)?

Good point.

[Geoff Waddington]

Ok, we can clean up the Page syntax a bit since we are redoing CSI.ini

FollowTCP/FollowMCP - fine as is

SynchPages/NoSynchPages - suggest rename to SynchBanking/NoSynchBanking

ScrollLink/NoScrollLink -- suggest eliminating altogether.

We already have ToggleScrollLink and we can use OnInitialization to accomplish the same result.

Suggest the default is off,

OnInitialization ToggleScrollLink

turns it on.

Suggested CSI.ini file format:

Version 2.0

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

Page "HomePage" FollowMCP SynchBanking 
"XTouch Universal" 8 0 "XTouch.mst" "XTouch" 
"iPhone" 0 0 "iPhone.ost" "iPhone"

The dropdown for Midi Surfaces will only show .mst files and the dropdown for OSC Surfaces will only show .ost files.

Looks much cleaner to me.

Sound about right ?




[edit]Hmmm...

Wonder if we should make Actions for ToggleFollowMCP and ToggleSynchBanking, and just supply reasonable defaults a la ToggleScrollLink ?

This would make things even cleaner, not only in CSI.ini, but also Ux in the Config Panel:

Version 2.0

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

Page "HomePage" 
"XTouch Universal" 8 0 "XTouch.mst" "XTouch" 
"iPhone" 0 0 "iPhone.ost" "iPhone"

[Funkybot]

Originally Posted by Geoff Waddington

[edit]Hmmm...

Wonder if we should make Actions for ToggleFollowMCP and ToggleSynchBanking, and just supply reasonable defaults a la ToggleScrollLink ?

Wow! Missed a lot here this morning. Everything proposed sounds good to me.

Just for my own edification, is the difference between SynchBanking and ScrollLink that in SynchBanking, Reaper's MCP will follow the banking from CSI and in ScrollLink, CSI follows Reaper's selection? If yes, probably makes sense to add toggle actions and default ToggleFollowMCP, ToggleSynchBanking, and ToggleScrollLink to on. I'd think 80-90% of users would want those on by default and best if they never had to touch those actions at all.

[Geoff Waddington]

Originally Posted by Funkybot

Wow! Missed a lot here this morning. Everything proposed sounds good to me.

Just for my own edification, is the difference between SynchBanking and ScrollLink that in SynchBanking, Reaper's MCP will follow the banking from CSI and in ScrollLink, CSI follows Reaper's selection? If yes, probably makes sense to add toggle actions and default ToggleFollowMCP, ToggleSynchBanking, and ToggleScrollLink to on. I'd think 80-90% of users would want those on by default and best if they never had to touch those actions at all.

No, SynchBanking keeps all Pages that have SynchBanking, in Synch, bank-wise -- any Bank adjustment on any Page banks all Pages that have SynchBanking.

ScrollLink causes Reaper to follow CSI.

There is nothing (yet) to cause CSI to follow Reaper.

[MixMonkey]

Originally Posted by Geoff Waddington

Ok, we can clean up the Page syntax a bit since we are redoing CSI.ini

FollowTCP/FollowMCP - fine as is

As long as we keep the reference to track visibility.

SynchPages/NoSynchPages - suggest rename to SynchBanking/NoSynchBanking

I think SyncPageBanking/NoSyncPageBanking might be clearer.

ScrollLink/NoScrollLink -- suggest eliminating altogether.

We already have ToggleScrollLink and we can use OnInitialization to accomplish the same result.

Suggest the default is off,

OnInitialization ToggleScrollLink

turns it on.

Agree. This is much less a prefs thing and much more an operational thing.

Wonder if we should make Actions for ToggleFollowMCP and ToggleSynchBanking, and just supply reasonable defaults a la ToggleScrollLink ?

This would be fine. Maybe use ToggleFollowMCPVisibility and ToggleSyncPageBanking and default both to on?

[MixMonkey]

Originally Posted by Geoff Waddington

There is nothing (yet) to cause CSI to follow Reaper.

Except by track selection, with:

Scroll view when tracks activated

(right click master fader in MCP)
...for the MCP.

and:

Reaper 40913 // Track: Vertical scroll selected tracks into view

...for the TCP.

[Geoff Waddington]

Originally Posted by MixMonkey

Except by track selection, with:

Scroll view when tracks activated

(right click master fader in MCP)
...for the MCP.

and:

Reaper 40913 // Track: Vertical scroll selected tracks into view

...for the TCP.

Yes, I meant an explicit CSI Action

[Geoff Waddington]

Originally Posted by MixMonkey

As long as we keep the reference to track visibility.



I think SyncPageBanking/NoSyncPageBanking might be clearer.



Agree. This is much less a prefs thing and much more an operational thing.



This would be fine. Maybe use ToggleFollowMCPVisibility and ToggleSyncPageBanking and default both to on?

OK,

FollowTCP/FollowMCP - history - replaced by ToggleFollowMCPVisibility - defaults to on.

SynchPages/NoSynchPages - - history - replaced by ToggleSynchPageBanking - defaults to on.

ScrollLink/NoScrollLink - history - replaced by ToggleScrollLink - defaults to on with a 0 param.

If you supply a param it offsets the Scroll -- remember you had a use for this ?

[Puck]

Couple things:

Since (presumably) you’ll be in the gui section. There’s that pesky windows scaling bug that cuts off the buttons when I’m at more than 100% scaling. (I.e. by the buttons I mean the line of buttons that includes “Add Midi” and “Add OSC”)

Also…

I don’t think CSI is back to respecting track visibility yet. Admittedly I haven’t tested this in recent builds so potentially I'm mistaken.

[MixMonkey]

Originally Posted by Geoff Waddington

OK,

FollowTCP/FollowMCP - history - replaced by ToggleFollowMCPVisibility - defaults to on.

SynchPages/NoSynchPages - - history - replaced by ToggleSynchPageBanking - defaults to on.

ScrollLink/NoScrollLink - history - replaced by ToggleScrollLink - defaults to on with a 0 param.

If you supply a param it offsets the Scroll -- remember you had a use for this ?

All sounds good I'm assuming that the toggle for follow MCP visibility is follow TCP visibility?

I use the ScrollLink offset to put the selected track in Reaper in front of me (in the middle) rather than on the far left.

[MixMonkey]

Originally Posted by Puck

I don’t think CSI is back to respecting track visibility yet. Admittedly I haven’t tested this in recent builds so potentially I'm mistaken.

There's definitely something hinky about it. What seems to happen is that if you hide some tracks in the MCP from the TCP in Reaper with the MCP hidden, the tracks won't disappear from the surface until the MCP is shown in Reaper. However, unhiding the tracks works just fine with the MCP hidden.

I get this a lot as I always hide MIDI tracks in the MCP and rarely have the MCP showing on the monitor.

[Funkybot]

Geoff, trying to work on the wiki before heading out today.

Has SelectedTrackFX been removed as an FX activation approach? I never actually used this method before, but my understanding was that in the past, you could use a SelectedTrackNavigator, then use either:

SomeButton     MapSelectedTrackFXToWidgets

Or...

OnTrackSelection     MapSelectedTrackFXToWidgets

...to activate the FX. This would've been for a "Console One" workflow where just selecting the track maps the FXParams to the appropriate widget on your surface.

Is this gone or is there a CSI 2.0 action that replaced MapSelectedTrackFXToWidgets? I tried GoSelectedTrack and that doesn't seem to do it and I don't see a Toggle action in the action list.

[Geoff Waddington]

Originally Posted by Puck

Since (presumably) you’ll be in the gui section. There’s that pesky windows scaling bug that cuts off the buttons when I’m at more than 100% scaling. (I.e. by the buttons I mean the line of buttons that includes “Add Midi” and “Add OSC”)

Pretty sure that one is the bug where Reaper dictates the Window size -- aka -- out of CSI's hands.

However with the GUI redesign, I'll try to make everything shorter

Originally Posted by Puck

I don’t think CSI is back to respecting track visibility yet. Admittedly I haven’t tested this in recent builds so potentially I'm mistaken.

Yeah, right you are, just tested this.

If you use Track Manager, you cannot control visibility based on the TCP, however you can control visibility based on the MCP, IF AND ONLY IF you have the Mixer visible, Uggghh.

The previous CSI version used to do a complete recalculation of every track on every update pass.

CSI cheated and used the following API values to determine visibility -- reasoning that if the track control panel was visible, the Track was

// B_SHOWINMIXER : bool * : track control panel visible in mixer (do not use on master track)
// B_SHOWINTCP : bool * : track control panel visible in arrange view (do not use on master track)

The much improved CSI design does not recalculate every Track 15 or so times a second (the update pass frequency).

The downside is, CSI is now at the mercy of the Reaper behaviour, presumably, with the Mixer visible, the Track Manager visibility changes trigger an update, with the Mixer hidden they do not. And there never seems to be an update triggered by TCP visibility changes.


The upshot of all of this is...

I think the best way to handle it is to eliminate the Follow TCP/MCP visibility function altogether and go with the TCP visibility, which seems to be the same as the overall Reaper Tracks.

The need for the visibility handling is lessened by the fact we have VCA spill and Folder Tracks, but I know there are going to be some unhappy folks, probably including you

[Funkybot]

Originally Posted by Geoff Waddington

There is nothing (yet) to cause CSI to follow Reaper.

Unless you use a SelectedTrack workflow like I do with the X-Touch One. I think this is why I get confused by this functionality. Thanks for clarifying.

[Funkybot]

Originally Posted by Geoff Waddington

I think the best way to handle it is to eliminate the Follow TCP/MCP visibility function altogether and go with the TCP visibility, which seems to be the same as the overall Reaper Tracks.

The need for the visibility handling is lessened by the fact we have VCA spill and Folder Tracks, but I know there are going to be some unhappy folks, probably including you

I'd rather live with the current-state bug myself!

I use kind of a "Studio One" workflow where the MCP view is almost always docked at the bottom of my screen and seldom ever closed. And when it's not docked at the bottom, the Mixer will be docked at the left side of the screen with only the selected track's fader visible in Reaper (bless the Screensets feature for allowing all of this).

I tend to never hide tracks in the Arranger and set visibility as needed in the MCP - and never run into the issue with hidden channels not sync'ing. So in my workflow, it's a non-issue and worth keeping the buggy behavior in.

[MixMonkey]

Originally Posted by Funkybot

I'd rather live with the current-state bug myself!

I would too

Mixer will be docked at the left side of the screen with only the selected track's fader visible in Reaper (bless the Screensets feature for allowing all of this).

Once I realised what was going on, this is where I ended up.

I think it's very important to be able to hide tracks from the surface. The surface only really has any use for controlling audio, it makes no sense having MIDI tracks present, particularly if they're sharing a name with their audio equivalent (that's about everything in my Kontakt tracks)

[Geoff Waddington]

Originally Posted by Funkybot

Geoff, trying to work on the wiki before heading out today.

Has SelectedTrackFX been removed as an FX activation approach? I never actually used this method before, but my understanding was that in the past, you could use a SelectedTrackNavigator, then use either:

SomeButton     MapSelectedTrackFXToWidgets

Or...

OnTrackSelection     MapSelectedTrackFXToWidgets

...to activate the FX. This would've been for a "Console One" workflow where just selecting the track maps the FXParams to the appropriate widget on your surface.

Is this gone or is there a CSI 2.0 action that replaced MapSelectedTrackFXToWidgets? I tried GoSelectedTrack and that doesn't seem to do it and I don't see a Toggle action in the action list.

GoSelectedTrackFX is the magic ticket

It does a GoAssociatedZone "SelectedTrackFX" under the hood.

[Geoff Waddington]

Originally Posted by Funkybot

I'd rather live with the current-state bug myself!

I use kind of a "Studio One" workflow where the MCP view is almost always docked at the bottom of my screen and seldom ever closed. And when it's not docked at the bottom, the Mixer will be docked at the left side of the screen with only the selected track's fader visible in Reaper (bless the Screensets feature for allowing all of this).

I tend to never hide tracks in the Arranger and set visibility as needed in the MCP - and never run into the issue with hidden channels not sync'ing. So in my workflow, it's a non-issue and worth keeping the buggy behavior in.

OK, that makes it easy.

CSI will be hardwired to Follow MCP visibility.

[Puck]

Originally Posted by Geoff Waddington

I think the best way to handle it is to eliminate the Follow TCP/MCP visibility function altogether and go with the TCP visibility, which seems to be the same as the overall Reaper Tracks.

The need for the visibility handling is lessened by the fact we have VCA spill and Folder Tracks, but I know there are going to be some unhappy folks, probably including you

I think it’s great to have CSI work the way it does now being more stable as a result. If going with TCP allows us to not have the mixer open to respect visibility, that would certainly solve my issue.

I don’t use folders or VCAs, but I would adapt and start if we can’t sort the visibility stuff out. VCA mode is pretty cool, I did some minor testing and I enjoyed how that worked, we just can’t bank through any of it now. (Admittedly that made my head spin thinking about implementing bank within VCA mode)

[Puck]

Originally Posted by Funkybot

I'd rather live with the current-state bug myself!

I use kind of a "Studio One" workflow where the MCP view is almost always docked at the bottom of my screen and seldom ever closed. And when it's not docked at the bottom, the Mixer will be docked at the left side of the screen with only the selected track's fader visible in Reaper (bless the Screensets feature for allowing all of this).

I tend to never hide tracks in the Arranger and set visibility as needed in the MCP - and never run into the issue with hidden channels not sync'ing. So in my workflow, it's a non-issue and worth keeping the buggy behavior in.

I can be swayed to use the inspector track mixer layout so that the mixer is always visible.

I don’t love that because it’s screen real estate I don’t necessarily need to see but if that remedies the issue then it’s worth it.

[MixMonkey]

Originally Posted by Geoff Waddington

OK, that makes it easy.

CSI will be hardwired to Follow MCP visibility.

Does that mean that the mixer will still need to be visible for the visibility status of any track within it to be respected?

[Geoff Waddington]

Originally Posted by Puck

I think it’s great to have CSI work the way it does now being more stable as a result. If going with TCP allows us to not have the mixer open to respect visibility, that would certainly solve my issue.

You must have cross posted, please see the one just a minute previous to your post

Originally Posted by Puck

I don’t use folders or VCAs, but I would adapt and start if we can’t sort the visibility stuff out. VCA mode is pretty cool, I did some minor testing and I enjoyed how that worked, we just can’t bank through any of it now. (Admittedly that made my head spin thinking about implementing bank within VCA mode)

You can bank the children, but you can't bank the parents (yet)

[Geoff Waddington]

Originally Posted by MixMonkey

Does that mean that the mixer will still need to be visible for the visibility status of any track within it to be respected?

I think so, according to my testing.

I know it needs to be visible to update in realtime, don't know about banking into an area where there are hidden tracks, perhaps try it and let me know

[Puck]

Originally Posted by Geoff Waddington

You must have cross posted, please see the one just a minute previous to your post



You can bank the children, but you can't bank the parents (yet)

What’s the action for banking children?

That didn’t seem to work when I tested.

[Geoff Waddington]

Originally Posted by Puck

What’s the action for banking children?

That didn’t seem to work when I tested.

You don't need one.

Whatever you have setup for banking Tracks banks VCA children in VCA mode.

[Funkybot]

Ok, I've created the wiki page on the different approaches for activating FX in CSI. Please see this page and provide any feedback (there's probably a million typos but I'll make 50 edits in the coming days to clean up any):

FX activation:
https://github.com/GeoffAWaddington/...SelectedTrack)

That page, combined with the FX and Instrument Mapping...
https://github.com/GeoffAWaddington/...rument-Mapping

...and also this FX Parameter Mapping Actions...
https://github.com/GeoffAWaddington/...apping-Actions

...should now cover every element of FX mapping/activation in only 3 [long ass] pages. My hope is this will be much easier to follow than the prior-state where this information was split across something like 9 pages.

[Geoff Waddington]

Originally Posted by Funkybot

Ok, I've created the wiki page on the different approaches for activating FX in CSI. Please see this page and provide any feedback (there's probably a million typos but I'll make 50 edits in the coming days to clean up any):

FX activation:
https://github.com/GeoffAWaddington/...SelectedTrack)

That page, combined with the FX and Instrument Mapping...
https://github.com/GeoffAWaddington/...rument-Mapping

...and also this FX Parameter Mapping Actions...
https://github.com/GeoffAWaddington/...apping-Actions

...should now cover every element of FX mapping/activation in only 3 [long ass] pages. My hope is this will be much easier to follow than the prior-state where this information was split across something like 9 pages.

That's really coming together nicely, much improved over the old endless pages approach !!

[MixMonkey]

Originally Posted by Geoff Waddington

I think so, according to my testing.

Not a problem, I've got used to that single channel mixer strip on the LHS of the main edit window.

I know it needs to be visible to update in realtime, don't know about banking into an area where there are hidden tracks, perhaps try it and let me know

This seems to work fine also. Hid a bunch of tracks not currently within the scope of the surface banking, from the TCP in Reaper. Then banked the surface to the place where they should be and they were hidden.