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

[Alexandre Torres Porres]

> 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 givesyou
one audio block as numbers rather than an 'audio rate print' thatdoes
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.

cheers

2015-03-14 6:21 GMT-03:00 Peter P. <peterparker at fastmail.com>:

> * Alexandre Torres Porres <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150314/41b0b47a/attachment-0001.html>