On Sep 18, 2007, at 8:23 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo,
Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the "purepd" or list-abs collections).
as far as i have understood it, the standard library wants to
duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or
whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that follows from it)
They key difference would be that each stdlib would have a
standardized interface, and each objectclass would conform to that
interface. For example, there could be an 'io' standard lib.
Everything in that lib would respond to [open(, [close(, etc. in the
same way, the first inlet would behave similarly, and the first
outlet would be the data in the form of lists, and the second outlet
would be status info in the form of lists.
So no, I don't think we should just copy over existing code without
change. Instead, we should use existing code when it's useful, but
focus on having a clean and consistent interface for each library.
Then the old "author's name" libraries, like iem, zexy, ggee, etc.
would remain in place for backwards compatibility.
.hc
fma.dsr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste