[PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

João Pais jmmmpais at googlemail.com
Mon Feb 23 00:12:17 CET 2009


>> I guess it never occurred to any of you to use objects with different
>> names...
>>
>> Or else why not just call every pd object "object" and then use
>> paths to
>> access them, like [pd/some/library/subdirectory/object]?
>>
>> Just kidding in a frustrated sort of way.
>
> Different names are a good idea, for sure.  But Pd should also not go
> down in flames if someone happens to create an object with a name that
> is already used somewhere.  Its not possible to know every single
> object that has ever been made.
>
> I just ran into this myself trying to create an abstraction called
> "beat".  Apparently, there is already a [beat], so I got unexpected
> results.

as I see it (if it matters), there are 2 pd distros, pd-van and pd-ext  
[although my view is that pd-ext should at some point assimilate pd-van -  
is there anyone out there that really sticks to pd-van, and doesn't use  
any externals, for other purposes than low-level educational ones?]. if  
there would be an updated documentation of pd-ext's content - and why not  
a "test-your-name" pdpedia page or external as well - it would be no  
problem to make sure these mistakes don't happen. my almost-recent  
(unefficient) efforts were to make an updated pd-ext object list, which  
could make clear what is available out there (maybe there wouldn't be the  
need to reinvent the wheel, or the counter), and also to avoid  
nameclashing. I can try to keep going at it, in order to keep people (and  
myself) informed of what's happening.

I guess pd won't come down in flames for nameclashing, but it has been  
happening for ever, and the only tactic to handle it was to ignore it,  
change the order some libraries were loaded or not load them at all, etc.  
Maybe it would be better just to stamp the foot down and try to sort out  
an efficient sollution for this? the problem won't go away, will just get  
worse, as the tendency is that more and more people will join the Pd army  
and write code for it (at least it's what we all expect, right?).




More information about the Pd-dev mailing list