<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/14/2015 11:13 AM, Alexandre
Torres Porres wrote:<br>
</div>
<blockquote
cite="mid:CAEAsFmh3RxGmP4CJ58tQE0AViKqn5YyzxEVJPpD_yHHv7ikN-w@mail.gmail.com"
type="cite">
<div dir="ltr"><span class="im"
style="font-size:12.8000001907349px">> print~ will always
start printing from the beginning of a 64 block period<br>
</span><i><span style="font-size:12.8000001907349px">The same
here. Perhaps it helps to see print~ as the object that
gives</span><br style="font-size:12.8000001907349px">
<span style="font-size:12.8000001907349px">you one audio block
as numbers rather than an 'audio rate print' that</span><br
style="font-size:12.8000001907349px">
<span style="font-size:12.8000001907349px">does things faster
than message timing.</span></i><br
style="font-size:12.8000001907349px">
<div><i><span style="font-size:12.8000001907349px"><br>
</span></i></div>
<div><span style="font-size:12.8000001907349px">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.</span></div>
</div>
</blockquote>
<br>
[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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
-Jonathan<br>
<br>
<blockquote
cite="mid:CAEAsFmh3RxGmP4CJ58tQE0AViKqn5YyzxEVJPpD_yHHv7ikN-w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><span style="font-size:12.8000001907349px"><br>
</span></div>
<div><span style="font-size:12.8000001907349px">cheers</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-03-14 6:21 GMT-03:00 Peter P. <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:peterparker@fastmail.com" target="_blank">peterparker@fastmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">*
Alexandre Torres Porres <<a moz-do-not-send="true"
href="mailto:porres@gmail.com">porres@gmail.com</a>>
[2015-03-14 07:36]:<br>
<span class="">> It seems there are other objects that
somehow restrict themselves to a 64<br>
> size block minimum.<br>
><br>
> print~ will always start printing from the beginning
of a 64 block period<br>
</span>The same here. Perhaps it helps to see print~ as the
object that gives<br>
you one audio block as numbers rather than an 'audio rate
print' that<br>
does things faster than message timing.<br>
<span class=""><br>
> snapshot~ will always output the last sample from an
audio block of 64<br>
</span>This sounded strange at first to me, but it makes
sense if you consider<br>
that snapshot~'s role is to give you one audio sample from
the audio<br>
stream. Since you will only receive messages in between
audio blocks the<br>
last sample in a vector is the one that is closest (in
timing) to the<br>
point at which you receive the value in the gui.<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>