there are other issues as well, which cause drop outs, that might be avoidable:
all this issues cannot be 'worked around' within pd, which makes pd sometimes not very suitable for presenting/live situations.
That's exactly what I meant in my previous message in the "pd evolution" thread. That is definitely something I have already heard before: that pd is not suitable or reliable for live/presentation. If a system which is entirely focused on REAL-TIME isn't suitable for presenting/live situations, then it is practically a prototyping tool as far as real-time is concerned!
I think that everything that causes dropouts (associated to action that are reasonably supposed to be done at "any time") should be considered a bug with high priority, if the words "real time" are not to be stripped off from the definition of PD. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Monitor LCD 17 160 - Cdr Memorex da 0,16 - Multifunzione Canon 63,94 - Stampa foto digitale da 0,06 Custodia dvd da 0,11. Questo e molto altro ancora su atomicshop.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6578&d=20070605
all this issues cannot be 'worked around' within pd, which makes pd sometimes not very suitable for presenting/live situations.
I'd be curious to know what happens when you try things like:
- using Jack in RT mode
- increasing buffer size
- using dual-core computer
- using "renice" on the pd process
Steve
On Tue, 2007-06-05 at 10:20 -0400, Stephen Sinclair wrote:
all this issues cannot be 'worked around' within pd, which makes pd sometimes not very suitable for presenting/live situations.
I'd be curious to know what happens when you try things like:
- using Jack in RT mode
- increasing buffer size
- using dual-core computer
- using "renice" on the pd process
this suggestions won't solve the mentioned problems for sure (besides increasing the buffer to a huge amount). since the problems arise withing pd itself, you cannot solve them by giving pd the highest priority. these suggestions do help, when switching workspaces cause drop outs for example or when any other software is disturbing the processing of pd. the problem is, that pd does *everything* in zero logical time, that is why reading/files can lead to dropouts: it is just not possible to read a 30MB file in no time. the solution would be to exclude these actions from the normal processing order of pd, so that pd can conitinue processing other objects without having to wait for the disk reading/writing object until the file is loaded completely.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
- using Jack in RT mode
- increasing buffer size
- using dual-core computer
- using "renice" on the pd process
this suggestions won't solve the mentioned problems for sure (besides increasing the buffer to a huge amount). since the problems arise withing pd itself, you cannot solve them by giving pd the highest priority. these suggestions do help, when switching workspaces cause drop outs for example or when any other software is disturbing the processing of pd.
but in pd, the audio and the gui are in separate processes:
$ ps -A f 6358 pts/0 Ss 0:00 _ bash 6368 pts/0 S+ 0:00 | _ pd -alsa -alsamidi 6369 pts/0 S+ 0:00 | _ sh -c TCL_LIBRARY="/home/ssteve/.local/li 6370 pts/0 Sl+ 0:00 | _ /home/ssteve/.local/lib/pd/bin/pd-gui
using renice on the audio process or running it in RT mode should indeed make a difference. (i'm talking specifically about Linux, but it should apply to other OS's as well.)
you could even try running the audio and gui processes on different computers.
for a performance environment, you could just discard the GUI and control everything through OSC remotely.
the problem is, that pd does *everything* in zero logical time, that is why reading/files can lead to dropouts: it is just not possible to read a 30MB file in no time.
I agree, I was only referring to the GUI-related problems. File reading could definitely benefit from being in a thread, I think this could be done in an external without too much difficulty. Though another idea is to load the file in chunks, so that only parts of it are loaded on each cycle, giving a chance for audio to run in between.
I'm not sure if readsf~ does this already.
Steve
Hallo, Matteo.sistisette hat gesagt: // Matteo.sistisette wrote:
That is definitely something I have already heard before: that pd is not suitable or reliable for live/presentation. If a system which is entirely focused on REAL-TIME isn't suitable for presenting/live situations, then it is practically a prototyping tool as far as real-time is concerned!
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.
CIao
Frank Barknecht _ ______footils.org_ __goto10.org__
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.
Agreed!
k
Frank Barknecht 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.
not really, it just proves, that some people know how to handle the problems, be it knowing about the limitations or just not caring about dropouts. a threadsafe soundfileloader for example would definitely improve the situation. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht 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.
not really, it just proves, that some people know how to handle the problems, be it knowing about the limitations or just not caring about dropouts.
Which doesn't contradict my statement that Pd is a suitable tool for live performances, otherwise these people in the know would use something else. (Pd also is a programming language, so part of the suitability for certain tasks depends on the quality of the programs written.)
My point is: We shouldn't make Pd worse than it actually is. Apart from Supercollider (and somehow Csound) 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. Pd throughout its 10-year history and with every major revision always was a usable tool for live performances (probably also thanks to Miller's conservatism when it comes to doing deep changes to the software). It's much more than just a prototyping tool, it always was a tool for practioneers.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
My point is: We shouldn't make Pd worse than it actually is.
My point is: We should make Pd better than it actually is. ;)
Good point. Lets not make Pd worse than it is, lets make it better.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, 2007-06-05 at 18:15 +0200, Frank Barknecht wrote:
Hallo, Matteo.sistisette hat gesagt: // Matteo.sistisette wrote:
That is definitely something I have already heard before: that pd is not suitable or reliable for live/presentation. If a system which is entirely focused on REAL-TIME isn't suitable for presenting/live situations, then it is practically a prototyping tool as far as real-time is concerned!
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.
hm... i said it is SOMETIMES not suitable for live situationst and i was defintely not talking about bugs. of course, i often use pd in live situations myself, nevertheless there are some severe issues, which are not just 'room for improvements', but essential for the working with pd. i consider these issues as severe, because they cannot be solved in pd space, so you just have to live with them.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Frank Barknecht -
Kevin McCoy -
marius schebella -
Matteo.sistisette -
Roman Haefeli -
Stephen Sinclair