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.