Control Surface Integration (CSI) Technical Feature Discussion

[Funkybot]

Originally Posted by Geoff Waddington

[edit] Actually just realized the Surfaces don't have to look the same, you could mix MCUs, C4s, Twisters, etc.

CSI auto map could just go by FXLayouts row number -- row 1 of Broadcaster FXLayouts, row 1 of Receiver1 FXLayouts, row 1 of Receiver2 FXLayouts, etc.

Then, similarly row 2, 3, 4, etc.

Broadcasters and Receivers could even have dissimilar FXLayouts row counts.

Even better!

[Geoff Waddington]

OK, getting ready to start coding.

One change I'd like to make:

Broadcast/Receive -> Broadcast/Listen

That avoids confusing checkbox names like ReceiveSelectedTrackReceives, etc.

I think Tracks, Folders, and VCAs should be defined exactly as they are now, I think MM (maybe FB ?) already proposed this.

If we imagine use cases where we display a choice, then press an Encoder to trigger an Action, we have the following:

TrackSend -- GoAssociatedZone TrackSend
TrackReceive -- GoAssociatedZone TrackReceive
TrackFXMenu -- GoFXSlot
SelectedTrackSend -- GoAssociatedZone SelectedTrackSend
SelectedTrackReceive -- GoAssociatedZone SelectedTrackReceive
SelectedTrackFXMenu -- GoFXSlot

Then we have the Auto map and Learn behaviours.

I would like to keep the number of checkboxes to a minimum of course.

Which checkboxes would you like to see in order to cover all of your use cases.

In other words, it seems logical that, if you have Listeners for FXMenu you, would also like auto map and Learn to span Listeners as well.

However, that might not work for MM's workflow.

So, if I could get folks to weigh in on their minimum checkbox set, that would be great.

Don't forget, for the more "stable" Zones, it is feasible to just not implement all Associated Zones for all Surfaces -- one Listener Surface could have a TrackSend Zone defined, but no SelectedTrackSend Zone defined, etc.

What is your minimum set that covers all of your use cases ?

Finally, if you don't use the "Advanced" feature, each Surface Broadcasts to itself only and Listens to itself only.

If you use the "Advanced" feature, each Broadcaster does not necessarily Listen to itself -- e.g, Pressing the Encoder does not automatically send that Action to the Broadcasting Surface.

Make sense ?

[Funkybot]

I like calling it listen.

How would users differentiate between "these two or three surfaces need to mirror each other exactly in a closed group" and "these two surfaces are part of an extender set?" Is that dictated strictly by the channel offset parameter? If I have an FXMenu1-8 on my Twister (MFT hardware, iPad and Desktop) I want those to be one independent group because I'll still have an FXMenu1-8 on the X-Touch Universal. Someone else may have two Twisters and want spanning. I'm hoping that there could be a simple way to differentiate between the behaviors without a ton of explaining.

Finally, if you don't use the "Advanced" feature, each Surface Broadcasts to itself only and Listens to itself only.

...so I was thinking about Cragster's post from a few days ago where he wanted 2 completely independent C4's with different plugin maps. The solution was to have 2 different zone folders with different fx.zon's in them. But the way I'm reading this, that sounds like it shouldn't be the case if each surface broadcasts/listens to itself. He should be able to have two surfaces operating completely independently with the same FX zone folder. Is that understanding right?

In general, I'd love to get away from requiring multiple copies of the zone folder for standalone behavior and/or mirroring if that's possible. CSI worked this way up until last week's Exp build. I think multiple zone folders should only be a requirement if users are looking to span FX across multiple surfaces. And that's only because you'll need 2 or 3 FX zones for each plugin with the different mappings for each surface.

In terms of my own needs, for the mirror setup, I'd want the following types of actions to broadcast/listen:

1. SelectedTrackFXMenu
2. GoFXSlot/ClearFXSlot
3. GoLearnFXParams/Save/Erase
4. GoHome
5. GroupModifiers (nice to have)

I think the "other Track style Zones" (e.g. TrackFXMenu, TrackSends, TrackReceives) would have to use the exact same logic as the Track zone. Just makes sense that they'd all operate using the same logic based on what shows up and how. Otherwise, why would you want to see FX Slot 1 on all tracks except on the extenders? So I'd actually just hard-code those in with the track zone logic unless someone has a good use-case for why they shouldn't be.

