[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