[PD] send~ and receive~ issues

[Piotr Majdak]

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


-- 
Piotr Majdak
Institut für Schallforschung
Österreichische Akademie der Wissenschaften
Reichsratsstr. 17
A-1010 Wien
Tel.: +43-1-4277-29511
Fax: +43-1-4277-9296
E-Mail: piotr at majdak.com
WWW: http://www.kfs.oeaw.ac.at