I continued my tests...adding chuck-1.2.1.3 from miniAudicle-0.2.0 to the candidates. result: connections like adc.chan(c) => looper => dac.chan(c); work in 1.2.0.8 and 1.2.1.3 but not in 1.2.1.4-dev-2 When further analysing, I find that adc.chan(0) => LiSa looper => dac works, but adc => LiSa looper => dac.chan(0); fails. I also noticed that the play rate 2 in the following script works only in 1.2.0.8, is this intentionally?: 2000::ms => dur duration; adc => LiSa looper => dac; adc => dac; duration => looper.duration; looper.recRamp( 20::ms ); <<<"recording...">>>; looper.record(1); duration => now; looper.record(0); adc =< dac; <<<"playing...">>>; looper.play(1); looper.loop(1); looper.rate(2); duration => now;

...

 adc => LiSa looper => dac.chan(0);

fails.

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

linux and jack

It could be a RtAudio issue.

rtaudio.h tells me // RtAudio: Version 3.0.2 (14 October 2005) seems to be old :-) 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; chuck's multichannel code seems to have some problems anyway.

...

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.

If you mean that line then you might want to try rate(2.0) to force it setting the rate, instead of getting the rate of the default (first) voice. I think that might make a difference. LiSa's functions are rather overloaded which can cause some confusion with implied casting.

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()?

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?

If any UGen is placed after lisa.chan(0), lisa.pan will not behave predictably in stereo. You'll need separate UGens to follow LiSa. Something like: lisa.chan(i) => gain[i] => dac.right and so forth. *********** Van Stiefel Director, Center for Music Technology West Chester University Assistant Professor, Department of Theory and Composition Swope Music Building College of Visual and Performing Arts West Chester, PA 19383 ________________________________ From: chuck-users-bounces@lists.cs.princeton.edu [chuck-users-bounces@lists.cs.princeton.edu] on behalf of Kassen [signal.automatique@gmail.com] Sent: Sunday, April 10, 2011 9:04 AM To: ChucK Users Mailing List Subject: Re: [chuck-users] record and play multiple LiSa objects on multiple channels Harald; works correctly on all three versions, as you see also adc.chan(0) => dac.chan(0) works . Ok, so then it's a LiSa issue and hopefully Dan will have a moment to look into it. I think Dan was experimenting with multi-channel looping and this seems to be a side-effect of that. 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. Hmmmm. I think LiSa is quite independent of SndBuf and is instead based on a Max/Msp tool. 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. Yes, that sounds sensible to me. ok, the voices are a special thing, I didn't take them into account. LiSa is really way more involved than the rest, more powerful but also a bit more tricky to understand. 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. Yes, but at the expense of uniformity. Personally I'm very much in favour of keeping things uniform as that means there are less surprises and there is less to learn. I can see how this would be a topic for debate though. 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? I feel all of this should be fine here. The dev-list is where the dev discussion "should" go but for some reason it isn't. I don't know. :-) Yours, Kas.

it doesn't all work properly yet, hence nothing about it... some general chuck multichannel issues need to be resolved... On Apr 10, 2011, at 4:14 PM, Kassen wrote:

2011/4/10 Stiefel, Van If any UGen is placed after lisa.chan(0), lisa.pan will not behave predictably in stereo.

Wait! Since when has LiSa had .chan(n) and .pan member functions? What do they do? Why wasn't this send to the LiSa Fanclub Newsletter? This sounds very exciting.

Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Harald, Kas (this is your name, right?),

Sure. My full first name is "Kassen", and signing as "Kas" seems nicely informal.

I first learned about LiSa as a recorder. Which is why I didn't expect things like the voices. Then I learned that LiSa is more a flexible sample player than a recorder.

Yes, it stands for LIve SAmpling. You can look at it as a looper (as in guitar loopers) or a simple sampler or a granulation tool. The technique is a fairly classical computer music one.

Currently I am re-visiting the WvOut and WaveLoop ugens. At the beginning when I didn't know much of chuck I made a silly mistake, which made me think I couldn't use them for my purpose. But now I found that they work well for me. LiSa is very nice for playing the same sample in multiple ways (different frequency etc.), but for my project it is a little oversized.

I think so, yes.

hmm, I don't think. Lisa's voices are special, no other ugens have them, right?

As I see it the core "special" thing here is UGen member functions taking two parameters and the extra convenience trick of being allowed to not specify the voice if you only need the first. As I see it the confusion arises from permitting that shortcut. Maybe that was a dubious choice but the convenience might be worth it? I don't know.

I agree...but then the shortcut isn't really needed.

No, not "needed" as such, but after writing some pages of code that makes ChucK look like a "scripting extension to LiSa" you come to appreciate it. :-) You do have a point and as I mentioned; I ran into it too, once. It's a hard to detect mistake. One big question here is that I can't see a alternative that would be clearly better in all ways yet not break existing code. Tricky stuff. Yours, Kas.