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.
I made abstractions [lop2~] and [hip2~] as signal-rate versions of [lop~] and [hip~].
If you use FFT, your patch has to know the block size, as a [fft~]-[ifft~] pair is like [*~] by the block size.- my patch only accepts 64 - why?
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 ?)- why does the $0-audioscope show extreme high amplitude when block~ size is <64 ?
Does it do the opposite thing when you use bigger block sizes ?
It's for several things :- makes it sense at all changing block~ size in order to get better message timing? Or what is it for...
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)
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC