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 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