[PD] pd extended development

IOhannes m zmoelnig zmoelnig at iem.at
Thu Apr 17 09:48:55 CEST 2008

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

> 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. 

at the beginning of this discussion (probably 2002 or so; i have no 
idea) i posted a diff for Pd that would allow this: using 
[mylib/myclass] after loading the multiclass-library "mylib" containing 
the class "myclass".

the patch never got accepted (iirc, the arguing was that nameclashes 
have to be solved on a social level rather than on a technical one)

> 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.

i think "generally better" would be to drop external support entirely 
from Pd; this would reduce nameclashes a lot; i don't know how to solve 
nameclashes of abstractions (without dropping abstraction support), but 
one idea would be to just not distribute any collections (like 
Pd-extended) anymore, and make the problem a _private_ one.

but i think we all agree that this is not going to happen.

anyhow, feel free to make Gem a single object per file library :-)


More information about the Pd-list mailing list