Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by MixMonkey

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:

ButtonM32           ToggleScrollLink  { #44123400 #e91234ff }

....but not gColor, bColor or aColor.

Conversely, in this, in the SelectedTrackFXMenu Zone:

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.

[Geoff Waddington]

New build is up.

CSI Exp.zip

Possible fix for OSC color insanity.

[Geoff Waddington]

Originally Posted by MixMonkey

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.

[Funkybot]

Originally Posted by Geoff Waddington

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."

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.

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

[Geoff Waddington]

Originally Posted by Funkybot

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."

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.

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...

[MixMonkey]

Originally Posted by Geoff Waddington

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:

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:

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.

[Geoff Waddington]

Originally Posted by MixMonkey

Much better! Track colors now back to normal and my initial use case for alpha is working correctly:

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:

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

[MixMonkey]

Originally Posted by Geoff Waddington

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:

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

[Geoff Waddington]

Originally Posted by MixMonkey

Thanks

I just tried the obvious work around:

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.

[jacksoonbrowne]

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

[ramses]

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.

[Geoff Waddington]

Originally Posted by jacksoonbrowne

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.

[Geoff Waddington]

Originally Posted by ramses

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.

[Geoff Waddington]

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

[Funkybot]

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.

[Geoff Waddington]

Originally Posted by Funkybot

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.

[Funkybot]

Originally Posted by Geoff Waddington

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.

[MixMonkey]

Originally Posted by Geoff Waddington

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.

[Geoff Waddington]

Originally Posted by MixMonkey

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.

[Geoff Waddington]

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.

[Funkybot]

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.

[MixMonkey]

Originally Posted by Geoff Waddington

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.

[Funkybot]

Originally Posted by MixMonkey

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.

[MT4U]

Originally Posted by Geoff Waddington

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

[Geoff Waddington]

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.

[Funkybot]

Originally Posted by Geoff Waddington

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.

[MixMonkey]

Originally Posted by Funkybot

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]

Originally Posted by Funkybot

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.

[Geoff Waddington]

Originally Posted by Funkybot

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.

[MixMonkey]

Would it not be possible to implement the EZFXZones and leave the existing method intact?

[Geoff Waddington]

Originally Posted by MixMonkey

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.

[MixMonkey]

Originally Posted by Geoff Waddington

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

[Geoff Waddington]

Originally Posted by Funkybot

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."

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.

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:

    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:

    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 ?

[MT4U]

Originally Posted by Geoff Waddington

OK, before everyone gets too excited, there were numerous roadblocks along the way today.

My first approach was:

    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:

    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!

[Funkybot]

This sounds great Geoff (except the crashes). Look forward to trying this out!

[Geoff Waddington]

Originally Posted by Funkybot

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:

    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:

    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

[Geoff Waddington]

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

[AtmanActive]

Originally Posted by Geoff Waddington

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.

[andyp24]

Originally Posted by AtmanActive

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.

[MixMonkey]

Originally Posted by Geoff Waddington

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.