Hi Mathieu,
 

There are three ways to get sample-accurate events :

 1. carry the event as part of a signal at the same rate as the audio.
    between apps, this could mean, for example, that you'd use an extra
    channel in jack for those events.

 2. carry the event as a message, then as the last step, convert it to a
    (sample-rate) signal for objects that can use that (for example, use
    a [vline~] plugged into [*~]'s right inlet)

 3. with objects (or aspects of objects) that just don't support
    sample-rate changes, you can use [block~ 1] if you can't find any
    sample-rate equivalent.

1. and 2. I don't understand how to approach (I'm on Win btw. but would like about functionality of Jack if it does something I can't do in Win).
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...

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't the jitter bothering you?
 
I made abstractions [lop2~] and [hip2~] as signal-rate versions of [lop~] and [hip~].

Your abstractions doesn't seem to be part of 0.42.5-extended? I couldn't find it with google search either... Where can I find it? And what method (1.,2. or 3.) did you use?
 
- my patch only accepts 64 - why?

If you use FFT, your patch has to know the block size, as a [fft~]-[ifft~] pair is like [*~] by the block size.

no  FFT yet 
 
- why does the $0-audioscope show extreme high amplitude when block~ size is <64 ?

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 ?)

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).
 
Does it do the opposite thing when you use bigger block sizes ?

I correct myself: it is ok in block~size 64 only, at any other size also higher sizes it shows the same giant burst.
 
- makes it sense at all changing block~ size in order to get better message timing? Or what is it for...

It's for several things :

 1. decrease to get more resolution
 2. increase to get more efficiency (of cpu)
 3. change to control the [fft~] window size (which is not controllable
    by its own parameters, unlike [fiddle~]'s window size
 4. when converting between different sampling rates, change
    proportionally to sample rate, to avoid having to split/merge blocks
    (this rarely matters at all)

i see. (well.. 4. I will understand one day I'm convinced ;)

thank you!
cheers
Dietrich 
 
 _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC