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
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
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~ <name_of_table>] 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
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 joseph.larralde@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~ <name_of_table>] 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
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 joseph.larralde@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~ <name_of_table>] 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
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" joseph.larralde@gmail.com An: "Giulio Moro" giuliomoro@yahoo.it, "Lucas Cordiviola" lucarda27@hotmail.com, pd-dev pd-dev@lists.iem.at 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 joseph.larralde@gmail.com[mailto:joseph.larralde@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~ <name_of_table>] 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%5Bhttps://github.com/ircam-jstoo...] 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%5Bhttps://github.com/libpd/libpd/wi...] 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[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto: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%5Bhttps://lists.puredata.info/li...]
I was able to build and run the node addon yesterday using the master branch of libpd, but still had trouble loading the externals today. I had some undefined symbols errors on garray_class and s_signal. Compiling libpd with the MULTI=true option fixed these errors, now everything seems ok. Thanks for the hint !
Joseph
Le 13/02/19 à 16:18, Christof Ressi a écrit :
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" joseph.larralde@gmail.com An: "Giulio Moro" giuliomoro@yahoo.it, "Lucas Cordiviola" lucarda27@hotmail.com, pd-dev pd-dev@lists.iem.at 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 joseph.larralde@gmail.com[mailto:joseph.larralde@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~ <name_of_table>] 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%5Bhttps://github.com/ircam-jstoo...] 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%5Bhttps://github.com/libpd/libpd/wi...] 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[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
Pd-dev mailing list Pd-dev@lists.iem.at[mailto: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%5Bhttps://lists.puredata.info/li...]
Ooops, speaked too fast ... Everything SEEMED ok at first sight (no visible errors), but in fact the addon doesn't work when libpd is compiled with PDINSTANCE, it gets stuck at initialization time. And even without this (just using latest libpd), sometimes the tests pass and the sound is crappy (far too loud), sometimes they don't and fail with a segfault. But that looks more like a problem with the addon itself, and probably with node's API. I'll discuss this with Benjamin (the addon's author). I'll let you know when this is fixed (hopefully in a near future).
Cheers, Joseph
Le 16/02/19 à 12:46, Joseph Larralde a écrit :
I was able to build and run the node addon yesterday using the master branch of libpd, but still had trouble loading the externals today. I had some undefined symbols errors on garray_class and s_signal. Compiling libpd with the MULTI=true option fixed these errors, now everything seems ok. Thanks for the hint !
Joseph
Le 13/02/19 à 16:18, Christof Ressi a écrit :
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" joseph.larralde@gmail.com An: "Giulio Moro" giuliomoro@yahoo.it, "Lucas Cordiviola" lucarda27@hotmail.com, pd-dev pd-dev@lists.iem.at 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 joseph.larralde@gmail.com[mailto:joseph.larralde@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~ <name_of_table>] 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%5Bhttps://github.com/ircam-jstoo...]
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%5Bhttps://github.com/libpd/libpd/wi...]
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[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
Pd-dev mailing list Pd-dev@lists.iem.at[mailto: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%5Bhttps://lists.puredata.info/li...]