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

[Krzysztof Czaja]

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