Jim Hinds writes:

I'd like to learn from Eduard's example of "not working."  My conjecture is that the fan-out of the ugen whitenoise is only one, and that the last "chuck" operator (whitenoise => dac) un-chucks the previous line. That is, for a general ugen (or other chuckable object): fan-in == many; fan-out == 1.

Yes?

I'd think so, yes (I'm just learning as well). But, my understanding of the chuck dataflow is that any signal must must have a destination before it can be used. I discovered that when fooling around with a signal that I did not want to hear so I was not chucking it to dac. Therefore in eduard's example: WvOut waveOut; gain g; 0.9 =>g.gain; noise whitenoise; // variable whitenoise contains no signal // why? because it's not being 'sucked' to another ugen. 0.5 => whitenoise.gain; "/CHUCK/samples/test.wav"=>waveOut.wavFilename; whitenoise => waveOut; // ... so it cannot be recorded whitenoise => dac; 2::second => now; waveOut.closeFile; whitenoise =< dac; I maybe wrong about this but you can try this: adc => gain g; while (true) { 755::ms => now; <<< g.last() >>>; } and it will print only 0s. this, however: adc => gain g => dac; while (true) { 755::ms => now; <<< g.last() >>>; } will print the actual values. I presume that this the raison d'être for the balckhole ugen. I, too, would appreciate any corrections in my understanding. ./MiS