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;
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
