Older blog entries for ensonic (starting at number 142)

gtk-doc

Just released gtk-doc 1.20 with lots of bugfixes and feature request implemented (32 tickets closed). If you are a developer, fetch it and rebuild your docs - I hope you like the new look!

The biggest feature is the large improvement over the rudimentary markdown support gtk-doc had - thanks to William Jon McCann for the contributions. Take a look at the manual to learn about the new syntax. We chose markdown, so that the syntax looks good in the sources and you can already go ahead using it. If someone builds with an older gtk-doc things might show up as is, but thats not the end of the world.
sndfile plugin for gstreamer 1.X

A merry christmas to everybody. As a little present for musicians, I started a rewrite of the sndfile plugin that had not been ported from gstreamer-0.10. The new version will not be consist of sfsrc and sfsink, but instead of sfdec and sfenc. For now sfdec exists, it can read a bunch of formats that we did not have support in gstreamer so far - xi, sds, 8svx/16sv, w64, ... and it works with playbin and co. I'll need to collect more test files to test all features. I'll also write the encoder/muxing part next.

libsnd file has good support for audio files that are used as instruments. There are quite a ew things that I can't map to gstreamer yet:

  • base note - could be a tag

  • loops - could be a special toc edition, but that sounds like a little abuse, some form of edit-list support would probably be better

  • envelopes (e.g. a volume envelope)

Maybe I can start with some element-messages for now.
buzztrax ui porting

The last two month I mostly worked on porting the UI from gtk+2 and gnome-canvas to gtk+3 and clutter. First I ported our own widgets (vumeter, waveform-viewer and pattern-editor). This was relative straight forward. One issue were the colors. I was using GtkStyle->bg[state] to draw the background, but the color there is simply wrong. Will have to see if things look better if I use GtkStyleContext.

I also wrote a prototype for a gnome-canvas replacement using clutter. This looks nice now and I am quite excited about the potential for adding nice stuff in the future. Clutter is a lot more powerful than gnome-canvas.

Right now I am in the middle of porting buzztrax-edit to gtk3. The application already compiles and starts. Getting it back to compile was about two evenings. Biggest work was to replace the v/h widgets with the orientable variants. After that came a lot of soft-breaks, e.g. "expose-event" signal -> "draw" signal. Some of the things are documented, but e.g. what to do as an application if you where using the "size-request" to provide a sane natural size to scrolled windows is left as an exercise to the reader :/ Next came attacking all the layout changes. I've figured solutions/hacks for many of them, but I guess this will keep me busy for a while.

On the machine view, I'll also need to do a lot more work. The basics work, but there is quite a few things commented out still. Many thanks to the folks in the clutter irc channel for their help so far.

700 files changed, 21979 insertions(+), 17892 deletions(-)
buzztard is now buzztrax

We applied as an organisation to take part in the Google Summer of Code program, but got rejected mainly due to the project name. As this was not the first time people where uncomfortable with the name, we renamed the project - buzztard is now called buzztrax. The homepage with the wiki and wordpress already got moved. The renamed codebase is online at github. The mailing lists have been migrated to buzztrax.org. A few things still need to be fixed (e.g. file releases).

Besides the renaming there are also some improvements on the code side. I am probably the last one to discover the g_signal_handlers_disconnect_by_* macros. Using these made the code a bit leaner. I also worked on the level-meter features. I did some cleanups on the widget. The syncing code is more efficient as we listen to sync-messages on the gstreamer side to avoid another thread round trip. Song rendering can disabled the level-meters for less noise on the screen and some performance savings. The song-rendering now uses the TOC support in gstreamer-1.0. That means that the labels of a song (intro, chorus, break, ...) will end up in wav and flac files right now. When other formats support toc, this will automatically work for those formats too. The flag in ogg muxing got fixed in upstream and now works for us again.

56 files changed, 715 insertions(+), 631 deletions(-)
buzztard & gstreamer hackfest

This month I mostly cleaned up small bits and pieces from the gstreamer-1.0 port. Most notably multitrack encoding works again. The handling of EOS and starting of the next track was racy. Speaking of the recording dialog - this one now has some basics for a silent mode implemented. For now it only disables the scrolling in the sequence view. Next thing would be to disable the level meters.

I hacked a bit more on the child-proxy iface. This now turned into utility functions that allows to write:
bt_child_proxy_set(obj, "prop1::prop2::prop3", val, NULL);
So what does this do?
GObject obj1, obj2;
g_object_get(obj, "prop1", &obj1, NULL);
g_object_get(obj1, "prop2", &obj2, NULL);
g_object_set(obj2, "prop3", val, NULL);
g_object_unref (obj2);
g_object_unref (obj1);

