DSP Robotics Support

ok just to get shure if we talking about the same, i open host - check used memory in taskmanager - load plugin - memory increases - unload plugin - memory should be the same like after open the host.. tried with my latest plugin and the same story happens as before memory increases with every reload of the plugin, so nothing changed after exchanging the vst.dll stw shared

i also did the metest with the new vst.dll sometimes it frees the mem like it should but most of the time it increases with 4k sometimes also more

What do you mean with 4k? 4kB? I suppose that's not a range which could give any reliable answers here.
Two things to consider:
1. If you have more than one instance of flowstone installed be sure to exchange the vst.dll in the original install folder.
I didn't verify it again but i had the same issue in my first testings when i exchanged the .dll only in the folder which contained my used flowstone instance. Seems as if stored install path is used when exporting.
2. Though i'm no expert in how a host manages VST plugs (and i guess it's individually different) but e.g. Cubase initializes its plugs at startup to my surprise not always in the same manner. Differences in memory use after starting are up to 40MB! So a first load and unload of a plug doesn't give a reliable value because the general memory use increases with a first load of any plug. And it looks as if parts of almost all plugs stay persistent in memory after first loading. That means with every new plug memory use increases - but only once. BTW simply opening a GUI on some plugs varies memory use up to 5MB.
Load and unload two or more times the mem example i provided and watch if memory usage repeatingly increases in a reasonable size or not. It should not with the update. At least it doesn't on my DAW in Cubase and Reaper. (Should be host independent anyway.)
If it still does your plugs may contain other things which cause the same problem like the memory buffer.

Here's my updated CodeMem plug for verification.

thx for your explanation stw, did some more tests and yes it is much better, your new test dll frees the mem fine, also when i compare my vsts "old" vs "new" exported it is fine but there is still increasing mem with reloading as example i have some delay fx with one multienvelope and one ruby knob - the old version was increasing mem around 2mb with each reload - the new version increases with around 200 kb on each reload.. which is much better but on some bigger vsts it is more up to 4 mb each reload..

do someone else getting same results, can this happen from "bad" dsp or assembly codes or ruby codes, or could the same problem still exist in the gui thread ?

I'm permitted to share it here so feel free to download it in case you want to export a proper working VST plug.

WTF? How can there be a known issue with the VST.dll file used for exporting VST's & one has to find out this way?! Shocking!

What do you mean with "this way" or what would you expect?

Well, by reading it in a Forum topic as opposed to a DSPR news update . . . DSPR has a lot of VST customers. . .

stw ...

Thank you for reporting and then posting this fix for everyone.

I too was a bit surprised that this was not posted by FlowStone themselves ... or at the least, a comment.

This is NOT a criticism of you ... by any means ! We all benefited from your effort along with posting further to explain. Again ... Big Thanks! But a fundamental changing of an Apps' file [or library] would expect a Dev statement ... even if this is not yet considered an 'official' release for the next update.

Minor detail I suppose. Very glad you did this nonetheless

Thanks!

And remember - surely devs are watching how folks react to minor updates, so keep calm, be grateful and no complaints. Otherwise no more minor support!

I didn't take that question personal by any means...
I just asked because the body of excitement wasn't clear.
However i understand the feelings about how the news is spread. Just a few thoughts to consider:
- Flowstone is out for some time now and i guess the related vst.dll was already used in SM. So it's a long time to find and report that special bug. Even if it may be a meaningful bug - complaints about it seemed to been rare. So it may be a important bug fix for some users but not worth for an immediate "official" announcement. Though it surely will be part of the next official update. Nevertheless all users who discovered the bug and search for a solution should find this thread.
- Even if one thinks that the way of presenting the fix maybe inadequate please keep in mind that this small one man development team - namend Malcolm - immediatly reacted on my report and presented a solution only two days later. That's one kind of support you see only very few!