[PD-dev] stripping down Pd-extended's default libs
dmotd at gmx.net
Tue Feb 17 17:14:37 CET 2009
On Tuesday 17 February 2009 22:29:10 Frank Barknecht wrote:
> IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
> > Frank Barknecht wrote:
> > >How does minimizing the number of "loaded libraries" affect the goal of
> > >storing preferences in patches?
> > depends on what you mean by "storing the preferences in patches".
> > one part of the preferences is the libraries to be loaded.
> > personally, i think it is a good thing to explicitely require libraries
> > in patches that need them.
> Yeah, but IMO one has nothing to do with the other. Just because a
> pd-extended user would be forced to manage preferences manually doesn't
> make [import] a builtin or makes everyone layout their patches and
> externals as Pd-extended does it neither lets it [declare] work in
> abstractions. So I don't see how a minimized set of libraries affects
> Personally I don't care what pd-extended loads and what not, but *if*
> minimizing libraries should be done, then I think no library should be
> loaded at all besides [import].
without having any real grasp of pd-extended (sorry, never used it), my
understanding is that [declare] and [import] may load libraries/objects
relative to the patch, but they are still loaded in memory and *will* override
the functionality expected in any patch loaded consecutively. without an
unload routine for external libs, or a method to restrict dynamic loading of
libs to the parent patch, then pd will still suffer nameclashes and aliasing of
default behaviour for any patch loaded thereafter.
i think this behaviour becomes even more confusing as the lib in question was
never explicitly loaded by the user.
please correct me if I am wrong or misguided!
More information about the Pd-dev