RE: expanding array sizes and null references. I hope this helps... //start out with an generic UGen array (named myArray) with size 2 UGen myArray[2]; <<< myArray.size() >>>; //change size of myArray to 3, using interger object 3 => int newSize; myArray.size(newSize); <<< myArray.size(newSize) >>>; //Since (I believe) expanded arrays do not actually have the classed object in the new index, you have put a "new" reference in. for (0 => int i; i < newSize; i++) { new UGen @=> myArray[i]; SinOsc s; s => myArray[i]; } // This works as long as you have a uniform array of primitive UGens, as you are declaring NEW versions of that UGen (also filling in the new NULL array referneces). // This may be troublesome, as you would have to re-update previous the UGen parameters, since they replaced with NEW ones. Nick Hwang On Mon, Feb 3, 2014 at 11:18 AM, George Locke

wrote:

no dice.

1 => int choosePulse;

BlitSquare pls[10]; BlitSaw saw[10]; BLT osc[10]; if (choosePulse) { pls @=> osc; } else { saw @=> osc; }

produces a compile error at the "pls @=> osc" line:

[untitled]:line(7): cannot assign '@=>' on types 'BlitSquare[]' @=> 'BLT[]'...

[untitled]:line(7): ...(reason: --- incompatible types for assignment)

Perry's workaround is good enough, though.

- George

On Sun, Feb 2, 2014 at 10:37 PM, Zacko Belsch wrote:

...

I'm not sure whether the following is relevant or not.

Looking at the chuck source code (in ugen_stk.h), it appears the common superclass of BlitSaw and BlitSquare is BLT, not Blit. Would what you tried work if you used BLT for your common array instead of Blit?

Bob H

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users