Object Orientaters, In languages like Java or ChucK, there are two OO ways to reuse code (besides copy-paste): by Inheritance: in this method, the class being defined is an elaborated version of the parent class (uses the extends command), like the way Orange is a special version of a Fruit by Composition: in this method, the class being defined is pieced together with instances of other classes, perhaps the way a Car class might be assembled with four instances of Wheel Now, if we wish to make a special version of a UGen by inheritance alone, we can already do this. By extending the UGen class you wish to use, you should be able to add or overwrite methods or variables. But what about composition? What if we wish to chain together several already useful into some compound effects object (for brevity's sake, perhaps)? public class StdFx extends UGen { //preconstructor PoleZero pz => NRev nrev => pan2 p; //dc filter - some STK synths need this pz.blockZero( 0.99 ); //no rev by default nrev.mix( 0.0 ); //random pan p.pan( std.rand2f( 0.1, 0.9 )); //omitted: controls for pan, rev, gain ... } This does the trick, basically. However, ChucK has no way of knowing that, to connect an object to StdFx, you connect its input to the PoleZero and the output from the pan2 into the output of this UGen. We must create a method to facilitate this: public void inOut( UGen in, UGen out ) { in => pz; p => out; } Which sort of breaks the flow in the calling program; sndbuf inst; StdFx stdfx; stdfx.inOut( inst, dac ); instead of just: snfbuf inst => StdFx stdfx => dac; So, to get the behavior we are going for in the language, it seems like the most direct way would be to specify an in and out reference for the correct UGens like so: public class StdFx extends UGen { //preconstructor PoleZero pz => NRev nrev => pan2 p; pz @=> this.in; p @=> this.out; //other stuff ... } So, will this kind of behavior be possible within the language as currently designed? I don't know. Most likely this behavior would stem from the implementation of Chuck_UGen::add( Chuck_UGen * src ) which is eventually executed by the VM on finding a => that resolves to a link operation. Offhand, we come up with two alternatives for producing this kind of behavior: 1. route link operations of a composite UGen in Chuck_UGen::add 2. some sample copying arrangement that would seem similar to linking So, what's the plan for supporting this? Graham