[PD] poor performance when saving an abstraction when many copies are loaded in a patch
chris at mccormick.cx
Fri Jan 11 01:27:39 CET 2008
On Thu, Jan 10, 2008 at 02:42:12PM +0100, matteo sisti sette wrote:
> Yes of course. I didn't mean to criticize your suggestion: I meant to
> "criticize PD" that makes that suggestion necessary.
> Of course that IS a valid workaround in a lot of situations where the
> use of abstractions is not very extensive; it is just not feasible
> when you're developing some complex large scale application that you
> need also to mantain or further develop in the future.
Here are some other reasons why you might not want to use Pd to develop
a large scale application (and why I won't call Pd a 'programming
* No hash/map/table type, or array type that holds anything except floats.
* No strings.
* No introspection.
* Dynamic patching is unsupported, hacky, and occasionally buggy.
* Audio processing is hard coded into it instead of being supported by the
core language as a library like in 99% of other programming languages.
* It's not easily portable to embedded systems without many modifications.
* Inconsistencies in the syntax as discussed many times on this list
* Lacking some other useful programming constructs.
It's great to use Pd for what it totally rocks at: making interesting
graphics and music, but I wouldn't encourage it to be used as a general
purpose programming language, because it simply isn't good enough at
There have been [code] patches submitted in the past to rectify some of
the above points, but Miller doesn't seem to be interested in turning
Pd into a general purpose programming language, which is probably a good
idea since it's so good at what it does already, and doing that might
ruin it completely.
Long live Pd, the greatest and most fun audio visual mangling tool I
More information about the Pd-list