[chuck-users] constructing UGens by composition

Graham Coleman gc at gehennom.net
Fri Sep 22 17:47:38 EDT 2006

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,

public class StdFx extends UGen {

  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 {

  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

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?


More information about the chuck-users mailing list