THE "How to speed up VST loading?" thread

Andrew J · 17 Dec 2008

Thanks for starting this thread infuzion.

As mentioned elsewhere, I still have issues with a slow loading of a plugin with lots of automation. I was guessing this was to do with large green arrays for the VST parameters (e.g. I've got one with 171 parameters & 30 programs which takes 9 seconds to load). I've noticed that working with large arrays can often slow things down, so I supposed that lots of parameters could slow down VST loading.

However Eska suggested that he has a synth that loads faster than my plugin despite having many more parameters (albeit on a different CPU). So perhaps I have to look elsewhere also. Another possibility is the number of knobs used (as per 1b in infuzion's post). My plugin has 64 rotary knobs, 6 faders, at least 56 switches, 36 handles, plus menus and edit boxes galore. I should probably mention that my knobs are a hybrid of the animated and readout knobs which have been modified to allow direct parameter entry by clicking on the label. There are also a number of meters and I have my own license manager which checks for and then loads a text file (I haven't checked how long that takes).

So some questions: - How many parameters is too many? - How many knobs is too many? - Is there a linear relationship between these numbers and loading times, or is there some sort of threshold beyond which there is a dramatic slow-down? - Has anyone had a look at delays caused by accessing the file system?

Thanks, Andrew

infuzion · 17 Dec 2008

AJ, have you tried to lower the "Total" in Preset Manager down to 8 or so?

Andrew J · 17 Dec 2008

Just tried it (reducing from 30 to 8 programs) - made absolutely no difference at all. It's maybe 1.5 seconds quicker if I remove the VST preset manager completely. Next up I tried removing my license manager and again found no difference. It's only when I start removing all my controls that load time improves. So I guess the next step is to start building dummy VSTs with different controls in it and see if any are worse than the others...

Andrew J · 17 Dec 2008

OK, have just made test VSTs - one each for knobs, sliders and pushbuttons. Firstly I did it with 48 controls per plug, and then 96 controls per plug. The pushbuttons load very quickly in each case, perhaps a bit slower with 96 but hard to tell. The sliders and pushbuttons each took ~2 secs to load with 48 and ~4 with 96. Going to 192 knobs took it out to ~8 seconds so it looks like it scales pretty well.

So what's the difference between these controls? All of them use a strip loader for the moving parts. The knob and slider both have auto readout labels with double click editing. On the other hand the pushbutton has no label at all. The knob and slider have other differences, but as their timing is similar I'd have to suspect the smart labels.

Looking around inside the smart labels, the first thing I notice is the font face selector. Removing that sees the load time of the 192 knob plug reduce from ~8 seconds to just over a second! Eu-bloody-reka!!! 🙂 🙂 🙂 🙂

I think I'll either hardwire the font or use a master font face selector going in to a wireless connector.

infuzion · 17 Dec 2008

Andrew J wrote: It's only when I start removing all my controls that load time improves. So I guess the next step is to start building dummy VSTs with different controls in it and see if any are worse than the others...

Maybe test out the reduced bitmap knob for me please? 😉 Animated Knob Optimization (~50%) Also try to knock out the MinMax sub-module in there (& related Preset feed), since I suspect a small part of the loading-lag is all the green maths being triggered at once when all the prefs are loaded. Less math = faster VST.

Andrew J · 17 Dec 2008

OK, but might be a couple days wait (when my holidays start)...

TomC · 17 Dec 2008

Andrew J wrote: Looking around inside the smart labels, the first thing I notice is the font face selector. Removing that sees the load time of the 192 knob plug reduce from ~8 seconds to just over a second! Eu-bloody-reka!!! 🙂 🙂 🙂 🙂

Yeah, I already noticed this, but it only helps if you remove ALL of them. The Window's fonts folder is only scanned once, no matter how much font selectors you have, so I don't think it scales.

But I have 2 different ideas, one concerning antivirus software (that we or Outsim probably can't avoid) and one concerning the wave loader (which CAN be fixed by Outsim) I'll do some tests to prove the second one and keep you posted.

Tom

exonerate · 17 Dec 2008

A few primitives send triggers after loading ,which I think could slow down the Initialization stage at least if not the actual loading, these triggers could then be causing large sections of green code to recalculate.

Here's a list...

Vst Parameter Array ( sends a trigger from the array output and float output)

Midi out Select (sends a trigger from the integer output)

Midi in select (sends a trigger from the integer output)

Samplerate

Wavetable (The wavetable is generated during load so large wavetables will add to load times, a trigger is also sent from the output )

Midi out devices ( sends a trigger from all outputs)

Midi in devices (sends a trigger from all outputs)

They are the ones I've come across, now the Vst parameter array can be a culprit for load times if the vst param array is large and after it you have a fair bit of array math.

Strangely the other vst parameter primitives don't output a trigger, also the normal arrays don't, so I'm wondering why the Vst parameter array does? The other primitives I can see the reason, samplerate and midi need to be checked and updated on load, but the vst parameter array?

Cheers 😉

Exo

TomC · 18 Dec 2008

exonerate wrote: Strangely the other vst parameter primitives don't output a trigger, also the normal arrays don't, so I'm wondering why the Vst parameter array does? The other primitives I can see the reason, samplerate and midi need to be checked and updated on load, but the vst parameter array?

Cheers 😉

Exo

Have you checked if you use rl's (sp?) "store path to preset" module somewhere? It's part of a lot of waveplayers and does some complicated calculations.

And these days it's easy to replace by the new String to Preset primitive.

Tom

Andrew J · 20 Dec 2008

infuzion wrote: Andrew J wrote: It's only when I start removing all my controls that load time improves. So I guess the next step is to start building dummy VSTs with different controls in it and see if any are worse than the others...

Maybe test out the reduced bitmap knob for me please? 😉 Animated Knob Optimization (~50%) Also try to knock out the MinMax sub-module in there (& related Preset feed), since I suspect a small part of the loading-lag is all the green maths being triggered at once when all the prefs are loaded. Less math = faster VST.

The reduced knob loads very fast, but so does the ordinary knob once the font dialog is out. Even with 192 knobs it's hard to tell if there's any difference, but the optimised one might be slightly faster.

Andrew J · 20 Dec 2008

TomC wrote: Yeah, I already noticed this, but it only helps if you remove ALL of them. The Window's fonts folder is only scanned once, no matter how much font selectors you have, so I don't think it scales.

Doesn't seem to work like that Tom. If I take the font selectors out of all the knobs and just have one font selector feeding them via a wireless, then the load time is very quick. Nothing else was changed in the schematic, so I'm pretty confident that there is something about the font selector that slows things down when you have a lot of them.

infuzion · 20 Dec 2008

Andrew J wrote: infuzion wrote: Maybe test out the reduced bitmap knob for me please? 😉 Animated Knob Optimization (~50%) Also try to knock out the MinMax sub-module in there (& related Preset feed)...

The reduced knob loads very fast, but so does the ordinary knob once the font dialog is out. Even with 192 knobs it's hard to tell if there's any difference, but the optimised one might be slightly faster.

Thanks for the test AJ! I assume you used my version, and left in all the MinMax sub-modules for your test? Could be slightly faster with out them when not needed, especially with automation.

Andrew J · 20 Dec 2008

I used the "Animated Knob v03n No Format UI, NO Step Barak,infuzion" version and left in the MinMaxes. It all happens so quick, there's no point trying to time a difference without the MinMaxes. Any difference is less than my reflex time.

infuzion · 20 Dec 2008

Andrew J wrote: I used the "Animated Knob v03n No Format UI, NO Step Barak,infuzion" version and left in the MinMaxes.

OK, I'm glad they work so far, any issues with automation or presets there please? Also, out of curiosity, what was the file size before & after please? We'll need the pre-zipped size of the OSM, but remember that SM zips usually the files, so you can either rename the *.OSM as *.zip, or use 7zip (best).