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

[Puck]

Originally Posted by MixMonkey

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

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

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


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

Agreed on both counts!

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

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

[Geoff Waddington]

Originally Posted by MixMonkey

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

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

Originally Posted by MixMonkey

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

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

[Geoff Waddington]

Originally Posted by Puck

Agreed on both counts!

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

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

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

[MixMonkey]

Originally Posted by Geoff Waddington

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

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

[Geoff Waddington]

Originally Posted by MixMonkey

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

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

[Puck]

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

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

[MixMonkey]

Originally Posted by Geoff Waddington

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

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

[Funkybot]

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

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

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

[MixMonkey]

Originally Posted by Funkybot

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

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

[Geoff Waddington]

Originally Posted by Puck

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

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

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

[Geoff Waddington]

Originally Posted by Funkybot

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

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

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

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

[Cragster]

Originally Posted by Funkybot

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

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

[MixMonkey]

Originally Posted by Cragster

Does this mean custom zones will not work in V2 ?

Not until SubZones are implemented.

[Cragster]

Originally Posted by MixMonkey

Not until SubZones are implemented.

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

[mattrglenn]

Originally Posted by Geoff Waddington

Glad to hear it's working !

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

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

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

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


Much work to be done on the v 2.0 documentation

Just circling back to this from a while ago…

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

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

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

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

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

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

Hopefully this makes sense!

[Geoff Waddington]

Originally Posted by mattrglenn

Just circling back to this from a while ago…

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

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

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

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

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

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

Hopefully this makes sense!

Thanks for testing !

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

[MixMonkey]

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

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

[Geoff Waddington]

Originally Posted by MixMonkey

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

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

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