[PD] Dynamic search paths and [declare] behavior in Pd.0.47

[IOhannes m zmoelnig]

On 2016-05-08 23:21, Miller Puckette wrote:
> Meanwhile a "real" fix
> is needed...

i think the sensible way would be, if a library loaded via declare could
add paths (and load other libraries).


e.g. with Gem, there are abstractions and a single external:
~/pd-externals/Gem/Gem-meta.pd
~/pd-externals/Gem/Gem.pd_linux
~/pd-externals/Gem/gemwin.pd
i would like to be able to say [declare -lib Gem], and this would
- load the Gem.pd_linux external (so i can use [square])
- add the path-to-Gem (~/pd-externals/Gem/) to the (local) searchpatch
(so i can use [gemwin], without any prefix)

i currently do this by automatically adding the path-to-Gem to Pd's
search-paths. this works OKish, but has the side-effect that if the user
*then* saves their startup preferences, they will have the path-to-Gem
stored persistently; so the next time they start Pd (without Gem
loaded), they will still have path-to-Gem in their search-path; also if
they happen to load an other of Gem from a different path, they will now
have *both* paths-to-Gem in their search-path.
i think that this is something not applicable to all libraries (e.g.
when loading "mrpeach/packOSC.pd_linux" i probably do *not* want to have
the entire "mrpeach" path added to my search-path.

i also don't want the user to know/care, that "square" is an objectclass
that get's added when loading the Gem.pd_linux, whereas "gemwin" is an
abstraction that needs a "path" to be added and "gemglutwindows" is a
single-object-external that also needs a "path" to be added.
the user should just state that they want to load the "Gem" library package.


simlarily with la-malinette (and extended-view-toolkit and probably some
more frameworks) a single importing of the framework should add a
(configurable) number of paths.


i *think* that the best way to achieve this is to allow a
library/framework to run some code when being setup.
for me the obvious place would be the "-meta" file (Gem-meta.pd) which
has become the de-facto standard to add meta-information to a library.
in it's simplest form, Pd could just treat that meta-file special and
run the "declare" statements of the meta-patch when importing the library.
(a more advanced form would actually load (and loadbang) the meta-patch,
so it can run some real code)


currently the meta-patch is really only used by the "libdir" loader.
i guess it is possible to add the functionality described above to the
"libdir" loader as a first step.


fgamsdr
IOhannes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160509/8ee24905/attachment-0001.sig>