[chuck-dev] fixed array compatibility checking (PATCH)
dtrueman at princeton.edu
Wed Sep 5 22:18:57 EDT 2012
LiSa multichannel is for multichannel output. i haven't looked at it in a long while, as there were issues with the chuck implementation of multichannel stuff, and i welcome someone smarter than me to fix/finish it....
On Sep 5, 2012, at 10:06 PM, Robin Haberkorn wrote:
> 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 v188.8.131.52 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.
> On 06/09/12 03:29, Robin Haberkorn wrote:
>> Here's another minor bug fix.
>> Consider this example:
>> UGen @osc;
>> new SinOsc @=> osc;
>> new PulseOsc @=> osc;
>> 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
>> 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,
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
More information about the chuck-dev