Hello,
With regards to the block limit thread and the following previous discussion [1], I have a question regarding event timing resolution in Puredata.
In the previous email thread, it was noted:
What is also interesting, is that i get the double value of 2.9 msec for blocksizes above 64, for example 65 and above. There are no adc~ or dac~ objects or any subpatches in this setup.
Does this mean that the resolution of a bang is in *multiples* of
1.45msec?
For example:
the event actually be sent, rendered, and perceived to occur every 8msec or will it be rounded up to the next block ( #6 ) at 8.7msec? 2. If an event is scheduled to occur every 1.50msec, will it be scheduled in time every 1.50msec or every 2.90msec?
I've read the pertinent section of Miller's "Theory and Technique of Electronic Music", but I guess this is one small bit I'm still hung up on.
Thanks, ~Brandon
[1] - http://lists.puredata.info/pipermail/pd-list/2009-01/067255.html
brandon zeeb wrote:
Hello,
With regards to the block limit thread and the following previous discussion [1], I have a question regarding event timing resolution in Puredata.
In the previous email thread, it was noted:
What is also interesting, is that i get the double value of 2.9 msec for blocksizes above 64, for example 65 and above. There are no adc~ or dac~ objects or any subpatches in this setup.
Does this mean that the resolution of a bang is in _multiples_ of 1.45msec?
For example:
- If I am attempting to send a message every 8msec (5.51 dsp blocks),
will the event actually be sent, rendered, and perceived to occur every 8msec or will it be rounded up to the next block ( #6 ) at 8.7msec? 2. If an event is scheduled to occur every 1.50msec, will it be scheduled in time every 1.50msec or every 2.90msec?
I've read the pertinent section of Miller's "Theory and Technique of Electronic Music", but I guess this is one small bit I'm still hung up on.
It averages out to the interval you specify (as long as the interval is longer than an audio block), but time is quantized to the duration of an audio block, because messages are sent at the end of the audio block during which they logically occur. So in case 1 you would get a sequence of 5 and 6 block intervals that averages out to 5.51. If your message rate is faster than the sample block rate you get multiple messages arriving at the same time.
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
If your message rate is faster than the sample block rate you get
multiple messages arriving at the same time.
But still each of these messages "knows" its own distinct scheduler time and can tell that time to a signal object that asks for it, like [vline~] does, which then can delay each of the messages accordingly. In the end, even the messages that arrive in the same block may trigger signal actions at different times.
Frank
i'm still at a loss to explain the effects observed in the attached patch:
Hallo, brandon zeeb hat gesagt: // brandon zeeb wrote:
For example:
- If I am attempting to send a message every 8msec (5.51 dsp blocks), will
the event actually be sent, rendered, and perceived to occur every 8msec or will it be rounded up to the next block ( #6 ) at 8.7msec?
If you send the message from a clock-object like [metro] it will be sent every 8 msec. "Rendered" and "perceived" are ambigous terms here that don't have much value without additional info on what exactly you mean by them (best do a patch).
- If an event is scheduled to occur every 1.50msec, will it be scheduled in
time every 1.50msec or every 2.90msec?
It will be scheduled every 1.5 msec. Or rather, it will be scheduled whenever Pd thinks it has time to schedule it, but you can depend on it to "happen" every 1.5 msec of Pd's internal scheduler time, not at some other time.
Pd has an internal clock, which is what drives [metro], [delay], [pipe], [timer] and some other objects. This "clock time" is as accurate as the resolution of numbers in Pd is (32 bit) and it is not quantized to any blocks.
However the difficulties start as soon as you convert from messages to audio signals (and back). Most dsp objects in Pd operate on block boundaries, so they are quantized.
For example if you try to build a fake phasor~ from a [line~] object and a fast [metro], the frequency will jitter around the block size.
Often this doesn't matter (because you'd use a phasor~ anyway), but if it should matter, you have to use one of the special audio objects that correctly interpret clock-messages without any block quantization. Instead of [line~] you just use [vline~] and your fake phasor~ will be perfectly in tune.
You don't need to do anything special when just dealing with messages without conversions to dsp. Note that events coming from the GUI (mouse clicks) are quantized to be read every 64 samples.
Frank