Re: [PD] [text] issue reading SysEx files
> Somewhere on my long do-list is an idea to make an addition to soundfiler
> to read binary chanracters into an array.
+1
@Mario: in the meantime you can use [mrpeach/binfile] to read arbitrary binary
data.
> Gesendet: Montag, 21. Januar 2019 um 00:34 Uhr
> Von: "Miller Puckette"
> An: "Mario Buoninfante"
> Cc: pd-list
> Betreff: Re: [PD] [text] issue reading SysEx files
>
> The trouble is probably the presence of a '{' character in the file.
> But there will be other problems - ASCII NULL characters will simply
> terminate the string early, and semicolons, spaces, and commas will
> confuse things.
>
> Somewhere on my long do-list is an idea to make an addition to soundfiler
> to read binary chanracters into an array.
>
> cheers
> Miller
>
> On Fri, Jan 18, 2019 at 04:39:04PM +, Mario Buoninfante wrote:
> > Hi,
> >
> > I've been trying to read SysEx files using [text], and I noticed that the
> > loaded file end up being corrupted in a way with bits and bops missing.
> > Also trying to manually copy and paste part of the file (from Atom text
> > editor) I'm not able to copy the entire file, there's always something
> > missing (ie select all the file in Atom, copy and paste in [text]).
> > When loading the file I've got no error, but then when I open the [text]
> > window, this is returned on the console:
> >
> > (Tcl) UNHANDLED ERROR: extra characters after close-brace
> > while executing
> > "pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ), Y Q Y1
> > -" ( , XFN ` 8 ) 6{` ) ) ;
> > }
> > pdtk_textwindow_append .x1006173..."
> > ("uplevel" body line 39)
> > invoked from within
> > "uplevel #0 $docmds
> >
> > I know, it's a kind of a weird thing trying to read SysEx files in this way
> > and probably it's just me trying to do something with the wrong tool.
> > But weirdly enough the sequences of characters I cannot copy and paste from
> > Atom, can then be directly typed in the [text] window.
> > I suspect this has to do with the character encoding.
> > Does anyone know why [text] behave this way?
> >
> > Cheers,
> > Mario
>
> > ___
> > 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
Re: [PD] [text] issue reading SysEx files
The trouble is probably the presence of a '{' character in the file.
But there will be other problems - ASCII NULL characters will simply
terminate the string early, and semicolons, spaces, and commas will
confuse things.
Somewhere on my long do-list is an idea to make an addition to soundfiler
to read binary chanracters into an array.
cheers
Miller
On Fri, Jan 18, 2019 at 04:39:04PM +, Mario Buoninfante wrote:
> Hi,
>
> I've been trying to read SysEx files using [text], and I noticed that the
> loaded file end up being corrupted in a way with bits and bops missing.
> Also trying to manually copy and paste part of the file (from Atom text
> editor) I'm not able to copy the entire file, there's always something
> missing (ie select all the file in Atom, copy and paste in [text]).
> When loading the file I've got no error, but then when I open the [text]
> window, this is returned on the console:
>
> (Tcl) UNHANDLED ERROR: extra characters after close-brace
> while executing
> "pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ), Y Q Y1
> -" ( , XFN ` 8 ) 6{` ) ) ;
> }
> pdtk_textwindow_append .x1006173..."
> ("uplevel" body line 39)
> invoked from within
> "uplevel #0 $docmds
>
> I know, it's a kind of a weird thing trying to read SysEx files in this way
> and probably it's just me trying to do something with the wrong tool.
> But weirdly enough the sequences of characters I cannot copy and paste from
> Atom, can then be directly typed in the [text] window.
> I suspect this has to do with the character encoding.
> Does anyone know why [text] behave this way?
>
> Cheers,
> Mario
> ___
> 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
Re: [PD] loading Camomile plug-ins using vstplugin~
cool, thanks for testing! Gesendet: Sonntag, 20. Januar 2019 um 20:17 Uhr Von: "JTG III" An: pd-list@lists.iem.at Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~ Seems to work on MacOS Sierra. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] loading Camomile plug-ins using vstplugin~
Seems to work on MacOS Sierra. On Sun, Jan 20, 2019, 1:55 PM Christof Ressi, 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" > > An: "Christof Ressi" > > Cc: cla...@mathr.co.uk, Pd-List > > 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" > > > > An: Pd-List > > > > 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" > > > > > 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 > > > > > -- > > > > > https://mathr.co.uk > > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > > 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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] loading Camomile plug-ins using vstplugin~
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" > An: "Christof Ressi" > Cc: cla...@mathr.co.uk, Pd-List > 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" > > > An: Pd-List > > > 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" > > > > 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 > > > > -- > > > > https://mathr.co.uk > > > > > > > > > > > > > > > > > > > > ___ > > > > 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
Re: [PD] loading Camomile plug-ins using vstplugin~
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" > An: "Christof Ressi" > Cc: cla...@mathr.co.uk, Pd-List > 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" > > > An: Pd-List > > > 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" > > > > 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 > > > > -- > > > > https://mathr.co.uk > > > > > > > > > > > > > > > > > > > > ___ > > > > 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
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" > > An: Pd-List > > 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" > > > 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 > > > -- > > > https://mathr.co.uk > > > > > > > > > > > > > > > ___ > > > 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
Re: [PD] loading Camomile plug-ins using vstplugin~
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 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" > > An: Pd-List > > 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" > > > 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 > > > -- > > > https://mathr.co.uk > > > > > > > > > > > > > > > ___ > > > 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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] loading Camomile plug-ins using vstplugin~
Em dom, 20 de jan de 2019 às 10:28, Christof Ressi 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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" > 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 > -- > https://mathr.co.uk > > > > > ___ > 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
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 -- https://mathr.co.uk ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] loading Camomile plug-ins using vstplugin~
Incepdion De: Pd-list em nome de Christof Ressi 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" > An: "Miller Puckette" > Cc: pd-l...@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" > > An: pd-l...@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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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" > An: "Miller Puckette" > Cc: pd-l...@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" > > An: pd-l...@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
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" > An: pd-l...@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
