Hi there, I was making some tests and saw that the order that you make
audio connections or create tilde~ objects make a difference, and this
affects when we're using [s~] / [r~].
The idea I had is that no matter what was going on, the sends and receives
would ALWAYS be in sync with the audio conenction cords, meaning there
would be no delay whatsoever. But that's not true, so I suspect this is
some sort of a bug that should be noted.
check the following patches, they are the same, but one is "ok" (where the
audio is cancelled) and the other "not ok" (where it isn't). The only
difference is the order that the objects were created and connected.
I, for one, would like to live in a Pd world where it'd always be "ok" no
matter what... cause if we have these delays, it ends up being really bad,
right?
what about you people? And is this too hard to "fix"?
cheers
The patches:
*
*
*"OK"*
#N canvas 223 59 450 300 10;
#X obj 99 162 -~;
#X obj 90 198 dac~;
#X obj 242 85 loadbang;
#X msg 242 114 \; pd dsp 1;
#X obj 114 111 s~ \$0-osc;
#X obj 114 133 r~ \$0-osc;
#X obj 99 73 osc~ 440;
#X connect 0 0 1 0;
#X connect 0 0 1 1;
#X connect 2 0 3 0;
#X connect 5 0 0 1;
#X connect 6 0 0 0;
#X connect 6 0 4 0;
*"NOT OK"*
#N canvas 223 59 450 300 10;
#X obj 99 73 osc~ 440;
#X obj 99 162 -~;
#X obj 90 198 dac~;
#X obj 242 85 loadbang;
#X msg 242 114 \; pd dsp 1;
#X obj 114 111 s~ \$0-osc;
#X obj 114 133 r~ \$0-osc;
#X connect 0 0 1 0;
#X connect 0 0 5 0;
#X connect 1 0 2 0;
#X connect 1 0 2 1;
#X connect 3 0 4 0;
#X connect 6 0 1 1;