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
I was just thinking about this about an hour ago and was literally just going to try it out right now! In, uh, unrelated news, my plans for tonight fell through, so, uh, my schedule is pretty wide open...
On Jan 19, 2019 8:57 PM, "Miller Puckette" msp@ucsd.edu wrote:
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
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
Sorry, I got confused! you were (obviously) talking about loading the Camomile plugin inside Pd with [vstplugin~]. And yeah, this probably won't work for reason you've mentioned. When I announced [vstplugin~] people immediately came up with this idea but they were joking (I hope!)
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?
there's not much I can do in [vstplugin~], VST plugins are basically a black box. Maybe [vstplugin~] + Camomile works if the Pd app is compiled with PDINSTANCE? But again, I don't see why anyone would want to do this instead of just loading the patch as an abstraction?
Christof
Gesendet: Sonntag, 20. Januar 2019 um 11:12 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edu Cc: pd-list@iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Incepdion
De: Pd-list pd-list-bounces@lists.iem.at em nome de Christof Ressi christof.ressi@gmx.at Enviado: domingo, 20 de janeiro de 2019 10:25 Para: Miller Puckette; Pd-List Assunto: Re: [PD] loading Camomile plug-ins using vstplugin~
Sorry, I got confused! you were (obviously) talking about loading the Camomile plugin inside Pd with [vstplugin~]. And yeah, this probably won't work for reason you've mentioned. When I announced [vstplugin~] people immediately came up with this idea but they were joking (I hope!)
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?
there's not much I can do in [vstplugin~], VST plugins are basically a black box. Maybe [vstplugin~] + Camomile works if the Pd app is compiled with PDINSTANCE? But again, I don't see why anyone would want to do this instead of just loading the patch as an abstraction?
Christof
Gesendet: Sonntag, 20. Januar 2019 um 11:12 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Miller Puckette" msp@ucsd.edu Cc: pd-list@iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em dom, 20 de jan de 2019 às 10:28, Christof Ressi christof.ressi@gmx.at escreveu:
When I announced [vstplugin~] people immediately came up with this idea but they were joking (I hope!)
yeah, I came up with it as a joke :) but I also expected something like that to work
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
the inverse is possible?
open a daw and use camomile, inside camomile patch there would be a custom way of using vstplugin~
this could be interesting, say, using arduino to control vsts inside daw without having to convert sensors data to midi or another protocol, just get bytes from comport directly to vstplugin~...
i'm crazy? or this make sense?
Em Dom, 20 de jan de 2019 14:19, Christof Ressi christof.ressi@gmx.at escreveu:
maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Bingo! I added the RTLD_DEEPBIND flag to the dlopen() call in vstplugin~ and my Camomile plug-in sprang to life.
Now, as to _why_ anyone migth want to do this, here's my use case: I'm working with a musician who uses Abelton on a Mac, so I want to write him a plug-in. But I have no usable real-time VST hosts on my old Mac (I keep an old MACOS so I can compile Pd back-compatibly). I also don't have any real-time VST hosting software on linux where I'm developing the patch for the plug-in. I could learn Ardour (maybe it's time I did that anyhow) but the fastest way I could see to be able to host my plug-in is from Pd, which is a piece of software I know well.
cheers Miller
On Sun, Jan 20, 2019 at 05:18:56PM +0100, Christof Ressi wrote:
maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this??? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
ha, nice to here this works! this was just a wild guess after all... unless there are any drawbacks (I'm not a linux expert) I'll add this to the code. Now I'm curious how vstplugin~ + Camomile behaves on macOS :-)
Btw, REAPER is available for Linux: https://www.reaper.fm/download.php#linux_download
Gesendet: Sonntag, 20. Januar 2019 um 18:07 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: claude@mathr.co.uk, Pd-List pd-list@lists.iem.at Betreff: Re: Re: [PD] loading Camomile plug-ins using vstplugin~
Bingo! I added the RTLD_DEEPBIND flag to the dlopen() call in vstplugin~ and my Camomile plug-in sprang to life.
Now, as to _why_ anyone migth want to do this, here's my use case: I'm working with a musician who uses Abelton on a Mac, so I want to write him a plug-in. But I have no usable real-time VST hosts on my old Mac (I keep an old MACOS so I can compile Pd back-compatibly). I also don't have any real-time VST hosting software on linux where I'm developing the patch for the plug-in. I could learn Ardour (maybe it's time I did that anyhow) but the fastest way I could see to be able to host my plug-in is from Pd, which is a piece of software I know well.
cheers Miller
On Sun, Jan 20, 2019 at 05:18:56PM +0100, Christof Ressi wrote:
maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this??? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
BTW, I recommend compiling vstplugin~ from the develop branch because I've fixed a bug on Linux where closing JUCE plugins (like Camomile) with the GUI enabled would sometimes crash X11. I can't merge into master yet because the commits are entangled with SuperCollider code which is still under review...
Christof
Gesendet: Sonntag, 20. Januar 2019 um 18:07 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: claude@mathr.co.uk, Pd-List pd-list@lists.iem.at Betreff: Re: Re: [PD] loading Camomile plug-ins using vstplugin~
Bingo! I added the RTLD_DEEPBIND flag to the dlopen() call in vstplugin~ and my Camomile plug-in sprang to life.
Now, as to _why_ anyone migth want to do this, here's my use case: I'm working with a musician who uses Abelton on a Mac, so I want to write him a plug-in. But I have no usable real-time VST hosts on my old Mac (I keep an old MACOS so I can compile Pd back-compatibly). I also don't have any real-time VST hosting software on linux where I'm developing the patch for the plug-in. I could learn Ardour (maybe it's time I did that anyhow) but the fastest way I could see to be able to host my plug-in is from Pd, which is a piece of software I know well.
cheers Miller
On Sun, Jan 20, 2019 at 05:18:56PM +0100, Christof Ressi wrote:
maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this??? But that would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Seems to work on MacOS Sierra.
On Sun, Jan 20, 2019, 1:55 PM Christof Ressi, christof.ressi@gmx.at wrote:
BTW, I recommend compiling vstplugin~ from the develop branch because I've fixed a bug on Linux where closing JUCE plugins (like Camomile) with the GUI enabled would sometimes crash X11. I can't merge into master yet because the commits are entangled with SuperCollider code which is still under review...
Christof
Gesendet: Sonntag, 20. Januar 2019 um 18:07 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: claude@mathr.co.uk, Pd-List pd-list@lists.iem.at Betreff: Re: Re: [PD] loading Camomile plug-ins using vstplugin~
Bingo! I added the RTLD_DEEPBIND flag to the dlopen() call in
vstplugin~ and
my Camomile plug-in sprang to life.
Now, as to _why_ anyone migth want to do this, here's my use case: I'm working with a musician who uses Abelton on a Mac, so I want to write
him a
plug-in. But I have no usable real-time VST hosts on my old Mac (I keep
an
old MACOS so I can compile Pd back-compatibly). I also don't have any real-time VST hosting software on linux where I'm developing the patch
for
the plug-in. I could learn Ardour (maybe it's time I did that anyhow)
but
the fastest way I could see to be able to host my plug-in is from Pd,
which
is a piece of software I know well.
cheers Miller
On Sun, Jan 20, 2019 at 05:18:56PM +0100, Christof Ressi wrote:
maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
http://man7.org/linux/man-pages/man3/dlopen.3.html
if I understand correctly, with this flag the shared object should
prefer its own symbols, in this case pd_init() from the statically linked libpd, not from the Pd app. I don't have time right now to test this, though.
and guess what: [vstplugin~] + Camomile actually seems to work on
Windows :-D :-D :-D. See attached picture.
Christof
Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Maybe static linking of libpd in Camomile would fix this?
I think Camomile already links statically against libpd.
Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr Von: "Claude Heiland-Allen" claude@mathr.co.uk An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Hi,
On 20/01/2019 01:52, Miller Puckette wrote:
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.
Maybe static linking of libpd in Camomile would fix this??? But
that
would just postpone the issue until the first dynamically-linked external is loaded by the deeper Pd, which tries to access eg class_new(): does it get the one in Pd host or Camomile .pd_linux?
On GNU glibc systems, dlmopen() may be relevant?
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
cool, thanks for testing!
Gesendet: Sonntag, 20. Januar 2019 um 20:17 Uhr Von: "JTG III" jordanthomasgibbonsiii@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
Seems to work on MacOS Sierra.
-
Alexandre Torres Porres -
Christof Ressi -
Claude Heiland-Allen -
Henri Augusto Bisognini -
José de Abreu -
JTG III -
Miller Puckette