But the SelectedTrack variants should broadcast/listen. That would be to cover the example of "I have an Extender on the Left, and the main MCU in the middle - I only want the Selected Track Sends on the middle one because it's closest." So I'd think we'd want listen options for:

6. SelectedTrackSends
7. SelectedTrackReceives

I don't think Focusing should matter right? Like if Focusing is enabled in the zone files, then FX focus on all surfaces.

[MixMonkey]

Originally Posted by Geoff Waddington

OK, getting ready to start coding.

One change I'd like to make:

Broadcast/Receive -> Broadcast/Listen

That avoids confusing checkbox names like ReceiveSelectedTrackReceives, etc.

Good idea! CSI is now so wide ranging, naming is becoming an issue

I think Tracks, Folders, and VCAs should be defined exactly as they are now, I think MM (maybe FB ?) already proposed this.

Not sure what you mean here. If you mean that Tracks, Folders and VCAs shouldn't be part of the Broadcast/Listen logic, then yes, I agree.

If we imagine use cases where we display a choice, then press an Encoder to trigger an Action, we have the following:

TrackSend -- GoAssociatedZone TrackSend
TrackReceive -- GoAssociatedZone TrackReceive
TrackFXMenu -- GoFXSlot
SelectedTrackSend -- GoAssociatedZone SelectedTrackSend
SelectedTrackReceive -- GoAssociatedZone SelectedTrackReceive
SelectedTrackFXMenu -- GoFXSlot

Then we have the Auto map and Learn behaviours.

I make that eight and I can't think of any others Is having all eight possible?

Finally, if you don't use the "Advanced" feature, each Surface Broadcasts to itself only and Listens to itself only.

This makes sense. It means that when you initially add a new surface, nothing unexpected happens until it's defined in the Advanced section.

If you use the "Advanced" feature, each Broadcaster does not necessarily Listen to itself -- e.g, Pressing the Encoder does not automatically send that Action to the Broadcasting Surface.

Interesting, what would the use case be for this? or is it just a natural product of the architecture? Seems fine though.

[MixMonkey]

Originally Posted by Funkybot

...so I was thinking about Cragster's post from a few days ago where he wanted 2 completely independent C4's with different plugin maps. The solution was to have 2 different zone folders with different fx.zon's in them.

I have two completely independant C4's. They each have their own Zone folder but share a common FXZones folder. With the introduction of Grouping, the FXMenus now work independently.

In general, I'd love to get away from requiring multiple copies of the zone folder for standalone behavior and/or mirroring if that's possible. CSI worked this way up until last week's Exp build. I think multiple zone folders should only be a requirement if users are looking to span FX across multiple surfaces. And that's only because you'll need 2 or 3 FX zones for each plugin with the different mappings for each surface.

I agree with you in principle, but is it easier for people to understand one surface = one zone folder, than it is to have to explain multiple FXZone folders?

In terms of my own needs, for the mirror setup, I'd want the following types of actions to broadcast/listen:

1. SelectedTrackFXMenu
2. GoFXSlot/ClearFXSlot
3. GoLearnFXParams/Save/Erase
4. GoHome
5. GroupModifiers (nice to have)

I totally forgot about modifiers. Yes please!

I think the "other Track style Zones" (e.g. TrackFXMenu, TrackSends, TrackReceives) would have to use the exact same logic as the Track zone.

Actually yes, that's very true. They should just follow the Track logic.

[Funkybot]

Originally Posted by MixMonkey

I agree with you in principle, but is it easier for people to understand one surface = one zone folder, than it is to have to explain multiple FXZone folders?

In my head it's more of a where it's all about the same mapping/configuration, there should just be a single folder. Like in the mirrored surface setup, why have 2 or 3 copies of the same folder when they're all going to mapped the same? That's going to make editing a bit of a chore and lead to the potential for "sh*t, I only made the change on 2 out of 3 surface zone folders! That weird behavior I was getting was drivinvg me nuts until I found that!"

We've all been there: file management is responsible for a lot of CSI errors. Having 2 or 3 copies of the same surface zone folder is going to compound the likelihood of those kinds of errors.

[Funkybot]

One more thought: would it make sense to have the broadcasters/listener instructions part of the CSI.ini rather than in the zone files?