This saved quite a few lines of C in buzztard. I wonder if this is something we want to add to glib? If we do I would go for a single ':' as a separator and we might also want to consider starting the property with one:
g_object_set(obj, ":prop1:prop2:prop3", val, NULL);
The leading ':' would help to quickly detect whether we need to split the property name and recurse into child objects. The whole scheme is backwards compatible as property names are not allowed to contain ':'.

In the end of march I attended the GStreamer hackfest in Milano. First I looked into a few tests - both on GStreamer and buzztard side. On the GStreamer side adder has some test fixes. On the buzztard side I improved my encoding tests. Wim gave me the crucial tip that fixed the dynamic adding/removing of analyzers while playing. Maybe I can try that for machines again. I showed the parser for controller-setups to some people and did smaller changes on it. I also discussed what we could do with gst-tracelib for gst-1.0 and started a new design-draft for it.

41 files changed, 871 insertions(+), 816 deletions(-)
buzztard

As I already mentioned in last months issue, I ported buzztard and gst-buzztard to use gstreamer-1.0. It will require 1.1.X for some fixes in gstreamer itself. So how did it went. The basic porting to make it compile against 1.0 took about 20 hours spread over a couple of days. It is quite straight forward. I updated the porting guide where things were not mentioned.

The more tricky part where the soft api changes. At this port I was running the apps with G_DEBUG=fatal_warnings. The property name changes here and there we easy to fix. Also request pad name changes (%d -> _%u) took not too long to handle. Other things like caps negotiation kept me busy for a few evenings. For once I was e.g. writing GST_AUDIO_NE ("S16") instead of GST_AUDIO_NE (S16) which leads to caps negotiation failing. Another recommendation is to avoid setting channel-mask=3 for stereo caps. It is purely optional, most elements drop it anyway and by leaving it out, you can merge the mono and stereo caps.

I ported freeverb in plugins-bad and made fixed to audiopanorama and adder. Adder and collectpads have a few more new tests upstream. Another things that took a while was getting seek-in-ready to work again. Buzztard needs to configure the playback segment from the application, as the sources happy beep for all eternity. In 0.10 I could send a seek to my bin in ready, in 1.0 it gets dropped (pads are flushing). Now I recursively iterate over sources and seek on all of them. This is only needed to get to playing. To get these things fixed I ported a few of my stand alone examples, but the majority of this is still left unported.

Now the basics seem to work. I am confident that I can fix the remaining issues in march and look forward to attend the hackfest in Milano over easter.

The porting for buzztard:
69 files changed, 1909 insertions(+), 1473 deletions(-)
The porting for gst-buzztard:
34 files changed, 1254 insertions(+), 1414 deletions(-)

The other thing I was doing this month was to experiment with embeddable scripting engines. I wrote a toy gtk app that opens a window, sets up the scripting engine, registers a function to get the window handle and start a script that calls the function to get the window and adds a vbox with two labels. I did that for lua, seed and gjs. For lua it took 30 min, for seek it took 30min, for gjs it took 2 hours and is still not working fully (the custom function returning a gobject).

69 files changed, 1907 insertions(+), 1507 deletions(-)
buzztard 0.7 is out

We started the year with a release in the beginning of January. So far only a few issues were reported. Patches for these are on the 0.7.1 branch. One last minute change in 0.7 was the departure from trying to link/unlink elements in gstreamer while playing. I sadly have to conclude that in 0.10 this only works for some cases. It was working sort of okayish for buzztard, but the were still deadlocks or internal dataflow errors from time to time. One such scenario is that when you happen to reconnect elements while the song loops. These things are not easy to sync from the application level. Lets hope this is easier in 1.0. The sticky events should help with setting up the context from new elements.

On the mainline I bumped the required library version and removed the ifdefs for the backwards compatibility. As a first bigger change, I ported the settings from gconf to dconf. We had a settings abstraction to other gconf or play keyfiles, which we now removed. Altogether I kept to use an intermediate object that exposes settings as a gobject with properties for the keys. This allows to use notify to bind to property changes instead of using a custom api.

Then I started with porting gst-buzztard & buzztard to gstreamer-1.0. I made good progress. I will report the details in the next update.

77 files changed, 5892 insertions(+), 8131 deletions(-)
buzztard

Happy new 2013!

Besides a lot of testing and little bug fixes here and there I finished of a few half ready features. One is range-randomize (press Ctrl+Shift+R). In contrast to randomize which takes the parameters min-max value as bounds, this one picks the bounds from the first and last value in the selected range. The other one is that now one can rename machines also from the sequence headers. I was afraid that swapping the GtkLabel with a GtkEntry would use too much space and look ugly, but luckily one can turn off the frame. I still get a different background color though.

