1.1.7 preset manager is slow

[infuzion]

I can see a somewhat complex synth with 128 patches be a little slow to change patches, but a 16 patch bank still slow in changing, taking 0.5+ seconds on a C2D desktop? Ridiculous & unprofessional. This is a long-standing issue with SM. Some of it is SM's slow handling of arrays in general, & some of it is each preset item causing triggers, so 30 knobs cause 30 retriggers. But the user does not care why, just that the OSM is slow to respond. I don't experience this in other synths.
Workaround: Smaller preset bank (8, or 1...)

Malc, let me know if you need example OSMs. But really any OSM with lots of knobs (eg 10 AHDSRs, a few effects, etc) will do.

[nix]

Thanks for bringing this up infuzion. The problem with load times in my schematic is pretty much entirely due to a 2048 sample VST parameter array in each of the 3 osc. This array enables recall of a loaded user wavetable, and preserves the random waveform so the patch doesn't sound different if you save and recall it. I will get back to you with an .osm that loads from file location and doesn't recall random form. So I just ditch the array. Load time is instant on my system then. If you want to change this in our working schematic just bypass the array and delete it. The prefab forms will still recall I think.
So basically my error in not letting infuzion know Malc
Kind regards 8D
edit: after getting rid of the preset array, it is the wavetable create on preset change that slows it

[infuzion]

This year-old bug really needs to be addressed!
viewtopic.php?f=9&t=10369&start=21

[rl]

I had no speed issues with the preset manager so far (neither 1.1.x nor 2.x). Example: 64 patches, 2 osc's with 20 waveforms of 256 samples each. Of course it has to be considered _what_ is triggered on preset change, e.g. to create a mem from an array the wavetable-create component builds mip-maped wavetables from an array using FFT calculation, normalizations, etc. so it's usually faster to create the wavetables beforehand and on preset change just switch the tables without recalculating them from arrays. That needs more memory, but the original arrays could be declared as "purgeable", and the tables need to be created only once even when used by multiple oscillators.

[infuzion]

Care to upload a patch for an example? I'm guessing it would have fewer prefs items (eg knobs) than the cases I had in mind when posting the bug. Also, I am not the only one having the large-presets are laggy issue:
viewtopic.php?f=9&t=10369&start=21

Though everything should be fine that version has some "known issues":
- Due to the large amonut of preset data, preset change is slooooowwwww. For better performance i built a version which only handles actual used parameters. That increases preset changing speed. Unfortunately i still get some strange errors which makes the whole preset management unstable. So this comes in a later update.

[philter5]

when using a preset manager that has 2 buttons for prevoius/next preset and no (dropdown-) menu for direct preset selection it could save some cpu if the preset changes not on every prev/next click, instead only changes if you hit a "change now" button after you made your selection. but fortunately most preset manager let you choose the preset from
a list...

[rl]

..Also, I am not the only one having the large-presets are laggy issue:
viewtopic.php?f=9&t=10369&start=21

That's indeed bloodily slow. I suspect the bus system to be the culprit. At least when deleting BusCreate modules the preset switching becomes faster.

[stw]

..Also, I am not the only one having the large-presets are laggy issue:
viewtopic.php?f=9&t=10369&start=21

That's indeed bloodily slow. I suspect the bus system to be the culprit. At least when deleting BusCreate modules the preset switching becomes faster.

I don't think it's the bus routing itself. I tried different alternatives of changing or deleting or just delinking modules and my guess is that it is the huge amount of drawing modules which causes the slowdown. The bad thing about is that i couldn't find a way of preventing unnecessary calculations or drawing threads or whatever is the cause here.
E.g. deleting the graphic modules or the bus links increases speed a lot while deleting the view links doesn't change anything. That means the speed increase you see comes from preventing data transfer to the targets even if it's not actually needed for a drawing.
So i'd rather blame the amount of calculated data itself to slow everything down. But the question remains why it is that slow?
As i described in the KnobMaker thread i have versions of the schematic which handles only actaul needed data which results in a far better performance. Unfortunately i couldn't manage to build a version without errors so far.

