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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
