Re: [PD-dev] libpd search paths
Hah, ok. I suppose this is a good nudge to make a libpd 0.12.0 release then. > On Feb 15, 2019, at 6:52 PM, Joseph Larralde > wrote: > > Ok, I finally got the addon to compile and run correctly (tests passed !) > The answer was simple : just use the master branch of libpd. > I started tweaking the Makefile of v0.11.0 to include g_undo.c (which I > noticed was containing the canvas_undo_undo function) in the sources but it > was not sufficient. > So I grabbed the master branch after seeing it seemed more up-to-date, and > voilà. > I still need to test this local version with the node project that loads > externals, but at least I have my own working local version which I can > modify at will. > > Thanks again for the help, I'll let you know how this goes with externals. > Joseph > > Le 15/02/19 à 15:11, Joseph Larralde a écrit : >> For the moment I'm using the default Makefile of libpd (version tagged >> 0.11.0), which makes use of the -DHAVE_LIBDL flag. >> It can't find the HAVE_LIBPD definition anywhere, though ... is this normal ? >> Sorry for my lack of knowledge of autotools, makefile, etc, but should I add >> `HAVE_LIBPD =` at the beginning of the Makefile ? (e.g. after `LIBPD_IMPLIB >> =` and `LIBPD_DEF =` lines ?) >> Or should it be added to the cflags with -DHAVE_LIBPD ? >> >> I added both and the addon builds fine (I got rid of the char * related >> errors by adding the -fpermissive flag), but I still get stuck when trying >> to run the js automated tests : >> they fail with an `undefined symbol` error, the undefined symbol being >> `canvas_undo_undo`. >> Sounds familiar to anybody ? >> I have no idea how to solve this ... >> >> Thanks, >> Joseph >> >> Le 14/02/19 à 14:32, Dan Wilcox a écrit : >>> If you're building libpd via a custom Makefile, see the flags used in the >>> libpd Makefile. Also, if you're using the libpd Makefile, double-check that >>> HAVE_LIBPD is being defined. >>> >>> On Thu, Feb 14, 2019 at 2:30 PM Joseph Larralde >> <mailto:joseph.larra...@gmail.com>> wrote: >>> Thank you Dan for your explanation. >>> And thanks everyone for helping. >>> >>> Yesterday I tried to recompile the node addon to use it locally but got >>> into other trouble. >>> I first recompiled libpd with MULTI=false after Christof's suggestion (to >>> enable the PDINSTANCE flag) but node-gyp was the first wall I was still >>> hitting. >>> It seems there are still some slight updates I need to do in the addon's >>> code (I got some char * vs const char * error). >>> Your 3rd point makes obvious sense and I'll try this in the first place >>> today. >>> >>> Joseph >>> >>> Le 14/02/19 à 13:07, Dan Wilcox a écrit : >>>> A few things: >>>> >>>> 1. libpd does not use any paths, settings, audio/midi backends, etc from >>>> desktop pd. It is only the core and less than "pd without the gui." This >>>> is by design as it makes no assumptions about the environment since it can >>>> be running in all manner of places. This means it will only search paths >>>> relative to an opened patch and those added explicitly by >>>> llibpd_add_to_search_path(). >>>> >>>> 2. Loading an external, whether it was compiled against 0.47 or 0.49 >>>> should work as, largely, the pd API has not changed that much. >>>> >>>> 3. libpd needs to be built with -DHAVE_LIBDL in order to be able to load >>>> separate, precompiled externals. >>>> >>>> 4. Some environments do *not* allow loading dynamic libraries for >>>> legal/security reasons, ie. iOS. I don't this is the problem, but it's >>>> good to know... >>>> >>>> I image you're issue is more to do with 3. >>>> >>>> Message: 1 >>>> Date: Wed, 13 Feb 2019 15:04:19 +0100 >>>> From: Joseph Larralde >>> <mailto:joseph.larra...@gmail.com>> >>>> To: Giulio Moro mailto:giuliom...@yahoo.it>>, Lucas >>>> Cordiviola >>>> mailto:lucard...@hotmail.com>>, pd-dev >>>> mailto:pd-dev@lists.iem.at>> >>>> Subject: Re: [PD-dev] libpd search paths >>>> Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com >>>> <mailto:2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com>> >>>> Content-Type: text/plain; charset="utf-8"; Format="f
Re: [PD-dev] libpd search paths
Ok, I finally got the addon to compile and run correctly (tests passed !)
The answer was simple : just use the master branch of libpd.
I started tweaking the Makefile of v0.11.0 to include g_undo.c (which I
noticed was containing the canvas_undo_undo function) in the sources but
it was not sufficient.
So I grabbed the master branch after seeing it seemed more up-to-date,
and voilà.
I still need to test this local version with the node project that loads
externals, but at least I have my own working local version which I can
modify at will.
Thanks again for the help, I'll let you know how this goes with externals.
Joseph
Le 15/02/19 à 15:11, Joseph Larralde a écrit :
For the moment I'm using the default Makefile of libpd (version tagged
0.11.0), which makes use of the -DHAVE_LIBDL flag.
It can't find the HAVE_LIBPD definition anywhere, though ... is this
normal ?
Sorry for my lack of knowledge of autotools, makefile, etc, but should
I add `HAVE_LIBPD =` at the beginning of the Makefile ? (e.g. after
`LIBPD_IMPLIB =` and `LIBPD_DEF =` lines ?)
Or should it be added to the cflags with -DHAVE_LIBPD ?
I added both and the addon builds fine (I got rid of the char *
related errors by adding the -fpermissive flag), but I still get stuck
when trying to run the js automated tests :
they fail with an `undefined symbol` error, the undefined symbol being
`canvas_undo_undo`.
Sounds familiar to anybody ?
I have no idea how to solve this ...
Thanks,
Joseph
Le 14/02/19 à 14:32, Dan Wilcox a écrit :
If you're building libpd via a custom Makefile, see the flags used in
the libpd Makefile. Also, if you're using the libpd Makefile,
double-check that HAVE_LIBPD is being defined.
On Thu, Feb 14, 2019 at 2:30 PM Joseph Larralde
mailto:joseph.larra...@gmail.com>> wrote:
Thank you Dan for your explanation.
And thanks everyone for helping.
Yesterday I tried to recompile the node addon to use it locally
but got into other trouble.
I first recompiled libpd with MULTI=false after Christof's
suggestion (to enable the PDINSTANCE flag) but node-gyp was the
first wall I was still hitting.
It seems there are still some slight updates I need to do in the
addon's code (I got some char * vs const char * error).
Your 3rd point makes obvious sense and I'll try this in the first
place today.
Joseph
Le 14/02/19 à 13:07, Dan Wilcox a écrit :
A few things:
1. libpd does not use any paths, settings, audio/midi backends,
etc from desktop pd. It is only the core and less than "pd
without the gui." This is by design as it makes no assumptions
about the environment since it can be running in all manner of
places. This means it will only search paths relative to an
opened patch and those added explicitly by
llibpd_add_to_search_path().
2. Loading an external, whether it was compiled against 0.47 or
0.49 should work as, largely, the pd API has not changed that much.
3. libpd needs to be built with -DHAVE_LIBDL in order to be able
to load separate, precompiled externals.
4. Some environments do *not* allow loading dynamic libraries
for legal/security reasons, ie. iOS. I don't this is the
problem, but it's good to know...
I image you're issue is more to do with 3.
Message: 1
Date: Wed, 13 Feb 2019 15:04:19 +0100
From: Joseph Larralde mailto:joseph.larra...@gmail.com>>
To: Giulio Moro mailto:giuliom...@yahoo.it>>, Lucas Cordiviola
mailto:lucard...@hotmail.com>>, pd-dev mailto:pd-dev@lists.iem.at>>
Subject: Re: [PD-dev] libpd search paths
Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com
<mailto:2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com>>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Mmmh you might have found the clue ...
Actually I built the externals against pd version 0.49-0 and
it makes
sense that they load properly with the same version.
node-libpd comes with an arm libpd binary which seems to
come from an
older version of pd (added 1 year ago).
I can already tell that it's not an architecture issue because
everything is working on my pi : the addon is loading and
running
abstractions when used in a node program, and pd is loading
and running
my externals.
Only loading my externals from node-libpd doesn't work.
Still trying to get a local version of node-libpd to work
... then I'll
replace the libpd.so with one that I'll build from the
latest version.
I can't see another explanation.
Do you know something about incompatibilities between
different versions
of pd ?
The libpd.so used by the addon is probably not older than 0.47
--
Re: [PD-dev] libpd search paths
For the moment I'm using the default Makefile of libpd (version tagged
0.11.0), which makes use of the -DHAVE_LIBDL flag.
It can't find the HAVE_LIBPD definition anywhere, though ... is this
normal ?
Sorry for my lack of knowledge of autotools, makefile, etc, but should I
add `HAVE_LIBPD =` at the beginning of the Makefile ? (e.g. after
`LIBPD_IMPLIB =` and `LIBPD_DEF =` lines ?)
Or should it be added to the cflags with -DHAVE_LIBPD ?
I added both and the addon builds fine (I got rid of the char * related
errors by adding the -fpermissive flag), but I still get stuck when
trying to run the js automated tests :
they fail with an `undefined symbol` error, the undefined symbol being
`canvas_undo_undo`.
Sounds familiar to anybody ?
I have no idea how to solve this ...
Thanks,
Joseph
Le 14/02/19 à 14:32, Dan Wilcox a écrit :
If you're building libpd via a custom Makefile, see the flags used in
the libpd Makefile. Also, if you're using the libpd Makefile,
double-check that HAVE_LIBPD is being defined.
On Thu, Feb 14, 2019 at 2:30 PM Joseph Larralde
mailto:joseph.larra...@gmail.com>> wrote:
Thank you Dan for your explanation.
And thanks everyone for helping.
Yesterday I tried to recompile the node addon to use it locally
but got into other trouble.
I first recompiled libpd with MULTI=false after Christof's
suggestion (to enable the PDINSTANCE flag) but node-gyp was the
first wall I was still hitting.
It seems there are still some slight updates I need to do in the
addon's code (I got some char * vs const char * error).
Your 3rd point makes obvious sense and I'll try this in the first
place today.
Joseph
Le 14/02/19 à 13:07, Dan Wilcox a écrit :
A few things:
1. libpd does not use any paths, settings, audio/midi backends,
etc from desktop pd. It is only the core and less than "pd
without the gui." This is by design as it makes no assumptions
about the environment since it can be running in all manner of
places. This means it will only search paths relative to an
opened patch and those added explicitly by
llibpd_add_to_search_path().
2. Loading an external, whether it was compiled against 0.47 or
0.49 should work as, largely, the pd API has not changed that much.
3. libpd needs to be built with -DHAVE_LIBDL in order to be able
to load separate, precompiled externals.
4. Some environments do *not* allow loading dynamic libraries for
legal/security reasons, ie. iOS. I don't this is the problem, but
it's good to know...
I image you're issue is more to do with 3.
Message: 1
Date: Wed, 13 Feb 2019 15:04:19 +0100
From: Joseph Larralde mailto:joseph.larra...@gmail.com>>
To: Giulio Moro mailto:giuliom...@yahoo.it>>, Lucas Cordiviola
mailto:lucard...@hotmail.com>>, pd-dev mailto:pd-dev@lists.iem.at>>
Subject: Re: [PD-dev] libpd search paths
Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com
<mailto:2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com>>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Mmmh you might have found the clue ...
Actually I built the externals against pd version 0.49-0 and
it makes
sense that they load properly with the same version.
node-libpd comes with an arm libpd binary which seems to come
from an
older version of pd (added 1 year ago).
I can already tell that it's not an architecture issue because
everything is working on my pi : the addon is loading and
running
abstractions when used in a node program, and pd is loading
and running
my externals.
Only loading my externals from node-libpd doesn't work.
Still trying to get a local version of node-libpd to work ...
then I'll
replace the libpd.so with one that I'll build from the latest
version.
I can't see another explanation.
Do you know something about incompatibilities between
different versions
of pd ?
The libpd.so used by the addon is probably not older than 0.47
--
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>
--
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
If you're building libpd via a custom Makefile, see the flags used in the libpd Makefile. Also, if you're using the libpd Makefile, double-check that HAVE_LIBPD is being defined. On Thu, Feb 14, 2019 at 2:30 PM Joseph Larralde wrote: > Thank you Dan for your explanation. > And thanks everyone for helping. > > Yesterday I tried to recompile the node addon to use it locally but got > into other trouble. > I first recompiled libpd with MULTI=false after Christof's suggestion (to > enable the PDINSTANCE flag) but node-gyp was the first wall I was still > hitting. > It seems there are still some slight updates I need to do in the addon's > code (I got some char * vs const char * error). > Your 3rd point makes obvious sense and I'll try this in the first place > today. > > Joseph > > Le 14/02/19 à 13:07, Dan Wilcox a écrit : > > A few things: > > 1. libpd does not use any paths, settings, audio/midi backends, etc from > desktop pd. It is only the core and less than "pd without the gui." This is > by design as it makes no assumptions about the environment since it can be > running in all manner of places. This means it will only search paths > relative to an opened patch and those added explicitly by > llibpd_add_to_search_path(). > > 2. Loading an external, whether it was compiled against 0.47 or 0.49 > should work as, largely, the pd API has not changed that much. > > 3. libpd needs to be built with -DHAVE_LIBDL in order to be able to load > separate, precompiled externals. > > 4. Some environments do *not* allow loading dynamic libraries for > legal/security reasons, ie. iOS. I don't this is the problem, but it's good > to know... > > I image you're issue is more to do with 3. > > Message: 1 >> Date: Wed, 13 Feb 2019 15:04:19 +0100 >> From: Joseph Larralde >> To: Giulio Moro , Lucas Cordiviola >> , pd-dev >> Subject: Re: [PD-dev] libpd search paths >> Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> Mmmh you might have found the clue ... >> Actually I built the externals against pd version 0.49-0 and it makes >> sense that they load properly with the same version. >> node-libpd comes with an arm libpd binary which seems to come from an >> older version of pd (added 1 year ago). >> I can already tell that it's not an architecture issue because >> everything is working on my pi : the addon is loading and running >> abstractions when used in a node program, and pd is loading and running >> my externals. >> Only loading my externals from node-libpd doesn't work. >> Still trying to get a local version of node-libpd to work ... then I'll >> replace the libpd.so with one that I'll build from the latest version. >> I can't see another explanation. >> Do you know something about incompatibilities between different versions >> of pd ? >> The libpd.so used by the addon is probably not older than 0.47 >> > > > -- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > -- Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
Thank you Dan for your explanation. And thanks everyone for helping. Yesterday I tried to recompile the node addon to use it locally but got into other trouble. I first recompiled libpd with MULTI=false after Christof's suggestion (to enable the PDINSTANCE flag) but node-gyp was the first wall I was still hitting. It seems there are still some slight updates I need to do in the addon's code (I got some char * vs const char * error). Your 3rd point makes obvious sense and I'll try this in the first place today. Joseph Le 14/02/19 à 13:07, Dan Wilcox a écrit : A few things: 1. libpd does not use any paths, settings, audio/midi backends, etc from desktop pd. It is only the core and less than "pd without the gui." This is by design as it makes no assumptions about the environment since it can be running in all manner of places. This means it will only search paths relative to an opened patch and those added explicitly by llibpd_add_to_search_path(). 2. Loading an external, whether it was compiled against 0.47 or 0.49 should work as, largely, the pd API has not changed that much. 3. libpd needs to be built with -DHAVE_LIBDL in order to be able to load separate, precompiled externals. 4. Some environments do *not* allow loading dynamic libraries for legal/security reasons, ie. iOS. I don't this is the problem, but it's good to know... I image you're issue is more to do with 3. Message: 1 Date: Wed, 13 Feb 2019 15:04:19 +0100 From: Joseph Larralde mailto:joseph.larra...@gmail.com>> To: Giulio Moro mailto:giuliom...@yahoo.it>>, Lucas Cordiviola mailto:lucard...@hotmail.com>>, pd-dev mailto:pd-dev@lists.iem.at>> Subject: Re: [PD-dev] libpd search paths Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com <mailto:2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com>> Content-Type: text/plain; charset="utf-8"; Format="flowed" Mmmh you might have found the clue ... Actually I built the externals against pd version 0.49-0 and it makes sense that they load properly with the same version. node-libpd comes with an arm libpd binary which seems to come from an older version of pd (added 1 year ago). I can already tell that it's not an architecture issue because everything is working on my pi : the addon is loading and running abstractions when used in a node program, and pd is loading and running my externals. Only loading my externals from node-libpd doesn't work. Still trying to get a local version of node-libpd to work ... then I'll replace the libpd.so with one that I'll build from the latest version. I can't see another explanation. Do you know something about incompatibilities between different versions of pd ? The libpd.so used by the addon is probably not older than 0.47 -- Dan Wilcox @danomatika danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
A few things: 1. libpd does not use any paths, settings, audio/midi backends, etc from desktop pd. It is only the core and less than "pd without the gui." This is by design as it makes no assumptions about the environment since it can be running in all manner of places. This means it will only search paths relative to an opened patch and those added explicitly by llibpd_add_to_search_path(). 2. Loading an external, whether it was compiled against 0.47 or 0.49 should work as, largely, the pd API has not changed that much. 3. libpd needs to be built with -DHAVE_LIBDL in order to be able to load separate, precompiled externals. 4. Some environments do *not* allow loading dynamic libraries for legal/security reasons, ie. iOS. I don't this is the problem, but it's good to know... I image you're issue is more to do with 3. Message: 1 > Date: Wed, 13 Feb 2019 15:04:19 +0100 > From: Joseph Larralde > To: Giulio Moro , Lucas Cordiviola > , pd-dev > Subject: Re: [PD-dev] libpd search paths > Message-ID: <2354c1c4-e6db-9143-1402-76dcd37b4...@gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Mmmh you might have found the clue ... > Actually I built the externals against pd version 0.49-0 and it makes > sense that they load properly with the same version. > node-libpd comes with an arm libpd binary which seems to come from an > older version of pd (added 1 year ago). > I can already tell that it's not an architecture issue because > everything is working on my pi : the addon is loading and running > abstractions when used in a node program, and pd is loading and running > my externals. > Only loading my externals from node-libpd doesn't work. > Still trying to get a local version of node-libpd to work ... then I'll > replace the libpd.so with one that I'll build from the latest version. > I can't see another explanation. > Do you know something about incompatibilities between different versions > of pd ? > The libpd.so used by the addon is probably not older than 0.47 > -- Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
> Actually I built the externals against pd version 0.49-0 and it makes sense > that they load properly with the same version. actually, Pd externals which only use the public API in m_pd.h are fully backwards compatible, e.g. many ancient externals from Pd extended still work with Pd 0.49. > node-libpd comes with an arm libpd binary which seems to come from an older > version of pd this is just a wild guess, but maybe the libpd binary was compiled with PDINSTANCE? if yes, externals which are not compiled with PDINSTANCE *and* use the global predefined Pd symbols (s_symbol, s_float, etc.) - instead of gensym() - won't load. Christof Gesendet: Mittwoch, 13. Februar 2019 um 15:04 Uhr Von: "Joseph Larralde" An: "Giulio Moro" , "Lucas Cordiviola" , pd-dev Betreff: Re: [PD-dev] libpd search paths Mmmh you might have found the clue ... Actually I built the externals against pd version 0.49-0 and it makes sense that they load properly with the same version. node-libpd comes with an arm libpd binary which seems to come from an older version of pd (added 1 year ago). I can already tell that it's not an architecture issue because everything is working on my pi : the addon is loading and running abstractions when used in a node program, and pd is loading and running my externals. Only loading my externals from node-libpd doesn't work. Still trying to get a local version of node-libpd to work ... then I'll replace the libpd.so with one that I'll build from the latest version. I can't see another explanation. Do you know something about incompatibilities between different versions of pd ? The libpd.so used by the addon is probably not older than 0.47 Le 13/02/19 à 13:58, Giulio Moro a écrit : If loading abstractions works, then it is possible that the external you are trying to load is somehow incompatible. Was it built for this specific architecture, against the same exact version of PureData? Are the externals relying on any external library? Are those libraries - if any - available on the computer you are running this on? I'd recommend you run a bare-minimum raw libpd program to make sure the externals are loaded properly. For instance, you can build and run the program in libpd/samples/c/pdtest/ and verify that it can load your externals successfully, so at least you can temporarily rule out the node.js wrapper as the cause of the issue. Giulio On Wednesday, 13 February 2019, 12:32:55 GMT, Joseph Larralde [mailto:joseph.larra...@gmail.com] wrote: Hi Lucas, From everything you listed, only loading an abstraction from the same dir worked. I'll investigate in the addon's code itself and see if I can get it to work using `libpd_add_to_search_path()` somewhere. Also, I might precise that usually I declare my externals using their folder name as a prefix, in this case [jl/gbend~ ] This frees me from having to use [declare] and avoids eventual name conflicts. Could this be an issue because of the library name not being the external's name when using [declare] ? Thanks for your suggestions, Joseph Le 13/02/19 à 11:58, Lucas Cordiviola a écrit : > Just a guess: > > -- Can you load abstractions on those dirs? > > if not: > > -- Can you load an abstraction in the same dir as your "main-patch.pd" > > If yes: > > -- Can you load the [external] in the same dir as "main-patch.pd" > > > > You can also test if [declare] is working. First with abstractions then > with [external]. > > > Mensaje telepatico asistido por maquinas. > > On 2/13/2019 6:42 AM, Joseph Larralde wrote: >> Hi, >> >> A friend of mine wrote this libpd wrapper for nodejs (which is >> actually a work in progress) : >> https://github.com/ircam-jstools/node-libpd[https://github.com/ircam-jstools/node-libpd] >> It's running fine on a pi3 I'm using ATM. >> >> Now I need to use some externals I wrote, and I can't get them to load >> properly. >> But, they're loading when I start my test patch using pd itself. >> >> Before diving into his wrapper code, I'd like to make sure I'm placing >> the externals in the right path. >> What makes me think it should be working is this page : >> https://github.com/libpd/libpd/wiki/misc[https://github.com/libpd/libpd/wiki/misc] >> And also the fact that in his code, he's calling the init() function >> from PdBase, which is itself calling the libpd_init() function. >> >> I tried putting the externals into /usr/local/lib/pd-externals, >> /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. >> But still no luck ... >> >> Can anyone confirm I'm not mistaken ? >> >> Cheers, >> Joseph >> >> >> >> ___ >> Pd-dev mailing
Re: [PD-dev] libpd search paths
Mmmh you might have found the clue ... Actually I built the externals against pd version 0.49-0 and it makes sense that they load properly with the same version. node-libpd comes with an arm libpd binary which seems to come from an older version of pd (added 1 year ago). I can already tell that it's not an architecture issue because everything is working on my pi : the addon is loading and running abstractions when used in a node program, and pd is loading and running my externals. Only loading my externals from node-libpd doesn't work. Still trying to get a local version of node-libpd to work ... then I'll replace the libpd.so with one that I'll build from the latest version. I can't see another explanation. Do you know something about incompatibilities between different versions of pd ? The libpd.so used by the addon is probably not older than 0.47 Le 13/02/19 à 13:58, Giulio Moro a écrit : If loading abstractions works, then it is possible that the external you are trying to load is somehow incompatible. Was it built for this specific architecture, against the same exact version of PureData? Are the externals relying on any external library? Are those libraries - if any - available on the computer you are running this on? I'd recommend you run a bare-minimum raw libpd program to make sure the externals are loaded properly. For instance, you can build and run the program in libpd/samples/c/pdtest/ and verify that it can load your externals successfully, so at least you can temporarily rule out the node.js wrapper as the cause of the issue. Giulio On Wednesday, 13 February 2019, 12:32:55 GMT, Joseph Larralde wrote: Hi Lucas, From everything you listed, only loading an abstraction from the same dir worked. I'll investigate in the addon's code itself and see if I can get it to work using `libpd_add_to_search_path()` somewhere. Also, I might precise that usually I declare my externals using their folder name as a prefix, in this case [jl/gbend~ ] This frees me from having to use [declare] and avoids eventual name conflicts. Could this be an issue because of the library name not being the external's name when using [declare] ? Thanks for your suggestions, Joseph Le 13/02/19 à 11:58, Lucas Cordiviola a écrit : > Just a guess: > > -- Can you load abstractions on those dirs? > > if not: > > -- Can you load an abstraction in the same dir as your "main-patch.pd" > > If yes: > > -- Can you load the [external] in the same dir as "main-patch.pd" > > > > You can also test if [declare] is working. First with abstractions then > with [external]. > > > Mensaje telepatico asistido por maquinas. > > On 2/13/2019 6:42 AM, Joseph Larralde wrote: >> Hi, >> >> A friend of mine wrote this libpd wrapper for nodejs (which is >> actually a work in progress) : >> https://github.com/ircam-jstools/node-libpd >> It's running fine on a pi3 I'm using ATM. >> >> Now I need to use some externals I wrote, and I can't get them to load >> properly. >> But, they're loading when I start my test patch using pd itself. >> >> Before diving into his wrapper code, I'd like to make sure I'm placing >> the externals in the right path. >> What makes me think it should be working is this page : >> https://github.com/libpd/libpd/wiki/misc >> And also the fact that in his code, he's calling the init() function >> from PdBase, which is itself calling the libpd_init() function. >> >> I tried putting the externals into /usr/local/lib/pd-externals, >> /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. >> But still no luck ... >> >> Can anyone confirm I'm not mistaken ? >> >> Cheers, >> Joseph >> >> >> >> ___ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
Hmm, it should work with objects in the same folder as the pd file you open. I have tried that on Bela and I can remove the libpd_add_to_search_path() calls, and - as long as I pass the appropriate relative path to the _main.pd file - then abstractions that live in the same folder as _main.pd are loaded correctly, even if the program is started from a different folder. Actually, can you try with some abstractions instead of externals? Maybe the externals cannot load for other reasons, but if you get the abstractions to work, then you'll have narrowed down your problem. On Wednesday, 13 February 2019, 12:15:59 GMT, Joseph Larralde wrote: Hi Giulio, Le 13/02/19 à 11:11, Giulio Moro a écrit : > That sounds like an interesting project, although I struggle to understand > how it would be used. Yes it is :) Actually we are working on a project where we make an extensive use of nodejs for distributed local applications, so it's worth using this addon in our case (and that's the kind of scenario for which it was initially created). I must admit that for my own use, I'm only launching pd from a node server and then doing everything else in the patches ... (I was inspired to do so after trying out the Bela once, so thanks for the inspiration) > AFAIK, libpd does not search in any of the default Pd paths. It comes with a > `libpd_add_to_search_path()` function that you should use to manually add the > search paths. From the README of node-libpd, among the todos there is : > • re-enable addToSearchPath and clearSearchPath Thanks for explaining the path issue before I went crazy. You're right, this is written in the todos of the README, which is a bit minimalistic ... > So that is probably where the issue lies. In the meantime you can consider > just copying or symlinking your externals to the current folder. Unfortunately, copying the external to the current folder didn't help, so I guess I'll have to modify the addon a bit to re-enable the addToSearchPath method and make a PR. From my experience of pd, I suspect this should be done at initialization time, so I might have to modify the addon's api to provide another json field in the init method instead. Does this sound right-minded ? Thanks, Joseph > > Giulio > > On Wednesday, 13 February 2019, 09:49:08 GMT, Joseph Larralde > wrote: > > Hi, > > A friend of mine wrote this libpd wrapper for nodejs (which is actually > a work in progress) : > https://github.com/ircam-jstools/node-libpd > It's running fine on a pi3 I'm using ATM. > > Now I need to use some externals I wrote, and I can't get them to load > properly. > But, they're loading when I start my test patch using pd itself. > > Before diving into his wrapper code, I'd like to make sure I'm placing > the externals in the right path. > What makes me think it should be working is this page : > https://github.com/libpd/libpd/wiki/misc > And also the fact that in his code, he's calling the init() function > from PdBase, which is itself calling the libpd_init() function. > > I tried putting the externals into /usr/local/lib/pd-externals, > /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. > But still no luck ... > > Can anyone confirm I'm not mistaken ? > > Cheers, > Joseph > > > > ___ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
there are a couple of things you can try with your [external] or with
one that you are sure that works with your arch {1} as Giulio mentioned:
1)
create a folder "jl" on the same dir as "main.pd"
put an abstraction on "jl" folder.
On "main.pd" call the abstraction with [jl/your-abs]
If the abstraction is loaded place your [external] in the "jl" folder
and try to load it with [jl/gbend~ ].
2)
You can also try placing "gbend~" binary in the same dir as "main.pd"
and call it using [gbend~ ].
3)
You can also test if [declare] is working.
On "main.pd" create a declare object [declare -path jl]
try loading your abstraction placed on "jl" folder just with [your-abs]
{1} You can use the standard Pd on your pi and use Deken to get some
external i.e [freeverb~] :
freeverb~-v1.2.3-(Linux-armv7l-32)(Sources)-externals.tgz
Uploaded by fjkraan @ 2016-07-29 16:40:59
I'm not sure if "Linux-armv7l-32" is for the pi (i guess it is).
Mensaje telepatico asistido por maquinas.
On 2/13/2019 9:54 AM, Joseph Larralde wrote:
> It seems to be a problem with externals because abstractions load just
> fine from the same folder (see also my answer to Lucas).
> I'm currently struggling to compile the node addon on my pi, and will
> let you know if I get some positive results.
>
> Le 13/02/19 à 13:47, Giulio Moro a écrit :
>> Hmm, it should work with objects in the same folder as the pd file
>> you open. I have tried that on Bela and I can remove the
>> libpd_add_to_search_path() calls, and - as long as I pass the
>> appropriate relative path to the _main.pd file - then abstractions
>> that live in the same folder as _main.pd are loaded correctly, even
>> if the program is started from a different folder. Actually, can you
>> try with some abstractions instead of externals? Maybe the externals
>> cannot load for other reasons, but if you get the abstractions to
>> work, then you'll have narrowed down your problem.
>>
>>
>> On Wednesday, 13 February 2019, 12:15:59 GMT, Joseph Larralde
>> wrote:
>>
>> Hi Giulio,
>>
>> Le 13/02/19 à 11:11, Giulio Moro a écrit :
>>> That sounds like an interesting project, although I struggle to
>>> understand how it would be used.
>> Yes it is :)
>> Actually we are working on a project where we make an extensive use of
>> nodejs for distributed local applications, so it's worth using this
>> addon in our case (and that's the kind of scenario for which it was
>> initially created).
>> I must admit that for my own use, I'm only launching pd from a node
>> server and then doing everything else in the patches ...
>> (I was inspired to do so after trying out the Bela once, so thanks for
>> the inspiration)
>>> AFAIK, libpd does not search in any of the default Pd paths. It
>>> comes with a `libpd_add_to_search_path()` function that you should
>>> use to manually add the search paths. From the README of node-libpd,
>>> among the todos there is :
>>> • re-enable addToSearchPath and clearSearchPath
>> Thanks for explaining the path issue before I went crazy.
>> You're right, this is written in the todos of the README, which is a bit
>> minimalistic ...
>>> So that is probably where the issue lies. In the meantime you can
>>> consider just copying or symlinking your externals to the current
>>> folder.
>> Unfortunately, copying the external to the current folder didn't help,
>> so I guess I'll have to modify the addon a bit to re-enable the
>> addToSearchPath method and make a PR.
>> >From my experience of pd, I suspect this should be done at
>> initialization time, so I might have to modify the addon's api to
>> provide another json field in the init method instead.
>> Does this sound right-minded ?
>>
>> Thanks,
>> Joseph
>>
>>
>>> Giulio
>>>
>>> On Wednesday, 13 February 2019, 09:49:08 GMT, Joseph Larralde
>>> wrote:
>>>
>>> Hi,
>>>
>>> A friend of mine wrote this libpd wrapper for nodejs (which is actually
>>> a work in progress) :
>>> https://github.com/ircam-jstools/node-libpd
>>> It's running fine on a pi3 I'm using ATM.
>>>
>>> Now I need to use some externals I wrote, and I can't get them to load
>>> properly.
>>> But, they're loading when I start my test patch using pd itself.
>>>
>>> Before diving into his wrapper code, I'd like to make sure I'm placing
>>> the externals in the right path.
>>> What makes me think it should be working is this page :
>>> https://github.com/libpd/libpd/wiki/misc
>>> And also the fact that in his code, he's calling the init() function
>>> from PdBase, which is itself calling the libpd_init() function.
>>>
>>> I tried putting the externals into /usr/local/lib/pd-externals,
>>> /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra.
>>> But still no luck ...
>>>
>>> Can anyone confirm I'm not mistaken ?
>>>
>>> Cheers,
>>> Joseph
>>>
>>>
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>
>
>
>
>
>
Re: [PD-dev] libpd search paths
It seems to be a problem with externals because abstractions load just fine from the same folder (see also my answer to Lucas). I'm currently struggling to compile the node addon on my pi, and will let you know if I get some positive results. Le 13/02/19 à 13:47, Giulio Moro a écrit : Hmm, it should work with objects in the same folder as the pd file you open. I have tried that on Bela and I can remove the libpd_add_to_search_path() calls, and - as long as I pass the appropriate relative path to the _main.pd file - then abstractions that live in the same folder as _main.pd are loaded correctly, even if the program is started from a different folder. Actually, can you try with some abstractions instead of externals? Maybe the externals cannot load for other reasons, but if you get the abstractions to work, then you'll have narrowed down your problem. On Wednesday, 13 February 2019, 12:15:59 GMT, Joseph Larralde wrote: Hi Giulio, Le 13/02/19 à 11:11, Giulio Moro a écrit : That sounds like an interesting project, although I struggle to understand how it would be used. Yes it is :) Actually we are working on a project where we make an extensive use of nodejs for distributed local applications, so it's worth using this addon in our case (and that's the kind of scenario for which it was initially created). I must admit that for my own use, I'm only launching pd from a node server and then doing everything else in the patches ... (I was inspired to do so after trying out the Bela once, so thanks for the inspiration) AFAIK, libpd does not search in any of the default Pd paths. It comes with a `libpd_add_to_search_path()` function that you should use to manually add the search paths. From the README of node-libpd, among the todos there is : • re-enable addToSearchPath and clearSearchPath Thanks for explaining the path issue before I went crazy. You're right, this is written in the todos of the README, which is a bit minimalistic ... So that is probably where the issue lies. In the meantime you can consider just copying or symlinking your externals to the current folder. Unfortunately, copying the external to the current folder didn't help, so I guess I'll have to modify the addon a bit to re-enable the addToSearchPath method and make a PR. >From my experience of pd, I suspect this should be done at initialization time, so I might have to modify the addon's api to provide another json field in the init method instead. Does this sound right-minded ? Thanks, Joseph Giulio On Wednesday, 13 February 2019, 09:49:08 GMT, Joseph Larralde wrote: Hi, A friend of mine wrote this libpd wrapper for nodejs (which is actually a work in progress) : https://github.com/ircam-jstools/node-libpd It's running fine on a pi3 I'm using ATM. Now I need to use some externals I wrote, and I can't get them to load properly. But, they're loading when I start my test patch using pd itself. Before diving into his wrapper code, I'd like to make sure I'm placing the externals in the right path. What makes me think it should be working is this page : https://github.com/libpd/libpd/wiki/misc And also the fact that in his code, he's calling the init() function from PdBase, which is itself calling the libpd_init() function. I tried putting the externals into /usr/local/lib/pd-externals, /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. But still no luck ... Can anyone confirm I'm not mistaken ? Cheers, Joseph ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
If loading abstractions works, then it is possible that the external you are trying to load is somehow incompatible. Was it built for this specific architecture, against the same exact version of PureData? Are the externals relying on any external library? Are those libraries - if any - available on the computer you are running this on?I'd recommend you run a bare-minimum raw libpd program to make sure the externals are loaded properly. For instance, you can build and run the program in libpd/samples/c/pdtest/ and verify that it can load your externals successfully, so at least you can temporarily rule out the node.js wrapper as the cause of the issue. Giulio On Wednesday, 13 February 2019, 12:32:55 GMT, Joseph Larralde wrote: Hi Lucas, >From everything you listed, only loading an abstraction from the same dir worked. I'll investigate in the addon's code itself and see if I can get it to work using `libpd_add_to_search_path()` somewhere. Also, I might precise that usually I declare my externals using their folder name as a prefix, in this case [jl/gbend~ ] This frees me from having to use [declare] and avoids eventual name conflicts. Could this be an issue because of the library name not being the external's name when using [declare] ? Thanks for your suggestions, Joseph Le 13/02/19 à 11:58, Lucas Cordiviola a écrit : > Just a guess: > > -- Can you load abstractions on those dirs? > > if not: > > -- Can you load an abstraction in the same dir as your "main-patch.pd" > > If yes: > > -- Can you load the [external] in the same dir as "main-patch.pd" > > > > You can also test if [declare] is working. First with abstractions then > with [external]. > > > Mensaje telepatico asistido por maquinas. > > On 2/13/2019 6:42 AM, Joseph Larralde wrote: >> Hi, >> >> A friend of mine wrote this libpd wrapper for nodejs (which is >> actually a work in progress) : >> https://github.com/ircam-jstools/node-libpd >> It's running fine on a pi3 I'm using ATM. >> >> Now I need to use some externals I wrote, and I can't get them to load >> properly. >> But, they're loading when I start my test patch using pd itself. >> >> Before diving into his wrapper code, I'd like to make sure I'm placing >> the externals in the right path. >> What makes me think it should be working is this page : >> https://github.com/libpd/libpd/wiki/misc >> And also the fact that in his code, he's calling the init() function >> from PdBase, which is itself calling the libpd_init() function. >> >> I tried putting the externals into /usr/local/lib/pd-externals, >> /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. >> But still no luck ... >> >> Can anyone confirm I'm not mistaken ? >> >> Cheers, >> Joseph >> >> >> >> ___ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
Hi Lucas, From everything you listed, only loading an abstraction from the same dir worked. I'll investigate in the addon's code itself and see if I can get it to work using `libpd_add_to_search_path()` somewhere. Also, I might precise that usually I declare my externals using their folder name as a prefix, in this case [jl/gbend~ ] This frees me from having to use [declare] and avoids eventual name conflicts. Could this be an issue because of the library name not being the external's name when using [declare] ? Thanks for your suggestions, Joseph Le 13/02/19 à 11:58, Lucas Cordiviola a écrit : Just a guess: -- Can you load abstractions on those dirs? if not: -- Can you load an abstraction in the same dir as your "main-patch.pd" If yes: -- Can you load the [external] in the same dir as "main-patch.pd" You can also test if [declare] is working. First with abstractions then with [external]. Mensaje telepatico asistido por maquinas. On 2/13/2019 6:42 AM, Joseph Larralde wrote: Hi, A friend of mine wrote this libpd wrapper for nodejs (which is actually a work in progress) : https://github.com/ircam-jstools/node-libpd It's running fine on a pi3 I'm using ATM. Now I need to use some externals I wrote, and I can't get them to load properly. But, they're loading when I start my test patch using pd itself. Before diving into his wrapper code, I'd like to make sure I'm placing the externals in the right path. What makes me think it should be working is this page : https://github.com/libpd/libpd/wiki/misc And also the fact that in his code, he's calling the init() function from PdBase, which is itself calling the libpd_init() function. I tried putting the externals into /usr/local/lib/pd-externals, /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. But still no luck ... Can anyone confirm I'm not mistaken ? Cheers, Joseph ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd search paths
Hi Giulio, Le 13/02/19 à 11:11, Giulio Moro a écrit : That sounds like an interesting project, although I struggle to understand how it would be used. Yes it is :) Actually we are working on a project where we make an extensive use of nodejs for distributed local applications, so it's worth using this addon in our case (and that's the kind of scenario for which it was initially created). I must admit that for my own use, I'm only launching pd from a node server and then doing everything else in the patches ... (I was inspired to do so after trying out the Bela once, so thanks for the inspiration) AFAIK, libpd does not search in any of the default Pd paths. It comes with a `libpd_add_to_search_path()` function that you should use to manually add the search paths. From the README of node-libpd, among the todos there is : • re-enable addToSearchPath and clearSearchPath Thanks for explaining the path issue before I went crazy. You're right, this is written in the todos of the README, which is a bit minimalistic ... So that is probably where the issue lies. In the meantime you can consider just copying or symlinking your externals to the current folder. Unfortunately, copying the external to the current folder didn't help, so I guess I'll have to modify the addon a bit to re-enable the addToSearchPath method and make a PR. From my experience of pd, I suspect this should be done at initialization time, so I might have to modify the addon's api to provide another json field in the init method instead. Does this sound right-minded ? Thanks, Joseph Giulio On Wednesday, 13 February 2019, 09:49:08 GMT, Joseph Larralde wrote: Hi, A friend of mine wrote this libpd wrapper for nodejs (which is actually a work in progress) : https://github.com/ircam-jstools/node-libpd It's running fine on a pi3 I'm using ATM. Now I need to use some externals I wrote, and I can't get them to load properly. But, they're loading when I start my test patch using pd itself. Before diving into his wrapper code, I'd like to make sure I'm placing the externals in the right path. What makes me think it should be working is this page : https://github.com/libpd/libpd/wiki/misc And also the fact that in his code, he's calling the init() function from PdBase, which is itself calling the libpd_init() function. I tried putting the externals into /usr/local/lib/pd-externals, /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra. But still no luck ... Can anyone confirm I'm not mistaken ? Cheers, Joseph ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
