Go Back   Cockos Incorporated Forums > REAPER Forums > MIDI Hardware, Control Surfaces, and OSC

Reply
 
Thread Tools Display Modes
Old 05-17-2022, 05:33 AM   #16801
Puck
Human being with feelings
 
Puck's Avatar
 
Join Date: Feb 2022
Location: Almost Canada
Posts: 214
Default

Quote:
Originally Posted by MixMonkey View Post
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)

Last edited by Puck; 05-17-2022 at 05:39 AM.
Puck is offline   Reply With Quote
Old 05-17-2022, 05:40 AM   #16802
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
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.

Quote:
Originally Posted by MixMonkey View Post
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.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-17-2022, 05:41 AM   #16803
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by Puck View Post
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.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-17-2022, 05:43 AM   #16804
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
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.
MixMonkey is offline   Reply With Quote
Old 05-17-2022, 05:53 AM   #16805
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
Can GoSubZone be made to work? I wondered whether modifiers was an easier option.
Yup, GoSubZone will work, it's just a bit complicated
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-17-2022, 06:05 AM   #16806
Puck
Human being with feelings
 
Puck's Avatar
 
Join Date: Feb 2022
Location: Almost Canada
Posts: 214
Default

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.
Puck is offline   Reply With Quote
Old 05-17-2022, 06:14 AM   #16807
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
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.
MixMonkey is offline   Reply With Quote
Old 05-17-2022, 06:27 AM   #16808
Funkybot
Human being with feelings
 
Join Date: Jul 2007
Posts: 3,789
Default

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.
Funkybot is offline   Reply With Quote
Old 05-17-2022, 07:37 AM   #16809
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Funkybot View Post
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.
MixMonkey is offline   Reply With Quote
Old 05-17-2022, 08:27 AM   #16810
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by Puck View Post
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
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-17-2022, 08:36 AM   #16811
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by Funkybot View Post
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...
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-17-2022, 10:10 AM   #16812
Cragster
Human being with feelings
 
Join Date: Apr 2019
Location: Inman, SC USA
Posts: 797
Default

Quote:
Originally Posted by Funkybot View Post
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
Cragster is offline   Reply With Quote
Old 05-17-2022, 10:13 AM   #16813
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Cragster View Post
Does this mean custom zones will not work in V2 ?
Not until SubZones are implemented.
MixMonkey is offline   Reply With Quote
Old 05-17-2022, 10:33 AM   #16814
Cragster
Human being with feelings
 
Join Date: Apr 2019
Location: Inman, SC USA
Posts: 797
Default

Quote:
Originally Posted by MixMonkey View Post
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
Cragster is offline   Reply With Quote
Old 05-17-2022, 05:43 PM   #16815
mattrglenn
Human being with feelings
 
mattrglenn's Avatar
 
Join Date: Dec 2019
Location: Los Angeles, CA
Posts: 55
Default

Quote:
Originally Posted by Geoff Waddington View Post
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!
mattrglenn is offline   Reply With Quote
Old 05-17-2022, 05:50 PM   #16816
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by mattrglenn View Post
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.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-18-2022, 04:04 PM   #16817
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

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.
MixMonkey is offline   Reply With Quote
Old 05-18-2022, 04:48 PM   #16818
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
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.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-19-2022, 06:58 AM   #16819
chinpou
Human being with feelings
 
Join Date: Aug 2021
Posts: 30
Default



Have you considered creating Rotary|CW / Rotary|CCW widgets? Trying to determine the wisest way to program my Nudge zone and I'd love to either

a) push the rotary under "Frame" to GoZone my Jogwheel and use it with modifiers to nudge an item's position, left & right trim, and contents by 1 frame or

b) use modifiers with the rotary under "Frame" to nudge item position, left & right trim, and contents by 1 frame.

Edit: read back on some of the recent dev convo and it looks like in 2.0 I'll be able to do option A with GoSubZones, I think
chinpou is offline   Reply With Quote
Old 05-19-2022, 03:22 PM   #16820
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Back to surface modifiers...

