buzztard
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.