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

[Charles Z Henry]

This is the first time I've read the code for snapshot~ and
vsnapshot~.  I had expected that it runs a message routine during the
perform routine--and it does not.  You can't take the output of
snapshot~ and use it to affect the following sample with a blocksize
of 1.

Messages are blocking, and processed depth-first as I understand it.
That's why the infinite loop in Pd is so fatal to the process.

So, what if I made an external (however dangerous to patch) that does
trigger a float message during each perform routine?  What good is it?

One programming hazard:  I think with this external it would be
possible to run things out of order, so that some messages that occur
slightly sooner in logical time from an object like metro, wait until
the default dac block size occurs, and wind up running after all of
the messages that occur during the perform routines.

Part of what I'm missing is how the timed messages work.  I never
learned this completely.



On Sun, Mar 15, 2015 at 11:55 AM, Jonathan Wilkes via Pd-list
<pd-list at lists.iem.at> wrote:
> 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 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 <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 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. <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
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>