[PD] isn't the GUI supposed to have lower priority than process?

[Matteo Sisti Sette]

Frank wrote:

> Just a note: Many people all over the world are using Pd in live
> performances, which proves that it is a suitable tool for this.
> That's it's not bug-free and has room for improvements is a different
> story.

And also:

> there is not a single piece of
> free software in its realm that managed to be the tool of choice for
> so many people for such a long time now


Now you make me feel like I have somewhat been criticising PD.  :$
That wasn't my intention.
I obviously love it, and use it, and choose it (every day of my life -lol-), 
so I do think it's the best around - or at least the best I've been able to 
find around.

And of course it is more than "usable" and "suitable" for live performance 
(though I must say that what many people do never proves anything).
I do use it for live performance (well, more precisely the people I work for 
use it for live performance, I use it at home and in their studio so that 
they can use it in live performance), and that's where my frustration comes 
from.

So what the hell was my point?

My point was that I do think that those issues which make it unsafe to use 
it in realtime (I revert to the realtime terminology because I think it is 
irrelevant whether it is a performance or a studio session: what is relevant 
is that you're doing something in real time and you have some real-time 
requirements) should be considered SEVERE issues.
So, the recent thread about evolution, future, and roadmaps came to my mind, 
and I just wanted to share (and submit to criticism) my opinion that I just 
can't imagine any roadmap that doesn't start with solving that kind of 
issues, since whatever the goal is, it passes thru solving them.

I am glad to see that many of you reacted with indignation when I insinuated 
that PD is a prototyping tool. That's the reaction I hoped to provoke. My 
point is that if we don't accept that PD is meant for prototyping (and I 
hope we don't accept it), then we should consider as a severe issue anything 
that prevents "trivial" or "common" or "reasonable" or "possibly desirable" 
operations to be performed in real time (with a decreasing degree of 
severity while ranging from trivial to possibly desirable).

"Severe issue" doesn't mean something that decreases our trust in PD, just 
something that shoud have a high rank in the to-do list.

Regretfully I can't contribute in any way, as my C/C++ programming skills 
are at the hello-world level.


Now just a note. Obviously it is just great that there exists a way to load 
a soundfile in zero logical time: if you do it at start up and don't care 
about the drop-out (inaudible on a zero output), it simplifies all those 
operations that need to be guaranteed to be done in a certain order. 
Changing the behaviour of sounfiler to threaded would be a disaster for 
backward compatibility, and the same goes for any object that suffers from 
similar limitations. Alternative threaded realtime-safe objects should be 
provided in those cases.


Regarding the question "who said that" (i.e. who said that pd is a tool for 
prototyping), I couldn't find the original source, but I found this in the 
list archive (obviously I take it out of its context):

On Wed, 21 Feb 2007 Kyle Klipowicz said:
> I recall a quote from Miller that paraphrased said something to the
> effect that Pd is like the bash shell in UNIX. You wouldn't write a
> word processor in a bash script, but it's great for rapidly
> prototyping a quick and useful solution. 

 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Fai squillare la PANTERA ROSA sul tuo cellulare: e' in REGALO
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6613&d=6-6