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?