Andy Farnell wrote:
I noticed something similar on 0.40 (pure:dyne)
Something to do with DACs. I had a patch where the [dac~] I was adding or deleteing didn't have any correspondence to the signal it was (supposed to be) outputting.
i don't think it is related to [dac~].
take attached abstraction and put it into your searchpath.
create a new patch and turn audio on.
add an instance of [randosc~ a]: a value is printed to the console. add another instance of [randosc~ b]: the [env~] in [randosc~ a] starts to work and prints to the console; the [env~] in [randosc~ b] does not work.
or another example (empty your patch): add an instance of [randosc~ a]: a value is printed to the console. add a [dac~]; the [env~] is still not working connect the [randosc~ a] to [dac~]: you will hear a sine and the [env~] within [randosc~ a] gets evaluated and printed to the console.
so: when adding a new abstraction (that is not connected yet to any other object in the patch!), the dsp-tree gets re-evaluated _but_ the newly added object is not part of it! forcing the dsp-tree to re-evaluate (e.g. by turning audio off&on; or adding another object; or connecting to ~-objects) adds the abstraction to the dsp-tree and it starts working...
fmgasdr. IOhannes
#N canvas 0 0 450 377 10; #X obj 188 184 osc~; #X obj 177 42 loadbang; #X obj 186 61 random 500; #X obj 191 225 *~ 0.1; #X obj 186 154 t f f; #X obj 235 153 print randosc; #X obj 187 110 + 100; #X obj 317 249 env~; #X obj 327 304 print $1-env; #X obj 112 298 outlet~; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 6 0; #X connect 3 0 7 0; #X connect 3 0 9 0; #X connect 4 0 0 0; #X connect 4 1 5 0; #X connect 6 0 4 0; #X connect 7 0 8 0;