On Tue, Feb 17, 2009 at 2:24 AM, marius schebella marius.schebella@gmail.com wrote:
hey hans,
if it's called "extended" and you strip it down to the bare bones, then where's the extended part? Do I understand you correctly that you want to restructure the whole library mess? maybe you should just go for one big lib called extended then, that includes everything that is not really related to special libraries like gem or pdp. I would support a public decision making process that votes nameclashing objects in or out to extended. but the most important thing is to document what's inside. then people can reference to that set of object classes and deal with exceptions.
eventually, I think users should not have to bother with namespaces at all. I still consider namespace declarations in a visual dataflow programming tool to be a hack.
btw, does the number of loaded libraries/object classes influence the startup time of patches?
Yo - So, I hear everything you're saying about simplicity and ease of sharing. But, I did test this, and if I remember correctly, measured a very, very significant difference in the speed of loading large patches after removing the 40+ search paths included by default with Pd-Extended. I'm sorry I don't have those results recorded - I thought it was a known issue and thus did not record things meticulously (but I think I might have jotted down the stats in a previous message in the archives). To the best of my memory, it was on the order of 2 minutes (which still sucks) versus over 10 minutes (which is just intolerable).
So, for that reason alone, I think it's extremely worthwhile creating a working namespacing system for Pd.
Two points: I don't think anyone discovers new objects by typing random words into object boxes (which would be an argument for making sure that as many of those random words turn magically into boxes as possible). I think most discover them by browsing the help system or reading others' patches. In both of those cases the declare/import system would be a very small cognitive load (since, in browsing the help, you're clicking on the names of the libraries to see the objects, and if everyone was using the namespaces, you'd see the [declare]/[import] in the patch right next to the object you're discovering).
There's the other issue of a lack of organization in the Pd-Extended collection - everyone has their own corner and it's a very rare library like [list-abs] that actually aims to collect objects around a common task. But, if we imagine a future where we do manage to get things organized by function rather than author (like Pd-MTL has begun to do), I think namespaces will become valuable - and we might as well get the functionality right now so we can begin to realize that future.
Finally, I think this: sure, Pd is an amazing language for beginners. It was the language that brought me personally from begin a dabbler in coding into a full-time constructor. But, there are unique things about Pd that have kept me (and, as I've seen, many extremely intelligent, capable and talented polyglot programmers like say, IOhannes, Mathieu, Thomas Grill, or Miller himself) using it. Such as: its realtime nature, the seamless melding of GUI and code, and the beauty of seeing your code as an image rather than piles of text. And most of all, its community, which leads me to yet another point in this speech : )
Perhaps I'd find certain things easier in other languages, building the size of applications that I'm building: maybe they'd be more stable, and use less memory, and start faster. But I am a composer, and these applications would be for the exploration of sound. And I'd find no inspiration for these explorations in any of those "serious" languages. I'd rarely find people doing cutting edge sound processing or generative composition, nor would I get to play with nearly as many audiovisual art pieces that often send me off implementing a new module in my system. Pd is a unique place where the cutting edges of programming and sound and composition are cutting each other.
*** INTERMISSION ***
Judging by the fact that I /have/ built my applications in Pd, and that they work 90% of the time, I'm convinced that Pd is extremely close to being an excellent language for the entire gamut of ambition. I think rather than making excuses for it, we should finish the job.
Finally, as a funny way of expressing my love: I don't think anyone is downloading Pd-extended right now and speeding off into sound dream land... anyone savvy enough to dig through the beautifully disheveled treasure trove of Pd-extended can probably handle the concept of declaring which libraries they'd like to use in their patch.
But anyway, that can always be resolved by offering a "Pd-EZ" that loads everything, alongside the newly rigorous Pd-extended. I just think that arguing against the whole initiative of namespaces within Pd is being unnecessarily pessimistic about its future and potential sophistication.
So, sorry about the length and in-eloquence of my homily (it's late and I'd need much more time to boil that all down : ) ), but I think most of my thoughts are there.
Best Luke
marius.
2009/2/16 Hans-Christoph Steiner hans@eds.org:
Hey,
Right now, Pd-extended is loading a lot of libraries by default. Most people never used most of those libraries, so I think it makes sense to reduce that number to move towards the goal of having the library loading embedded in the patch itself.
So the question now is, which libraries should stay in for now, to ease the transition? Here's the current list in the order they are loaded:
Gem cyclone zexy creb cxc iemlib list-abs mapping markex maxlib memento mjlib motex oscx pddp pdogg pixeltango pmpd rradical sigpack smlib toxy unauthorized vbap pan freeverb hcs jmmmp ext13 ggee iem_anything flib ekext flatspace pdp pidip
I think it should be something like:
cyclone zexy creb iemlib ggee iem_anything flatspace
Or does it even make sense to do it in stages?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev