[CM] Freeing up s7 instances & memory

Christos Vagias chris.actondev at gmail.com
Thu Sep 10 04:26:56 PDT 2020


Some context about my scenario, where only the proper "free" will work.

I made some small skeleton for making VST3 applications with s7 doing the
DSP & GUI (using iPlug2
framework & Dear ImGui for the graphics).

Normal scenario:
The DAW host loads my dynamic library and whenever a user adds an instance
of this VST, a new
s7 instance is created. (well and one more for the GUI, cause it runs in a
separate thread).
So we have 2 s7 instances per.. plugin instance.

Now, when a user adds a new instance of  the plugin, 2 more s7 instances
will be initiated.
One thing to note here: globals are shared amongst these plugin instances.
So indeed, a pool of s7 instances could work: when removing a plugin, 2 s7
instances are freed (the dsp and gui).
Then, when the user adds a new plugin, these 2 instances of the pool could
be reused.
The memory keeps growing though (has to do with the max loaded plugin
instances)

However:
It's possible that the DAW runs the plugin sandboxed in a separate process.
That means globals are not shared, and the s7 instances pool cannot work.
The memory keeps growing even more quickly in this scenario.

Sorry for insisting a lot on this.
At the moment even with the worst case scenario of memory growing it's
fine, cause these VSTs plugins are
only a playground for me.
But if this project were to be something used by others, this memory
leaking is a deal-breaker.

PS
If anyone is interested in this (VST3 with S7) feel free to contact me (I
have the repo private still).
And hopefully they could help with either code or advice :)

On Thu, 10 Sep 2020 at 12:59, <bil at ccrma.stanford.edu> wrote:

> Hmmm -- let me think about that -- I already have a
> "shadow_rootlet" that masquerades as rootlet (for
> FFI writers' convenience).
>
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20200910/e86dfe51/attachment-0001.html>


More information about the Cmdist mailing list