If we get a front-end for it in the CSI device preferences, I'm thinking it could be covered in a new section of the CSI.ini.

Version 3.0

MidiSurface "XTouchOne" 7 9 
OSCSurface "iPad" 8008 9008 192.168.1.160
MidiSurface "CMC-QC-2" 10 12 
MidiSurface "X Touch Universal" 25 26 
MidiSurface "CMC-QC-1" 9 11 
OSCSurface "iPhone" 9009 8009 192.168.1.153
MidiSurface "SCE-24" 0 14 
MidiSurface "MFTwister" 6 8 
OSCSurface "Desktop" 8011 9011 192.168.1.152

Page "HomePage" UseScrollLink
"X Touch Universal" 8 0 "X-Touch.mst" "X-Touch_FB" "X-Touch_FB" 
"XTouchOne" 1 0 "X-Touch_One.mst" "X-Touch_One_FB" "X-Touch_One_FB" 
"iPad" 8 0 "FXTwister.ost" "FXTwister_iPAD" "FXTwisterFXZones" 
"CMC-QC-1" 0 0 "Stienberg_CMC-QC-1.mst" "Steinberg_CMC-QC-1" "Steinberg_CMC-QC-1" 
"CMC-QC-2" 0 0 "Stienberg_CMC-QC-2.mst" "Steinberg_CMC-QC-2" "Steinberg_CMC-QC-2" 
"iPhone" 1 0 "CSIPhoneRemote.ost" "CSIPhoneRemote" "CSIPhoneRemote" 
"MFTwister" 8 0 "MIDIFighterTwisterEncoder.mst" "FXTwister_MFT" "FXTwisterFXZones" 
"Desktop" 8 0 "FXTwister.ost" "FXTwister_Desktop" "FXTwister_Desktop" 

Braodcasters "HomePage"
MFTwister SelectedTrackFXMenu GoFXSlot LearnFXParams
Desktop SelectedTrackFXMenu GoFXSlot LearnFXParams
iPad SelectedTrackFXMenu GoFXSlot LearnFXParams

Listeners "HomePage"
MFTwister SelectedTrackFXMenu GoFXSlot LearnFXParams
Desktop SelectedTrackFXMenu GoFXSlot LearnFXParams
iPad SelectedTrackFXMenu GoFXSlot LearnFXParams

[MT4U]

If I understand things correctly, in next version, broadcasting other Zones than the "fixed" Associated Zones will not be possible.

In my "X-Touch+Extender = 16 tracks surface wannabe" setup that's a big huge stepback

[Funkybot]

Originally Posted by MT4U

If I understand things correctly, in next version, broadcasting other Zones than the "fixed" Associated Zones will not be possible.

In my "X-Touch+Extender = 16 tracks surface wannabe" setup that's a big huge stepback

What are you doing in those other zones? Might help to understand the use-case.

[Geoff Waddington]

Ok, I'm just going to answer these in any old order, forgive me for not attributing authorship

You can Broadcast anything anywhere.

The new functionality will be defined in CSI.ini.

The duplicate Zone requirement is mostly driven by the way Learn works right now, remember the one Surface clobbers another upon Save issue when there is a shared Zone folder ?

Broadcasters don't necessarily Listen to themselves -- you might want FXMenu on a Broadcaster, but have GoFXSlot do nothing on the Broadcaster, and just open the FX on Listeners.

I think modifiers should work like this:

ToggleUseLocalModifiers isolates modifiers for a Listener Surface.

If a Surface is a Broadcaster, ToggleUseLocalModifiers isolates the Group from global.

It gets trickier if a Surface is both a Broadcaster and a Listener, haven't thought that through yet

Thanks for the discussion, more to come I'm sure...

[MT4U]

Originally Posted by Funkybot

What are you doing in those other zones? Might help to understand the use-case.

Macro stuff. Displaying Track Templates for some 10+ Audio/MIDI inputs, also for adding track templates with different plug-ins pre-configured.

Just to look at the 16 screens (Extender+X-Touch) and select if you're recording Guitar 1, Drum Overheads/MIDI e-drum inputs/etc/etc, each template with a different base FX chain all setup-up.

In FX SubZones, which is a totally different scenario I usually have my synths's OSC/AMP/Filter/etc/etc subzones spread across all 16 tracks and have 6 SubZones instead of 12 if I had to use a single 8-tracker.

