[PD-dev] generating the standard library: techniques
Hans-Christoph Steiner
hans at eds.org
Sat Apr 1 00:30:22 CEST 2006
On Mar 31, 2006, at 10:42 AM, carmen wrote:
>> So the question is, if we're going ahead to create this kind of
>> standard
>> libs for PD, what should they be written in?
>
> C
>
>>
>
>
>> If we want a lot of functionality fast then python seems like the
>> best
>> solution
>
> anyone can already use Python, Tcl Scheme, Guile, Ruby etc..
>
> it would be great to have bindings to all the POSIX stuff like fopen
> () etc , instead of semi-featured inconsistent frontends to a few
> pieces here and there like the [sprintf] external in cyclone or the
> [popen] external or bits of fopen() in soundfiler..maybe it can be
> generated with SWIG.. since stuff like python just hooks into the
> same things, i dont see why PD cant do it without a
> middleman..although maybe string/raw-bytes types and some better
> object-reference mechanisms would help? .. i have no idea how much
> work it would be (has anyone on this list implemented a standard
> library in a scripting language?)
Yes indeed, Pd definitely needs standard libs. I agree, they should
be written in C, but they can also be written in Pd whenever
possible. I don't necessarily think that POSIX is the best interface
for Pd, but I have no problem if someone wants to make a POSIX lib.
I think that would be a nice thing to have in addition to a more Pd-
ish set of libs to do strings/symbols, files, etc.
Right now, I am just writing some objects as I think of them, but my
plan is to start designing libraries that are coherently organized
with consistent interfaces and naming schemes. I think these new
libraries should ignore backwards compatibility, because we have
backwards compatibility if we just leave the existing code in place
as libdirs.
.hc
________________________________________________________________________
____
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
More information about the Pd-dev
mailing list