Another month with good progress. I've started with the undo/redo parts in the sequencer view. Most of the edits are handled now. I am still stuck with one problem though. So far the order of signal handler on object removal did not matter. Now it does :/ There are things that when they get removed remove other things. And that causes chains of modificatins that in the change log would overwrite (shadow) the save data. Not yet sure how to solve that. I'll probably confront someone at the desktop summit with the problem over some beer in the hope that I find a solution while I am explaining the issue :) As a good side effect of the undo/redo work, I could remove the warning dialogs that I was showing when removing things. Makes the editor more pleasant to use.

During my july trip to mountain view I brought two cheap midi controlers - korg nanokontrol and nanokeys 2. The nanokeys 2 is not so nice, but the nanokontrol seems to be okay. Unfortunately I didn't notice is is the old model, the nanokontrol 2 has more keys. I have played quite a bit with the nanokontrol in buzztard. Found and fixed a few bugs. One thing I definitely needed to do is to store the keys one has trained. Thanks to my long train journeys between munich and leipzig these days, that got implemented. For the nanokeys I need to still do a couple of things and those will have to wait for the next version.

As I was blocked on the undo/redo I did more small mini-songs. As usual found a couple of bugs. Buzztard stores timestamps in the song (like when it was created and when it was saved the last time). When closing a song with changes it warns you about loosing the changes for the last n hours/minutes. Thas was completely off if one loads a song and makes some changes. I need to set the last-saved to the time of the first change. A few other bugs were related to 64bit arch and using wrong int types in varargs functions. I also made some ui improvements. The settings hide more unusable audiosinks (apexsink, sfsink), especially probing apexsink caused long delays as I don't have the hardware for it.

One issue that I had no good explanation for but that was quite apparent when doing demos was small breaks when the song loops. Especially at the first loop it caused a bad glitch and later it sometimes played a bit too much or skipped something when wrapping around. I had made some test apps for it, but could not reproduce it there so far. Finally I looked at it again and found a small self-contained testcase that was reproducing it. On that case I could narrow it down to a combination of two gstreamer elements causing it. Still it was not straight forward to fix it, after all it is not crashing or such. I decided that the only way forward was to get a good picture of what is happening and verifying the events step by step. Voila, we now have a improved gst-tracelib and a gnuplot script for plotting event over time. Would be nice to have a more interactive UI for gnuplot though. I filed a bug and put the data there, if you are curious about the graphs. After some more nights I found the issue and the fix for the adder plugin is now upstream. A simillar change needs to be done for the videomixer elements (will look into that soon).

This month I made great progress. I have been making several small demo songs and found+fixed quite many bugs and glitches along with that.

After a little break I took up undo/redo work and could make good progress. Now also pattern property changes (name and length) are tracked. In the sequence the boilerplate code is there, single edits, track and property changes are handled. In the machine view the initial machine position is tracked in the change-log.

In the middle of the month I did doc updates - api docs had some stuff missing and the user help finality has more beef and short-cut tables for all the keyboard accelerators.

OmniMancer on irc gave me some good first perspective usage experience. I added a blacklist filter to hide gstreamer elements from the menu that are known to be not useful for buzztard (e.g. dtmfsrc). Also some machines used GTypes not yet supported by the UI - this is now fixed. With that came some fixes in
pattern editing (blending parameters wasn't working in all cases). I also added a flip operation to the patterns. Also to make a few things easier for new users I added two items to help menu - file a bug and goto irc. The later fires up the freenode webirc as xdg-open seems to be unable to launch e.g. xchat for irc://
urls.

I have started to write the missing treemodel for the sequence view and used that changed to overhaul a few things. Even without the new model its quite a bit faster as we do less model rebuilds (e.g. when expanding the length). Also the row-shading code is simpler and with that the cell-data functions. Finally
the pattern usage tracking is now using a hashtable instead of rescanning the sequence.

With all those changes comes a bag of bug fixes - I'll skip listing them here - it is all in the change log. Also I did a bit of code cleanups and reorgs. Like using macros for the GType handling to save lines of code. Or bump the gtk+ version (2.10.12) to get rid of fallback code. Finally I rechecked a glib bug regarding mime-matching. It's fixed since a while, but I still saw it, as the .recently-used.xbel file had the wrong mime type from the time when glib had the bug in there. Maybe it would be good to trim that file from time to time. Imho
it should also be in $XDG_CACHE_DIR and not $HOME, but that is a different story.

In the begining of the month I finished the new treeview models. There were a couple of corner cases I did not handled yet. I did some thinking about the remaining model, but did not yet write any code for it. Instead I did some code review of the whole project leading to numerous small cleanups and fixes. I also got rid of some holes in the api docs.

Otherwise I worked more on GStreamer and gtk-doc. In GStreamer I mostly hacked on a baseclass for audio-visualizers which is now in gst-plugins-bad (together with 4 elements using it).

There are some other reasons for not having so much time to hack on, of which I will shortly speak about :)

