Memory allocation

[stw]

One thing i remember from good ole SM times is a memory allocation prob after deleting VST plugs.
I just ran into the same thing. After deleting an instance of my plug app. 30% of the used memory when loaded will not be released. In my case that means every load/unload increses the host memory use 30-50 MB. (Observed in Cubase and Reaper)
What discovers the next prob right away.
Without hacking the hell out the plug and getting rid of all what can be killed the whole thing is blown up to 150MB/instance. Though i use 200knobs/switches (all sharing the same 10 bitmaps) and 4 delays which occupy 20MB altogether this is way too much.
But that's another story...

Does anyone know if the memory alloc problem was fixed anytime or if there's anything what could be done to avoid it?

[Nubeat7]

confirmed in renoise too, also when plugs dont use any images and have just 5 (ruby) knobs

also tested with just one lightweight ruby knob for vol and a clip fx plugin, nothing else, memory increases with every reload

[Tzarls]

I had this problem with SM, but in my case I was using samples, so problem was a lot worse. everytime someone unloads my VST, 125MB of memory remains occuppied by samples than won´t be used again.

I never upgraded to FS so I don´t know if the problem is the same when using samples. You should check and inform the developers.

[Nubeat7]

what i also found out when compaaring with other plugins is that some of the old tobybear plugs have the same effect but in a smaller rate, but also some of the big ones like effectrix and wizoo verb are increasing the memory when reloading them but just 2 or 3 times then they keep the memory at the same level and stop increasing when reloading..

how weird?

[stw]

Before i bother Malc with a bug report i prepared a small test .fsm to get some user confirmation.
It contains two modules each creating a 128MB memory buffer. One with the mem create prim and one with a variable declaration in code.
On my VST hosts the Mem Create prim version loads and unloads fine while the code version locks the complete memory buffer when unloading it!

Would be nice to get feedback from some testers.

memtest.fsm

(128.28 KiB) Downloaded 845 times

[stw]

Ok, i bothered Malc just without any other user approvements. Here's the result.
As quick as in earlier bug conversations i had with him he presented the solution. A new VST.dll
I'm permitted to share it here so feel free to download it in case you want to export a proper working VST plug.

vst.zip

- Bug Fix: Memory buffer is freed correctly when unloading the plug.

(1.72 MiB) Downloaded 882 times

[Nubeat7]

thx stw for sharing this, but what to do with this dll?

[stw]

Exchange it with the original .dll in your Flowstone folder

[Nubeat7]

ahh, ok thanks.

[TrojakEW]

Regarding vst.dll I found that dspr uses upx to compress file. So I just did few test (with different compression settings) and found that uncopressed dll uses 1mb less memory (in my case) and plugin load three times faster. Original, compressed dll file is (roughly) 1.8mb and uncopressed is 7mb - that's only drawback.