Hi,
here's a good question from the Csound list. CC'ing to csound@lists.bath.ac.uk would be nice.
----- Forwarded message from gogins@pipeline.com -----
From: gogins@pipeline.com Date: Tue, 14 Aug 2001 17:16:45 -0400 To: csound@lists.bath.ac.uk Subject: Re: [Csnd] Csound vs PD
What I meant is "out of real time." In other words, if there are too many instruments running to work in real time, so that a performance would experience dropouts, the performance can still be saved as a soundfile without dropouts, even if it takes, for exmaple, ten minutes to render a 2 minute piece.
csound@lists.bath.ac.uk wrote:
----- Original Message ----- From: To: Sent: Tuesday, August 14, 2001 7:35 PM Subject: Re: [Csnd] Csound vs PD
Thanks for your very informative reply. What you are saying is what I
thought would be the case based on just looking at PD after heavy use of Csound.
Is there ANY way PD can render to a soundfile out of real time?
YES. There are several objects which allow you to save the output to HD.
----- End forwarded message -----
/_/ _\
hi,
has anybody wondered if having just the opposite to what Michael Gogins wanted, ie. the possibility of faster than real-time rendering, would be worth making a simple, small and localized addition to m_scheduler() function. Like changing its nodacs flag-argument into a more general 'time_source' enum-argument, and providing a case of moving time forward as soon as all computations are done. But maybe nobody will ever use Pd in batch processing...
Krzysztof
Frank Barknecht wrote: [...]
From: gogins@pipeline.com
[...]
What I meant is "out of real time." In other words, if there are too many instruments running to work in real time, so that a performance would experience dropouts, the performance can still be saved as a soundfile without dropouts, even if it takes, for exmaple, ten minutes to render a 2 minute piece.
[...]
%%%%% % actually this one was then answered on Csound list:
Simon Kirby wrote [quoting Pd docs]: [...]
"If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this. "
This kind of behaviour is common among various real-time audio programs I've used. For example, in Buzz it is common to record a performance to disk while playing - even if there are loads of dropouts these do not show up in the resultant file.
this might already be the case... while experimenting with the pipewrite/piperead mp3 streaming and runnning with -nosound, pd occasionally seems to get progressively ahead of the stream... (latency increases with time).
it's possible that this is being caused by some other factor tho.
pix.
On Thu, 16 Aug 2001 13:15:35 +0200 Krzysztof Czaja czaja@chopin.edu.pl wrote:
hi,
has anybody wondered if having just the opposite to what Michael Gogins wanted, ie. the possibility of faster than real-time rendering, would be worth making a simple, small and localized addition to m_scheduler() function. Like changing its nodacs flag-argument into a more general 'time_source' enum-argument, and providing a case of moving time forward as soon as all computations are done. But maybe nobody will ever use Pd in batch processing...
Krzysztof
Frank Barknecht wrote: [...]
From: gogins@pipeline.com
[...]
What I meant is "out of real time." In other words, if there are too
many instruments running to work in real time, so that a performance would experience dropouts, the performance can still be saved as a soundfile without dropouts, even if it takes, for exmaple, ten minutes to render a 2 minute piece. [...]
%%%%% % actually this one was then answered on Csound list:
Simon Kirby wrote [quoting Pd docs]: [...]
"If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On
the
other hand, disk strewaming objects will work correctly, so that you
may
use Pd as a batch program with soundfile input and/or output. The
"-nogui" and
"-send" startup flags are provided to aid in doing this. "
This kind of behaviour is common among various real-time audio
programs
I've used. For example, in Buzz it is common to record a performance
to
disk while playing - even if there are loads of dropouts these do not
show
up in the resultant file.
-
Frank Barknecht -
Krzysztof Czaja -
pix