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

Reply
 
Thread Tools Display Modes
Old 09-07-2022, 04:21 PM   #19721
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by MixMonkey View Post
The good news: alpha variable works, sometimes...

The bad news: Colors are utterly FUBARed, whatever you set for the first six digits of the hex code you get a lighter or darker shade of red.

So, this produces bright red: #ffffffff but so does this: #ff0000ff. This produces a dark red: #555555ff and so does this: #550000ff.

In the TouchOSC monitor I can only see the rColor being sent for something like this:
Code:
ButtonM32           ToggleScrollLink  { #44123400 #e91234ff }
....but not gColor, bColor or aColor.

Conversely, in this, in the SelectedTrackFXMenu Zone:
Code:
FXBypassL|		ToggleFXBypass   { #ff5555ff #ff555500 }
...all I see in the TouchOSC monitor is aColor.

Track colors set with { Track } are still wrong.
Wow !

Will investigate.

[edit] Ah, just struck me what's wrong, fixing.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 09-07-2022 at 04:44 PM.
Geoff Waddington is offline   Reply With Quote
Old 09-07-2022, 04:43 PM   #19722
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

New build is up.

CSI Exp.zip

Possible fix for OSC color insanity.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-07-2022, 04:46 PM   #19723
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by MixMonkey View Post
Track colors set with { Track } are still wrong.
What's wrong with them ?

I believe you said they were washed out ?

What happens if you set them to full alpha in the color picker -- the Reaper monitor screen will look horrendously bright.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-07-2022, 04:58 PM   #19724
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

Quote:
Originally Posted by Geoff Waddington View Post
Funkybot, MixMonkey, and all the other experienced Zone builders out there, do you think we can use these values plus the FX parameter step list to come up with a reasonable value for tick count for a given FX parameter ?
What if it's a custom curve where we define # of ticks for each step based on the total # of steps. So we start with 2 steps, then count up. The list below would effectively say, "ok, if the FXParam has 2 steps total, that's 15 ticks to go from step to step. If the FXParam has 3 steps total, that's also 15 ticks, if it's 4 steps total that's 14 ticks for each step, and so on."
Code:
TickCount 
    Rotary 15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 3
TickCountEnd
The list above goes from 2 total FXParam steps to 25 FXParam steps. Anything >25 would use the last value. Of course, you could stop at 10 if desired.

This way CSI stores this as kind of a lookup table and can quickly assign based on the number of FXParams. I know you're kind of opposed to a table approach, but I feel like this lines up very nicely with acceleration curves in that users could define them as needed.

This might not be super obvious, but we could explain it in the wiki.

Someone else's curve might look like this.
Code:
TickCount 
    Rotary 5 5 5 5 5 4 4 4 4 4 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1
TickCountEnd
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-07-2022, 05:09 PM   #19725
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by Funkybot View Post
What if it's a custom curve where we define # of ticks for each step based on the total # of steps. So we start with 2 steps, then count up. The list below would effectively say, "ok, if the FXParam has 2 steps total, that's 15 ticks to go from step to step. If the FXParam has 3 steps total, that's also 15 ticks, if it's 4 steps total that's 14 ticks for each step, and so on."
Code:
TickCount 
    Rotary 15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 3
TickCountEnd
The list above goes from 2 total FXParam steps to 25 FXParam steps. Anything >25 would use the last value. Of course, you could stop at 10 if desired.

This way CSI stores this as kind of a lookup table and can quickly assign based on the number of FXParams. I know you're kind of opposed to a table approach, but I feel like this lines up very nicely with acceleration curves in that users could define them as needed.

This might not be super obvious, but we could explain it in the wiki.

Someone else's curve might look like this.
Code:
TickCount 
    Rotary 5 5 5 5 5 4 4 4 4 4 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1
TickCountEnd
Once again, bad communication on my part.

I meant I'm opposed to having users have to define tables.

What you just posted could work for what I have in mind.

CSI automatically synthesizes the correct values, using the algorithm you just provided in english, we just have to translate that to code.

We could try it, refine it, and hopefully end up with something that works really well automatically.

If we could even come close, we might be able to reduce the users involvement to a one number parameter, say strength.

They could set strength = 1, strength = 2, etc.

I'm shooting for something as totally automated as possible here, hopefully completely automated...
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-07-2022, 05:46 PM   #19726
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

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

CSI Exp.zip

Possible fix for OSC color insanity.
Much better! Track colors now back to normal and my initial use case for alpha is working correctly:
Code:
FXBypassL|                 ToggleFXBypass   { #FA9501ff #00000000 }
FXOfflineL|                ToggleFXOffline  { #ff5555ff #00000000 }
In the FXMenu, this causes the FXSlot button to be orange when bypassed and red when offline (these are the overlaid indicators, not the buttons themselves) The button is blue when neither bypassed or offline, but this is done by setting the color in TouchOSC.

However, if I try to do this:
Code:
FXBypassL|                 ToggleFXBypass   { #FA9501ff #01c8ffff }
FXOfflineL|                ToggleFXOffline  { #ff5555ff #00000000 }
...so that the button is blue when unbypassed (instead of setting a background color in TouchOSC) I get no indicator at all (bypassed or unbypassed)

EDIT: Just checked the TouchOSC monitor and it only seems to send out the alpha variable for either state when the "off" hex value has the alpha set to 00.

Last edited by MixMonkey; 09-07-2022 at 05:55 PM.
MixMonkey is online now   Reply With Quote
Old 09-07-2022, 06:00 PM   #19727
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by MixMonkey View Post
Much better! Track colors now back to normal and my initial use case for alpha is working correctly:
Code:
FXBypassL|                 ToggleFXBypass   { #FA9501ff #00000000 }
FXOfflineL|                ToggleFXOffline  { #ff5555ff #00000000 }
In the FXMenu, this causes the FXSlot button to be orange when bypassed and red when offline (these are the overlaid indicators, not the buttons themselves) The button is blue when neither bypassed or offline, but this is done by setting the color in TouchOSC.

However, if I try to do this:
Code:
FXBypassL|                 ToggleFXBypass   { #FA9501ff #01c8ffff }
FXOfflineL|                ToggleFXOffline  { #ff5555ff #00000000 }
...so that the button is blue when unbypassed (instead of setting a background color in TouchOSC) I get no indicator at all (bypassed or unbypassed)

EDIT: Just checked the TouchOSC monitor and it only seems to send out the alpha variable for either state when the "off" hex value has the alpha set to 00.
Yeah, it was an incredibly stupid mistake on my part

I'll check into your ToggleFXBypass and ToggleFXOffline issues tomorrow, a much more reasonable bug to solve
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-07-2022, 06:16 PM   #19728
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Geoff Waddington View Post
I'll check into your ToggleFXBypass and ToggleFXOffline issues tomorrow, a much more reasonable bug to solve
Thanks

I just tried the obvious work around:
Code:
FXBypassL|                 ToggleFXBypass   { #FA9501 #01c8ff }
FXOfflineL|                ToggleFXOffline  { #ff5555ff #00000000 }
...leave out the alpha (only the top indicator (offline), needs to go transparent) and just have a button that has one color for bypassed and another for unbypassed. Works fine
MixMonkey is online now   Reply With Quote
Old 09-07-2022, 07:22 PM   #19729
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by MixMonkey View Post
Thanks

I just tried the obvious work around:
Code:
FXBypassL|                 ToggleFXBypass   { #FA9501 #01c8ff }
FXOfflineL|                ToggleFXOffline  { #ff5555ff #00000000 }
...leave out the alpha (only the top indicator (offline), needs to go transparent) and just have a button that has one color for bypassed and another for unbypassed. Works fine
Cool, let's live with the workaround for now.

There is a design flaw in the color handling, and it's a pretty big fix, I'll get to it, but down the road a bit.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-07-2022, 09:20 PM   #19730
jacksoonbrowne
Human being with feelings
 
jacksoonbrowne's Avatar
 
Join Date: Aug 2017
Location: Ottawa, Canada
Posts: 657
Default

Hi geoff,

Just wondering if you had a chance to review the post of my source code modification for SentToPort and ReceivesOnPort when both are set to the same port number? (needed for Behringer X/MIDAS series consoles)

I doubt anyone using OSC on CSI has yet required the same send and receive port.



Cheers,
Roy
jacksoonbrowne is offline   Reply With Quote
Old 09-07-2022, 09:39 PM   #19731
ramses
Human being with feelings
 
Join Date: Jul 2009
Posts: 1,232
Default

Hi,

I'm just wondering what's the status of the new version (v2)? Is it fairly complete and documented? I'm eager to get to work preparing new setups for my Softube Console 1 and Console 1 Fader, but I would like the basics to be finalized for the most part before I get my feet wet again. Thanks.
ramses is offline   Reply With Quote
Old 09-08-2022, 12:08 AM   #19732
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by jacksoonbrowne View Post
Hi geoff,

Just wondering if you had a chance to review the post of my source code modification for SentToPort and ReceivesOnPort when both are set to the same port number? (needed for Behringer X/MIDAS series consoles)

I doubt anyone using OSC on CSI has yet required the same send and receive port.



Cheers,
Roy
Not yet.

Probably won't get to it for a couple of days.

If you are following the thread, a recent idea has come up for greatly simplifying how users define FX Zones AND simultaneously greatly simplifying CSI code internals.

Going to do that first, since there is so much bang for the buck.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 12:09 AM   #19733
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by ramses View Post
Hi,

I'm just wondering what's the status of the new version (v2)? Is it fairly complete and documented? I'm eager to get to work preparing new setups for my Softube Console 1 and Console 1 Fader, but I would like the basics to be finalized for the most part before I get my feet wet again. Thanks.
I would wait a few days, we are in the middle of some major changes that will make Zones much easier to define.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 12:21 AM   #19734
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

I was thinking about how disruptive the new changes are going to be as in, "Geeez, here we go again, all my Zone files have to be redone".

But the short answer actually is -- "You won't need to do anything at all".

We will, of course, need to replace the .mst files with the new design, but that's one per surface.

The longer answer is, "If you are OCD like me, you will want to clean up your FX zones, but if you don't really care, CSI will gladly ignore all the braces, long strings of values, etc., they will simply be ignored completely"

So, as disruptive as these changes are, there is little to no impact to the end users

I'm calling that a win
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 05:27 AM   #19735
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

That's definitely a win - and a big one! Looking forward to this!

Just something to think about (you probably already did) but if it's possible to just automatically update the .mst files for users with new values when they're not present, that would be another win for laziness. May not be worth the effort on you since it is just a one-time update.
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-08-2022, 05:32 AM   #19736
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by Funkybot View Post
Just something to think about (you probably already did) but if it's possible to just automatically update the .mst files for users with new values when they're not present, that would be another win for laziness. May not be worth the effort on you since it is just a one-time update.
Did consider it, but since it's, as you say, a one-time update to a very small set of files -- probably under 20 -- but more importantly -- probably no more than 2 or 3 for most folks -- a lot of programming effort for very little gain.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 05:41 AM   #19737
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

Quote:
Originally Posted by Geoff Waddington View Post
Did consider it, but since it's, as you say, a one-time update to a very small set of files -- probably under 20 -- but more importantly -- probably no more than 2 or 3 for most folks -- a lot of programming effort for very little gain.
Makes total sense.
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-08-2022, 05:45 AM   #19738
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Geoff Waddington View Post
Cool, let's live with the workaround for now.

There is a design flaw in the color handling, and it's a pretty big fix, I'll get to it, but down the road a bit.
There's a problem with the VCA and Folder mode Actions that were recently added. When activated they send out a never ending stream of rColor and gColor messages. The Send and Receive Actions don't do this.
MixMonkey is online now   Reply With Quote
Old 09-08-2022, 06:35 AM   #19739
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by MixMonkey View Post
There's a problem with the VCA and Folder mode Actions that were recently added. When activated they send out a never ending stream of rColor and gColor messages. The Send and Receive Actions don't do this.
Thanks, will investigate.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 07:00 AM   #19740
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

After having a look at the code in the cold light of day, I realize it's far too ambitious to completely cut over immediately.

So, let's take a phased approach.

The auto stepped values will only be calculated for the new EZFXZones.

Then we will implement the new Widget based acceleration for everything.

This way we also retain the old methods (except for acceleration), if someone prefers to use them for whatever reason.

I guess that's really the only hard committal point, are we sure Widget acceleration can be safely defined in the .mst file, with no need for acceleration deviation from Zone to Zone ?

I leave that question up to the more experienced Zone builders, so far I'm hearing that is indeed the case.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 07:06 AM   #19741
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

What you're proposing works for me. I've created hundreds of fx.zon's with thousands of acceleration values and I think they're all the same, only varying for each surface. It's really only the stepped params that I ever change the tick size for as discussed yesterday. If I did ever change acceleration for a particular widget, it was likely a rare case of a dodgy plugin response and not something I can even say for sure I've done.
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-08-2022, 07:09 AM   #19742
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Geoff Waddington View Post
I guess that's really the only hard committal point, are we sure Widget acceleration can be safely defined in the .mst file, with no need for acceleration deviation from Zone to Zone ?
No you can't Having a default acceleration makes perfect sense and will cover the majority of cases but it would unwise not to allow customised acceleration on a per parameter basis.
I'm afraid your "one size fits all" approach will be continually undermined by the lack of standardisation between plugin manufacturers.

Regarding stepped parameters, once you get past about 10 steps there's little point in using them, you may just as well use the continuous encoder. There are a few plugins that will only work if they are sent stepped values, another reason to keep the customisation option.
MixMonkey is online now   Reply With Quote
Old 09-08-2022, 07:24 AM   #19743
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

Quote:
Originally Posted by MixMonkey View Post
There are a few plugins that will only work if they are sent stepped values, another reason to keep the customisation option.
In my experience, it's more than a few. I've frequently hit the "encoder gets stuck at a step" issue while mapping plugins. But if CSI will calculate the step locations automatically and can apply the correct number of encoder ticks, there'd be no reason to worry about it at all IMO.

I would love the option to set an Acceleration default and override as needed in the zones, but it sounds like that's the source of a lot of complexity that Geoff is trying to clean up. And at least in my experience, 99.9% of my plugin params use the default acceleration level I like for my Twisters. If I did change it, it was just for a wonky plugin param or two (for some reason the AudioThing convolution plugins like Spring and Speakers come to mind - and just the params to select the impulse response).

So I could live with a default. But being able to override would be having our cake and eating it too. But I'm sympathetic to the plight of the baker and what he's trying to do here.
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-08-2022, 07:24 AM   #19744
MT4U
Human being with feelings
 
MT4U's Avatar
 
Join Date: Jan 2022
Location: Unifield
Posts: 396
Default

Quote:
Originally Posted by Geoff Waddington View Post
After having a look at the code in the cold light of day, I realize it's far too ambitious to completely cut over immediately.

So, let's take a phased approach.

The auto stepped values will only be calculated for the new EZFXZones.

Then we will implement the new Widget based acceleration for everything.

This way we also retain the old methods (except for acceleration), if someone prefers to use them for whatever reason.

I guess that's really the only hard committal point, are we sure Widget acceleration can be safely defined in the .mst file, with no need for acceleration deviation from Zone to Zone ?

I leave that question up to the more experienced Zone builders, so far I'm hearing that is indeed the case.

Hi Geoff. Regarding acceleration, and while working on my FX editor (almost complete, maybe I'll upload it during the weekend after more testing) I opted for a default acceleration curve and the possibility to modify acceleration per widget.

At some point I thought of having some different acceleration presets to choose from, but now you guys got me thinking if that is really necessary.

This is a capture of what I'm doing. Basically I calculate a bezier with one control point that the user moves.



Acceleration is configured on Rotary2
__________________

CSI_FX
: SubZone based GUI/Automapper for CSI.(UPD:2024-01-13)
Video Demo/Tutorial
Scripts for CSI: Reaper EEL2 scripts to use with CSI

Last edited by MT4U; 09-08-2022 at 07:56 AM.
MT4U is online now   Reply With Quote
Old 09-08-2022, 07:26 AM   #19745
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Thanks, looks like we will keep the default acceleration parameter for the new EZFXZone.

I think we can still calculate step sizes and probably even tick counts for the EZFXZones though.

Of course, we will keep the existing methods, since they offer the ultimate flexibility that is needed occasionally.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 07:30 AM   #19746
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

Quote:
Originally Posted by Geoff Waddington View Post
Thanks, looks like we will keep the default acceleration parameter for the new EZFXZone.

I think we can still calculate step sizes and probably even tick counts for the EZFXZones though.

Of course, we will keep the existing methods, since they offer the ultimate flexibility that is needed occasionally.
Suggestion: maybe move the Default Acceleration to the .mst file like you were thinking, and eliminate the need for that action to be added to each EZFXZone where present in the .mst. If that's not a crazy amount of work.

This way, it "just works" without having to worry about it, but can be overriden in the zone as needed. Or not...I'm good having it in the zones too.
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-08-2022, 07:47 AM   #19747
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Funkybot View Post
Suggestion: maybe move the Default Acceleration to the .mst file like you were thinking, and eliminate the need for that action to be added to each EZFXZone where present in the .mst. If that's not a crazy amount of work.

This way, it "just works" without having to worry about it, but can be overriden in the zone as needed. Or not...I'm good having it in the zones too.
This would be my ideal solution too. I'm not against the idea of a default acceleration value per surface, I just think it would be unwise to not be able to override it.
MixMonkey is online now   Reply With Quote
Old 09-08-2022, 07:51 AM   #19748
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Funkybot View Post
In my experience, it's more than a few. I've frequently hit the "encoder gets stuck at a step" issue while mapping plugins.
Ironically, this problem can usually be overcome by just not using steps and using the continuous encoder instead.
MixMonkey is online now   Reply With Quote
Old 09-08-2022, 07:54 AM   #19749
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by Funkybot View Post
Suggestion: maybe move the Default Acceleration to the .mst file like you were thinking, and eliminate the need for that action to be added to each EZFXZone where present in the .mst. If that's not a crazy amount of work.

This way, it "just works" without having to worry about it, but can be overriden in the zone as needed. Or not...I'm good having it in the zones too.
OK, sounds good, but we will implement that after we get stepped values operational.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 07:56 AM   #19750
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Would it not be possible to implement the EZFXZones and leave the existing method intact?
MixMonkey is online now   Reply With Quote
Old 09-08-2022, 08:00 AM   #19751
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by MixMonkey View Post
Would it not be possible to implement the EZFXZones and leave the existing method intact?
It would be possible, it's what I'm doing right now

Matter of fact, I'm even still allowing overriding steps in EZFXZones.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 08:08 AM   #19752
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Geoff Waddington View Post
It would be possible, it's what I'm doing right now

Matter of fact, I'm even still allowing overriding steps in EZFXZones.
As long as the existing method is still an option, I'm all for EZFXZones being as EZ as possible
MixMonkey is online now   Reply With Quote
Old 09-08-2022, 04:19 PM   #19753
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by Funkybot View Post
What if it's a custom curve where we define # of ticks for each step based on the total # of steps. So we start with 2 steps, then count up. The list below would effectively say, "ok, if the FXParam has 2 steps total, that's 15 ticks to go from step to step. If the FXParam has 3 steps total, that's also 15 ticks, if it's 4 steps total that's 14 ticks for each step, and so on."
Code:
TickCount 
    Rotary 15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 3
TickCountEnd
The list above goes from 2 total FXParam steps to 25 FXParam steps. Anything >25 would use the last value. Of course, you could stop at 10 if desired.

This way CSI stores this as kind of a lookup table and can quickly assign based on the number of FXParams. I know you're kind of opposed to a table approach, but I feel like this lines up very nicely with acceleration curves in that users could define them as needed.

This might not be super obvious, but we could explain it in the wiki.

Someone else's curve might look like this.
Code:
TickCount 
    Rotary 5 5 5 5 5 4 4 4 4 4 3 3 3 3 3 2 2 2 2 2 1 1 1 1 1
TickCountEnd
OK, before everyone gets too excited, there were numerous roadblocks along the way today.

My first approach was:
Code:
    Undo_BeginBlock();

    // Insert Track at end of project

    // Copy FX from original location and perform our magic

    Undo_EndBlock();

    Undo_DoUndo2(); // this undoes everything 
                    // captured in our block, 
                    // all at once
The insert Track part went fine.

As soon as I tried to copy the FX from the original Track, immediate super hard crash

OK, let's not use copy, let's just put a new FX on the inserted Track using Insert FX by name, should have nothing to do with the original Track, right ?

Ha !!

Same immediate super hard crash

Ok, let's go brute force and do all the calculations at the beginning.

Yup, works.

So now I need those with huge amounts of Zone definitions to try out the build I'll be putting up, likely tomorrow, and see how it performs on startup.


Ok, now back to the topic at hand.

The auto step generator seems to be working nicely in my very limited testing.

Let's see what we can do to come up with automated tick counts.

Here are the 2 possible candidates Funkybot posted above:
Code:
    15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 3 3
    5  5  5  5  5  4  4  4  4  4  3  3  3 3 3 2 2 2 2 2 1 1 1 1 1
If I read this right, those lists are highly correlated to encoder step size -- aka delta.

Could it be as simple as this ?

For now we just use the existing StepSize parameter available in EZFXZone definitions.

Seems like we could use that to determine the tick count list values.

Later on, we might improve it by adding a StepSize param to the .mst, then we wouldn't need to set StepSize for each Zone.

Im pretty punchy after a hard days work smashing up a boatload of hard crashes, but does this make any sense ?
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-08-2022, 05:40 PM   #19754
MT4U
Human being with feelings
 
MT4U's Avatar
 
Join Date: Jan 2022
Location: Unifield
Posts: 396
Default

Quote:
Originally Posted by Geoff Waddington View Post
OK, before everyone gets too excited, there were numerous roadblocks along the way today.

My first approach was:
Code:
    Undo_BeginBlock();

    // Insert Track at end of project

    // Copy FX from original location and perform our magic

    Undo_EndBlock();

    Undo_DoUndo2(); // this undoes everything 
                    // captured in our block, 
                    // all at once
The insert Track part went fine.

As soon as I tried to copy the FX from the original Track, immediate super hard crash

OK, let's not use copy, let's just put a new FX on the inserted Track using Insert FX by name, should have nothing to do with the original Track, right ?

Ha !!

Same immediate super hard crash

Ok, let's go brute force and do all the calculations at the beginning.

Yup, works.

So now I need those with huge amounts of Zone definitions to try out the build I'll be putting up, likely tomorrow, and see how it performs on startup.


Ok, now back to the topic at hand.

The auto step generator seems to be working nicely in my very limited testing.

Let's see what we can do to come up with automated tick counts.

Here are the 2 possible candidates Funkybot posted above:
Code:
    15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 3 3
    5  5  5  5  5  4  4  4  4  4  3  3  3 3 3 2 2 2 2 2 1 1 1 1 1
If I read this right, those lists are highly correlated to encoder step size -- aka delta.

Could it be as simple as this ?

For now we just use the existing StepSize parameter available in EZFXZone definitions.

Seems like we could use that to determine the tick count list values.

Later on, we might improve it by adding a StepSize param to the .mst, then we wouldn't need to set StepSize for each Zone.

Im pretty punchy after a hard days work smashing up a boatload of hard crashes, but does this make any sense ?

It sure makes sense. Sorry about the crashing experience. That's a turn off

Anyway. Great work as always, Sir!
__________________

CSI_FX
: SubZone based GUI/Automapper for CSI.(UPD:2024-01-13)
Video Demo/Tutorial
Scripts for CSI: Reaper EEL2 scripts to use with CSI

Last edited by MT4U; 09-08-2022 at 05:48 PM.
MT4U is online now   Reply With Quote
Old 09-08-2022, 06:50 PM   #19755
Funkybot
Human being with feelings
 
Funkybot's Avatar
 
Join Date: Jul 2007
Location: New Joisey
Posts: 6,072
Default

This sounds great Geoff (except the crashes). Look forward to trying this out!
__________________
CSI v3 Wiki
Funkybot is online now   Reply With Quote
Old 09-09-2022, 01:25 AM   #19756
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Quote:
Originally Posted by Funkybot View Post
Now, I think Tick Counts are a little tricky. They're pretty much a necessity with stepped params IMO, but I'll frequently vary the number of tick counts required based on 1) which surface I'm using and 2) how many stepped params there are on a given FXParam.

So starting wtih the surface: the MFTwister in Velocity Sensitive mode sends out a LOT of messages with small movements. So I tend to use a higher number of tick counts compared to the SCE-24, which doesn't send as many messages with small movements. So it really is surface specific.
Ok, if I read this right, you would also tend to set a smaller Step Size (delta) for the MFTwister than for the SCE-24, correct ?

And you would use these values for tick count for the MFTwister:
Code:
    15 15 14 14 13 13 12 12 11 11 10 10 9 9 8 8 7 7 6 6 5 5 4 3 3
and these values for the SCE24:
Code:
    5  5  5  5  5  4  4  4  4  4  3  3  3 3 3 2 2 2 2 2 1 1 1 1 1
If I have this right, it means the Step Size (delta) is inversely correlated to the tick counts.

If so, we can probably come up with something reasonable by setting only the StepSize parameter, everything else can be derived -- for most cases -- you can still fall back to manual, even in an EZFXZone, if necessary.

And if we can get the Step Size and Acceleration Values from the .mst file, we have fully automatic generation out of the box !

As stated, you can always override this where necessary.

That would be great news indeed
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com

Last edited by Geoff Waddington; 09-09-2022 at 01:43 AM.
Geoff Waddington is offline   Reply With Quote
Old 09-09-2022, 01:36 AM   #19757
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,454
Default

Thanks for the SCE24 Zones Funkybot, with those I was able to do some testing with a bit of load.

I tried about 20 UAD plugins which I own and you had Zones for.

It added a couple of seconds to project load time.

Obviously that won't scale well at all.

So, we go to plan B.

On startup we will scan all of the tracks in the project, and calculate the Step Sizes for any FX we encounter.

If you have 20 different FX in a project, you will see an increase in project load time of the aforementioned couple of seconds or so.

Then, every time you add an FX that has not been previously calculated, CSI will calculate the Step Sizes for that FX.

Will have to test it in the real world, boots on the ground sense, but it looks reasonable from here, unless you use a ton of different plugins in a given project
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline   Reply With Quote
Old 09-09-2022, 03:32 AM   #19758
AtmanActive
Human being with feelings
 
AtmanActive's Avatar
 
Join Date: Dec 2009
Location: United Kingdom
Posts: 685
Default

Quote:
Originally Posted by Geoff Waddington View Post
It added a couple of seconds to project load time.

Obviously that won't scale well at all.

So, we go to plan B.

On startup we will scan all of the tracks in the project, and calculate the Step Sizes for any FX we encounter.

If you have 20 different FX in a project, you will see an increase in project load time of the aforementioned couple of seconds or so.
Count me out.
I'll be the first one to uninstall CSI completely.
Under no circumstances will I allow any plug-in in Reaper to hog the CPU like that.
My projects usually have about 200 tracks and 500 FXs running at all times. Every ounce of CPU is precious to me. I already installed/tried/uninstalled many community add-ons for Reaper exactly because of this. Looks good on empty Reaper project, doesn't hold up in real-world usage.

What I'm trying to say here is that invasive, CPU intensive actions like that should be strictly optional so users can choose if they find it useful or not. Otherwise, all-or-nothing approach can just lead to frustrated users leaving when they hit the buffer-underruns on playback or double loading times on project load.

It is one thing to control Reaper. It is completely another to scan all FXs and their parameters on project load.

Just my 2 cents.
AtmanActive is offline   Reply With Quote
Old 09-09-2022, 04:44 AM   #19759
andyp24
Human being with feelings
 
andyp24's Avatar
 
Join Date: Mar 2016
Posts: 1,242
Default

Quote:
Originally Posted by AtmanActive View Post
Count me out.
I'll be the first one to uninstall CSI completely.
Under no circumstances will I allow any plug-in in Reaper to hog the CPU like that.
My projects usually have about 200 tracks and 500 FXs running at all times. Every ounce of CPU is precious to me. I already installed/tried/uninstalled many community add-ons for Reaper exactly because of this. Looks good on empty Reaper project, doesn't hold up in real-world usage.

What I'm trying to say here is that invasive, CPU intensive actions like that should be strictly optional so users can choose if they find it useful or not. Otherwise, all-or-nothing approach can just lead to frustrated users leaving when they hit the buffer-underruns on playback or double loading times on project load.

It is one thing to control Reaper. It is completely another to scan all FXs and their parameters on project load.

Just my 2 cents.
Of those 500 FX, how many of them are different though? I'm pretty sure Geoff is saying that if you have 100 instances of ReaEQ (or whatever) it will count as 1 FX to scan. I also run large track counts for many projects, but almost all of them will have the same EQ and Compressor on.
andyp24 is offline   Reply With Quote
Old 09-09-2022, 04:45 AM   #19760
MixMonkey
Human being with feelings
 
MixMonkey's Avatar
 
Join Date: Sep 2017
Location: London, England.
Posts: 4,927
Default

Quote:
Originally Posted by Geoff Waddington View Post
Will have to test it in the real world, boots on the ground sense, but it looks reasonable from here, unless you use a ton of different plugins in a given project
I'm afraid I've completely lost track of what you're trying to achieve here This seems to be an extremely complicated solution to address a very minor issue ie step sizes in certain plugin parameters.

Three points here:

Firstly, most stepped plugin parameters still respond to continuous (inc/dec) controller input, so are not unusable by default.

Secondly, if the user wishes to assign a stepped parameter to a push control, it would be a simple matter for them to find the push in the Zone file (which, presumably, is toggling between 0.0 and 1.0) and fill in the steps in between. Whilst there are undoubtably a few plugins where determining the step sizes is challenging, the great majority are simple.

Thirdly, once you get up to 10 or more steps, it becomes much easier to just use a continuous encoder with acceleration. I wasted a lot of time trying get 20+ step encoders to work properly before I realised it was much simpler to just not use steps.
MixMonkey is online now   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 07:08 AM.


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