After last month spectrum analyzer work, I also looked at
the volume meters again. Handling the updates is a bit
tricky as I need to sync them to the audio playback. Now I
have optimizations in place to skip updates when the meter
is zero or maxed and has not changed. This is actually quite
often the case.

I also fixed a small UI glitch; song-io plugins did not tell
so far whether they support saving and/or loading. Thus one
could end up selecting a format and then getting an error.
Now one will see only the formats that plugins can handle.

Finally I got around catching up on the docs too. Now all
dialogs have some docs including screenshots.

One refactoring I was actually considering to push for after
the next release was getting rid of the GtkListStores and
use real GtkTreeModels instead. The disadvantage of a
ListStore is that it is static, if the underlying object is
dynamic one needs to manually synchronize it. This enlarges
the code and also the duplicated data storage uses memory.
Writing own models was in the end not so difficult, it is
quite some boilerplate code though. The first one I wrote is
a object-list-model.
It allows to bind object-properties to model columns. If
e.g. a field changes, the model notifies and the view
updates. The whole thing could become more generic if we
would have an iterator interfaces and the collection types
(list, array, ..) would be gobjects implementing the iface.
Well, I am not the first to notice that
:). Next I made 2 specialized models and started to take
them into use. As a bonus e.g. the machine model provides a
nice logical sorting. One more model to implement and
switch to.

I got totally awesome birthday gifts today - Gnome 3 and
Banshee 2 - thanks
everybody :). When I asked on the irc
what people will then release on my next anniversary -
"well, like gnome 3.6 ;)" was the answer.

I have been refactoring GStreamer's spectrum analyzer. It is
now working faster and also allows to get per-channel
results. For testing I updated buzztard to check if one has
the new version and if so show per channel graphs. While
hacking on the analyzer graphs I have also refactored the
code, so that now it is possible to probe the final output
as well.

I spend the bigger part of the month on the tests again. I
had an unref too much somewhere. Even after all the work in
refdbg this is still difficult to track down. Eventually I
found it and now all tests are green.

buzztard
I was testing buzztard a lot on my MeeGo netbook this month.
As screen space is more precious on netbooks I was running
it often in fullscreen mode and noticed that some windows
seem to not open. When leaving full screen the windows
appeared. Somehow they opened behind the main window. I
looked over all child windows and dialogs and cleaned up the
handling with a helper method doing:

On my desktop it works fine on the netbook the problem still
happens :/ No idea right now. As a good side effect I
ensured that all dialogs have a properly set default response.

I was also running the performance tests and did some
oprofiling. I knew already that my data-fixup code for
buzzmachines caused quite some overhead. It is handling
denormals and marking full zero buffers as empty. I now
added code that
sets the FPU on x86 machines to DAZ|FZ mode from the
application and disable the fixup code. On my netbook my 11
min benchmark song renders in about 1 min instead of 1:20
min before. On my desktop most of the change are hard to
measure as it already only takes 5 seconds :). Anyway the
oprofile runs confirm the speedup. The code disappeared from
the top 20.

The pattern editor widget becomes slow when getting large.
Some text drawing operations look expensive. For a start I
ported the whole widget to use cairo, but that does not take
care of the slowness. After more measurements it becomes
clear that I need to rework this more. I need to render it
offscreen and reply to expose events by copying pixels.

