May passed quickly. I was testing a lot and as usual this brings bugs to day- light. I noticed one particular problem, that I still have to solve. Buzztard songs are actually zip file containing the songs.XML file and references files like samples. When the song is save the externals are copied from its original location into the zip. First there is a chance that the file becomes unavailable between loading it and saving the song (e.g. if the files where loaded some a sample CD) and then of course if those songs are given to someone then the zip is all there is. I see two ways to handle it - a) if the file is not available, save the raw-pcm as a wave-file, b) when loading new files samples, copy these somewhere and keep the file open and when loading a song, copy this somewhere and keep it open (somewhere = local file system). One thing I already have implemented is save saving, that is rename the old file, save and in the case of failure roll back.

There were also a couple of bugfixes in the UI. I had a long session to fix object destruction and detaching related signal handlers - too bad that the limitations in g_signal_connect_object() still render it pretty useless.

In the beginning of the month I continued with the work on the buzzmachines module. I rewrote one effect from scratch and its pretty compatible. I also added more presets and demo-songs.

While testing more buzz songs I realized two long standing issues. On the buzz song loader I got one detail wrong from the reverse-engineering - I was loading polyphonic pattern with voices and time swapped. That was easy to fix and make many songs sound proper. I made a few other compatibility fixes and improvements on the song load too. The other problem was actually much more work - the buzzmachine emulation had a big flaw. When I instantiated a plugin I was loading the dll/so once for the class and created the machine instance at the same time. The emulation API only had a init(). That means for multiple instances I was "reusing" the class wide instance. It worked surprisingly well :) Now I did a big refactoring there. In class init the dll/so is loaded and for each gobject instance I create a instance of the wrapped machine.

Finally I got around implementing one feature in the GStreamer side. There are a couple of wrapper plugins in gstreamer that act as a bridge between different plugin APIs. The way this was done had quite a drawback. Whenever the plugin was loaded, it was re-registering all the element types. In order to do that it needed plugin specific metadata. So it was loading each of the bridged plugins and querying the features. It needed two patches to get that changed. Now gstreamer does not ref each element class of a loaded plugin during loading and the registry can cache plugin specific metadata. What does it mean practically? A typical buzz song now loads in a quarter of the time.