o 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...
>>>>
.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="u
eb 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-de
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-140
om: 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:
+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"
>
bol, 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
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
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
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
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
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 -
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
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
14 matches
Mail list logo
