[PD] timing question

Derek Holzer derek at umatic.nl
Mon Dec 17 17:09:45 CET 2007

Sorry, I read this now and it sounds idiotic! Of course, I know why (one 
is programmed for DSP and one is not). But again, I thought the 
difference was that message objects were calculated slower, ie. at block 
boundaries, which in fact is the restriction of DSP objects! So now that 
I've been told that actually DSP objects are "slower", it shakes up my 
world view a bit, so I'm looking for new metaphors to get it back 
together ;-)


Derek Holzer wrote:
> This is all fine and dandy.
> But what about when they ask why they can't connect [osc~ 440] to [+ 1], 
> for example. Why won't PD let the connection get made? I.e., why can't 
> audio go to message objects?
> d.
> Frank Barknecht wrote:
>> Hallo,
>> Derek Holzer hat gesagt: // Derek Holzer wrote:
>>> 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 ;-)
>> Actually for workshops it's easy: A [metro 1] will send a bang every 1
>> msecs, regardless what's happening with audio. Nothing complicated
>> about that. In Max/MSP it's more complicated, as a [metro 1] may send
>> bangs with varying periods of not always 1msec. But Pd is easy.
>> Though, even in Pd, GUI messages are treated special: If you click on
>> a [bang( message, this will only be evaluated every 64 samples. But
>> you probably cannot click the mouse repeatedly with a constant 1 msec
>> period anyways, so it shouldn't matter.
>> The second thing, people need to learn then is, that most signal
>> objects can only be scheduled on block boundaries. So if you send a
>> new frequency to an [osc~] as a float message, the osc~ will not
>> respond immediatly, as it has already calculated the next block of
>> samples. So the new frequency can only be taken into account for the
>> next block after that. IIR block here means 64 samples always,
>> regardless of block~ size. But I may be wrong about that.
>> [vline~] is one of the few special objects which additionally can
>> "look into the future" and change it's value kind of in the middle of
>> a block (other objects like that are vsnapshot~ and Claude's wonderful
>> analogue-envelope generator - and I'm working on making the as of now
>> unreleased lua~/vessel~ external clock-aware, too). But this "see the
>> future" only works for messages, that Pd already knows about, and
>> these are messages that originate in a clock-based object like metro,
>> delay, pipe, etc.  Messages not coming from there, i.e. GUI messages,
>> cannot be known in advance of course. But as these are quantized to
>> 64 samples anyway, it doesn't matter most of the time.
>> Ciao

derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 77:
"Give way to your worst impulse"

More information about the Pd-list mailing list