Older blog entries for ensonic (starting at number 57)

It was nice to see some more faces behind the nick names and talk to the people. At the end of the conference we collected the notes from the feedback wall. I've posted the 'dislike' items already, the other will follow soon. Obviously some are not serious. But some of them are. Please look over them and comment.

Borked ATM

On sunday morning I had a nice experience with this ATM in belgium. I inserted my card and it could not read it. I've tried again and this time a dos-terminal came to front with '8' digits printed in a loop. Then it rebooted.

After it came up again. Playing the window login sounds etc. The startup was horrible. They tried to cover some scripts that were running in two dos-windows with a fullscreen picture that they periodically forced to be on top. It failed and flickered. Then the application was started and it prompted to insert the card. So far so good, if only my card wouldn't be still in there. I pressed 'cancel' and behold! It rebooted again. Wow! Btw. the manufacturer is Diebold - yes the ones that also make the oh-so-secure voting machines. To cut the story, I was using my N800 to surf to my banks homepage, call them and lock my card. They also said that quite likely the bank will sent to card to my bank and hey in turn to me.

I really wonder why someone uses windows for an atm. you can't lock it down and it costs money. Next question is why the bank pays so little interest in the actual configuration and application. the diebold setup is horribly unprofessional. Guys mind the fortis atm for now.

Marc-Andre Lureau, Zeeshan Ali currently rework the GObject documenation a bit.

I posted a call for feedback on the gtk-app-devel list. Please let us know what is missing, outdated or can be improved. Thanks!

Last month I started to offer extensions from the buzztard project for gstreamer inclusion [1] [2] [3] [4]. I believe that the idea behind is generic enough to support them. The discussion and interest has been relative low so far :( I'll probably interpret this then as agreement and commit the changes. The preset handling has been improved. The buzz presets can be saved now too and meta data (comments) can be edited as well. The generic implementation also shapes up.

As my solution for [5] seems to be disliked I went for a hack :( I now hide the treeview headers and simulate my own. Now the header widgets work. As some extra sweetness the header have per track volume meters. While working on this I also made the label-browser function. It allows to jump to labels in the timeline.

I also started to add some functionality to the wavetable page. Its now possible to browse the files and preview the selected entry.

I was curious how well the buzz song import now works. Especially with the better handling of missing machines. So I added a test script, similar to the unit test in core, that runs over all your buzz songs, imports them and dumps basic info into text files. Then it greps the text files to generate most wanted machine top 10 :).

Last weekend I did a first rough port of buzztard for the N800. I have some of the UI changes in place already. The GStreamer side was pleasant - no changes needed. Unfortunately the gstreamer on the device is not the most up to date and thus the app does not work too well.

gstreamer

A lot of action on the GStreamer front too. Dozen interesting elements ranging from midi-song rendering to new audio fx landed in bugzilla and partially already in CVS.

In last month news I wrote about the gst element check. Now we also have the respective UI parts. The apps check if the have mandatory and optional elements available. If elements are missing the user will see an explanation which are missing and what for they are needed. For optional elements its up to the user to decide if that is okay or if they should be installed. In the future we can make use of the new gstreamer libgimmicodec mechanism, to download and install missing elements on the fly.

I also continued working on the preset support. The interface got some default implementation, e.g. to generate a randomized preset. The buzzmachine wrapper implements most of the interface. We can load presets, rename and remove them. The later two actions are not yet persistent - I need to implement saving still. On the UI side I implemented the preset pane for the machine settings window. I decided not to copy the buzz UI here. I should post a screenshot soon.

I also went over the todo: comments in the source once again and implemented things here and there. Now one can add/removed tracks for polyphonic machines. Also adding/removing tracks in the sequence is now working fine and updates all UI items properly.

Right now I am also giving the dialogs an overhaul. All got a default action (e.g. press enter to dismiss). They also get moved into a separate object each. This helps to test them standalone and to auto-screen-shot them during the test runs.

Finally I spend some time configuring our buildbot. For the first time all steps are green. The machine the test run on does not have X11 running. Still we can run UI tests and do screenshots of all windows. The magic can be found in a few helper methods that pick a free display number, spawn a Xvfb server and setup a GdkDisplay for gtk+. The buildbot stuff definitely rocks! I hope we can extend this in the future - anyone found a way to trigger builds from sourceforge.net cvs commits (via commit hook)? Make me happy and mailto: ensonic (at) users (dot) sf (dot) net.

life

Over new year I've been back in germany with my girl friend for a week. Finland is not bad, but still we miss quite a lot of things:

• Döner Kebab - don't laugh, in case you visit Leipzig (my hometown) once, go to Connewitz and have a Döner, for 2 €, just delicious
• breakfast rolls - the finns have them here too, but its just not the same
• same for beer and sausages :)

