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.
72 files changed, 6268 insertions(+), 1250 deletions(-)
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.
43 files changed, 796 insertions(+), 100 deletions(-)
gtk_window_set_transient_for(window, main_window); gtk_window_set_destroy_with_parent(window, TRUE);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.
44 files changed, 1087 insertions(+), 317 deletions(-)
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:
list=gtk_tree_view_new(); g_signal_connect(list,"size-request",G_CALLBACK(on_list_size_request),NULL); ... static void on_list_size_request(GtkWidget *widget,GtkRequisition *requisition,gpointer user_data) { gint max_height=gdk_screen_get_height(gdk_screen_get_default())/2; gint height=2+MIN(requisition->height,max_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./* 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); }
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.
50 files changed, 2402 insertions(+), 1183 deletions(-)
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.
81 files changed, 2682 insertions(+), 817 deletions(-)
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!