thank you guys for your answers!<div><br></div><div>I think I understand the basic theory.</div><div>Experience is something else... e.g.</div><div>line~ and metro doesn't work sample correct even in block~ size 1</div>
<div>vline~ doesn't work in block~ sizes <64</div><div><br></div><div>And even thresholds fastest response is 64, less block size doesn't increase it's quality. I'm baffled because I understood this object as gateway from audio back to event (sample count/analysis to trigger)...</div>
<div><br></div><div>Anyway. I'm too focused I'm afraid. There will be a lot other possibilities.</div><div><br></div><div>thank you for clarifications so far!</div><div><br></div><div>best</div><div>Dietrich</div>
<div><br><div><br><br><div class="gmail_quote">2010/12/22 Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, 2010-12-22 at 09:01 -0500, brandon zeeb wrote:<br>
> If Pd's default block size is 64 samples, and "events" are only<br>
> processed at the beginning of a block cycle.<br>
<br>
</div>Not true. Events a.k.a messages are 'virtually' [1] processed at any<br>
time (literally any time, which includes any time between samples. The<br>
only restriction is the resolution of the 32bit floating point number<br>
format used by Pd).<br>
<br>
This can be easily shown with this little patch:<br>
<br>
[metro 3.1415]<br>
|<br>
[t b b]<br>
| |<br>
[timer]<br>
|<br>
[3.1415\ <- number box<br>
<br>
You can change the metro to any value and [timer] will report back<br>
exactly that value. AFAIK, this exact timing occurs as long we're<br>
considering the message-only domain.<br>
<br>
However, there are some objectclasses which accept messages at the<br>
inlets and produce signals at the outlets, e.g. [sig~]. Many (almost<br>
all?) of them only evaluate the messages _at_ block boundaries and thus<br>
the resulting signal can only be changed at block boundaries. This<br>
effect makes the messages look like they only happen at block<br>
boundaries, although they actually happen at any time.<br>
<br>
There are other objects that work in both, message and signal domain,<br>
which don't suffer from that problem: [vline~] and [vsnapshot~]. Both<br>
take the exact timing of the message into account.<br>
<br>
<br>
[1]: I say 'virtually', because Pd actually really computes one or<br>
several events only once per block, though is this done transparently<br>
when looking from the outside.<br>
<br>
<br>
Summary:<br>
<br>
* [metro] and [del] are as accurate as you can wish them to be.<br>
<br>
* Always use [vline~] when timing-exact conversion from message to<br>
signal matters<br>
<br>
* most tilde-classes with message inlets ignore the timing of the<br>
messages<br>
<br>
* You don't need lower block sizes for having exact timing in the<br>
message domain<br>
<br>
* Messages triggered from external sources (GUIs [bng]/[hslider] etc.,<br>
MIDI [midiin]/[ctlin] etc., networking [netreceive] etc., serial<br>
[comport], etc.) usually don't have more exact timing than the block<br>
size.<br>
<br>
Roman<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div><br></div></div>