Hi Mathieu,<br><div class="gmail_quote"><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There are three ways to get sample-accurate events :<br>
<br>
  1. carry the event as part of a signal at the same rate as the audio.<br>
     between apps, this could mean, for example, that you&#39;d use an extra<br>
     channel in jack for those events.<br>
<br>
  2. carry the event as a message, then as the last step, convert it to a<br>
     (sample-rate) signal for objects that can use that (for example, use<br>
     a [vline~] plugged into [*~]&#39;s right inlet)<br>
<br>
  3. with objects (or aspects of objects) that just don&#39;t support<br>
     sample-rate changes, you can use [block~ 1] if you can&#39;t find any<br>
     sample-rate equivalent.<br></blockquote><div><br></div><div>1. and 2. I don&#39;t understand how to approach (I&#39;m on Win btw. but would like about functionality of Jack if it does something I can&#39;t do in Win).</div>

<div>3. I tried as I already mentioned but there must be an error in my structure because the log window talks a lot of errors each time I try to change the block~ size...</div><div><br></div><div>Could you show me working examples finding and processing sample accurate timed events? How do you use sequencers? What about fast retriggering percussives or delay like effects - isn&#39;t the jitter bothering you?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I made abstractions [lop2~] and [hip2~] as signal-rate versions of [lop~] and [hip~].</blockquote><div><br></div><div>Your abstractions doesn&#39;t seem to be part of 0.42.5-extended? I couldn&#39;t <a href="http://www.google.de/#sclient=psy&amp;hl=de&amp;q=%22lop2~%22%20(pd%20OR%20puredata)&amp;aq=&amp;aqi=&amp;aql=&amp;oq=&amp;gs_rfai=&amp;pbx=1&amp;fp=9518358c6ae80f89&amp;pf=p&amp;pdl=3000">find it</a> with google search either... Where can I find it? And what method (1.,2. or 3.) did you use?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- my patch only accepts 64 - why?<br>
</blockquote>
<br></div>
If you use FFT, your patch has to know the block size, as a [fft~]-[ifft~] pair is like [*~] by the block size.</blockquote><div><br></div><div>no  FFT yet </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- why does the $0-audioscope show extreme high amplitude when block~ size is &lt;64 ?<br>
</blockquote>
<br></div>
Does it double amplitude when you halve the block size, or does it double amplitude when you quadruple the block size, or some other pattern ? (which ?)<br></blockquote><div><br></div><div>it shots out of screen limit, the scroll bar appears and is very small... so the value must very high. Look at it I attached it (you need to touch some controls of the audioscope in order to update correctly - I have a bug there).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Does it do the opposite thing when you use bigger block sizes ?</blockquote><div><br></div><div>I correct myself: it is ok in block~size 64 only, at any other size also higher sizes it shows the same giant burst.</div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- makes it sense at all changing block~ size in order to get better message timing? Or what is it for...<br>
</blockquote>
<br></div>
It&#39;s for several things :<br>
<br>
  1. decrease to get more resolution<br>
  2. increase to get more efficiency (of cpu)<br>
  3. change to control the [fft~] window size (which is not controllable<br>
     by its own parameters, unlike [fiddle~]&#39;s window size<br>
  4. when converting between different sampling rates, change<br>
     proportionally to sample rate, to avoid having to split/merge blocks<br>
     (this rarely matters at all)<br></blockquote><div><br></div><div>i see. (well.. 4. I will understand one day I&#39;m convinced ;)</div><div><br></div><div>thank you!</div><div>cheers</div><div>Dietrich </div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 _______________________________________________________________________<br><font color="#888888">
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC<br>
</font></blockquote></div><br>