[chuck-users] zipper noise (++)

[Ge Wang]

Hi Kassen and all!

> "need" is a big word but if you would have a moment to spare I would 
> very much apreceate your thoughts on some of the issues around those 
> asignments of ugen's to array members.

The current specification for arrays of Objects is that each element is a
reference, like a non-array Object variable, can be treated as such.

For example, as you know:

   Object foo;
   Object @ bar;

At this point, both foo and bar is a reference variable to an Object, the 
only different being foo is referencing an instance of Object, whereas bar 
is referencing NULL at this point.

assignment:

   // assign foo to bar: both now point to the same instance
   foo @=> bar;

Going to arrays isn't really any different:

   Object fooray[10];
   Object @ barray[10];

fooray simply contains 10 references (each referencing at this point to 
newly allocated Object instances), barray also contains 10 references, but 
due to the @ declaration all elements are NULL.  Except for this 
difference, fooray and barray are the same: they both contain references 
to Objects.

If we want, we can assign references to the elements of fooray and barray:

   // assuming fooray.cap() == barray.cap()
   for( int i; i < fooray.cap(); i++ )
       fooray[i] @=> barray[i];

This above fills barray's elements with corresponding elements of fooray.

We can also assign new instances to fooray's elements and to barray's 
elements:

   // make a new Object (reference variable obj)
   Object obj;
   obj @=> fooray[0];
   obj @=> barray[2];

   // make a new Object
   new Object @=> fooray[4];
   new Object @=> barray[5];

The objects, in theory, are reference counted and garbage collected as 
appropriate.  In practice, the garbage collection system is not finished 
(completing it is actually the main goal, along with string manipulations, 
of the 1.2.0.6 release).  In the cases above, it actually works, I think.

In the case of UGens, it's no different really, except the @=> and => 
operators do completely different things.  As Perry explained:

   UGen foo;
   UGen bar;

   foo => bar; // connects foo to bar, as we all know
   foo @=> bar; // assigns foo to bar

In the 'foo @=> bar;' case, bar now references the same UGen as foo. 
What bar was previously referencing should have it's reference count 
decremented and be potentially garbaged collected.

Things get potentially kind of wacky is when we combine @=> and => into a 
single statement, like:

   // make an array (all elements == NULL, due to @)
   sinosc @ bank[N];

   // make new sinosc, assign it to bank[0], connect it to dac
   sinosc s @=> bank[0] => dac;

Like Perry wrote, this decomposes into the following lines:

   // make new sinosc
   sinosc s;
   // assign it
   s @=> bank[0];
   // connect bank[0] to dac
   bank[0] => dac;

The thing to remember is @=> always signifies assignment, => depends on 
the context.

And that's pretty much it.  I am actually still not sure if I answered the 
right question - please let me know...  Doh.  If this part of the language 
seems confusing, we can certainly try to improve it.

Best wishes, Kassen and all.

Ge!