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 <george.locke.maxmsp@gmail.com> 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 <zackobelsch@gmail.com> 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