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