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

Kassen signal.automatique at gmail.com
Sun Apr 10 03:21:18 EDT 2011


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20110410/1b1fa5aa/attachment.html>


More information about the chuck-users mailing list