buzztard project status 01/06/2009


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.

Have fun,

buzztard core developer team

Posted by Stefan Sauer 2009-06-10