::  Posts  ::  RSS  ::  ◂◂RSS  ::  Contact

More work on looper software

April 26th, 2010
tech, music, looper  [html]
I've now (after talking to chris jacoby and blake) got the software for a three loop synchronizing system working. The problem I had last week was that I needed the loops to sync: now I understand what I needed to do. Calculating how long you need to wait until the beginning of the loop comes around is somewhat tricky. The issue was that LiSa buffers have several attributes: duration, play/record positions, and loop start/ends. Waiting for loopEnd - position samples is pretty good, unless the loop happens to go off the end of the buffer and come back on the other side, in which case loopEnd will be less than position and we can't wait for negative intervals. So in those cases we want to add on the duration of the loop. To cover both cases, we calculate the result modulo duration, so we're always between 0 and duration, which gives:
(duration + loopEnd - position) % duration
Unfortunately, this isn't quite right. There's latency involved in the system, with buffers in several places. This means that the samples that you are recording at time T were created to go along with samples that you played at time T - latency where latency is small but noticible. If I were able to get jack working with chuck in realtime mode (and the usb mouse driver too) then I might be able to get latency down to perhaps 2ms (64 samples) and be able to ignore it. That approach didn't seem to be working. Talking to blake, though, I realized I could simply start recording a little early to compensate. So really the number of samples to wait for is:
(duration + loopEnd - position - latency) % duration
Then the question is, what to set latency to. I put jack on its default setting, where it performed pretty well. This turned out to be using two buffers of 1024 samples each. So I started with latency set to 2048. Some trial and error showed that really what I wanted was 1024+1024+512. Where does the 512 come from? I'm not sure. It might be jack's input buffer, or perhaps a chuck buffer. Regardless, I can now play one loop and then put another one on top of it totally synchronized. Very exciting.

Comment via: facebook

Recent posts on blogs I like:

Cops on Public Transportation

I wrote a post about American moral panics about fare evasion two months ago, which was mirrored on Streetsblog. I made a mistake in that post that I’d like to correct – and yet the correction itself showcases something interesting about why there are arm…

via Pedestrian Observations January 17, 2020

A foolish consistency

“The other terror that scares us from self-trust is our consistency; a reverence for our past act or word, because the eyes of others have no other data for computing our orbit than our past acts, and we are loath to disappoint them. But why should you ke…

via Holly Elmore January 5, 2020

Algorithms interviews: theory vs. practice

When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site d…

via Posts on Dan Luu January 5, 2020

more     (via openring)

More Posts:


  ::  Posts  ::  RSS  ::  ◂◂RSS  ::  Contact