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@fastmail.com>:

* Alexandre Torres Porres <porres@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list