Harald;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> That's a bug in 1.2.1.4 then, that should work. What OS are you on?<br>
<br>
</div>linux and jack<br>
<div class="im"><br></div></blockquote><div><br>Strange, so far most multi-channel issues have involved the plan (non-ASIO) Windows drivers. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
seems to be old :-)<br>
<br></blockquote><div><br>Indeed. I hope that'll be fixed with the upcoming update.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

I would assume the bug is in LiSa and/or multichannel code, because it<br>
depends on the way it is connected, remember this works:<br>
<br>
  LiSa looper => dac;<br></blockquote><div><br>Could you try this;<br><br>SinOsc s => dac.chan(0);<br><br>..? That should tell us whether it's the UGen or the dac that causes the issue.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
chuck's multichannel code seems to have some problems anyway.<br>
<br></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

>> looper.rate(2);<br>
<br>
on further testing I found it's because the parameter should be a<br>
float (as you also suggested).<br>
Sorry, I was fooled by the fact, that 1.2.0.8 worked.<br>
<div class="im"><br></div></blockquote><div><br>I ran into the same thing once, took me a whole afternoon of muttering non-polite things to find.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
</div>indeed...<br>
Do you mean the function is overloaded with a function rate(int x) ?<br>
if so what is the purpose of x?<br>
Or will a rate(2) be delegated to rate()?<br>
</blockquote></div><br>Well... LiSa has a lot of voices for playback (see the explanation in the /examples/special/<a href="http://readme_lisa2.ck">readme_lisa2.ck</a> (or similar) file. To set the loop-end of voice 3 to a second;<br>
<br>my_lisa.loopEnd(3 , second); //simple, right?<br><br>Now we try to get it instead;<br><br>my_lisa.loopEnd(3); //should now return a second<br><br>If we want to set the first voice we can omit the voice command for convenience;<br>
<br>my_lisa.loopEnd(second); //no need to deal with voices if we only need one.<br><br>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;<br>
<br><<< my_sinosc.freq() >>>;<br><br>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.<br>
<br>Hope this clarifies,<br>Kas.<br><br><br>