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