The chuck-using looper software was being too annoying. I couldn't figure out why latency was being slightly off and variable between runs, I couldn't figure out how to get it to run realtime, and chuck kept crashing when I went to record long loops, giving:

subgraph starting at RtApiJack timed out (subgraph_wait_fd=9, status = 0, state = Running, pollret = 0 revents = 0x0)

I decided to have a look at writing this in straight C against the JACK api. Which seems to have worked quite well. It wasn't that much work, and now I know exactly what's going on. Chuck was good for prototyping, and really easy to get started with, but I have a lot more trust in this new version. One downside is that unless OSX has /dev/input/mouse then this is linux only. Which is sad. If there's an easy fast way to get mouse events on OSX I could add it.

So. This requires at leas the following:

$ sudo apt-get install jackd libjack-dev
$ gcc -std=c99 -o looper_sync -ljack -lpthread -lrt looper_sync.c
$ sudo chmod ugo+r /dev/input/mouse*
$ jackd -d alsa -p 256 &
$ ./looper_sync

Unfortunately, while I was testing this one last time before writing it up, I managed to get the exact same "subgraph timed out" error in the C version that I'd gotten in the chuck version. I don't get it as easily in the new version; sometimes I can record three full length loops and not get it. Perhaps, though, this error means I'm trying to do too much work on one processing cycle? I need to look at it more. On my desktop it runs great, so I'm thinking it has to do with the eeepc being substantially less powerful.