I was just thinking about this:
Sometimes realtime is not important and even unpractical (realtime in the 1:1 time sense, not as in 'realtime priority'). For example when I want to prototype a certain audio-processing architecture (quick and dirty - just for proof-of-concept), but the processing is demanding more than the CPU can keep up with in realtime. Another case is batch processing audio-files which could run much faster than in realtime.
Practically this would (only?) imply that all audio IO is skipped, and the scheduler runs everything as fast as possible. All audio IO should be done with files (by using the regular sound file IO objects).
Does this sound useful to anyone else?
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. Cool!
regards, j#|@
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.
... 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@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi Miller and list,
From: "Miller Puckette" mpuckett@man104-1.ucsd.edu
... aah, nobody answered because it's such an important question...
I was afraid that I was the only one to consider it an important feature...
I'm planning to add ANOTHER flag, like -nosound, but also disabling
waiting
for the system clock (as Pd now does.)
That's the way I'd expect it to work.
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..)
This sounds like a GREAT plan! In the case of VST-plugging non-realtime would probably work 'out-of-the-box' by using the plugin in a batch processor, eg. cubase 'mixdown', wavelab 'apply' or whatever.
On Thu, Nov 14, 2002 at 01:04:46PM +0100, Krzysztof Czaja wrote:
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).
Right!
thanks all, j#|@
-
Johannes Taelman -
Johannes Taelman
-
Krzysztof Czaja -
Miller Puckette