One of the things that keeps CSI an R&D effort is the ongoing struggle of fully supporting each controller in a natural and intuitive way, whilst still allowing complete integration with CSI

So let's take a couple of examples.

There are 6 automation buttons on an MCU, X-Touch, etc.

There are also 6 Reaper automation states.

If we re-purpose Group to mean Latch Preview, we have a fairly natural representation.

And if we add Shift variants for global, things work fairly well.




Now let's look at the up/down/left/right buttons.

Intuitively, they want to associate with Marker, Nudge, Scrub, and Zoom.

In effect, Marker, Nudge, Scrub, and Zoom represent natural surface modifiers for the up/down/left/right buttons.

Trouble is, if we promote them to full fledged modifiers, they are meaningless on surfaces that do not support those buttons.

Alternatively, we have discussed adding per surface modifiers definitions, but they have their own syntactic and conceptual challenges.

I'm suggesting a third approach, riffing off the MCU PanWidth Action.

Right now we use this bastardized beast in the .mst file to handle things:

Code:
Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
	Toggle 90 20 7f
WidgetEnd
This ties Rotary1 directly to RotaryPush1 -- Toggle 90 20 7f is RotaryPush1.

A cleaner solution might be keeping them separate and then implementing a Zone file something like this:

Code:
Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd
Code:
    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan
This way RotaryPush simply toggles an internal variable -- aka sets the state of the MCUTrackPan operation.

The secret sauce is in the MCUTrackPan Action itself -- it takes into account the state of the internal variable set by ToggleMCUTrackPan.

This decouples things in a very nice way -- it eliminates the monstrous .mst definition and at the same time frees up Rotary
and RotaryPush to be used "normally" in other Zones.

If we use the same approach for the other surface modifiers just mentioned we get:

Code:
    Marker ToggleMCUMarker
    Nudge  ToggleMCUNudge
    Scrub  ToggleMCUScrub
    Zoom   ToggleMCUZoom

    Up     MCUUp
    Down   MCUDown
    Left   MCULeft
    Right  MCURight
Once again the secret sauce is in the the MCU up/down/left/right variants themselves.

They notice the state of the Marker, Nudge, Scrub, Zoom state variables and act accordingly.

Also, internally, the ToggleMCUMarker, ToggleMCUNudge, ToggleMCUScrub, and ToggleMCUZoom are associated "radio button style" -- they are mutually exclusive.

Seems like a more optimal way to handle these sorts of things, what say you folks ?
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-19-2022, 04:53 PM   #16821
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
Seems like a more optimal way to handle these sorts of things, what say you folks ?
Sorry, but I find this approach extremely reductionist considering the colossal size of the Reaper Action set.

Sure, it would cover PanWidth, Zoom, Nudge, Marker and Scrub, but what about all the other, highly personalised ways people interact with Reaper and the large variety of surfaces that exist?

Would it not be possible to expand the existing global modifier arrangement of Shift, Option, Control and Alt and create additional Modifiers, say Mod1 to Mod32?

Then people could assign whatever buttons they liked to them, for pretty much whatever purpose they liked, just like they can with the existing Modifiers. The Modifiers would still be global in scope, but because there are now more than 4, modifiers that are used in one Zone or surface don't have to be used in another unless it's desired.
MixMonkey is offline   Reply With Quote
Old 05-19-2022, 05:46 PM   #16822
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
Sorry, but I find this approach extremely reductionist considering the colossal size of the Reaper Action set.

Sure, it would cover PanWidth, Zoom, Nudge, Marker and Scrub, but what about all the other, highly personalised ways people interact with Reaper and the large variety of surfaces that exist?

Would it not be possible to expand the existing global modifier arrangement of Shift, Option, Control and Alt and create additional Modifiers, say Mod1 to Mod32?

