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

[Alexandre Torres Porres]

I did read, but I think how snapshot~ can't work in a block size of 1 is a
side issue.

But whatever restrictions it has, we do have [vsnapshot~] as a workaround.
Unfortunately, there's no help file yet to [vnapshot~]. Hopefully there'll
be one in the next update.

> couldn't [bang~] have a conditional where it schedules
>  more clock callbacks with the relevant timestamps?

yeah, right? couldn't it? why not?

cheers

2015-03-15 13:55 GMT-03:00 Jonathan Wilkes <jancsika at yahoo.com>:

> 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 <
> porres at 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 <porres at 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
> considerthat snapshot~'s role is to give you one audio sample from the
> audiostream. Since you will only receive messages in between audio blocks
> thelast sample in a vector is the one that is closest (in timing) to
> thepoint 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 <porres at 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 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.
>
>
>
>
>
> _______________________________________________
> 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/20150317/d3d936a7/attachment-0001.html>