[PD] puredata evolution
Matteo Sisti Sette
matteo.sistisette at email.it
Mon Jun 4 21:44:25 CEST 2007
Hi,
PD is often said to be meant to be a tool for just prototyping.
It certainly had to be so when it was born but hey, nowadays, with the
available cpu power of average machines... don't you think that it is no
more necessarily so?
I'm curious: how many of you really re-code their pd patches into something
else when you're finished experimenting and you've reached a reasonably
"final" version of what you're patching?
I don't.
I put this under the thread of "pd evolution" because in my opinion, in my
wishes, in my personal vision of pd's future, one really important step
would be to assume it is no more a tool for prototyping but an environment
for developing final applications. I think pd-vanilla is the data-flow,
audio-oriented analoguous of an interpreted programming language. Ok, an
interpreted language is 1000 times slower than a compiled one, so, in the
case of applications requiring 100% state-of-the-art cpu power, it can only
be used for prototyping; however, for applications that require much less
computing power than is available, a lot of interpreted languages are used
for developing real-life applications.
IMHO there are just a couple of crucial things that need to be solved in
order to make that step in PD.
One is a few bugs that make your life impossible when you're developing a
somewhat "large" application (i.e. many abstraction, reused many times, and
nested, as is needed when designing a complex system either top-down or
bottom-up or mixed). Every time you hit CTRL+S, you're likely to be obliged
to close PD and restart it.
And the second is the GUI is tremendously slow.
I don't mind it may be somewhat limited if one wants to build arbitrary
interfaces. I just accept (and eventually love) pd's gui, with its bangs,
toggles, sliders, and the way they work; with appropriate programming (i.e.
patching) they are powerful (you can use them as display avoiding manual
changes, you can obtain multiple controllers of the same value that don't
loose their coherence etc etc).
I just take them as they are and as they work...
but the problem is: it's all so slow.
I can't believe it can't be faster and less cpu-expensive.
Reimplementing the CURRENT guy mechanism, without any change in its
"specifications", in a faster way would be imho an enormous benefit to those
who use PD as a developing environment. Because it would encourage rather
than discourage such practices as nesting GOP-enabled abstractions to
mantain complex interfaces manageable.
I don't know whether some of the aspects I describe are specific to the
Windows version, as I only use PD under Windows. However, coherently with
the idea of a reliable developing environment, if this environment is
supposed to be platform-independent, platform-specific issues should be
solved.
I'd love to hear other opinions about all this.
Bye
m.
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
In REGALO 'All the Good Thing' di NELLY FURTADO
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6617&d=4-6
More information about the Pd-list
mailing list