During testing I noticed some inconsistencies when renaming machines and found a rather bad data corruption. Certain interaction would create songs that won't read back fully. One can manually fix them up (it is xml after all). I fixed the bug and could even make the format a bit simpler. I had to touch quite a few places:
30 files changed, 246 insertions(+), 404 deletions(-)
Old songs can still be read, but songs written with the new version, also need the new version for reading. One lesson learned, the 'id' attribute in xml is special.

Another results from testing is that the shell based test scripts can now be run standalone to check a bunch of songs (do syntax check, print stats, convert or encode songs).

Finally I entered string freeze for 0.7. I already received the first updates for the translations, thanks a lot! I am looking forward to release it soon.

I uploaded some example song snippets to soundcloud.

438 files changed, 3138 insertions(+), 2800 deletions(-)
buzztard

Finally pushed the pattern control-source: 26 files changed, 1204 insertions, 1333 deletions. It looks like only a little gain in code size, but that is not true; we added more tests and splitting up a large class always comes with some boilerplate for the new class. There are still some opportunities for optimizations, which I'll probably try some soon.

In the UI I improved the interaction controller workflow. For controllers that implement control discovery the dialog from the context menu will also bind the new controller. The settings are now finally useful, as there one can do mass-learning (tweak all knows and then go through the list and name them).

Writing synth plugins for buzztard would be quite a bit of copy and paste. I chopped simsyn into pieces as reusable objects in libgst-buzztard. We have a few oscillators, envelope objects and the svf-filter. The gst elements would proxy some properties of the synth component. Unfortunately that means copy'n'paste of the property setup. I've tried this code, but it shows no effect :/

GObjectClass * filter_klass = g_type_class_ref (GSTBT_TYPE_FILTER_SVF);
g_object_class_install_property (gobject_class, PROP_RESONANCE,
g_param_spec_override ("resonance",
g_object_class_find_property (filter_klass, "resonance")));
g_type_class_unref (filter_klass);


A full standalone example can be found at here.

We also have a new element called wavereplay. This is mainly for testing the wavetable oscillator, but also has a nice property compared to tracker elements. It only has parameters to select the wave to play and it will play it from start to finish in syn with the song. That is if you seek to 2:00, the wave will play content from 2:00. This is unlike tracker elements that would only play what gets triggered from the new time position. One practical use is doing a mixdown of the music rendering with the vocal recordings. In such a song you load two wave (song, vocals), use two wavereplay elements, add effect elements to the one for the vocals and re-render the song to create the mixdown.

I thought I knew pretty much all about gobject. This month I discovered something old I did not know about. It is supported to calls g_object_class_install_property() for a property inherited from the baseclass to e.g. narrow down the value range. This is very useful for the "children" property of polyphonic elements (where children is the number of voices). The interface does only limit the property to the full int range. With this feature elements like e.g. sidsyn can override the range to 3...3 (sid has always 3 voices).

The last bigger change this month was a refactoring cleanup in sequence and song-info. This was quite a big of code shuffling, but now all the timing info is in song-info (which already has bpm an stuff). This change helped with an optimization in the pattern control-sources.

132 files changed, 2417 insertions(+), 2138 deletions(-)
buzztard

After a discussion on IRC about tunings I looked into adding some of those to the ToneConversion class which so far only implemented the usual equal temperament. I have to say the wikipedia articles on this matter are awesome, detailed and plentiful. I added two 12tone tunings to the ToneConversion class now and implemented tuning in sidsyn and simsyn.

I also had a look at the TODO comments and planned items on the wiki. When I was writing the list model classes I did not wrote ones for the wavetable and wave-level-list. I did this now. The list models can also be tested separately from the UI (which is harder to test). I wrote basic tests for all model classes which bumps the test coverage in the ui by 10% (61% classes have tests now, 105 ui tests).

IRC was quite active this month. Another chat was on the wave-table page and wave-preview. The workflow was indeed needless complicated. Now preview is a toggle and if it is active, moving the selection in the file-browser will play sounds. Other discussion motivated me to implement audio-device selection in the settings. So far one could only select the protocol. Now for e.g. alsa or pulseaudio one can also choose to which device to play the audio. While working on the settings I started to make the interaction controller setting more useful. So far the only use of this settings-tab was to list the detected settings. I added a couple of messages to help the user to know what to do when e.g. the list of devices is empty. And I started to implement batch-learning of controls to the settings.

84 files changed, 4199 insertions(+), 1653 deletions(-)

133 older entries...

New Advogato Features

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!