[PD] timing question

[Claude Heiland-Allen]

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