snapshot~ is to vsnapshot~ what line~ is to vline~.
Did you read the chapter of Miller's book which he linked to here?
On Saturday, March 14, 2015 11:55 AM, Alexandre Torres Porres
<por...@gmail.com> wrote:
moreover, [snapshot~] will also print 64 equal values of the last value in a
64 block even if the patch is running at a block size of "1", being this kind
of behaviour my biggest surprise that i point in this thread.
2015-03-14 12:17 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>:
> 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.
For snapshot, I know I ran proper tests as I was comparing it to vsnapshot~,
meaning that it wasn't constricted to the bang gui behaviour. So sending bangs
at every sample did only spit out 64 equal values of the last sample in the
block - whereas [vsnapshot~] can give a value for each sample.
cheers
2015-03-14 12:13 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>:
> 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.
cheers
2015-03-14 6:21 GMT-03:00 Peter P. <peterpar...@fastmail.com>:
* Alexandre Torres Porres <por...@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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
