Living Without the Bunnies

Artifastring 1.0

I'm happy to announce the release of Artifastring 1.0, a highly optimized physical simulation of a violin for sound synthesis. http://percival-music.ca/artifastring/

This is an implementation of modal bowed string physical modeling as described by Matthias Demoucron; references are given on the project's main page. The code is available under the GPL v3 or higher.

I had a blast optimising this stuff -- actually, I had far too much fun working on tiny speed improvements. Surprisingly, making the code multithreaded didn't help; the extra overhead of the mutex and condition variables nuked the benefit of modeling each violin string separately for any realistic length of discretized input.

I won't get into everything I did, but here's the main four points:

• As suggested in a conference paper, if a violin string wasn't vibrating and had no input, I didn't bother calculating new values for it -- I just returned 0.0. (this model doesn't include sympathetic vibrations, so there was absolutely no change in the output from doing this).
  I also detected if the string was barely vibrating (i.e. producing a force of less than 1e-6 on the bridge and each modal velocity was below 1e-4), and then "turned off" that string. This step did change the output, but only very slightly. I picked those values experimentally -- I plucked the string, then looked for the time when I really couldn't hear the sound any more. Admittedly, I was using a pair of £10 headphones... if I had a more expensive sound setup (whether headphones, speakers, a larger room, room with less background noise, etc), these values might be too low. If that were the case, it's easy enough to change those constants.
• Caching any values more complicated than addition or multiplication. In particular, the results of any trig functions were cached -- the amount of extra memory required is trivial (something like 20 kb ?).
• The code calculates eigenvectors of the string for each mode. This is a series of calculatations in the form

  y_i = sin(x*i)   , i = 0, 1, 2... N (where N=56 in my case)
  

  There's a well-known optimization for this: to calculate y_n = sin(nW+B), use y_n = 2*cos(W)*y_(n-1) - y(n-2).

  I could improve on that, though. In my case, there's no B, and I know that sin(0) = 0. So I only need to calculate sin(-W) and cos(W).

  But wait, it gets better! The quoted webpage includes this code:

  double y[3];
  double keep[N];
  for (int i=0; i<N; i++) {
      y[2] = p*y[1] - y[0];
      keep[i] = sqrt_two_div_l * y[2];
      y[0] = y[1];
      y[1] = y[2];
  }
  

  but this involves unnecessary copying. We can avoid that by using a ring buffer of size 2:

  double y[2];
  double keep[N];
  unsigned int latest = 0;
  for (int i=0; i<N; i++) {
      y[latest] = p*y[!latest] - y[latest];
      keep[i] = sqrt_two_div_l * y[latest];
      latest = !latest;
  }
  

  hmm... it just occurred to me that I could avoid using y if I postponed the multiplication by sqrt_two_div_l until after I'd finished calculating the entire array. I mean, go through the array once calculating the sin() values, then go through again multiplying everything by sqrt_two_div_l. I could also get rid of the "latest" variable, and just use i. Hmm... :)
• Fast ring buffer pointer calculation: the traditional way is to use modulo:

  i = (i++) % BUFFER_SIZE;
  

  But modulo is division -- it's slow. Another way is to use a comparison:

  i++;
  if (i == BUFFER_SIZE) {
      i = 0;
  }
  

  That's better, but still uses a bunch of CPU cycles. To improve it even more (courtesy of my brother), if you always use a buffer size which is a power of 2, you can just use an AND!

  i++;
  i &= BUFFER_SIZE_MINUS_ONE;
  

  Of course, we've defined BUFFER_SIZE and BUFFER_SIZE_MINUS_ONE at compile-time.

Sadly, none of this optimization is actually useful. Ok, the "inactive string" trick cut the processing time by more than half -- but the other tricks only gave 2-5% improvements in speed. One of the first lessons for people doing computer science is that running time doesn't matter. The real improvements are made at the level of algorithms... if you can do O(ln(n)) less operations than the next person, then it doesn't matter if you wrote your code in perl and he used hand-crafted assembly. Your code is guaranteed to be faster for any sufficiently large problem.

... of course, in the grand scheme of "doing stupid things," spending 3 days obsessing about speed and making your code run 20% faster is hardly a terrible thing. I mean, the next stage of the project is using the physical model to play music; that will involve a *lot* of experiments, and the faster the code runs, the more comfortable those experiments will be.

Anyway, there's the code. I don't have any fancy examples yet; I'm still learning how to "play" this virtual instrument. I should have neat stuff in a month or two.

Firelily

A long time ago in a city far, far away... I wrote a server in perl which transformed OSC messages into png's of sheet music.

This was back when I was doing my second Bachelor's degree; this time a B.Mus. It was my final project for the 4th-year computer music seminar at the University of Victoria, Canada. It wasn't a new idea, even back in 2006. But few people had done this kind of thing, and in any case, this was just one course in a bachelor degree. I got my 'A', finished the degree, and moved on.

However, I'd mentioned the program on the lilypond-user mailing list, and some people were interested. So interested that one of them recently emailed me to ask if my program was available -- I'd previously given him a "don't redistribute this" tarball a few years ago, with the understanding that I was still working on the infrastructure and was embarrassed about some of it.

Well, it's now clear that I'm never going to go back and "clean up" that work. I'm not saying that I'll never return to interactive sheet music -- I think it's an awesome idea -- but if/when I were to return to it, I'd want to start from scratch, almost certainly use python, etc.

Still, that's no reason to hold my earlier work hostage. So I'm announcing the release of Firelily 0.3.

This is old code which I wrote during my second degree (B.Mus). It does not represent my current ability level, with regards to programming ability, project organization, compositional techniques, or anything else.

My research interests have shifted; I now consider this project abandoned.

I'm happy to make it available under the BSD license. I'm not certain that it would be of any use to anybody, but I've had one such request, so here you go! If you would prefer it under a different license (GPL, Apache, artistic, whatever), then just ask and I'll (almost certainly) license it to you under that other license. http://percival-music.ca/software/firelily-0.3.tar.gz

Jamie Bullock has expressed an interest in maintaining and improving Firelily, so if anybody stumbles across this blog post in a few months/years, go look there. :)