[PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

Jonathan Wilkes jancsika at yahoo.com
Sun Mar 15 01:21:28 CET 2015


On 03/14/2015 11:13 AM, Alexandre Torres Porres wrote:
> > print~ will always start printing from the beginning of a 64 block period
> /The same here. Perhaps it helps to see print~ as the object that gives
> you one audio block as numbers rather than an 'audio rate print' that
> does things faster than message timing./
> /
> /
> I also meant that it can't help but start from a 64 block boundary, 
> even if the block is less, such as "1", but I think that this is 
> because the bang button is always aligned to a 64 block tick, as I 
> pointed out later, so I may have to run other tests to see how 
> [print~] actually behaves with different size blocks.

[print~] will print the number of samples in the block size for your 
canvas (or use the default size 64 if nothing is specified).  So if you 
have [block~ 1], [print~] will print a single value.

However, at [block~ 1] you won't be able to print out two _consecutive_ 
samples using consecutive bangs, no matter what you try.  Instead you 
must send a float to specify consecutive blocks. That is because Pd's 
event scheduler is limited to firing events at the system block boundary 
(where the system block is hard coded to 64).  The [bang~] object is 
constrained in the same way.

This gets confusing in the edge cases because, as I wrote in the other 
thread, Pd's does internal timekeeping as if the event timings weren't 
limited by anything except the double precision.  So if you try to send 
a bang every sample with [delay], measuring that delay with [timer] will 
give you the result you expect, regardless of the block size.  But the 
moment you try to enter the signal domain (by sending to a signal 
object), you run up against the reality that those events actually get 
fired only on block boundaries.

However, an object like [vline~] calculates its ramps based off of the 
precise values provided by Pd's event timekeeping.  So even though two 
bangs arrive on block boundaries, they arrive with the timestamps 
specified by [del], [pipe], etc.  That's why in tutorial C04 you're able 
to take the metro all the way down to 1ms and the [vline~] signal path 
will output the correct frequency.

I believe ChucK has a different design that doesn't have this underlying 
timing constraint I'm describing here.  But it's unclear to me how 
valuable that would be in practice.  Even if you could [bang~] every 
sample and convert back to a signal every sample, a chain of control 
objects of any complexity is going to be inefficient due to overhead of 
the message dispatching system. (After all if it were efficient there 
wouldn't be much need for signals.)

-Jonathan

>
> cheers
>
> 2015-03-14 6:21 GMT-03:00 Peter P. <peterparker at fastmail.com 
> <mailto:peterparker at fastmail.com>>:
>
>     * Alexandre Torres Porres <porres at gmail.com
>     <mailto:porres at gmail.com>> [2015-03-14 07:36]:
>     > It seems there are other objects that somehow restrict themselves to a 64
>     > size block minimum.
>     >
>     > print~ will always start printing from the beginning of a 64
>     block period
>     The same here. Perhaps it helps to see print~ as the object that gives
>     you one audio block as numbers rather than an 'audio rate print' that
>     does things faster than message timing.
>
>     > snapshot~ will always output the last sample from an audio block
>     of 64
>     This sounded strange at first to me, but it makes sense if you
>     consider
>     that snapshot~'s role is to give you one audio sample from the audio
>     stream. Since you will only receive messages in between audio
>     blocks the
>     last sample in a vector is the one that is closest (in timing) to the
>     point at which you receive the value in the gui.
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150314/93959eb0/attachment.html>


More information about the Pd-list mailing list