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

[Luke Iannini]

On Tue, Feb 17, 2009 at 2:24 AM, marius schebella
<marius.schebella at 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 at 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 at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>