THE "How to speed up VST loading?" thread

[infuzion]

1) If you have alot of present information, the file will be large, & the OSM & exported VST will load very slow. Things that will cause this is:
1a. VST Parameter Arrays
1b. many many knobs
1c. 32+ "Total" in Preset Manager (upper preset storage limit depends on 1a & 1b above)

==
Please post your tips, questions, & verifications for "How to speed up VST loading?" only below. Start a new thread if off topic please.

==
Tips as of Feb02 archived on the WIKI:
http://www.synthmaker.co.uk/dokuwiki/do ... ading_time

[Andrew J]

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]

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

[Andrew J]

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]

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]

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?
viewtopic.php?f=7&t=6470&st=0&sk=t&sd=a&start=28
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]

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

[TomC]

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]

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]

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]

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?
viewtopic.php?f=7&t=6470&st=0&sk=t&sd=a&start=28
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]

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]

Maybe test out the reduced bitmap knob for me please?
viewtopic.php?f=7&t=6470&st=0&sk=t&sd=a&start=28
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]

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]

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