Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright

Memory allocation

For general discussion related FlowStone

Re: Memory allocation

Postby Nubeat7 » Fri Jan 17, 2014 11:45 pm

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
User avatar
Nubeat7
 
Posts: 1347
Joined: Sat Apr 14, 2012 9:59 am
Location: Vienna

Re: Memory allocation

Postby stw » Sat Jan 18, 2014 10:25 am

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.
128MB Code Mem.zip
(1.72 MiB) Downloaded 810 times
stw
 
Posts: 111
Joined: Tue Jul 13, 2010 11:09 am

Re: Memory allocation

Postby Nubeat7 » Sat Jan 18, 2014 8:31 pm

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 ?
User avatar
Nubeat7
 
Posts: 1347
Joined: Sat Apr 14, 2012 9:59 am
Location: Vienna

Re: Memory allocation

Postby Drnkhobo » Sun Jan 26, 2014 9:02 am

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! :o
Drnkhobo
 
Posts: 312
Joined: Sun Aug 19, 2012 7:13 pm
Location: ZA

Re: Memory allocation

Postby stw » Sun Jan 26, 2014 9:17 am

What do you mean with "this way" or what would you expect?
stw
 
Posts: 111
Joined: Tue Jul 13, 2010 11:09 am

Re: Memory allocation

Postby Drnkhobo » Sun Jan 26, 2014 11:57 am

Well, by reading it in a Forum topic as opposed to a DSPR news update . . . DSPR has a lot of VST customers. . .
Drnkhobo
 
Posts: 312
Joined: Sun Aug 19, 2012 7:13 pm
Location: ZA

Re: Memory allocation

Postby RJHollins » Sun Jan 26, 2014 12:59 pm

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! 8-) 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 :D

Thanks!
RJHollins
 
Posts: 1571
Joined: Thu Mar 08, 2012 7:58 pm

Re: Memory allocation

Postby tester » Sun Jan 26, 2014 1:35 pm

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! :mrgreen: :mrgreen: :mrgreen:
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
tester
 
Posts: 1786
Joined: Wed Jan 18, 2012 10:52 pm
Location: Poland, internet

Re: Memory allocation

Postby stw » Sun Jan 26, 2014 2:01 pm

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!
stw
 
Posts: 111
Joined: Tue Jul 13, 2010 11:09 am

Previous

Return to General

Who is online

Users browsing this forum: Google [Bot] and 75 guests