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