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