[PD] Feature suggestion: pd non-realtime

[Miller Puckette]

... aah, nobody answered because it's such an important question...  I'm 
planning to add ANOTHER flag, like -nosound, but also disabling waiting for
the system clock (as Pd now does.)  At the same time I want to introduce
the modifications needed to allow Pd patches as VST plugins.  As it looks
right now that should appear in 0.37 (i.e., I don't want to break 0.36
open now that it mostly works..)

cheers
Miller

On Thu, Nov 14, 2002 at 01:04:46PM +0100, Krzysztof Czaja wrote:
> hi Johannes,
> 
> wonder, why nobody has answered yet?  If I am not totally out
> of my wits, than pd -noaudio does no good either, because in
> that case Pd's audio is synced to the realtime clock
> (gettimeofday on Unix).
> 
> Measuring with [bang~]->[t b b]->[realtime]->[number] may be
> deceptive.  If you look at an average of [realtime]'s output,
> then it will show 1.4 (at 44.1kHz).
> 
> In short, Pd is not suited for faster-than-real-time processing
> (yet? -- it takes just a few lines of code to make it), but otoh,
> it is perfectly suited for slower-than-real-time processing.
> 
> Krzysztof
> 
> Johannes Taelman wrote:
> ...
>  > ahem - wait a second - just started pd -noaudio and I can still turn on
>  > DSP and pd seems to process audio wihtout IO. Measuring the bang~-interval
>  > gives 0ms instead of reflecting the audio buffersize. The delay object
>  > also still delays everything in realtime. It looks like what I want is
>  > already possible as long as the patch does not use metro, delay or timer.
> 
> 
> _______________________________________________
> PD-list mailing list
> PD-list at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list