[PD] timing question

[Derek Holzer]

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

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 42:
"Destroy
-nothing
-the most important thing"