[PD] now that we don't have user-settable global search paths in Pd-E 0.43

[katja]

Hello,

Since a few years I've been using Pd-extended 0.43 incidentally, and
since a few months I use it intensively. The discontinuation of
user-settable global search paths made me hopping around between
alternative solutions, finding out their pro's and cons by (sometimes
painful) experience. Don't get me wrong - I think the discontinuation
of user-settable global search paths was a good decision. Once you get
the best way to work around, it's much easier to share complex patches
including dependencies.

Initially I preferred the 'namespaces approach'; organize abstractions
in folders and instantiate them like you can instantiate objects as
[cyclone/svf~], [zexy/limiter~] etc. Sometimes however I felt the need
to reorganize folders with abstractions or homebrew externals. Such
reorganization forces the namespaces in patches to be refactored. Not
good!

Then I tried [import] and [declare] instead. I settled on [declare]
because it is vanilla Pd, the most flexible approach for all sorts of
situations. Fortunately, [declare] doesn't report an error if a path
is non-existent, so you can give several options to cover various
situations if so desired. I include my home brew binaries and
abstractions in subdirs of a project dir, and point to them from the
main project patch with [declare -path bin], [declare -path
abstractions] and so on.

But ow!... with all the namespaces removed I suddenly recalled what
makes namespaces so useful. Some classes exist in more than one
library. A notable example is [pow~]. There's one in vanilla / Pd core
and one in cyclone. Both used to have their exponent and mantissa
inlets swapped as compared to [pow]. Somewhere in the Pd 0.43 series,
vanilla's [pow~] was refactored to have it's inlets matching the [pow]
format. So it became incompatible with Pd 0.42, while [cyclone/pow~]
was still compatible with Pd 0.42 and 0.43.

Namespaces are also very useful if you have collections of
abstractions which you never share but only use for development
purposes. For example, I have collections of oscilloscope abstractions
and small math utilities. They are stored in their appropriate subdirs
on one of the default location as mentioned here:

http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files

So I can instantiate something like [scopes/scope2~] to quickly check
two signal waveforms without including the path in the patch itself,
and the object must be removed before the patch is shared.

After struggling with Pd search paths for many years, I'm finally
starting to get a grip on it. Thanks to / forced by discontinuation of
user-settable global paths. No matter how, I guess this will remain
tough matter for Pd beginners.

Katja