[PD] pd extended development

Roman Haefeli reduzierer at yahoo.de
Thu Apr 17 00:15:26 CEST 2008

On Wed, 2008-04-16 at 15:48 -0400, marius schebella wrote:

> how many nameclashes do we have? 20, 30? how many libraries are affected 
> 5? yea, that's what has to be done.
> the situation right now is worse than any solution with a default class. 
> because an object like urn is already problematic. a mentored 
> "quasi-official" pd-objectclass list would at least guarantee future 
> compatibility for the one class that would be considered the default. 
> and the other urns would have to be explicitely called with notdefault/urn.
> but that is exactly what needs to be done to prevent nameclashes. if you 
> don't do it, then you never will have compatibility...

how important is the portability between pd-extended and
pd-vanilla/externals considered? any solution, that involves the
[mylib/myclass] scheme creates patches, that are broken on a pd
installation with multiclass externals. 

not only this, but also for a patch dev it can be quite a pain to make a
patch work on both using [declare], because in one case you need
-stdpath and in the other -stdlib. in the end you are forced to use
always both for no good reason. 

i think it is not up to me to ask such questions, but wouldn't it be
generally better, if the multiple-class-per-external format would be
simply dropped? this would also have the nice side effect, that noone
would ever use aliasses anymore, which currently (and in the future?)
aren't fully supported.

from what i can tell, making a patch work exactly the same on extended
and vanilla adds quite some overhead. or is it only me, who would like
to create portable (between vanilla and extended) patches?


Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

More information about the Pd-list mailing list