I also worked a bit more on the interaction-controller
library. udev/hal code is refactored into extra objects
(saves me a lot of #ifdefs). It also has some tests now. I
still have a mysterious issue with udev. Run this
stand alone example as told in the header - for me
valgrind complains about uninitialized data access. It only
seems to happen when you have a /dev/input/mice which all my
computers have. I have a workaround, but believe more
testing from other would be great.

As there was no project news over x-mas, I have a slightly
longer one this time. Before I dive into the usual code
changes, something else - tadaa - we have a new webpage. The
previous page was a mediawiki with a few customizations. Now
we use a combo of wordpress-3 and mediawiki. Both use a
similar theme (based on the arch linux one).
Wordpres gives as news, forum, social-network features and
much more. The first days I was suffering a lot from
wordpress account creation spam. Luckily this seems to be
under control now. The concept and a lot of the work was
done by Joe Pea. We both have quite a few more things on the
todo list. One of the next items is single sign in for
wordpress and mediawiki. Stay tuned.

In the last two month I improved the song-recovery workflow.
The recovery is now giving better feedback to the user and
we're properly cleaning up afterwards. The machine machine
and pattern view do now have almost full undo/redo.

Quite several times already I had to deal with a dialog
containing a treeview showing a list of items. The latest
example is the song-recovery dialog. Giving such a dialog a
nice good initial size is tricky. The treeview usually goes
into a scrolled window. By default one can see the headers
and maybe one line. Of course one can resize the dialog a
bit, but as the line height is not easy to figure it is
still not easy. One approach I came up with is to grow the
dialog to show all lines until it would exceed a certain
limit. The limit would be e.g. half of screen or window
height. The code for that is quite simple:

/* make sure the dialog resize without showing a scrollbar until it would
* reach half screen height */
gtk_widget_set_size_request(gtk_widget_get_parent(widget),-1,height);
}

Another thing in gtk that I wonder if it has a better
solution is the disposal of popup-menus. The problem is that
gtk_menu_popup is not taking ownership of the menu, but
there seems to be now event when the menu is done, so that
one can unref it. The only solution I can see is the pre-
create the menu and ref-sink it. When the entity that owns
it is disposed it can destroy and unref it.

As we're quite gtk related in this time anyway one more
discovery. Listening for key-press-event instead of key-
release-event and widgets makes key-repeat work. Have added
that to the gtk api docs.

Beside all the things above a couple of bug-fixes went in
(make preferences in machines work (e.g. choosing fluidsynth
instruments). I did some refactoring on midi controller
handling; one can use the pitchwheel now and continuous
controllers work better. Finally the dialogs warning about
unsaved changes are more user-friendly; they now show the
time passed since last saved/created in addition to the
timestamp.

Last month I made good progress on the undo/redo. I am now
running the undo/redo
in sync with the object lifecycle. The downside of this is
that undo/redo fails
when you have ref-count leaks. This now makes them more
apparent. When trying to
debug them I noticed that refdbg is not working
anymore since quite a while.
I was googling what other people use for such problems.
Well, apparently
everybody hates ref-count issues. Also most of the info you
find is how to get
traces for refcount activity. That is what refdbg does also.
As this did not work
for me anymore I've tried systemtap. Unfortunately right now
its not useful for
user-space work on most distros (except fedora) - bugs
filed. Next step:
gdb scripting. I
managed to get a gdb
script running. Now even for simple cases you
quickly end up with a log of 150 backtraces. That is a lot
to manually review. I
went one step further and wrote a
script to filter the traces. Over time I
got the trace-log down to 20 entries. This is practical.
Unfortunately the gdb
script only work for tracing the lifecycle of one particular
object. If I extend
it to work for all refcounting activity I hit a gdb
limitation to not allow
nested commands :/. Back to refdbg :) I finally figured why
it does not work and
have started to
fix it up. Lets see how far I get next month.

Buzztard

Naturally this used most of my hacking time. Still I managed
to make some progress there as well. The buzztard
irc channel was much
more active this month. People reported small things here
and there and most of
it got fixed right away. The manual got some more love too
to help people to get
started and improve the description of several concepts.
Finally all the
refcount-debugging leads to a lot of code reviews. I found
several areas with
lots of needless refcount activity - fixes are in the
repository.