Hi Miller, I'm the developer of [vstplugin~].
Anyhow, who would ever want to do this?
I hope nobody :-) the idea of hosting VST plugins inside a Pd patch which itself is used as a VST plugin sounds pretty absurd to me. Every decent DAW lets you connect VST plugins freely in FX chains, so I don't see any reason for opening VST plugins within other VST plugins.
I've also heard the joke about using [vstplugin~] + Camomile to host Pd inside Pd (to go "full circle") - which I think should actually work, but I wouldn't recommend it either :-).
Christof
Gesendet: Sonntag, 20. Januar 2019 um 02:52 Uhr Von: "Miller Puckette" msp@ucsd.edu An: pd-list@iem.at Betreff: [PD] loading Camomile plug-ins using vstplugin~
To Pd list -
In case anyone else thought they could use vstplugin~ (By Hannes, available from https://git.iem.at/pd/vstplugin) to load Camomile (https://github.com/pierreguillot/Camomile) -
I don't think it works. Unless I'm misreading things, once Camomile calls pd_init(), that call doesn't go to the pd_init that's compiled into Camomile (via libpd) but instead calls pd_init from the Pd that called vstplugin~ that called Camomile. This does nothing, and the next thing libpd tries to access in the Pd instance fails.
Here, Pure Data itself (the calling program) is compiled single-thread, and libpd is compiled multi-thread; this means data structures in the two are different so they can't call back and forth; anything in libpd had better refer to its own version of things and not the calling program's.
Perhaps there's a way vstplugin~ could load the VST in such a way as to have it only make calls back into vstplugin~ but not into Pd? It's all a bit confusing to me. Anyhow, who would ever want to do this? (Except actually for complicated reasons I would :)
Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list