Hi Claude,
OK, thanks for going into it a bit more. Makes sense to me, of course, but I'll have to chew on it a while and think of a way to communicate it without twisting up people's heads too much at too early a part of the workshops ;-)
Still, it is an inherent part of PD that you keep messages and audio separate. Thus the different graphical look of the patch cables, and the fact that it will not let you connect an audio cable to a non-audio object. There must be some reason for this, and speed of the objects is what I thought it was.
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Thanks, Zen-Master Claudius. Your quantum revelations still leave me wondering, however, what is the minimum time between two events which can be scheduled?
[delay 0] works.
I teach my students that the reason you can't send audio to "message" (i.e. non-audio) objects is that "message" objects run slower. While this may not be "logically" correct to many of the hackers that live on this list, it is a convenient way to explain the difference to artists just beginning in this world. Block size was the technical answer I gave.
You can send audio to message objects, eg: [tabsend~]. What you can't do is have a ( message -> non-clock-aware-audio -> message ) turnaround less than a block size, as all messages that can affect an audio block are computed before the audio block is computed.
Now that I know this is false, I need a new explanation. Plus I'd like to know what the limits of message processing speed are. In "real time", please.
Actually, "message" time is in advance of "audio" time, which is in advance of "real" time: a message sent to a [vline~] logically occurs in the future, compared to the time the [vline~] starts computing the particular audio block when the event will have occured, which is in the future compared to the "real" time when the audio plays. (Sorry for tense confusion, it's tricky...).
message computation happens before audio computation happens before audio playback
Pd has no notion of "real" time, only "logical" time, of which "audio logical time" is as close to real time as you are likely to get if you don't overload your CPU and cause dropouts.
The limit of message processing speed depends on how fast your CPU is compared to the messages you want to process. No CPU is fast enough to compute ( "bang"--[until] ) in a finite time...
Claude
BTW, I like how I can turn on [pix_write] and [writesf~] and have everything work in logical time (with very many dropouts) and the final video be in perfect sync with the sound. Using [gemhead] for sequencing the audio is kinda fun too, but I'm just afraid I'll get bored with 125bpm ;)
best, d.
Claude Heiland-Allen wrote:
Derek Holzer wrote:
Hi all,
Charles Henry wrote:
On Dec 17, 2007 3:03 AM, Frank Barknecht fbar@footils.org wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
> [metro 1] creates a bang each millisecond, approximately. The > message > rate is constrained by the block size, so you would want to put > [metro > 1] inside of a subpatch with [block~ 1] for best time resolution. That's not true. Message rate is not related to the dsp vector size.
My mistake. I thought messages had to run in between dsp blocks.
Someone please refresh/adjust my memory... what IS the message rate in PD? I also thought it was related to block size all these years. And how can it be changed if needed?
There is no fixed rate, it's event-based with continuous time (or as continuous as floating point numbers gets you). But - it works with "logical" time, any relationship to "real" time is purely a coincidence.
Claude