1.1.7 preset manager is slow

Discuss suspected defects before submitting a bug report

Moderator: electrogear

1.1.7 preset manager is slow

Postby infuzion on Sun May 23, 2010 1:32 pm

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.
Need help? First search the forum & WiKi, then post in the help forum with a clear topic, request, & OSM. Then please WiKi the correct solution. If you want my personal assistance, I charge by the hour or for an exchange of services.
infuzion
smstar
smstar
 
Posts: 6169
Joined: Wed May 04, 2005 8:02 pm
Location: Earth, USA, CO, Denver

Re: 1.1.7 preset manager is slow

Postby nix on Tue May 25, 2010 12:11 am

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
User avatar
nix
smaniac
 
Posts: 1173
Joined: Wed Nov 02, 2005 11:25 am
Location: Australia

Re: 1.1.7 preset manager is slow

Postby infuzion on Fri May 20, 2011 8:33 pm

This year-old bug really needs to be addressed!
viewtopic.php?f=9&t=10369&start=21
Need help? First search the forum & WiKi, then post in the help forum with a clear topic, request, & OSM. Then please WiKi the correct solution. If you want my personal assistance, I charge by the hour or for an exchange of services.
infuzion
smstar
smstar
 
Posts: 6169
Joined: Wed May 04, 2005 8:02 pm
Location: Earth, USA, CO, Denver

Re: 1.1.7 preset manager is slow

Postby rl on Sun May 22, 2011 3:27 pm

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.
User avatar
rl
dsp wiz
 
Posts: 1494
Joined: Mon Feb 07, 2005 10:24 pm
Location: de.earth.universe.known

Re: 1.1.7 preset manager is slow

Postby infuzion on Mon May 23, 2011 3:01 am

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
stw wrote: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.
Need help? First search the forum & WiKi, then post in the help forum with a clear topic, request, & OSM. Then please WiKi the correct solution. If you want my personal assistance, I charge by the hour or for an exchange of services.
infuzion
smstar
smstar
 
Posts: 6169
Joined: Wed May 04, 2005 8:02 pm
Location: Earth, USA, CO, Denver

Re: 1.1.7 preset manager is slow

Postby philter5 on Mon May 23, 2011 4:13 am

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...
---Yes, a piece of software CAN be your best friend---
User avatar
philter5
smaniac
 
Posts: 1495
Joined: Thu Jan 04, 2007 7:52 pm
Location: Germany

Re: 1.1.7 preset manager is slow

Postby rl on Mon May 23, 2011 7:26 am

infuzion wrote:..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.
User avatar
rl
dsp wiz
 
Posts: 1494
Joined: Mon Feb 07, 2005 10:24 pm
Location: de.earth.universe.known

Re: 1.1.7 preset manager is slow

Postby stw on Mon May 23, 2011 8:33 am

rl wrote:
infuzion wrote:..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... :(
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Re: 1.1.7 preset manager is slow

Postby trogluddite on Mon May 23, 2011 11:39 am

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.
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3032
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK

Re: 1.1.7 preset manager is slow

Postby stw on Thu Jun 02, 2011 10:50 am

trogluddite wrote: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 217 times
stw
smanatic
 
Posts: 641
Joined: Mon Jun 30, 2008 2:55 pm

Re: 1.1.7 preset manager is slow

Postby trogluddite on Thu Jun 02, 2011 12:57 pm

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.
Feel free to use any schematics and algorithms I post on the forum in your own designs - a credit is appreciated (but not a requirement).
Don't stagnate, mutate to create. Without randomness and serendipity the earth would be just another barren rock.
User avatar
trogluddite
smychopath
 
Posts: 3032
Joined: Mon Oct 20, 2008 3:52 pm
Location: Yorkshire, UK


Return to Bugs

Who is online

Users browsing this forum: No registered users and 2 guests