I've been using Extender buttons for FX SubZone navigation and learned to live with it, but when you need to go to a SubZone from the Track zone, any mapping of actions in the Extender, for example

  Select8        GoSubZone    "Zone-66"

breaks all the "Select|" actions even if you add yet another button press and go for things like "Option+Select8" it still does.

Also, things like toggling Focused FX mapping on the Extender can only be done OnZoneActivation, no way to add a "Toggle" button since they are all in use in the Track zone and they break even if I try to use modifiers for the Toggle function.

If the main MCU broadcasted SubZone navigation to, let's say some "Config Zone", I could be toggling stuff on and off in the Extender without breaking the track zone.

I'm quite happy right now sticking to CSI 3.1.0 but would really like to stay up-to-date and have the superb Learn functionality .

Let's say the power of customizable SubZones is the reason I turned to CSI in the first place :-)

[Geoff Waddington]

Originally Posted by MT4U

Macro stuff. Displaying Track Templates for some 10+ Audio/MIDI inputs, also for adding track templates with different plug-ins pre-configured.

Just to look at the 16 screens (Extender+X-Touch) and select if you're recording Guitar 1, Drum Overheads/MIDI e-drum inputs/etc/etc, each template with a different base FX chain all setup-up.

In FX SubZones, which is a totally different scenario I usually have my synths's OSC/AMP/Filter/etc/etc subzones spread across all 16 tracks and have 6 SubZones instead of 12 if I had to use a single 8-tracker.

I've been using Extender buttons for FX SubZone navigation and learned to live with it, but when you need to go to a SubZone from the Track zone, any mapping of actions in the Extender, for example

  Select8        GoSubZone    "Zone-66"

breaks all the "Select|" actions even if you add yet another button press and go for things like "Option+Select8" it still does.

Also, things like toggling Focused FX mapping on the Extender can only be done OnZoneActivation, no way to add a "Toggle" button since they are all in use in the Track zone and they break even if I try to use modifiers for the Toggle function.

If the main MCU broadcasted SubZone navigation to, let's say some "Config Zone", I could be toggling stuff on and off in the Extender without breaking the track zone.

I'm quite happy right now sticking to CSI 3.1.0 but would really like to stay up-to-date and have the superb Learn functionality .

Let's say the power of customizable SubZones is the reason I turned to CSI in the first place :-)

I think I misunderstood when I answered your post a while back.

Associated Zones are hardwired, but SubZones are not.

Is Broadcasting SubZone changes what you are looking for ?

[MT4U]

Originally Posted by Geoff Waddington

I think I misunderstood when I answered your post a while back.

Associated Zones are hardwired, but SubZones are not.

Is Broadcasting SubZone changes what you are looking for ?

Exactly!

Since SubZone changes are not Broadcasted, I've been getting away "illegally" slipping them into the Associated Zones up until 3.1.0

The most basic use case I can think of is a "toggle" zone for the Extender where I can configure ToggleEnableFocusedFXMapping, ToggleEnableFocusedFXParamMapping for that particular surface, and I need to go to that SubZone from a button press on the main MCU since all the extender buttons are in use in the Track Zone.

[Geoff Waddington]

Originally Posted by MT4U

Exactly!

Since SubZone changes are not Broadcasted, I've been getting away "illegally" slipping them into the Associated Zones up until 3.1.0

The most basic use case I can think of is a "toggle" zone for the Extender where I can configure ToggleEnableFocusedFXMapping, ToggleEnableFocusedFXParamMapping for that particular surface, and I need to go to that SubZone from a button press on the main MCU since all the extender buttons are in use in the Track Zone.

Ok, will add Broadcast/Listen SubZone to the list.

[MT4U]

Originally Posted by Geoff Waddington

Ok, will add Broadcast/Listen SubZone to the list.

Thank you so much!

[Geoff Waddington]

Ok, so I think these are the checkboxes needed for the Listener list:

Selected Track Scope
Send
Receive
Learn
Auto-Map
FXSlot

Track Scope
SubZone
GoHome
FXSlot

Selected Track Scope would include Focused FX for Learn and Auto-Map.

Modifier scope would work as stated earlier.

Make sense ?

[Funkybot]

Sounds good to me!

MT4U, are you calling SubZones from a SelectedTrack scope? Is that even a thing?

[Geoff Waddington]