This month we fleshed out the planning for 0.2. From now on we like to release often and regularily. We defined a lot of small gtk ui tasks. If you like to help, we welcome you with open arms on irc://irc.quakenet.org/#buzztard.

First changes after the release are already in CVS. I worked on the buzzmachine emulation. I can now handle some more plugins. We need to update and re-run the coverage tests to get a clear picture. Regarding wrapper gst-elements we have a bug in gstreamer bugzilla that needs some work.

I also worked on the UI a bit more. The machine preferences and properties now have some reasonable size. Its not easy to get a default size for generated UIs. Right now I clamp the height to the screen-height minus some extra. Would be nice to have some way to figure how much space one should leave for upper/lower panels. I also needed to add a workaround for the window-width wobble. If you had sliders with labels in the UI, the width was dependent on the label with.I can't really know the maximum width beforehand easily, so I had to set a default width. Good enough for now.

I also started two new inerfaces for gstreamer elements. First one is about the help documentation of the element. Buzztard can show the docs of buzzmachines or the gtk-doc of native element already. The second iface is about the preset handling. Implementing that for the buzzmachines is next on the todo list.

Finally I also started to put some gstreamer element check into the core lib. During configure we can check for installed elements and it would't make sense anyway. So we are going to check for mandatory and optional elements at application start. Checking works fine already. Now I need to add the UI dialog for the missing elements report.

Have a nice christmas month - we'll get back to you next year.

Finally! We did release 0.1 "genesis". In June 2002 we registered the project and started thinking. For more than year nothing big happened. In February 2004 the first GStreamer example code landed in CVS. That was using GStreamer 0.8. Then the metamorphosis began: using GObject, adding unit tests, API docs, user docs and so on. In August 2005 came the switch to GStreamer 0.10. In summer 2006 our team grew from 2 to 4 developers. The whole project already contains 139000 lines of code. Downloads are available on the sf.net project page. Instructions for building are on the project wiki.

Even though the current code is maybe a bit rough and the applications are not that usable yet, we're confident that new releases will follow quickly and bring the missing pieces. If you want it happen faster, join the project. We have lots of tasks, some with a fleshed out concept, some merely ideas, some suitable for not so experienced developers, so quite tricky. Give us a visit on irc://irc.quakenet.org/buzztard.

Zeenix posted his ideas a few days agao. Here are mine. The idea is to have a proxy element for remote elements so that you can treat the whole pipeline as a local one. The proxy element creates the real instance by talking to GOD (GStreamer Object Daemon, GObject Daemon, ...) on the respective machine.

At runtime when the proxy-element receives data it sends it to the remote element and after processing it gets it back and forwards it to the element. The challenge is to optimize links when multiple conected elements are on the same remote machine so that the data gets passed directly there.

proxy creation

In addition to

GstElement* gst_element_factory_make (const gchar *factoryname, const gchar *name);

we need:

GstElement* gst_element_factory_make_remote (const gchar *factoryname, const gchar *name, GstRemoteFactory *remote);

