• 

So, I finally took the time to finish up my psychobass plugin project's report and make a runnable JAR-file of my Boids application.

If you like staring at flames etc, I suggest trying out the Boids app. It's actually quite much fun looking at it. Beware of the fixed 1200x800 resolution though...

The plugin project report is less fun, but if you are interested in dsp, it might be worth looking at...

This page is dedicated to LV2 plugins written by me. So far there is only one, which was a school project, and rather academic by nature (read: not very useful), but might be worth playing with anyway.

Psychobass

This is a plugin that creates (even and odd) harmonics for bass frequencies, enhancing the perceived bass content.

• Project report, this explains it all in detail
• Project plan, probably not very useful
• SVN

Block-diagram:

• 

It's been a while since I last blogged, so I thought I'll just post about what I've been up to lately:

• The Psycho Acoustic Bass Plugin
  I promised to develop it in a public svn repository, but never published the URL. Sorry about that. Anyway, it is now in a working state and available here. It doesn't do miracles, but it does do something. I'll blog more about this when I get some feedback from the project report...
• Suunto heart rate monitors in Linux/OS X
  I bought myself a Suunto Heart rate monitor with a "pc pod" for connecting it to a computer. However, Suunto provides only Windows software for getting training data out of the device. Long story short, I ended up writing a small ANT driver for Linux and have been able to get some data out of the device. However the data format is rather cryptic, and I've been in contact with Suunto about the possibilities of getting a Linux/OS X version of their (rather good looking) Training SDK out. I haven't yet gotten a good response from them, but once I do, I'll blog...
• Futurice
  In the beginning of the year I started working part-time as a software developer at Futurice. I've been doing mainly mobile software development, and so far I've enjoyed it :)
• Ardour 2.8 is out!
  It looks like this time I haven't made a single commit to the 2.X tree since the last release. Partly because of my new job and lots of school work I haven't had quite as much time to work with Ardour as I could have wished. However, I have been doing some little work here and there in the 3.0 branch. Nothing big though.
• Boids (flocks herds etc.)
  This is a school project that I got a bit obsessed about :) The idea is to make a flocking model where each character in the flock acts autonomously, together forming clear flocking behavior. This is a Java project which is not ready yet, but you can nevertheless check it out here if you wish. It uses the great Processing framework (from "Java mode") for the 3D graphics. More on this once The course finishes. I'll also make the source code publicly available :)

As you can see, I've really been a lazy blogger, as there is a lot I could have blogged about :/ Anyway, I will try my best to keep you posted with my progress with this stuff. The plugin project especially is something that probably still requires some work to be truly useful, and hopefully I'll get some feedback from people who are interested.

I've been developing a nice plugin visualization idea together with Ardour co-developer Sampo Savolainen lately. Sampo originally had the idea of feeding white noise through an EQ plugin, and displaying a spectrum of this to see the frequency response. This way you could see what the plugin is actually doing, instead of some approximation of what it is trying to do. The idea is to update the graph every time plugin parameters are adjusted. This will probably be embedded in Ardour's plugin GUI at some stage (probably in 3.0).

• 

However, this approach had it's problems with getting a smooth graph. After a bit of thinking, I finally noticed we could simply use the impulse response of the plugin, and *drumroll* it works great! Sampo has cooked up a test client, which hosts a ladspa plugin and shows it's amplitude and phase response.

For anyone who knows his DSP, it should be pretty obvious that measuring the impulse response is only useful for LTI filters. However, another idea emerged from this one: Showing the difference between output and input (output_spectrum - input_spectrum) could be useful for non-LTI plugins. Plotting non-linear plugins like this should give valuable information about new signal components produced by non-linearities. However, selecting the parts of the signal to be used for the analysis is not trivial and will need quite a bit of thinking and experimenting.

To say a few words about Ardour development in general: 2.6 should be released any time now and 3.0 is moving forward fast. I finished a region export dialog for 3.0 today. It offers the possibilities to export the raw region output, region output with fades or track output.

The title of this blog entry refers to a feature I implemented for Ardour this week, which caused a lot of discussion. The feature is trimming silence from export products, and the question is how to define silence. A pretty good definition is "a short period of a signal with a low enough RMS value". (skip the next chapter if this doesn't sound interesting ;)

The above mentioned definition is needed because absolute silence is very rare in real life situations, and it implies setting two parameters: a threshold for the RMS value and a length for the period. Setting the threshold level is pretty straightforward, but the period length is a bit more complex. The length of the period depends on the lower bound of the bandwidth you consider relevant. To get a reliable measurement, the period length should be at least half of the wavelength of the lowest frequency. This would mean 1/20 seconds for a lower bound frequency of 10Hz, which is pretty reasonable. If more accuracy is required the measurement could be done with a sliding window, but this would mean much heavier processing.

Anyway, what I ended up implementing doesn't include any of the above, but only trims all the zero valued samples from the beginning and end of the export product. The reasoning for doing the simpler implementation is the fact that doing something more complex should be done in the editor, not in the export dialog. This will keep the export dialog cleaner and allow more precise editing in the editor. However, this more sophisticated silence trimming will some day most probably be implemented as an editing feature in Ardour.

And last but not least a brief status report:
So far this week I have finalized the structural changes I started last week and implemented normalizing and trimming silence from export files. Next I should do adding silence to the beginning and end, and then move on to next weeks tasks.