Originally Posted by Funkybot

Sounds good to me!

MT4U, are you calling SubZones from a SelectedTrack scope? Is that even a thing?

Well, I actually think SubZones can be called from any scope, the Track Scope just had less things, so I placed it there.

Matter of fact, if we can agree the FXSlot applies to both Track Scope and Selected Track Scope, we wouldn't even need those qualifiers.

[Funkybot]

Originally Posted by Geoff Waddington

Matter of fact, if we can agree the FXSlot applies to both Track Scope and Selected Track Scope, we would even need those qualifiers.

I can agree to that!

[Geoff Waddington]

Originally Posted by Funkybot

I can agree to that!

Ok, can we also combine

Learn
Auto-Map
FXSlot

and call it

FX

Don't forget, all Broadcasters will broadcast every one one of those things in the previous list always.

It's up to the Listener to decide what they want to "hear"

[Funkybot]

Originally Posted by Geoff Waddington

Ok, can we also combine

Learn
Auto-Map
FXSlot

and call it

FX

I'm thinking there may be a use case for having the Learn buttons on one surface broadcasting to another separate from the GoFXSlot. Would have to think about that some more.

Example: I don't have great buttons to use for Learn, Save and Erase on the Twister. I can use the side bank buttons, but they're awkwardly located. I can create OSC buttons though. So maybe in my particular setup, that wouldn't be an issue.

Others should definitely chime in.

Originally Posted by Geoff Waddington

Don't forget, all Broadcasters will broadcast every one one of those things in the previous list always.

It's up to the Listener to decide what they want to "hear"

Regarding this: the broadcaster will still have specific group targets right? They're not broadcasting everything everywhere?

Example:

MFtwister to/from iPad for mirroring as one broadcast/listen group.

X-Touch+Extender for spilling as another broadcast/listen group.

The two groups never broadcast to each other.

[Geoff Waddington]

Originally Posted by Funkybot

I'm thinking there may be a use case for having the Learn buttons on one surface broadcasting to another separate from the GoFXSlot. Would have to think about that some more.

Example: I don't have great buttons to use for Learn, Save and Erase on the Twister. I can use the side bank buttons, but they're awkwardly located. I can create OSC buttons though. So maybe in my particular setup, that wouldn't be an issue.

Others should definitely chime in.



Regarding this: the broadcaster will still have specific group targets right? They're not broadcasting everything everywhere?

Example:

MFtwister to/from iPad for mirroring as one broadcast/listen group.

X-Touch+Extender for spilling as another broadcast/listen group.

The two groups never broadcast to each other.

Yes just to be clear, Broadcasters broadcast everything to their Listeners, not all Surfaces.

So, in your first scenario, if you wanted, you could set the Listener to listen for Learn, Save and Erase, but not GoFXSlot, if we don't combine them.

You've sold me.

For now at least, here's the list of things a Listener can listen to:

GoHome
SubZone
Send
Receive
Learn
Auto-Map
FXSlot

The Broadcaster will broadcast all of the above to all Listeners for that Broadcaster, the individual Listeners decide what they want to hear.

[Funkybot]

Sounds mighty good to me!

[MixMonkey]

Originally Posted by Geoff Waddington

For now at least, here's the list of things a Listener can listen to:

GoHome
SubZone
Send
Receive
Learn
Auto-Map
FXSlot

Are these (where appropriate) the SelectedTrack variants? There was discussion about the Track variants being left alone as far as Broadcast/Listen was concerned.

I notice FXMenu is missing. Is this because I've misunderstood the mechanism? Also modifiers?

The Broadcaster will broadcast all of the above to all Listeners for that Broadcaster, the individual Listeners decide what they want to hear.

...and Broadcasters and Listeners are determined by their membership of a Broadcast Group (just to be clear).

[Geoff Waddington]

Originally Posted by MixMonkey

Are these (where appropriate) the SelectedTrack variants? There was discussion about the Track variants being left alone as far as Broadcast/Listen was concerned.

Yes, Track Sends and Receives stay as is.

TrackFXMenu Broadcast/Listens like SelectedTrackTrackFXMenu.

Originally Posted by MixMonkey

I notice FXMenu is missing. Is this because I've misunderstood the mechanism? Also modifiers?

Do we need a separate checkbox for FXMenu ?