Then people could assign whatever buttons they liked to them, for pretty much whatever purpose they liked, just like they can with the existing Modifiers. The Modifiers would still be global in scope, but because there are now more than 4, modifiers that are used in one Zone or surface don't have to be used in another unless it's desired.
Totally, totally get where you are coming from on this.

It's a game of flexibility vs usability



For you, me, Funkybot, and many others keeping everything separate allows max flexibility.

On the other hand, some "ready to go" bundles are easier to understand and use for some folks.

I guess the real question is "Do those folks really use the bundled components", or do they expect an "out of the box" solution anyway, in which case, flexibility is the way to go.

Wasn't sure I agreed the modifiers should be global, but then I considered something like an extender, and global modifiers make perfect sense

Decisions, decisions

I certainly hope we can do better than Mod1 to Mod32

I say we should allow named modifiers.

If we allow modifiers to be global and there is a duplicate modifier definition in 2 different surface files, I guess "he who parses last" wins ?

Now we face another issue.

What happens if we have a modifier definition used in surface 1 that is defined in surface 2, and surface 1 loads before surface 2 ?

I guess we could just go on faith that it would eventually get defined.

If not, there would be no harm, except that the Actions in Surface 1 that used modifiers from another surface that never get resolved would just never get called [edit 3] I guess that's no different than what happens today if you define a Shift Action, but have no Shift button defined

Then there are the use cases of stringing together multiple modifiers, my head is starting to spin

Pondering...

[edit] Or maybe duplicate modifiers in 2 surfaces just means 2 different ways to engage the same modifier from different places...
And maybe we allow only one "extra" modifier beyond Touch, Shift, Control, Alt, Option -- that still opens up a ton of possibilities without the head spin...

[edit 2] Man, I'm sure glad I got the X-touch, just staring at it makes me think harder
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki

Last edited by Geoff Waddington; 05-19-2022 at 06:16 PM.
Geoff Waddington is offline   Reply With Quote
Old 05-19-2022, 06:38 PM   #16823
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
Totally, totally get where you are coming from on this.

It's a game of flexibility vs usability
Yes, it's partly that, but also about relieving us (well, mainly you) of trying to second guess how peeps will use CSI.
Quote:
For you, me, Funkybot, and many others keeping everything separate allows max flexibility.

On the other hand, some "ready to go" bundles are easier to understand and use for some folks.

I guess the real question is "Do those folks really use the bundled components", or do they expect an "out of the box" solution anyway, in which case, flexibility is the way to go.
I think most people will begin with a bundled solution to get started, then very quickly start pulling it apart and customising it (they are Reaper users after all)
Quote:
Wasn't sure I agreed the modifiers should be global, but then I considered something like an extender, and global modifiers make perfect sense
The reason for keeping the modifiers global was twofold. Firstly, the system that is currently in place is simple, predicatable and rock solid. Let's just expand it. Secondly, it avoids the Broadcast/Receive paradigm. If you want a modifier to operate in a particular Zone, make a definition for it. If you don't, don't. If you have 32 to play with there's plenty of scope to avoid using them where you don't want them, unlike only having 4.

Quote:
I certainly hope we can do better than Mod1 to Mod32

I say we should allow named modifiers.
You could, but it's easier to keep track of what you've used if they're generic, but that might just be me If you allow names, people will just name them the same as the button that they've assigned to it. So button "Marker" becomes modifier "Marker" and maybe that's ok. It certainly makes the syntax easier:
Code:
Marker    Marker
Marker+Right    Reaper "40173" //Go to next marker
Quote:
If we allow modifiers to be global and there is a duplicate modifier definition in 2 different surface files, I guess "he who parses last" wins ?
When you say "duplicate modifier definition", do you mean assigning the same modifier to different buttons on two surfaces? I do that at the moment. Or do you mean having different actions assigned to same modifier+Button definition? I do that too Pretty hard to avoid when there's only 4 modifiers...

Quote:
Now we face another issue.

