LiSa looping issue
Hello all, I'm writing a looper using LiSa. All is behaving just as expected except for this: When I overdub, I can't seem to get out of overdub mode. I'd like to default back to a non-overdubbing recording. The .loopRec function does not work. ChucK says that LiSa does not have that function. If I force 0 => *.loop, then my playback won't loop either. Does anyone have any thoughts on this? Also, if I call *.clear, I get nothing. Hopefully I'm just slow :) Thanks. I'm using Dracula 1.2.0.8 Thanks,Matt
On Mon, Apr 23, 2012 at 02:01:52PM -0400, Matt Bard wrote:
Hi, Matt!
I'm using Dracula 1.2.0.8
Then that is most likely the issue; since then there have been quite a few updates and especially LiSa has been improved a lot. If you are using 1.2.0.8 then I suspect you are on a Debian based Linux and using the old package. I would recommend you try building ChucK from the latest source. If that would be a new kind of thing to do for you then I hope it inspires some confidence to hear that it's not as difficult as it might seem and there will be help if you have problems. Hope that helps, shout if it doesn't. Yours, Kas.
Kas, So, I went ahead and updated to 1.2.1.3 last night. I noticed the error with .loopRec is gone. However, my issue persists. Apparently I misunderstand something. Here is a portion of my code: if (func == 1) { //looper.clear(); //Causes a RT error with Jack //0 => looper.loopRec; //Does nothing 0 => looper.play; //Record 0::ms => looper.recPos; <<<"Recording">>>; 1 => looper.record; now => start; } if (func == 2) { //Playback Loop Continuously 0 => looper.record; now - start => looper.loopEnd; 0::ms => looper.playPos; <<<"Playing">>>; 1 => looper.play; } if (func == 6) { //Begin Overdub 0.8 => looper.feedback; looper.playPos() => looper.recPos; 1 => looper.record; } if (func == 7) { //End Overdub 0 => looper.record; } Basically, everything works fine so long as I don't overdub. If I call the first portion then the second, I get a loop. If I recall the first, it overwrites the original loop and I get another loop... awesome. ie (sporking some other function): 1 => func; wait 2 => func; wait 1 => func; wait 2 => func; Now, as soon as I go for the overdub, all is well until I try and start from the beginning. 1 => func; wait 2=> func; wait 6=> func; wait 7=>func; wait 1=>func; //Here I end up with things overdubbing again even if I set 0=>looper.loopRec; It seems that loop recording begins after I set a feedback level (I'm cool with that), but how do I get out of loopRec mode if not with the commented out line? Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction? Much thanks, Matt
Date: Mon, 23 Apr 2012 20:10:25 +0200 From: signal.automatique@gmail.com To: chuck-users@lists.cs.princeton.edu Subject: Re: [chuck-users] LiSa looping issue
On Mon, Apr 23, 2012 at 02:01:52PM -0400, Matt Bard wrote:
Hi, Matt!
I'm using Dracula 1.2.0.8
Then that is most likely the issue; since then there have been quite a few updates and especially LiSa has been improved a lot.
If you are using 1.2.0.8 then I suspect you are on a Debian based Linux and using the old package. I would recommend you try building ChucK from the latest source. If that would be a new kind of thing to do for you then I hope it inspires some confidence to hear that it's not as difficult as it might seem and there will be help if you have problems.
Hope that helps, shout if it doesn't.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Tue, Apr 24, 2012 at 07:39:03PM -0400, Matt Bard wrote:
Kas,
So, I went ahead and updated to 1.2.1.3 last night.
Great, congratulations!
I noticed the error with .loopRec is gone.
Also good, we'll get there :-)
However, my issue persists. Apparently I misunderstand something. Here is a portion of my code:
Ok, let's have a look.
if (func == 1) { //looper.clear(); //Causes a RT error with Jack
Right, that is simply a ChucK bug then, with some luck Dan Trueman (LiSa's "father") will have a look at what is wrong there.
//0 => looper.loopRec; //Does nothing 0 => looper.play; //Record
Here I am scratching my head; does the combination of the code and comment imply that you would like "not playing" to equal "recording"? That would be a interesting way of working, but it's not true. .play starts and stops playback and .record starts and stops recording. .loopRec is a bit like .loop, .loop only works when playing and in that case makes playback loop, while .loopRec only affects recording and sets whether recording -when it happens- works in a looped fashion.
It seems that loop recording begins after I set a feedback level (I'm cool with that), but how do I get out of loopRec mode if not with the commented out line? Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction?
I think here might be the reasoning error; the "loop" in loopRec refers to looping in time, not to a signal feedback loop (that may also exist). loopRec means that as the recording position reaches the end of the buffer it'll "loop" back to the start. Maybe I am reading you wrong, but so far that seems to be it.
Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction?
Well, those two are simply plain bugs; things should not shut down over simple function calls. .clear() I'm not sure about, I don't think I ever had to use it, but I really thought .duration was fine. That's strange. How far does that get you? Or am I misunderstanding something? Yours, Kas.
Kas, Thank you for clarifying a few things. There was a definite fallacy in my loopRec understanding. Your response cleared that up.
0 => looper.play; //Record
Here I am scratching my head; does the combination of the code and comment imply that you would like "not playing" to equal "recording"? That comment made me scratch my head too after looking at it. I just botched my comment. Everything is working just as expected there except my commenting ability.
So, it appears that I do understand what is going on. My issue then is simply that I cannot call .clear() appropriately (.duration was my backup which also failed). Hopefully that will get fixed at some point, or maybe I can write a function to clear things out myself to seeif that works. Thanks again for all your insight. -Matt
Date: Wed, 25 Apr 2012 10:41:03 +0200 From: signal.automatique@gmail.com To: chuck-users@lists.cs.princeton.edu Subject: Re: [chuck-users] LiSa looping issue
On Tue, Apr 24, 2012 at 07:39:03PM -0400, Matt Bard wrote:
Kas,
So, I went ahead and updated to 1.2.1.3 last night.
Great, congratulations!
I noticed the error with .loopRec is gone.
Also good, we'll get there :-)
However, my issue persists. Apparently I misunderstand something. Here is a portion of my code:
Ok, let's have a look.
if (func == 1) { //looper.clear(); //Causes a RT error with Jack
Right, that is simply a ChucK bug then, with some luck Dan Trueman (LiSa's "father") will have a look at what is wrong there.
//0 => looper.loopRec; //Does nothing 0 => looper.play; //Record
Here I am scratching my head; does the combination of the code and comment imply that you would like "not playing" to equal "recording"? That would be a interesting way of working, but it's not true. .play starts and stops playback and .record starts and stops recording. .loopRec is a bit like .loop, .loop only works when playing and in that case makes playback loop, while .loopRec only affects recording and sets whether recording -when it happens- works in a looped fashion.
It seems that loop recording begins after I set a feedback level (I'm cool with that), but how do I get out of loopRec mode if not with the commented out line? Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction?
I think here might be the reasoning error; the "loop" in loopRec refers to looping in time, not to a signal feedback loop (that may also exist). loopRec means that as the recording position reaches the end of the buffer it'll "loop" back to the start.
Maybe I am reading you wrong, but so far that seems to be it.
Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction?
Well, those two are simply plain bugs; things should not shut down over simple function calls. .clear() I'm not sure about, I don't think I ever had to use it, but I really thought .duration was fine. That's strange.
How far does that get you? Or am I misunderstanding something?
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Wed, Apr 25, 2012 at 09:10:59AM -0400, Matt Bard wrote:
Kas,
Thank you for clarifying a few things. There was a definite fallacy in my loopRec understanding. Your response cleared that up.
It happens, I had something quite similar last week where I talked about "loop" in the sense of "iterate over.." and my discussion partner assumed there was some signal feedback. Such oddities in natural languages can easily throw us for a loop ;-)
That comment made me scratch my head too after looking at it. I just botched my comment. Everything is working just as expected there except my commenting ability.
No problem, I was just making sure because misunderstandings are easy to have.
So, it appears that I do understand what is going on. My issue then is simply that I cannot call .clear() appropriately (.duration was my backup which also failed). Hopefully that will get fixed at some point, or maybe I can write a function to clear things out myself to see if that works. Thanks again for all your insight.
Well, the easiest way of manually clearing would be to write a loop that would write a 0.0 to each valueAt() location. However, that would, as Dan pointed out, be doing *exactly* what .clear() does in LiSa's source. That doesn't seem like a solution to me, especially not as a loop in ChucK will never be as fast as one in the C++ source. It's also odd to me that you'd get a error from Jack and not ChucK. A ChucK error could happen if there would be a typo in the source, Jack only gets involved once there is a generated signal (from LiSa in this case) that made it through the UGen graph, to the output and to the sound system. Could you send the most simple example possible that will create this error for you, as well as the exact error? It may also be relevant to know whether you are using Jackd1 or Jackd2 (check in your package manager, probably Synaptic). I'd also be interested in knowing whether you are using some exceptionally small buffer size. Oh, and the exact error you get when calling .duration() as well, please. Contrary to Dan I am on Linux so I could try to reproduce this and we can -hopefully- make some guesses about what is going wrong. Yours, Kas.
Gentlemen, Here is the shortest snippet I could write to generate the issue: adc => LiSa looper => dac; 1::minute => looper.duration; 1 => looper.record; 100::ms => now; 0 => looper.record; 1::minute => looper.duration; I get no errors specifically from ChucK (even if I put an infinite while loop in there to advance time)... ChucK will just hang out for as long as I'll let it. However, here is the response from Jack: subgraph starting at qjackctl timed out (subgraph_wait_fd=17, status = 0, state = Running, pollret = 0 revents = 0x0) bad status (1) for client ChucK handling event (type = 8) **** alsa_pcm: xrun of at least 0.143 msecs So, it looks like an xrun. The laptop I'm using is pretty dang old... is it possible that the low amount of RAM and slower processor could be causing this? -Matt
Date: Wed, 25 Apr 2012 16:11:12 +0200 From: signal.automatique@gmail.com To: chuck-users@lists.cs.princeton.edu Subject: Re: [chuck-users] LiSa looping issue
On Wed, Apr 25, 2012 at 09:10:59AM -0400, Matt Bard wrote:
Kas,
Thank you for clarifying a few things. There was a definite fallacy in my loopRec understanding. Your response cleared that up.
It happens, I had something quite similar last week where I talked about "loop" in the sense of "iterate over.." and my discussion partner assumed there was some signal feedback. Such oddities in natural languages can easily throw us for a loop ;-)
That comment made me scratch my head too after looking at it. I just botched my comment. Everything is working just as expected there except my commenting ability.
No problem, I was just making sure because misunderstandings are easy to have.
So, it appears that I do understand what is going on. My issue then is simply that I cannot call .clear() appropriately (.duration was my backup which also failed). Hopefully that will get fixed at some point, or maybe I can write a function to clear things out myself to see if that works. Thanks again for all your insight.
Well, the easiest way of manually clearing would be to write a loop that would write a 0.0 to each valueAt() location. However, that would, as Dan pointed out, be doing *exactly* what .clear() does in LiSa's source. That doesn't seem like a solution to me, especially not as a loop in ChucK will never be as fast as one in the C++ source.
It's also odd to me that you'd get a error from Jack and not ChucK. A ChucK error could happen if there would be a typo in the source, Jack only gets involved once there is a generated signal (from LiSa in this case) that made it through the UGen graph, to the output and to the sound system.
Could you send the most simple example possible that will create this error for you, as well as the exact error? It may also be relevant to know whether you are using Jackd1 or Jackd2 (check in your package manager, probably Synaptic). I'd also be interested in knowing whether you are using some exceptionally small buffer size. Oh, and the exact error you get when calling .duration() as well, please. Contrary to Dan I am on Linux so I could try to reproduce this and we can -hopefully- make some guesses about what is going wrong.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
hey, not sure what's going on here. both .duration (which LiSa can't function without, as this is where memory is allocated) and .clear() (which just moves through the buffer and zeros every sample, one line of code) work fine for me. but i'm on OSX, so could be a Linux/Jack-specific issue? not sure how i can help with this, alas! could you provide the shortist piece of code that causes the error, and if there are any messages from Jack when it shuts down, send those on as well? dan On Apr 25, 2012, at 4:41 AM, Kassen wrote:
On Tue, Apr 24, 2012 at 07:39:03PM -0400, Matt Bard wrote:
Kas,
So, I went ahead and updated to 1.2.1.3 last night.
Great, congratulations!
I noticed the error with .loopRec is gone.
Also good, we'll get there :-)
However, my issue persists. Apparently I misunderstand something. Here is a portion of my code:
Ok, let's have a look.
if (func == 1) { //looper.clear(); //Causes a RT error with Jack
Right, that is simply a ChucK bug then, with some luck Dan Trueman (LiSa's "father") will have a look at what is wrong there.
//0 => looper.loopRec; //Does nothing 0 => looper.play; //Record
Here I am scratching my head; does the combination of the code and comment imply that you would like "not playing" to equal "recording"? That would be a interesting way of working, but it's not true. .play starts and stops playback and .record starts and stops recording. .loopRec is a bit like .loop, .loop only works when playing and in that case makes playback loop, while .loopRec only affects recording and sets whether recording -when it happens- works in a looped fashion.
It seems that loop recording begins after I set a feedback level (I'm cool with that), but how do I get out of loopRec mode if not with the commented out line? Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction?
I think here might be the reasoning error; the "loop" in loopRec refers to looping in time, not to a signal feedback loop (that may also exist). loopRec means that as the recording position reaches the end of the buffer it'll "loop" back to the start.
Maybe I am reading you wrong, but so far that seems to be it.
Also, if I call .clear() or call .duration, I get a realtime error from Jack and it shuts down. I'm sure I'm missing something. Could you point me in the right direction?
Well, those two are simply plain bugs; things should not shut down over simple function calls. .clear() I'm not sure about, I don't think I ever had to use it, but I really thought .duration was fine. That's strange.
How far does that get you? Or am I misunderstanding something?
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (3)
-
Dan Trueman -
Kassen -
Matt Bard