[chuck-dev] fixed array compatibility checking (PATCH)

[Robin Haberkorn]

btw.

1st) I see many places in the ChucK code where null pointers are checked
like this:
if( pointer )...
This is a common mistake since the null pointer does not necessarily
have to be 0. That's one of the reasons why there is a NULL macro which
may be defined differently (by the operating system or a specific
compiler). If I recall correctly it's even a Linux kernel build option.
So instead it should read
if( pointer != NULL )

2nd) There have been significant changes on LiSa in ChucK v1.3.0.0 which
are completely undocumented and not even mentioned in the change log.
For once, it mas been made a multi-channel UGen (8 output channels for
whatever reason), breaking existing ChucK programs.
E.g. LiSa l => Gain g => dac;
l's channel 0 is not chucked to g. You must do that explicitly.
Could you tell me why it has been made a multi-channel UGen? I don't see
how you can record multi-channel samples, set the number of channels
used by a sample, etc.
I will have a look at LiSa code next since it appears to be really
really slow. So slow that a bank of 7 LiSas (not doing anything!) in my
UGen graph completely swallows all of my remaining DSP load.

cheers,
Robin

On 06/09/12 03:29, Robin Haberkorn wrote:
> Hi!
> 
> Here's another minor bug fix.
> 
> Consider this example:
> 
> UGen @osc[2];
> new SinOsc @=> osc[0];
> new PulseOsc @=> osc[1];
> 
> It will work because the type checker will consider SinOsc/PulseOsc and
> UGen compatible for assignment (using the "isa" function which in turn
> is using the <= operator). This is because Chuck_Type "<=" will check
> that SinOsc is a child of UGen.
> 
> However, unintuitively you cannot use the array constructor:
> 
> [new SinOsc, new PulseOsc] @=> UGen @osc[];
> 
> Since the left-hand-side type (Osc[] in this case) is not considered
> compatible to UGen[]. Neither are they directly the same nor are they
> descended.
> That's because "<=" does not check for the arrays' "actual" types (Osc
> and UGen) being compatible.
> 
> You must either declare the "osc" variable with the same type as the
> constructed array:
> 
> [new SinOsc, new PulseOsc] @=> Osc @osc[];
> 
> or you have to cast the array members to UGen so the lhs type is
> (predictably) UGen[]:
> 
> [new SinOsc $ UGen, new PulseOsc $ UGen] @=> UGen @osc[];
> 
> Both options are not very intuitive for the user. The "Osc" class/type
> is not even documented I think. Not to mention that it's not always easy
> to guess the type of a constructed Object array.
> 
> The attached patch fixes that by allowing arrays of the same depth and
> derived "actual" types being considered compatible.
> 
> I think this is the last array patch for the time being, though I'm
> tempted to implement support for map keys in the inline array
> constructor :-).
> 
> Best regards,
> Robin
>