What happens if we have a modifier definition used in surface 1 that is defined in surface 2, and surface 1 loads before surface 2 ?
I'm pretty sure that happens at the moment. I use modifiers in my XT Zones that are definied in the MCU Zone. They seem to work ok.

Quote:
Then there are the use cases of stringing together multiple modifiers, my head is starting to spin
What happens at the moment? Shift+Control+Option+Alt works ok (and every other combo I've tried) What's the difference between having 4 modifiers and 32?
MixMonkey is offline   Reply With Quote
Old 05-19-2022, 06:43 PM   #16824
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
[edit] Or maybe duplicate modifiers in 2 surfaces just means 2 different ways to engage the same modifier from different places...
..yep, it does and sometimes you want it and sometimes you don't.

Quote:
And maybe we allow only one "extra" modifier beyond Touch, Shift, Control, Alt, Option -- that still opens up a ton of possibilities without the head spin...
If add more you could forget about SubZones, just saying
Quote:
[edit 2] Man, I'm sure glad I got the X-touch, just staring at it makes me think harder
...and you've got illuminated Function buttons, perfect for modifiers!
MixMonkey is offline   Reply With Quote
Old 05-19-2022, 07:00 PM   #16825
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
What happens at the moment? Shift+Control+Option+Alt works ok (and every other combo I've tried) What's the difference between having 4 modifiers and 32?
Yup, but internally they are represented by 5 positions, Touch, Shift, Option, Control, Alt, no matter how you define them in your Zone file -- e.g. Alt+Shift turns into Shift+Alt, because Shift is in position 2, and Alt is in position 5.

If we allow named ones, which are seductive syntactically, we have no idea how many there are and what position they should occupy, so our existing modifier strategy breaks.

This is an argument for Mod1 - Mod32

There is also the separate issue of "radio button" style modifiers.

As far as replacing SubZones, that is only true if you have the luxury of a lot of modifiers.

With SubZones you can use one button to string SubZone navigations together, and you are more likely to need said SubZones on surfaces with less controls and modifiers.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-19-2022, 08:03 PM   #16826
Funkybot
Human being with feelings
 
Join Date: Jul 2007
Posts: 3,789
Default

Random thought: when I first started down the road of editing zone files, I just assumed incorrectly that any button could be combined with any other to act as a modifier. So I tried stuff like...

Code:
Zoom+Up    Reaper "123"
...I didn't know any better.

Getting more on topic: I'm still thinking subzones, if implemented, would negate the need for the ToggleMCUZoom and ToggleMCUScrub type actions and surface modifiers. I'd just have this in my code...

Code:
Zoom    GoSubZone "Zoom"
Scrub   GoSubZone "Scrub"
...with those zones appropriately defined and a way to get back home. And I'm thinking Geoff would just include those SubZones and mapping in the MCU and X-Touch zone files, so they were pre-configured for new users who would just expect those buttons to work out of the box, but may want to tinker once they know more. The other benefit of that approach is it's not MCU-centric and more flexible. I'm thinking Faderport users, OSC surfaces, etc.
Funkybot is offline   Reply With Quote
Old 05-20-2022, 04:43 AM   #16827
Puck
Human being with feelings
 
Puck's Avatar
 
Join Date: Feb 2022
Location: Almost Canada
Posts: 214
Default

We’re dancing around something pretty cool here.

I’m not sure what that is exactly yet, but I know we’ll get there.

With regard to usability versus flexibility/customization:

The plan is to have some sort of repository for surfaces/starter zones after we get 2.0 to a good place yeah? To me, this would be the ultimate out of the box solution for new users.

….

I know when I heard the term surface modifiers and radio button style I assumed they’d be one surface and only one active at a time. It’d be nice to be able to define them ourselves per zone but I’m not really pushing for any of this.

In terms of complicated fx zones: the above would be great for replacing the subzone use case where you aren’t stepping through them. You wouldn’t have to have multiple fx zone files either for all your “subzones” they would be contained in one file. Just some thoughts.
Puck is offline   Reply With Quote
Old 05-20-2022, 05:05 AM   #16828
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by Funkybot View Post
Random thought: when I first started down the road of editing zone files, I just assumed incorrectly that any button could be combined with any other to act as a modifier. So I tried stuff like...

Code:
Zoom+Up    Reaper "123"
...I didn't know any better.

Getting more on topic: I'm still thinking subzones, if implemented, would negate the need for the ToggleMCUZoom and ToggleMCUScrub type actions and surface modifiers. I'd just have this in my code...

Code:
Zoom    GoSubZone "Zoom"
Scrub   GoSubZone "Scrub"
...with those zones appropriately defined and a way to get back home. And I'm thinking Geoff would just include those SubZones and mapping in the MCU and X-Touch zone files, so they were pre-configured for new users who would just expect those buttons to work out of the box, but may want to tinker once they know more. The other benefit of that approach is it's not MCU-centric and more flexible. I'm thinking Faderport users, OSC surfaces, etc.
Yup, I would say the more we discuss Surface modifiers, the stronger the case gets for not implementing them, and the stronger the case gets for implementing SubZones to accomplish the same thing, simultaneously giving us a better:

internal coding model
more understandable/usable Ux.

As well, SubZones satisfy the need for custom Zones.

I would say rigor mortis has set in on the old grey mare named Surface Modifiers
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-20-2022, 05:10 AM   #16829
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by Puck View Post
We’re dancing around something pretty cool here.

I’m not sure what that is exactly yet, but I know we’ll get there.

With regard to usability versus flexibility/customization:

The plan is to have some sort of repository for surfaces/starter zones after we get 2.0 to a good place yeah? To me, this would be the ultimate out of the box solution for new users.
Yup, agree totally !

Quote:
Originally Posted by Puck View Post
I know when I heard the term surface modifiers and radio button style I assumed they’d be one surface and only one active at a time. It’d be nice to be able to define them ourselves per zone but I’m not really pushing for any of this.
Thanks for reminding me, SubZones are automatically radio button style, it's inherent in the design

Quote:
Originally Posted by Puck View Post
In terms of complicated fx zones: the above would be great for replacing the subzone use case where you aren’t stepping through them. You wouldn’t have to have multiple fx zone files either for all your “subzones” they would be contained in one file. Just some thoughts.
Yeah, pretty sure the complexity outweighs the usability here
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-20-2022, 05:19 AM   #16830
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

One last thing that indicates this discussion has been at least somewhat productive, MCUTrackPan will be redesigned thusly, such that RotaryPush is available for other tasks:

Code:
Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd
Code:
    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-20-2022, 05:22 AM   #16831
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
Yup, I would say the more we discuss Surface modifiers, the stronger the case gets for not implementing them, and the stronger the case gets for implementing SubZones to accomplish the same thing, simultaneously giving us a better:

internal coding model
more understandable/usable Ux.

As well, SubZones satisfy the need for custom Zones.

I would say rigor mortis has set in on the old grey mare named Surface Modifiers
Cool, let's do SubZones then Extending the existing Modifier architecture was only really a 'thing' if it was quick and easy to implement. It didn't need to have named modifiers or combinations.
MixMonkey is offline   Reply With Quote
Old 05-20-2022, 06:10 AM   #16832
Funkybot
Human being with feelings
 
Join Date: Jul 2007
Posts: 3,789
Default

Quote:
Originally Posted by Geoff Waddington View Post
One last thing that indicates this discussion has been at least somewhat productive, MCUTrackPan will be redesigned thusly, such that RotaryPush is available for other tasks:

Code:
Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
WidgetEnd

Widget RotaryPush1
	Toggle 90 20 7f
WidgetEnd
Code:
    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPan
I like this.

I think SubZones are the best way forward but it's important to try to fully vet alternative approaches and ideas.
Funkybot is offline   Reply With Quote
Old 05-20-2022, 06:38 AM   #16833
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Funkybot View Post
I think SubZones are the best way forward but it's important to try to fully vet alternative approaches and ideas.
SubZones are definitely where people will really get into customising how CSI behaves.
MixMonkey is offline   Reply With Quote
Old 05-20-2022, 04:42 PM   #16834
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
SubZones are definitely where people will really get into customising how CSI behaves.
Yup, definitely agree, and it follows that now the community can likely come up with a real solid "starter set" for everything except SubZones and FX Zones.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-20-2022, 04:49 PM   #16835
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

New build is up.

CSI Exp.zip

.ost should work again in the config panel.

Possible fix for the Reaper Banking Synchronize bug.

Revamped MCUTrackPan as per discussion:

Code:
Widget RotaryPush1
	Press 90 20 7f
WidgetEnd

Widget Rotary1
	Encoder b0 10 7f [ > 01-0f < 41-4f ]
	FB_Encoder b0 10 7f
	Toggle 90 20 7f
WidgetEnd
Code:
Zone "Track"
    DisplayUpper|            	TrackNameDisplay
    Fader|Touch+DisplayLower| 	TrackVolumeDisplay
    DisplayLower|      		MCUTrackPanDisplay
    Fader|                   	TrackVolume 
    Rotary|                     MCUTrackPan
    RotaryPush|                 ToggleMCUTrackPanWidth
    RecordArm|                  TrackRecordArm
    Solo|                       TrackSolo
    Mute|                       TrackMute
    Select|                     TrackUniqueSelect
    Shift+Select|               TrackRangeSelect
    Control+Select|             TrackSelect
ZoneEnd
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-20-2022, 05:03 PM   #16836
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
Yup, definitely agree, and it follows that now the community can likely come up with a real solid "starter set" for everything except SubZones and FX Zones.
Absolutely, possibly include a simple SubZone, say Zoom, to function as an example so that the syntax/Zone arrangement is laid out. Same goes for FX.
MixMonkey is offline   Reply With Quote
Old 05-20-2022, 05:17 PM   #16837
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 3,213
Default

Quote:
Originally Posted by Geoff Waddington View Post
New build is up.

CSI Exp.zip

.ost should work again in the config panel.

Possible fix for the Reaper Banking Synchronize bug.

Revamped MCUTrackPan as per discussion:
.ost surface menu working again. Banking seems to work correctly now when clicking on track with mouse

Will try out the MCUTrackPan when back in studio
MixMonkey is offline   Reply With Quote
Old 05-20-2022, 05:33 PM   #16838
Funkybot
Human being with feelings
 
Join Date: Jul 2007
Posts: 3,789
Default

Are we thinking SubZones for Zoom, Scrub, and Nudge? Any other buttons on the MCU we think need a corresponding SubZone? Flip?

Last edited by Funkybot; 05-20-2022 at 05:39 PM.
Funkybot is offline   Reply With Quote
Old 05-20-2022, 05:37 PM   #16839
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by MixMonkey View Post
.ost surface menu working again. Banking seems to work correctly now when clicking on track with mouse

Will try out the MCUTrackPan when back in studio
Good news, thanks for testing !
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Old 05-20-2022, 05:39 PM   #16840
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 7,816
Default

Quote:
Originally Posted by Funkybot View Post
Are we thinking SubZones for Zoom, Scrub, and Nudge? Any other buttons on the MCU we think need a corresponding SubZone?
Yup, was also thinking Marker:

Up -- add marker

Left/Right -- prev/next marker

Down -- delete current marker

[edit] Just saw your edit Flip is another good one.
__________________
Software -- https://stash.reaper.fm/v/42437/CSI%20v1_1.zip
Donate -- via PayPal to waddingtongeoff@gmail.com
Wiki -- https://github.com/GeoffAWaddington/...ntegrator/wiki
Geoff Waddington is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:20 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.