Hi List,
I have a question about converting control messages to signal
messages that I thought about after reading a recent thread about
triggering sounds made from [osc~].
I recently tried a simple test to see if I could generate audio
using a [del] metronome, a counter, and [sin] in a subpatch with
[block~ 1]. However, I ended up with a kind of staircase signal that
resembles a sine wave, where each step is 64 samples long.
Does this mean it's not possible in Pd to
convert control messages to audio faster than however long it takes to
play a 64-sample block? I (think) I understand why this is true for a
normal canvas with the default blocksize 64, but not for the subpatch
where I've reset the block size to be smaller.
-Jonathan
On Wed, 2010-12-08 at 14:33 -0800, Jonathan Wilkes wrote:
Hi List, I have a question about converting control messages to signal messages that I thought about after reading a recent thread about triggering sounds made from [osc~]. I recently tried a simple test to see if I could generate audio using a [del] metronome, a counter, and [sin] in a subpatch with [block~ 1]. However, I ended up with a kind of staircase signal that resembles a sine wave, where each step is 64 samples long. Does this mean it's not possible in Pd to
convert control messages to audio faster than however long it takes to play a 64-sample block? I (think) I understand why this is true for a normal canvas with the default blocksize 64, but not for the subpatch where I've reset the block size to be smaller.
Yeah, it is possible and no, you don't need to adjust the block size of the canvas. Setting the block size can be useful for implementing short audio signal feedbacks and for FFT operations where you sometimes need even bigger block size. The case you describe here is about message to signal conversion which should generally work without adjustments to block size. First, you need a metro that is faster than the 1ms-limited [metro], so your [del] based metro should do. [del] and [metro], both are able to schedule messages in between of blocks, but not all object classes with control inlets and signal outlets take that scheduled timing into account. For instance, [sig~] updates the audio signal only at block boundaries. OTOH, [vline~] uses this timing information to create sub-sample accurate signals (sub-sample accurate means here that a ramp might start and end between samples). I assume, you're now using a [sig~] for the conversion. Try replacing it with a [vline~] and it should do.
I am too lazy to test right now, so I hope everything I said is correct.
Roman