On Tue, 21 Dec 2010, Dietrich Pank wrote:
Audio - always sample rate clocked Event - any(!) time, even between samples Now I need to get to know and used to the clock and trigger "secrets" in pd. I want to work efficiently of course but also to be sample accurate if needed.
There are three ways to get sample-accurate events :
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.
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)
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~].
- 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.
- 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 ?)
Does it do the opposite thing when you use bigger block sizes ?
- 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 :
decrease to get more resolution
increase to get more efficiency (of cpu)
change to control the [fft~] window size (which is not controllable by its own parameters, unlike [fiddle~]'s window size)
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