and some API to get a remote factory handle via hostname lookup, ip address lookup or even zeroconf (avahi).

So how does this sounds like. Anything in here that definitely wont work?

In the past I was using the freedesktop.org syncmail script for my repositories on sf.net. The advantage over the sf.net one is, that it also sends a mail with links for viewcvs. Now since May when sf.net changed the cvs infrastructure the scripts stopped sending mail.

Recentry I stated to analyse the problem. Wayne Davison of sf.net pointed out that the email system changed and the fdo script was using sendmail directly. Okay, with my nearly non-existent python skills I rewrote the fdo one to send mails to the smtp on a given port. I tested the script on a local cvs repository and it worked. Still on the sf.net site it didn't. Its not easy to debug it if you can't see the output :(

This was when I had the smart, but lethal idea. I've added 2>commitinfo.log to the hookscript invokation in commitinfo (and the same for loginfo). Then I've added the logs to the checkoutlist file. The plan was that by checking out CVSROOT I get the logs. Unfortunately CVS tries to be smart and quotes the stderr redirect and passes this as the first arg to the hookscript. This then fails to parse it and aborts. CVS in turn interprets this as hookscript check failed and thus rejects the commit. Bang!

Fortunately the sf.net admins commented out the broken entries, so that now I can commit stuff again. Had anyone more succes with adapting the fdo syncmail script?

Finally I found some time to work one one thing that was getting on my nerves. For the unit tests we now have a BtTestSettings class. This allows us to simulate all sort of settings. The other benefit is that we don't need to make sure that we don't modify user settings during test runs. And we get not hit by my favourite GConf nastyness anymore [1].

Next I did a lot more bugfixing in the UI - or lets call it implementing previously unimplemented stuff. Added some more tooltips here and there, syncing data displays and so on.

Waffel spend some time so set up a buildmaster and a buildslave. This way our code gets rebuild every 6 hours. The 6 hours cycle has two reasons - our cvshook-script (from fdo) does not run on sf.net and the sf.net anon-cvs has a big delay. Anyway even the current setup revealed some bugs, where some of them are already fixed.

Tommi fights with cairo to build a real pattern editor widget for us. Hope we can post some screenshots from it soon.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=316331

I really hope Advogato remains online. I checked some blog software packages, but none was convincing. I would need one that is multi-user capable and imports the rss-0.82 feed happily.

buzztard

Lots of news this time. Also this time I welcome another team member on board - Tommi 'nbd' Sakari Uimonen. His first action was a code review of the core lib and a big patch that const'ified it more. By giving him a quick demo of the application we also uncovered a lot of bugs. Next nbd will work on a pattern editor widget.

Berzerka implemented song-length changing. The list will be dynamically expanded as one scrolls down. Also keyboard shortcuts are coming to set Length and move the loop area.

While we were working on the sequence display, we fixed the step filtering for different rhythms and also implemented many details for rhythm support (other than 4/4). Speaking of the GUI - lots of changes there. The machine view looks a bit nicer and has some zoom and layout fixes. Zoom fit was a bit harder than expected and seems to be still not always be correct. The context menu to add machines is now hierarchical. In the status bar we now show CPU usage. At least during development this is quite useful.

Lots of code has been added to handle error situations better. If you load songs with missing machines or samples, these components will be tracked. After loading we present a report of missing elements. Later we can add machine download or to specify a new location if the sample has been moved or renamed.

Many task were done to prepare a first release. We now have a nice about dialog. It also shows the latest release notes. This dialog will always be shown once after updating. The user guide is more complete. German language catalogues are complete. Finally a lot of cruft code has been removed.

I also worked a bit on the buzz machine emulation. It now also support stereo machines (need more work on the application side). The example buzz songs have been fixed. The now all play again. The gstreamer buzzmachine plugin generates better parameter names. It also maps some parameters to enums. Instead with a slider, they are presented as a dropdown then.