However there're seem to be secrets of preset performance i'll probably never unveal. I have orther large projects which suffer from the same poor preset change performance. The more preset data appears the slower everything runs. Almost not noticable at the beginnig but steadyly increasing up to a point where it's an abolute showstopper.
On the other hand i remind some testing in the past with e.g. hundreds of SM deafult knobs which seems to handle preset data instantly. Maybe a hallucination...

[trogluddite]

From my experience, I'd agree that any kind of re-routing (busses, selectors etc.) makes a big difference.
It's not just the preset changing time that is affected either, it's also noticable in the severity of CPU spikes when changing presets. I've had problems with a couple of my VST exports causing audio pops in my sequencer when changing modulation routing because of this - happens sometimes even if the GUI is hidden and I use MIDI to make the change (I always block re-draws when the plugin editor is not open). I don't mean the plugin itself 'popping', but a CPU spike that I can see clearly on unrelated tracks.

My guess is that the re-compiling of the schematic takes place individually for each routing change - so for schematics with lots of routing changes there are multiple re-compiles happening - each one generating its own flurry of triggers (in green parts) and re-runs of stage(0) (in the stream parts).

Busses definitely seem worse in this respect than selectors - possibly each 'Create' or 'Extract' string change forces every single bus node to be re-calculated to search for the matching connectors? (NB: Malc is currently looking into a bug with busses where the timing of the 're-wiring' can create problems with mono4 data on busses.)

I've wondered before whether there is some way to use the 'Before Preset Change' and 'After Preset Change' outputs from the Manager to somehow inhibit triggers/recompiles to reduce the amount of calculations required - Infuzion's HeartBeat schematic uses this to get rid of excess ReDraws while the preset is changing, but so far I've had no luck using it to prevent streams from running stage(0) code etc.

[stw]

From my experience, I'd agree that any kind of re-routing (busses, selectors etc.) makes a big difference.
It's not just the preset changing time that is affected either, it's also noticable in the severity of CPU spikes when changing presets. I've had problems with a couple of my VST exports causing audio pops in my sequencer when changing modulation routing because of this - happens sometimes even if the GUI is hidden and I use MIDI to make the change (I always block re-draws when the plugin editor is not open). I don't mean the plugin itself 'popping', but a CPU spike that I can see clearly on unrelated tracks.

After some more testing i still guess a slow preset change is the result of different happenings at one moment.
I didn't dig deeper into the routing issue but i think you pointed out what the cause is here.
I had a short email exchange with malc and he said that it's not the preset change itself what is slow but rather lots of calculations afterwards especially creating big wavetables etc. I think he's right at this point. The question is how to prevent calculations which are obviously necessary to invoke changing parameters correctly? Even if there IS a lot of things to process SM still is far far away from being on par with native plugIns. I tested some PlugIns whith huge amount of parameters but i couldn't find anything which comes near SMs "relaxed" attitude.
Another big issue seems to be the amount of gui elements. E.g. my KnobMaker osm contains only drawing elements and not much calcultions nor any streams. But that's so incredibly slow that it's almost unuseable. I suspect the drawing implementation inside SM to cause that huge delay. I found that it's not possible to prevent any drawing element from being (re)drawn at a preset change if it's wired to a triggered preset parameter prim. That was at least new to me and explains pretty well what's going on if a osm contains lots of them.
Even a complete missing of a redraw prim or a disconnected view doesn't affect that behaviour. So the more draw elements are used the slower a preset change runs.
This also would explain why there're CPU spikes even though the editor is closed.
After discovering that i changed my current project from various copied gui elements which are visible one at a time to only one "master knob" and a redirecting of parameters instead. That at least seems to speed up preset change more than 50%!
Another method could be to trigger parameters to a gui element only if it becomes visible. I'll try that on the KnobMaker project...
I attached an explaining osm...

Preset redraw.osm

(64.76 KiB) Downloaded 150 times

[trogluddite]

Lunchtime at work, so I can't see your .osm just now - but it sounds very similar to the way I made my Soopa Loopa plugin work. Each knob contains an array of the possible parameters it could change - and then both the knob output and GUI read and write to the currently visible parameter.
TBH, I did it originally to save screen space, and the array structure just worked nicely with the rest of the schematic (no array builder prim. back then) - but a fortunate side effect has been that the GUI load is relatively low compared to other plugin I built with a similar number of parameters.