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;
On 08/11/13 23:26, Alexandre Torres Porres wrote:
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~].
yes.
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.
no.
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 you are experiencing is the signal-equivalent of "fan-out" in message-domain: in msg-world, if you connect a single outlet to multiple inlets, the order of execution is undefined, so you MUST use trigger. this is not a problem with DSP-objects, as the order of execution in a fan-out situation can be evaluated at DSP compile time. but if you have "implicit connections" (e.g. using [s~]/[r~]), the DSP graph cannot be evaluated in a well-defined way.
fortunately, Pd offers a solution (just like the [trigger] for messages): use subpatches connected with dummy inlet~/outlet~s to force the order of DSP execution.
e.g.
the following might introduce a 1-block-delay between the input to [s~] and the output from [r~], depending on which part of the DSP-graph is evaluated first.
[r~ bla] | [dac~]
[osc~ 440] | [s~ bla]
which can be fixed using subpatches with dummy inlet~/outlet~s: pd A: [inlet~] dummy inlet
[r~ bla] | [dac~]
pd B: [outlet~] dummy outlet
[osc~ 440] | [s~ bla]
and then do: [pd B] | [pd A]
which will guarantee that the contents of [pd A] is executed after [pd B].
fgmasrd IOhannes
-
Alexandre Torres Porres -
IOhannes m zmölnig