[PD] Re: pure == slow, impure == fast ? was purepd
ix at replic.net
Sun Nov 20 01:25:01 CET 2005
> That's great! I've started a project I call "PurePd". Whenever I get
> inspired, I write a Pd patch that is a clone of a useful external. I
> just added it to abstractions/purepd and the build system. It would be
> great if you could contribute this patch as [list2symbol] and anything
> else that you can think of. I have a Max-style [counter], [speedlim],
> and even a [metro] in the works.
its a nice ideal, but i cant help but think we'd end up with something performing more like ruby than a realtime media system if 'everything is an abstraction' and the core just defined syntax. i mean the few times i rewrote things in pd - [hsv2rgb] and [sprintf] - they ended up about 10 times slower.. and thats not even dealing with a fraction of the bandwidth of audio or video..
maybe theres a way to byte-compile them down to get some of the performance back, a la .pyc or .elc...but that sounds more like a PhD project...
> I have also started writing objects in Pd that make writing objects in
> Pd much easier. Things like [float_argument] and [symbol_argument]
> which handle receiving arguments, and can distinguish between when the
> object is instantiated with an argument, and when it is not. Other
> ideas I have for patches in this genre are a debug objects that can be
> controlled locally or by a global send/receive. Also, I have been
> sketching out print_error and print_version objects.
> I need a new name for this second project now, since it makes sense to
> keep it distinct from PurePd. "libtools" comes to mind....
awfully reminiscent of 'libtool'.. i guess instead of libtoolize you could have libtoolsize, or PurePdIze, to instantly convert all your C objects into PD objects, and get the real-time gratification of a 80% performance loss..
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list