Hi there,
IOhannes m zmoelnig wrote:
forget it...
the solution is order-forcing, as described in 3.audio.examples/G05.execution.order.pd
Thanks for your suggestions, it took some time to process them.
It was a heap of work and testing, but now I know definitively that I don't have any order-forcing problems.
It seems like [readsf~] or [delay] have some timing problems. I reduced my patches to something like that:
[bang( | | | | [delay X1] [delay X2] [delay X3] .... [delay Xn] [1( [1( [1( [1( [readsf~ 1] [readsf~ 1] [readsf~ 1] [readsf~ 1] [dac~ 1] [dac~ 2] [dac~ 3] [dac~ n]
(all delays are connected to the same bang!)
Assuming X1==X2==X3==Xn all dac~'s play synchronously. That's the good news.
Now let's set the delay to 140; 649.333; 789.333; 1300; 1440 (all these values are integer in block size units) and look at the outputs, relatively to the delay values. Channels 3 and 4 won't be delayed by 789.333 or 1300, but they will be played 64 samples earlier than expected. (Or all others 64 samples later).
Something really strange: just change a delay value (and don't forget to quantize it to 64 samples) and the situation will change: another channels will be played earlier. Unfortunetaly, I can't see any pattern.
Do you have an idea, what's wrong with readsf~ or delay?
regards, Piotr Majdak