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!
On Thu, Sep 10, 2020 at 4:27 AM Christos Vagias <[email protected]> wrote: > 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, <[email protected]> wrote: > >> Hmmm -- let me think about that -- I already have a >> "shadow_rootlet" that masquerades as rootlet (for >> FFI writers' convenience). >> >> _______________________________________________ >> Cmdist mailing list >> [email protected] >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist >
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
