Chasing Memory Leaks

[Wayne McHugh]

I think I've taken more than enough of your time on this slippery issue. I'm pleased enough to have found a way to moderate its effect.  I did have a go in Cakewalk, simply adding Addictive Keys to a project and removing it, and presto an average 25M leak on each iteration, mostly consistent across 23 times adding and deleting.  I'm sorry, I should have tried that test much sooner.  I've taken this to XLN support to seek their advice/explanation/assistance.  If I learn anything of value I'll pass it on.

I did the same test for SI-Drum kits in Cakewalk and it did the same, though losing less memory (consistent with my own app).  That surprised me since the SI VSTi's are so closely connected with Cakewalk.

Anyway, consider this a dead question for now, even though it remains unresolved for me.

[rv]

Hello Ian, Can you send me your corrections on BASS_VST or to falcosoft or to the github ?

Ah, I think I see what it is now. That update also added some processing buffer allocation tweaks, which aren't working properly when the VST has 0 inputs, eg. a VSTi. Here's another update that should fix that:

   www.un4seen.com/stuff/bass_vst.zip

Let me know if it still isn't working properly for you.

[Ian @ un4seen]

That fix was for a bug that isn't actually in the current BASS_VST release - the mentioned processing buffer tweaks are coming in the next release. If you have a custom BASS_VST version that you would like to try them in, I can send the latest sources.

[rv]

Yes Please

If you have a custom BASS_VST version that you would like to try them in, I can send the latest sources.

[Ian @ un4seen]

OK, here's the latest stuff:

   www.un4seen.com/stuff/bass_vst.zip
   www.un4seen.com/stuff/bass_vst-src.zip

There's a brief changelog at the top of the BASS_VST.H file. Please report any problems.