[PD-dev] stripping down Pd-extended's default libs

[dmotd]

On Tuesday 17 February 2009 22:29:10 Frank Barknecht wrote:
> Hallo,
>
> 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
> anything.
>
> 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].
>
> Ciao

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!

ciao, 

dmotd