Right now it has the same behaviour as FXSlot in terms of Broadcast/Listen.

I think modifiers should work like this:

ToggleUseLocalModifiers isolates modifiers for a Listener Surface.

If a Surface is a Broadcaster, ToggleUseLocalModifiers isolates the Group from global.

Originally Posted by MixMonkey

...and Broadcasters and Listeners are determined by their membership of a Broadcast Group (just to be clear).

Yes.

[MT4U]

Originally Posted by Funkybot

Sounds good to me!

MT4U, are you calling SubZones from a SelectedTrack scope? Is that even a thing?

Dunno if that's even a thing. I'm calling some SubZones from the X-Touch Buttons.zon (broadcasted to the Extender) and others from within FX Zones, though inside the FX Zones there is no problem mapping track buttons on the Extender for SubZone navigation. There are no "|" in those FX Zone definitions so it creates no problem whatsoever.
Just get used to navigate both surfaces separately instead of one big combo and I can surf from Oscillators into Filters, Envelopes and the moon.

[MixMonkey]

Originally Posted by Geoff Waddington

Yes, Track Sends and Receives stay as is.

TrackFXMenu Broadcast/Listens like SelectedTrackTrackFXMenu.

Cool

Do we need a separate checkbox for FXMenu ?
Right now it has the same behaviour as FXSlot in terms of Broadcast/Listen.

Thinking about it a bit more, no probably not. GoFXSlot is the significant thing. The only reason for the FXMenu to appear on two surfaces is when you intend to make different selections from it on each (like my C4s) and this is acheived by using OnTrackSelection.

I think modifiers should work like this:

ToggleUseLocalModifiers isolates modifiers for a Listener Surface.

If a Surface is a Broadcaster, ToggleUseLocalModifiers isolates the Group from global.

That sounds great!

It gets trickier if a Surface is both a Broadcaster and a Listener, haven't thought that through yet.

I think it should be the same as when the surface was only a Broadcaster ie isolating the Group from global but still capable of listening for modifiers from other Broadcasters in the Group (thinking about the BCR2000/iPad or MFT/iPad combos).

[Funkybot]

Originally Posted by MT4U

Just get used to navigate both surfaces separately instead of one big combo and I can surf from Oscillators into Filters, Envelopes and the moon.

