<div dir="ltr">HI Christos, I'd love to look at the repo if you're able to add me as a viewer. I'm iainctduncan on github. I look forward to seeing it in action!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 4:27 AM Christos Vagias <<a href="mailto:chris.actondev@gmail.com">chris.actondev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Some context about my scenario, where only the proper "free" will work.</div><div><br></div><div>I made some small skeleton for making VST3 applications with s7 doing the DSP & GUI (using iPlug2</div><div>framework & Dear ImGui for the graphics).</div><div><br></div><div>Normal scenario:</div><div>The DAW host loads my dynamic library and whenever a user adds an instance of this VST, a new</div><div>s7 instance is created. (well and one more for the GUI, cause it runs in a separate thread).</div><div>So we have 2 s7 instances per.. plugin instance.</div><div><br></div><div>Now, when a user adds a new instance of the plugin, 2 more s7 instances will be initiated.</div><div>One thing to note here: globals are shared amongst these plugin instances.</div><div>So indeed, a pool of s7 instances could work: when removing a plugin, 2 s7 instances are freed (the dsp and gui).</div><div>Then, when the user adds a new plugin, these 2 instances of the pool could be reused.</div><div>The memory keeps growing though (has to do with the max loaded plugin instances)<br></div><div><br></div><div>However:<br></div><div>It's possible that the DAW runs the plugin sandboxed in a separate process.</div><div>That means globals are not shared, and the s7 instances pool cannot work.</div><div>The memory keeps growing even more quickly in this scenario.</div><div><br></div><div>Sorry for insisting a lot on this.</div><div>At the moment even with the worst case scenario of memory growing it's fine, cause these VSTs plugins are</div><div>only a playground for me.<br></div><div>But if this project were to be something used by others, this memory leaking is a deal-breaker.</div><div><br></div><div>PS</div><div>If anyone is interested in this (VST3 with S7) feel free to contact me (I have the repo private still).<br></div><div>And hopefully they could help with either code or advice :)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Sep 2020 at 12:59, <<a href="mailto:bil@ccrma.stanford.edu" target="_blank">bil@ccrma.stanford.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hmmm -- let me think about that -- I already have a<br>
"shadow_rootlet" that masquerades as rootlet (for<br>
FFI writers' convenience).<br>
<br>
_______________________________________________<br>
Cmdist mailing list<br>
<a href="mailto:Cmdist@ccrma.stanford.edu" target="_blank">Cmdist@ccrma.stanford.edu</a><br>
<a href="https://cm-mail.stanford.edu/mailman/listinfo/cmdist" rel="noreferrer" target="_blank">https://cm-mail.stanford.edu/mailman/listinfo/cmdist</a><br>
</blockquote></div>
_______________________________________________<br>
Cmdist mailing list<br>
<a href="mailto:Cmdist@ccrma.stanford.edu" target="_blank">Cmdist@ccrma.stanford.edu</a><br>
<a href="https://cm-mail.stanford.edu/mailman/listinfo/cmdist" rel="noreferrer" target="_blank">https://cm-mail.stanford.edu/mailman/listinfo/cmdist</a><br>
</blockquote></div>