On 03/14/2015 11:13 AM, Alexandre Torres Porres wrote:
> 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.
[print~] will print the number of samples in the block size for your
canvas (or use the default size 64 if nothing is specified). So if you
have [block~ 1], [print~] will print a single value.
However, at [block~ 1] you won't be able to print out two _consecutive_
samples using consecutive bangs, no matter what you try. Instead you
must send a float to specify consecutive blocks. That is because Pd's
event scheduler is limited to firing events at the system block boundary
(where the system block is hard coded to 64). The [bang~] object is
constrained in the same way.
This gets confusing in the edge cases because, as I wrote in the other
thread, Pd's does internal timekeeping as if the event timings weren't
limited by anything except the double precision. So if you try to send
a bang every sample with [delay], measuring that delay with [timer] will
give you the result you expect, regardless of the block size. But the
moment you try to enter the signal domain (by sending to a signal
object), you run up against the reality that those events actually get
fired only on block boundaries.
However, an object like [vline~] calculates its ramps based off of the
precise values provided by Pd's event timekeeping. So even though two
bangs arrive on block boundaries, they arrive with the timestamps
specified by [del], [pipe], etc. That's why in tutorial C04 you're able
to take the metro all the way down to 1ms and the [vline~] signal path
will output the correct frequency.
I believe ChucK has a different design that doesn't have this underlying
timing constraint I'm describing here. But it's unclear to me how
valuable that would be in practice. Even if you could [bang~] every
sample and convert back to a signal every sample, a chain of control
objects of any complexity is going to be inefficient due to overhead of
the message dispatching system. (After all if it were efficient there
wouldn't be much need for signals.)
-Jonathan
cheers
2015-03-14 6:21 GMT-03:00 Peter P. <peterpar...@fastmail.com
<mailto:peterpar...@fastmail.com>>:
* Alexandre Torres Porres <por...@gmail.com
<mailto: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
