[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

Frank Barknecht fbar at footils.org
Tue Sep 18 17:04:34 CEST 2007


Hallo,
Georg Holzmann hat gesagt: // Georg Holzmann wrote:

> As far as I undestood it the code of e.g. comport would go in this 
> standard lib (e.g. to hardware/comport) but should not duplicate the 
> code - instead the iem/comport code should be obsolete and now 
> maintained in hardware/comport.

Yes, that would be the idea for binaries in the std-lib.

> But as the others convinced me at the pd conv I don't think that this 
> will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)

Depends on how you define "this": I don't think that every external
has to move over to stdlib immediately, if at all. comport would be a
good example for an external that could stay outside the stdlib for
the next 8-10 years without any bigger problems, as it is an object
with a rather specific purpose. [drip] OTOH would be a candidate to
take immediately. The old build-system by Guenther ("flatspace" in
pd-extended) already showed the how the whole stdlib could be built as
far as externals are concerned, and abstractions are dead easy to
handle (as long as they are core-Pd-abstractions).

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__




More information about the Pd-list mailing list