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