Gotcha. Yeah, I tend to use modifiers that way. Unmodified is kind of a "globals" page for synths (output volume, VCF freq/res, glide, maybe FX). Shift is ADSR. Option is Filter (cutoff/res appear again here but that's ok). Control is Osc1/Osc2. Then LFO's...

It's a decent paradigm for virtual analogs. Breaks down with more complex synths.

[MT4U]

Originally Posted by Funkybot

Gotcha. Yeah, I tend to use modifiers that way. Unmodified is kind of a "globals" page for synths (output volume, VCF freq/res, glide, maybe FX). Shift is ADSR. Option is Filter (cutoff/res appear again here but that's ok). Control is Osc1/Osc2. Then LFO's...

It's a decent paradigm for virtual analogs. Breaks down with more complex synths.

I did the same for a while, but it was getting messy when the oscillator count was up high, let alone FM synthesis, and then I found SubZones and well, my mind started to fly...

[Geoff Waddington]

New Exp build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

First cut at the Broadcast/Listen GUI.

I didn't want to put much time into this without feedback.

So, almost nothing works

It's just to show the layout for discussion/approval.

Press Advanced on the main config window.

The Broadcast/Listen dialog opens.

You can add Surfaces, but you can't remove them.

You can check boxes, but nothing is remembered.

The group box always says Surface, it will later say MCU, X Touch, etc.

You get the idea.

So, with you now ready to use your imagination, here's the workflow.

Select a Broadcaster and add it to the Broadcasters list.

Select and add Listeners to the Listeners list.

Configure individual Listeners by selecting them in the list and checking boxes.

Rinse and repeat.

Press Ok or Cancel.

Let me know what you think.

[Funkybot]

From a purely GUI layout perspective, I'd suggest putting the dropdowns and broadcaster/listerner lists up top, then the checkboxes below the listener listbox, but otherwise this looks good. Easy to use/understand.

Will there be something to prevent users from selecting their broadcaster as a listener?

[Geoff Waddington]

Originally Posted by Funkybot

From a purely GUI layout perspective, I'd suggest putting the dropdowns and broadcaster/listerner lists up top, then the checkboxes below the listener listbox, but otherwise this looks good. Easy to use/understand.

Yeah, I thought of that, but concluded that when users select an item in a list they would tend to look up rather than down.

What you suggest makes more sense logically, just don't know if it's the best Ux choice.

Originally Posted by Funkybot

Will there be something to prevent users from selecting their broadcaster as a listener?

No, that's a valid choice.

[Funkybot]

Originally Posted by Geoff Waddington

Yeah, I thought of that, but concluded that when users select an item in a list they would tend to look up rather than down.

What you suggest makes more sense logically, just don't know if it's the best Ux choice.

I think people, in the west at least, are just used at starting at the top-left and working to the right then down. It also makes sense from a process perspective: select the broadcaster, select the listeners, select what they listen to. It's not a big screen or anything so I don't think there's a big difference in looking up vs down.

Originally Posted by Geoff Waddington

No, that's a valid choice.

Yeah, I took the pup for a walk and remembered what you said yesterday about broadcasters not listening to themselves so they could do things like broadcast GoFXSlot to another surface. So eventually got there on my own.

Regarding the checkboxes: will they be at the listener-surface level? Specifically, will selecting a different listener from the list eventually update the checkbox list? Right now, they look almost global, but that's because nothing is working I'm sure.

If they will be listener level, I think that's all the more reason to put the checkboxes below. Emphasize the hierarchy. Otherwise, the checkbox location makes it look like they'll apply to all listeners (checkboxes above listeners), which I don't think should be the case.

[Geoff Waddington]

Originally Posted by Funkybot

I think people, in the west at least, are just used at starting at the top-left and working to the right then down. It also makes sense from a process perspective: select the broadcaster, select the listeners, select what they listen to. It's not a big screen or anything so I don't think there's a big difference in looking up vs down.

Fair enough, it does make more sense logically, and workflow wise.

Originally Posted by Funkybot

Regarding the checkboxes: will they be at the listener-surface level? Specifically, will selecting a different listener from the list eventually update the checkbox list? Right now, they look almost global, but that's because nothing is working I'm sure.

Yes, select a Listener, and the checkboxes will reflect the state of the selected Listener.

Originally Posted by Funkybot

Regarding the checkboxes: will they be at If they will be listener level, I think that's all the more reason to put the checkboxes below. Emphasize the hierarchy. Otherwise, the checkbox location makes it look like they'll apply to all listeners (checkboxes above listeners), which I don't think should be the case.

Good point, maybe move the checkboxes to the right of the Listeners list to further emphasize the hierarchy and workflow.

[Funkybot]

Checkboxes to the right sounds good.

[MixMonkey]

Originally Posted by Funkybot

Checkboxes to the right sounds good.

Sounds good to me too. Apart from moving the checkboxes, looking good!

Modifiers staying in the Zone, OnInitialization?

[Geoff Waddington]

Originally Posted by MixMonkey

Sounds good to me too. Apart from moving the checkboxes, looking good!

Modifiers staying in the Zone, OnInitialization?

Yes, because we want them to be dynamic.

For instance, I could have an X Touch that is a Broadcaster to which an SCE24 and the X Touch itself listen.

Say the FXMenu is on the X Touch.

Say the user Pushed a Rotary for GoFXSlot.

Say the X Touch and the SCE24 both listen to this.

The X Touch has 8 Rotaries, the SCE24 has 24.

It probably makes sense to isolate the SCE24, modifier wise, since there is likely to be a lot more modifier engage/disengage on the X Touch, as it only has 8 Rotaries.

In this case you could put two ToggleUseLocalModifiers in the SCE24 Zone, one upon Zone activation and one upon Zone deactivation.

This is but one of many use cases I envision where dynamic control of modifiers is beneficial.

[MixMonkey]

Originally Posted by Geoff Waddington

Yes, because we want them to be dynamic.

Fine by me

[Geoff Waddington]

New Exp build is up.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

Still basically non functional, but you can play around a bit more to get the feel, before I commit to coding it this way.

Remove and Ok buttons do nothing.

Everything else should work, but, of course, nothing gets saved, and CSI doesn't change at all.

This is just a GUI Ux test.

Let me know what you think.

[Funkybot]

Very good! No feedback. This is very clearly laid out.