Blue Cat's Plug'n Script 3.3 Released - DSP DIY Summer?

[ilyaorlov]

I have a question about metering!
I see it takes a little amount of CPU, and with many plugins in project (say 30-50) this CPU load can be quite high.
Thinking about custom metering that turns off when gui is closed.
Maybe you could point us to some examples how to make meters like in PnS (the algorithms for calculation)? Cause in general they are very cool!

[Blue Cat Audio]

That's indeed an option I'd like to add in the future too .

For the meters, a simple filter usually does the trick:

double value=abs(sample);
if(value>envelope)
envelope=value;
else
envelope=value*lowPassCoeff+(1-lowPassCoeff)*envelope;

Adjust the coefficient according to the release speed of the meter that you like.

[ilyaorlov]

Thanks a lot!

[ilyaorlov]

I'm adding a new features to the plugin, so the skin loads slower and slower (1.8 seconds now on first start), so I'm thinking about optimizing it.
Are there some tricks for that? What's good, what's bad? Which elements to avoid (that slow loading), or something like that?
I don't have KUIML_WIDGETSs inside, all is glued into a single XML.

[Blue Cat Audio]

Wow that's pretty slow. Usually the slowest thing to load is graphics resources if you have many large images. Are you maybe using lost of scripts upon load too? It's hard to tell without seeing the actual skin.

[ilyaorlov]

Yea, I will try to track it down,
there are couple of build_time scripts, that indeed slow down the process, esp. considering they are called twice But i think maybe PARAM_LINKS or STRING_LINKS, or POPUP_MENUs or FORMULA_PARAMS or something else are really slow and should be avoided. Maybe auto size calculations are slow... Probably I can figure that out by tests!

[Blue Cat Audio]

Scripts are probably negligible, except if you process tons of data.

Layout computation can Indeed be pretty intensive if you change many widgets sizes (it is a complex system with potentially lots of recursion). In general you should use as much fixed size as you can.

[ilyaorlov]

So my main issue was with using .* with required_objects too much.
With a bit of optimization I could reduce skin loading time from 1650 to 950 ms.

[ilyaorlov]

Just a quick question: can data.samplesToProcess be 0 at any point in processBlock? Should be check for it's value in case of division by zero?

[Blue Cat Audio]

I don't think so, but who knows in the future (and maybe it's already the case with VST3)! Rule #1: be paranoid, always!

[ilyaorlov]

And another beginners question:
how do you compare doubles for equality?

double instance_detection_time = .... ;
double runtime = ... ;

I do
if ((runtime < (0.1 + instance_detection_time)) and (runtime > (instance_detection_time - 0.1)))

because simple
if (runtime == instance_detection_time)
won't work in many times, cause float values are often slightly unequal

should I use something more beautiful like "closeTo(runtime, instance_detection_time, 0.1)" or is there some better practice for that?

[ilyaorlov]

2) Isn't there a simple action to toggle param on/off?

I have to switch params from POPUP_MENU like this

<ACT name="$text$" id="$ACT_ID$" script="$param_id$ = abs($param_id$ - 1);" requires="$param_id$" />
<MENU_ITEM action_id="$ACT_ID$" checked_param_id="$param_id$" />

It requires every param to be exposed to change it from the script. Maybe there's a way to do that without scripting?

[Blue Cat Audio]

There is no specific action to do that, scripting is probably the most simple way. But if you are using a button to toggle those parameters, a button with 2 positions and loop=true will do that for you.

[ilyaorlov]

Is there any perfomance difference if we use a single ACTION_TRIGGER event_id="a.value_changed;b.value_changed;c.value_changed" script="..."
or separate ACTION_TRIGGERs for a, b, c, and the script is the same?

[Blue Cat Audio]

There is not much difference regarding runtime performance. However if you use a single trigger, you will use 3 times less memory and it will not compile the script 3 times.