Harald;

> That's a bug in 1.2.1.4 then, that should work. What OS are you on?

linux and jack


Strange, so far most multi-channel issues have involved the plan (non-ASIO) Windows drivers.

seems to be old :-)


Indeed. I hope that'll be fixed with the upcoming update.
 
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);

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

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.
 
>> looper.rate(2);

on further testing I found it's because the parameter should be a
float (as you also suggested).
Sorry, I was fooled by the fact, that 1.2.0.8 worked.


I ran into the same thing once, took me a whole afternoon of muttering non-polite things to find.
 


indeed...
Do you mean the function is overloaded with a function rate(int x) ?
if so what is the purpose of x?
Or will a rate(2) be delegated to rate()?

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;

my_lisa.loopEnd(3 , second); //simple, right?

Now we try to get it instead;

my_lisa.loopEnd(3); //should now return a second

If we want to set the first voice we can omit the voice command for convenience;

my_lisa.loopEnd(second); //no need to deal with voices if we only need one.

Here it is all quite clear, however, you can imagine that getting voice 3(int)'s rate and setting the first voice to a rate of 3.0(float) may look very similar. This is what you ran into and this is where the problem came from. This is uniform with other ChucK functions where dropping the parameter turns it into a "get" function, like;

<<< my_sinosc.freq() >>>;

LiSa is merely a bit more extensive than most UGens so now that LiSa became uniform with the rest after version 1.2.0.8 we got this chance for some confusion. IMHO the current situation is consistent and powerful, but I agree that it can be a bit tricky.

Hope this clarifies,
Kas.