Hallo, Piotr Majdak hat gesagt: // Piotr Majdak wrote:
I have a problem with the latency between some parts of my patches - some of them are delayed by 64 samples (=block size). I think I've created some [r~]s before other [s~]s, which would lead to this behaviour. But: I don't know which objects are affected and I've got more than 50 [s~]s and [r~]s ;-)
The structure of the signal path is something like that:
main patch "mypatch": [pd PLAY] [pd DAC]
subpatch "PLAY": [play sig1] [play sig2] ... [play sigN]
abstraction "play.pd": [readsf~] | | [s~ $1]subpatch "DAC":
[dac dac1] [dac dac2] ... [dac dacN] | | | | | | [dac~ 1] [dac~ 2] [dac~ 3] abstraction "dac.pd": [r~ sigX] | | [outlet~] (playX will be set in real time to the necessary signal sigX)Then, I want to start each of the readsf~ with different delays. To achieve that I use [1( with many [delay]s, with different delay values for each [readsf~]. Even if I quantize all delay values to the block size, I've got an additional delay of the block size on some channels, which only depends on the delay values and is not a jitter on DAC buffers!
One problem might be, that [del] is quantized to I think, 64 samples. You cannot go below that with a [del] object. You might try the t3 objects instead.
Is it possible to determine the order of [s~] and [r~] having a look to the patch files?
Yes, somehow at least. Take a long(!) look at doc/3.audio.examples/G05.execution.order.pd
Ordering involves using subpatches which force your objects to be in a certain dsp-ordering. Maybe dummy-connecting your PLAY and DAC subpatches as shown in the example file will already help in your case.
Ciao
Frank Barknecht _ ______footils.org__