On 03/16/2015 01:46 PM, Charles Z Henry wrote:
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?
It'd be something like vline~ but going in the opposite direction. But I
think there are problems with it. (See below.)
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.
[Warning: wrong things may lurk below. I'm still figuring out how this
works...]
They work off of clock callbacks. clock_set registers the timestamp in
a linked list, and before it fires the corresponding event it sets the
current time to that timestamp.
That way even if a dsp tick were somehow changed to last an entire day,
you could still get deterministic output out of the timing objects when
they fire at rates shorter than a day. For example, you could specify
delay times for printing out a message at breakfast, lunch, and dinner time:
[loadbang]
|
[delay 8 hours]
|
[breakfast time!(
|
[print]
[loadbang]
|
[delay 12 hours]
|
[lunch time!(
|
[print]
[loadbang]
|
[delay 18 hours]
|
[dinner time!(
|
[print]
In such a case of day long system blocks, all the messages would
unfortunately print out without any delay between them. But on the
bright side, the clock callback timestamps would ensure that you see
them print out in the correct order. Additionally stuff like [timer]
would output a value _as_ _if_ those delay objects had fired with the
timestamps you provided them.
Now, in that same day-long block system, from what I understand you
could use [vline~] to have ramps (or jumps) in the signal at the
relevant meal times. That's one of the reasons Pd's clock API is very
useful. Still, there's no way I know to get events to actually fire at
anything lower than the system block time. At least not without doing
your own timekeeping inside your external.
Anyway, if you make the external to output a bang inside the perform
routine, try it at [block~ 1], and measure the logical time between
outputs with [timer]. My prediction is that it will measure "0", which
is wrong. So I think you'll have to do the math inside the perform
routine to figure out what the delay would be given a block size below
64, and then use clock_set to output the bang with the relevant delay
specified.
-Jonathan
On Sun, Mar 15, 2015 at 11:55 AM, Jonathan Wilkes via Pd-list
<pd-list@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
<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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
