[PD] [gogins at pipeline.com: Re: [Csnd] Csound vs PD]

Krzysztof Czaja czaja at chopin.edu.pl
Thu Aug 16 13:15:35 CEST 2001


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...


Frank Barknecht wrote:
> From: gogins at 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.

More information about the Pd-list mailing list