[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