[PD] declare vs. namespaces - current best practice

Alexandre Torres Porres porres at gmail.com
Sat Jan 6 04:04:58 CET 2018

ok, that changes things a bit.

It is still true that [declare] will prioritize to first load an object
from that specified lib (let's call it lib1), even if there's another one
(lib2) with the same object listed in the path. But this only happens if
none of these objects have been called before.

So this is still safe if you're sharing a patch to be first opened on its

Now, things get hard to control if you've forced to load the object from
lib2 beforehand, then try to load the other one from lib1 without a prefix
and trying to rely on [declare]. But this also depends wether it is an
abstraction or not, and, as I see it, that is inconsistent behaviour.

Not only that, but I could also ask wether this is more of an issue on how
Pd handles the object search than how [declare] works.

And to come back to my first remark here on this thread, if [declare]
cannot always force a priority, shouldn't it?

I would assume that's what it had to do.


2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig <zmoelnig at iem.at>:

> On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
> >
> > The compiled object from the lib listed in the path doesn't get called,
> and
> > the one specified in [declare] gets called instead.
> >
> repeat the test with two abstractions having loading libraries providing
> the same object.
> e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd
> uses a [gate] stub that prints "gate 2".
> load abs1.pd, after that abs2.pd (either manually, or by putting them
> into a master patch). observe the console.
> fgamdsr
> IOhannes
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180106/e20fb84d/attachment.html>

More information about the Pd-list mailing list