Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by cjewellstudios

Exactly.

I was just trying to illustrate that the sheer amount of pages for managing that use case would be, well, unmanageable.

Cool, I just don't get how this relates to GoZone, etc. since these are just Reaper Actions with a param a la:

   someButton Reaper "someScript"

Where's the connection with GoZone here, maybe I need a coffee

[cjewellstudios]

Originally Posted by Geoff Waddington

Cool, I just don't get how this relates to GoZone, etc. since these are just Reaper Actions with a param a la:

   someButton Reaper "someScript"

Where's the connection with GoZone here, maybe I need a coffee

A nice cup of Joe maybe in order either way

It relates to GoZone due the following:

Imagine a large amount of buttons all defined in the Buttons Zone.

Now imagine the top row of

Regions, InsertFX, Item Manipulation, Automation actions.

In my "steamdeck" like workflow I'm imagining here, you could look at those buttons like folders. Each button would GoZone to a zone that writes over all the buttons below. For example GoZone "Regions" would write over all the buttons with things like

Create region named chorus 1
Go to region named chorus 1 on next bar
Etc, etc.

(Those are all scripts/custom actions I've made)

So as you can imagine, I would be using GoZone quite alot.

Does that clear up the confusion? Or is it more likely that I am missing something?

[MixMonkey]

I think we may be massively overthinking the Selected/Focused FX thing. If you had two sets of FX.zon folders, one SelectedTrack, one FocusedFX and you had:

SomeButton MapFocusedFXToWidgets

but left out:

OnFXFocus MapFocusedFXToWidgets

Wouldn't pressing SomeButton map the currently focused FX to the surface, replacing what was there before, as FocusedFX is top of the priority list?

[Geoff Waddington]

Originally Posted by cjewellstudios

A nice cup of Joe maybe in order either way

It relates to GoZone due the following:

Imagine a large amount of buttons all defined in the Buttons Zone.

Now imagine the top row of

Regions, InsertFX, Item Manipulation, Automation actions.

In my "steamdeck" like workflow I'm imagining here, you could look at those buttons like folders. Each button would GoZone to a zone that writes over all the buttons below. For example GoZone "Regions" would write over all the buttons with things like

Create region named chorus 1
Go to region named chorus 1 on next bar
Etc, etc.

(Those are all scripts/custom actions I've made)

So as you can imagine, I would be using GoZone quite alot.

Does that clear up the confusion? Or is it more likely that I am missing something?

Ah, OK, I think I'm starting to get this.

First of all, because of this use case, let's continue to call it GoSubZone.

Then, we will have to lift the hard constraint that you can't use GoSubZone on fixed Zones -- you want to be able to GoSubZone on the "Buttons" Zone -- so the constraint will be reduced to a guideline -- "don't try this at home, unless you really know what you're doing".

When you GoSubZone from "Buttons", the called Zone will inherit the Button Navigator (there isn't one) and all will work fine.

Does this cover your use case ?

[MixMonkey]

Originally Posted by cjewellstudios

Now imagine the top row of

Regions, InsertFX, Item Manipulation, Automation actions.

In my "steamdeck" like workflow I'm imagining here, you could look at those buttons like folders. Each button would GoZone to a zone that writes over all the buttons below.

I have this setup too, in my iPad Mixer. Very useful. How about allowing GoZone, but only between un-navigated Zones (like Buttons)?

EDIT: Ah, just saw your post. Is this the same thing?

[cjewellstudios]

Does this cover your use case ?

Yes! I believe so.

Would there be naming constraints?

GoSubZone "Buttons-InsertFX"

[Funkybot]

I see the value in being able to GoZone unnavigated zones. I mean, yeah, you can do all that with Pages, but the downside to that approach is that you might need five different copies of your zone folders and FX's. Probably cleaner to allow for it on page via unnavigated GoZones but I'm not sure what that means for the CSI internals in terms of complexity. If it's doable and now's the time to ask: then great. If it's a nightmare, then Pages already allow for that!

[Geoff Waddington]

Thanks for the good discussion.

There will be no naming constraints other than no dups as now.

If you use GoSubZone and the originating Zone has no Navigator, it's the same as GoZone.

You may be wondering why in the world I'm against GoZone.

Two words -- Zone Management.

The great thing about GoSubZone is that it gives the SubZone a context.

For instance we could have a dictionary of active Zones and their SubZones.

That way, when we Deactivate, Unmap etc., we know what to do.

With free Zones (GoZone) we don't know when to Deactivate, Unmap etc., the whole thing turns into a housekeeping mess real fast, and even can lead to memory leaks with dead Zones hanging about all over the place, and other such nonsense

It's not about activating a Zone, it's about what the heck to do when you're finished with it

[cjewellstudios]

I'm sure we've given Geoff enough to ponder.

Sorry I didnt bring that up before, I must have assumed we were just getting rid of GoZone for the fixed zones.

GoZone between zones that don't have navigators sounds logical to me.

....

And yeah I thought the same as MixMonkey basically. Either we are ignoring the navigator with focusedfx or we have two versions of the zone or

...maybe CSI gets the fx navigator from the action we use to map the fx and we do so with the virtual widgets and actions already in place.

Edit: this response was given without the context of Geoff's previous post.

In light of that. GoSubZone seems fine to me. However the focusedfx point is possibly still worth discussing maybe

[Funkybot]

Originally Posted by MixMonkey

I think we may be massively overthinking the Selected/Focused FX thing. If you had two sets of FX.zon folders, one SelectedTrack, one FocusedFX and you had:

SomeButton MapFocusedFXToWidgets

but left out:

OnFXFocus MapFocusedFXToWidgets

Wouldn't pressing SomeButton map the currently focused FX to the surface, replacing what was there before, as FocusedFX is top of the priority list?

I think "maybe in the past" but the last round of recent updates made it so FocusedFX just automatically focus without any additional mapping actions. It's, currently anyway, based entirely on the navigator and nothing else (other than the user focusing one). It's a nice, simple, "always on" implementation.

But I like where your head is at. Maybe what we want is this:

SomeButton     ToggleFocusedFXOverride

The idea being simply:

1. If you have FocusedFX as your FX navigator type, that action does NOTHING. You're already in FocusedFX mode.

But...where it becomes useful is...

2. If you have SelectedTrackNavigator as your FX navigator type, then run that action, that will temporarily enable FocusedFX mode. CSI will ignore the SelectedTrackNavigator for FX and temporarily replace it with a FocusedFXNavigator.

This would let you have best of both worlds on a single set of pages. But this is deep into feature request and "scope creep" territory.

[lexaproductions]

Hi Geoff, Thanks for this beautiful addition to Reaper!
I'm trying to implement the Hold Modifier feature. I made this in my zon file:

Button -> action_A
Hold+Button -> action_B

From what I can understand I get this from my controller:
Short Press -> action_A
Long Press -> action_A+action_B

Is there any way to get action_B only on the long presses???

[Geoff Waddington]

Originally Posted by lexaproductions

I'm trying to implement the Hold Modifier feature. I made this in my zon file:

Button -> action_A
Hold+Button -> action_B

From what I can understand I get this from my controller:
Short Press -> action_A
Long Press -> action_A+action_B

Is there any way to get action_B only on the long presses???

No, because CSI is designed to be as responsive as possible.

Therefore Actions happen on press not release.

I use Hold here to display the metronome settings.

If I just quickly press and release, I toggle the metronome on/off.

If I Hold, I toggle the metronome AND display the settings.

That's the type of use case for which Hold is designed.

In order to do what you want, we would have to give up response, because CSI couldn't act until the button is released.

Then it would have to time the span between press and release and act accordingly.

We made a design decision early not to go that route.

Modifiers are you friend and usually much more appropriate for use cases like yours.

[lexaproductions]

I understand the design decision and that's what I thought.

Unfortunately I use this for a foot controller and It's hard for me to push 2 buttons at the same time with one foot.

Back to the drawing board...

[Funkybot]

Originally Posted by lexaproductions

I understand the design decision and that's what I thought.

Unfortunately I use this for a foot controller and It's hard for me to push 2 buttons at the same time with one foot.

Back to the drawing board...

I don't know what your specific use-case is, but if you always wanted it to fire Action A on press and Action B on release, that would be possible (split the messages up in the .mst into separate press and release widgets). That approach has obvious drawbacks for 99.9% of use cases though.

[lexaproductions]

Originally Posted by Funkybot

I don't know what your specific use-case is, but if you always wanted it to fire Action A on press and Action B on release, that would be possible (split the messages up in the .mst into separate press and release widgets). That approach has obvious drawbacks for 99.9% of use cases though.

I was actually trying to avoid action_A

Here's my scenario. I use a button to trigger playback
But while it's playing, that button needs to trigger either A or B without retriggering playback at the same time.

[Funkybot]

Originally Posted by lexaproductions

I was actually trying to avoid action_A

Here's my scenario. I use a button to trigger playback
But while it's playing, that button needs to trigger either A or B without retriggering playback at the same time.

Does the timing of when A or B get triggered matter? Will you change them on the fly? If so, Hold wouldn't be a good approach either. It would be too hard to get the timing right. Do you have the opportunity to use two footswitches for this task? What hardware are you using? Are you playing guitar while you're trying to do this, which is why you can't use a modifier? I'd think one of the guitar flooboard controllers would be perfect for this (like the Behringer FCB1010). You'd assign action A to one button and action B to another, then just use one foot to switch between them as needed.

[lexaproductions]

The timing doesn't really matter. as long I could trigger one or the other. I'll try to work something out on the reascript side of things.

I have a twelve button Footswitch already really full of features. But I'll find another approach to this.
CSI is really a game changer for me. Now that I've finally put my head at it.

[Geoff Waddington]

Ok, time to build something.

Everything is as designed thus far.

We will be adding the concept of SubZones anchored to their calling Zone.

We will leave the whole Navigator thing alone... for now

Really the only external changes will be of this sort:

    	OnInitialization	Broadcast GoZone
	OnInitialization 	ReceiveBroadcast GoFXSlot GoSendSlot

	OnTrackSelection 	Map SelectedTrackFX

        SomeButton              GoSubZone SomeSubZone

Ok with everyone ?

[Funkybot]

Originally Posted by Geoff Waddington

Ok, time to build something.

Everything is as designed thus far.

We will be adding the concept of SubZones anchored to their calling Zone.

We will leave the whole Navigator thing alone... for now

Really the only external changes will be of this sort:

    	OnInitialization	Broadcast GoZone
	OnInitialization 	ReceiveBroadcast GoFXSlot GoSendSlot

	OnTrackSelection 	Map SelectedTrackFX

        SomeButton              GoSubZone SomeSubZone

Ok with everyone ?

Ok with me!

[MixMonkey]

Originally Posted by Geoff Waddington

Ok, time to build something.

Everything is as designed thus far.

We will be adding the concept of SubZones anchored to their calling Zone.

We will leave the whole Navigator thing alone... for now

Really the only external changes will be of this sort:

    	OnInitialization	Broadcast GoZone
	OnInitialization 	ReceiveBroadcast GoFXSlot GoSendSlot

	OnTrackSelection 	Map SelectedTrackFX

        SomeButton              GoSubZone SomeSubZone

Ok with everyone ?

Why 'ReceiveBroadcast' and not just 'Receive'?

[Geoff Waddington]

Originally Posted by MixMonkey

Why 'ReceiveBroadcast' and not just 'Receive'?

Sure, done !

[MixMonkey]

Originally Posted by Geoff Waddington

Sure, done !

Jubbly

[MacroFan]

Hi All,
If it exists, what would the action be to "bank" through VCA masters in VCA mode? I can't find anything about it in the wiki or on this thread about it.

[Geoff Waddington]

Ah, after a bleary eyed day, finally made some headway on a nagging problem.

For the uber geeks

There is indeed some kind of memory corruption related to value based vectors, and the recent work I did made it worse.

So, now converting all CSI vectors to pointer based.

Hopefully, that will straighten out our SubZone issues.

[airon]

Has anyone considered using ReaPack to install and update CSI ?

Just for stable releases of course. Perhaps we can work out how to do it with Cfillion.

[MixMonkey]

Originally Posted by MacroFan

Hi All,
If it exists, what would the action be to "bank" through VCA masters in VCA mode? I can't find anything about it in the wiki or on this thread about it.

At the present time there's no banking on VCA masters, hopefully this will be added in the future.

[MixMonkey]

Originally Posted by Geoff Waddington

Ah, after a bleary eyed day, finally made some headway on a nagging problem.

For the uber geeks

There is indeed some kind of memory corruption related to value based vectors, and the recent work I did made it worse.

So, now converting all CSI vectors to pointer based.

Hopefully, that will straighten out our SubZone issues.

Solving the SubZone crash on Mac would be awesome

[cjewellstudios]

Originally Posted by Geoff Waddington

For the uber geeks

There is indeed some kind of memory corruption related to value based vectors, and the recent work I did made it worse.

So, now converting all CSI vectors to pointer based.

Hopefully, that will straighten out our SubZone issues.

Thanks for the geekery update!

I thought vectors/pointers had to do with graphics/mouse clicks/touch gestures.

CSI is in C++ right?

I'm going to start digging into that soon.

[MacroFan]

Originally Posted by MixMonkey

At the present time there's no banking on VCA masters, hopefully this will be added in the future.

Thanks MixMonkey! Glad I didn't miss anything.

[Mavriq]

Originally Posted by airon

Has anyone considered using ReaPack to install and update CSI ?

Just for stable releases of course. Perhaps we can work out how to do it with Cfillion.

I can setup a git repository for releases if you want. There is a template that can be setup to automatically publish updates etc. Its pretty easy to use once set up. I can set it up with CSI ver 1.0 and 1.1 and then send the info for Geoff to test its the way he wants it. After that I can give ownership of the repo to him and show how to update etc. He has enough on his hands.

Incidentally I'm a Geoff as well. Small world.

[Funkybot]

Originally Posted by gvanbrunt

I can setup a git repository for releases if you want. There is a template that can be setup to automatically publish updates etc. Its pretty easy to use once set up. I can set it up with CSI ver 1.0 and 1.1 and then send the info for Geoff to test its the way he wants it. After that I can give ownership of the repo to him and show how to update etc. He has enough on his hands.

Incidentally I'm a Geoff as well. Small world.

Welcome to the thread "other Geoff!" And also a Canuck!

Question: can Reapack be used for updating Userplugins? I mean, I know it can be used for actions, but I believe even SWS Extensions still require a manual install and don't have a Reapack option. Or if they do, I just didn't know about that or that capability.

[airon]

Yes. The ReaTeam repo has at least one user plugin.

[Geoff Waddington]

There is a design issue with fixed Zones that contain SubZones.

Easy to know when to instantiate -- via GoSubZone, but hard to know when to get rid of them

With FX Zones, as soon as the FX Zone is Unmapped, we can dump the SubZones.

Fixed Zones never get Unmapped, they just get Activated/Deactivated.

I think we should cheat here and see how the following works, unless someone has a better idea...

SubZones that belong to a Fixed Zone -- aka they were instantiated by a call to GoSubZone from one of the Fixed Zones -- build up in the Fixed Zone list of SubZones, until you call GoHome, that cleans everything up.

No idea how this will work in reality, but the alternatives I can come up with have this strange odour, almost like a ... stack...

[Geoff Waddington]

Hmmm...

My Sunday morning mind just jumped to an alternative solution.


Is the use case we have been describing less nebulous than a call to an FX name, and more like a call to another Fixed Zone ?

In other words could we solve this by implementing IncludedZones a bit different.

We could add an optional param to IncludedZone definitions:

Zone Home
        IncludedZones
           "Buttons"
           "Channel"
           "TrackFXMenu" Inactive
           "AnyOtherFixedStyleSubZone" Inactive
        IncludedZonesEnd
ZoneEnd

GoSubZone would be restricted to FX -- and renamed to GoFXSubZone

Make sense ?

[cjewellstudios]

Originally Posted by Geoff Waddington

There is a design issue with fixed Zones that contain SubZones....

Is the Buttons thing the only use case for this?

I wouldn't expect to be able to go back a level. As in, if I've written over a few widgets, you can get rid of the previous ones. I guess I'm saying I dont think you need to keep them at all. I would expect to have to GoSubZone again if I wanted those widgets back.

I havent had my coffee yet though.

Oh and is that the only use case?

Edit: replied before your edit that contained a possible solution. Have to think a bit

[MixMonkey]

Originally Posted by Geoff Waddington

SubZones that belong to a Fixed Zone -- aka they were instantiated by a call to GoSubZone from one of the Fixed Zones -- build up in the Fixed Zone list of SubZones, until you call GoHome, that cleans everything up.

My Button SubZones are always cleared by GoZone Home, so this seems ok to me

In other words could we solve this by implementing IncludedZones a bit different.

We could add an optional param to IncludedZone definitions:

Zone Home
        IncludedZones
           "Buttons"
           "Channel"
           "TrackFXMenu" Inactive
           "AnyOtherFixedStyleSubZone" Inactive
        IncludedZonesEnd
ZoneEnd

So all the Fixed Zone SubZones would be listed as Included Zones and Activated/De-activated by GoZone SomeSubZone/GoZone Home?

[Geoff Waddington]

Originally Posted by cjewellstudios

Is the Buttons thing the only use case for this?

Originally Posted by cjewellstudios

I wouldn't expect to be able to go back a level. As in, if I've written over a few widgets, you can get rid of the previous ones. I guess I'm saying I dont think you need to keep them at all. I would expect to have to GoSubZone again if I wanted those widgets back.

In answer to an earlier post -- yes, it's C++, and are you sure you want to be a C++ coder -- you have to manage memory by hand

In this case, think of what happens with multiple calls to GoSubZone.

For each call to SubZone, you have to instantiate a Zone and put it somewhere -- because you MUST free the memory you instantiated, or it will build up over time, as in the use case you describe, you must be able to find it to free the memory later -- but when ?

With FX it is easy, they get Mapped/Unmapped frequently, so, although there may be some obscure way to get memory leaks, they will tend to be far less likely/common.

The use case you describe involves frequent switching back and forth, recipe for memory leak city...

[Geoff Waddington]

Originally Posted by MixMonkey

So all the Fixed Zone SubZones would be listed as Included Zones and Activated/De-activated by GoZone SomeSubZone/GoZone Home?

Yes, I think it more accurately reflects the intended semantics and really eases the programming chores.

Those Zones would include:

SelectedTrackFXMenu
TrackFXMenu
SelectedTrackReceives
TrackSends

... etc.

as well as any other FixedStyle Zones you define.

You would mark all of them Inactive so that they start life that way.

Then just activate/deactivate as needed.

We would likely eliminate GoSubZone and all map Variants that applied to Fixed Zones (MapTrackSend, etc.) and just GoZone or maybe introduce a new Action -- Activate.

That would mean we just need:

       someButton Activate TrackSend


       someFXZoneButton GoFXSubZone "AnFXName"

[edit] Maybe we don't need Activate, we already have Map.

which do you like better:

       someButton Activate TrackSend

       someButton Map TrackSend

[cjewellstudios]

Originally Posted by Geoff Waddington

In answer to an earlier post -- yes, it's C++, and are you sure you want to be a C++ coder -- you have to manage memory by hand

No lol

I just have an appreciation for what devs do and how they do it. It's taken me a very long time to get in to lua and I enjoy it. I just want to be able to look at what you've done and understand it lol.


What you are proposing makes sense I think


We include all of our potential zones and we'll have actions to activate (and potentially de-activate or no?) them. That I suppose eases up on the "hey, what the heck should I do with this widget" situation, yes?

[MixMonkey]

Originally Posted by cjewellstudios

We include all of our potential zones and we'll have actions to activate (and potentially de-activate or no)?

I was wondering about de-activate too, with GoZone Home being the blunt instrument that it is.