[chuck-users] record and play multiple LiSa objects on multiple channels

Harald Gutsche hg42 at gmx.net
Sun Apr 10 08:12:54 EDT 2011


Kassen,

>> I would assume the bug is in LiSa and/or multichannel code, because it
>> depends on the way it is connected, remember this works:
>>
>>  LiSa looper => dac;
>
> Could you try this;
>
> SinOsc s => dac.chan(0);

yes,

SinOsc s;
s => dac.chan(0);
1000::ms => now;
s =< dac.chan(0);
s => dac.chan(1);
1000::ms => now;
s =< dac.chan(1);
1000::ms => now;
adc.chan(0) => dac.chan(0);
1000::ms => now;
adc.chan(0) =< dac.chan(0);
adc.chan(1) => dac.chan(1);
1000::ms => now;
adc.chan(1) =< dac.chan(1);
1000::ms => now;

works correctly on all three versions, as you see also adc.chan(0) =>
dac.chan(0) works .

> ..? That should tell us whether it's the UGen or the dac that causes the
> issue.

I think it's more complicated.
When I tried to hack cuck's source code (which was around 1.2.1.3), I
had no problems to understand adc and dac, as these ugens are
unbuffered.
Those simply copy a single sample from in to out. Pan2 and Mix2 are
the same and use ugen's gain
I got confused when looking at sndbuf's code. lisa should be similar.
How is the multichannel code supposed to work?
LiSaMulti_tick didn't change from 1.2.1.3 to current, so the problem
must be elsewhere.

>> chuck's multichannel code seems to have some problems anyway.
> Yes, stereo is half implemented, I think really only pan2 and maybe a sample
> player are true stereo. My gut feeling says this is something else though.

yes, e.g. simply using

    if( !type_engine_import_ugen_begin( env, "Gain", "UGen_Stereo",
env->global(),
                                        NULL, NULL, NULL, NULL, 2, 2 ) )
        return FALSE;
    // end import
    if( !type_engine_import_class_end( env ) )
        return FALSE;

somewhere would make a gain stereo. Note that only the 2, 2 and the
UGen_Stereo make the difference.
Also from my first impressions, LiSa, sndbuf etc. don't use UGen_Multi
or UGen_Stereo. So for such things they seem to be missing features.
I think, one problem is that the number of channels is an attribute of
a type. Most things in chuck are dynamic, so making the number of
channels fixed when creating the type object doesn't make sense to me.

> Well... LiSa has a lot of voices for playback (see the explanation in the
> /examples/special/readme_lisa2.ck (or similar) file. To set the loop-end of
> voice 3 to a second;

ok, the voices are a special thing, I didn't take them into account.
C++'s polymorphic functions are often a problematic concept. Perhaps
rateVoice would be a better name. Or e.g. my_lisa.voice(v).rate(2.0)
would make it more clear.

> from. This is uniform with other ChucK functions where dropping the
> parameter turns it into a "get" function, like;
>
> <<< my_sinosc.freq() >>>;

I think this type of polymorphic functions is generally ok. But mixing
another polymorphic kind is not.
I think, different types of numbers should be considered similar,
especially when automatic conversions exist.

> Hope this clarifies,

yes, thanks

btw. should I've written some of the low level developer topics to chuck-dev?
I wrote it here, because chuck-dev seems to be dead.
Where do the devs meet?


More information about the chuck-users mailing list