From Buzztrax

Jump to: navigation, search

Below is a list of future ideas, things todo, etc. Some of the items are especially well suited for new contributors. All the sources are written in C and thus knowledge of C is required. The project is using the GObject model for object orientation; Some experience with that is definitely helpful. In any case, we're happy to get new developers started in our irc channel, but many resources are given in the developer section of this wiki.

When adding new ideas, describe the objective, do some research (add links) and try to break a task down into steps with expected results.


The UI is written using gtk+2.0, cairo and gnome-canvas. There are many ideas to improve things here and there. Most of the tasks below are relative easy and will be naturally quite user visible.

move own widgets into a separate lib

Having a separate library would ease sharing the widgets across applications. We could name it src/lib/libbuzztrax-widgets. It would contain: vu-meter, volume and panorama-popup, waveform, pattern editor. We'd move the widgets, the tests and the documentation.

no popup windows

Right now a couple things appear in separate windows; e.g. the machine properties/preferences and signal analyzers. The user needs to place these windows as they might cover something else. It would be nice to have dedicated areas in the main window that will take these views. We don't need to change this for modal windows (settings, recording).

We should consider this for all the views. We can always have a left or right pane with browsing and details.

embedded help viewer

Having an embedded help viewer would allow smoother help integration. We can show different help documents in the same way, without leaving the application.

Trusktr's UI Ideas

Trusktr's Ideas on UI improvements are a list of tasks we're currently discussing as a student GSoC project.

step resolution need better visualization

Choosing "step>1" in the sequencer can cause pattern-events to be hidden, as we would just show patterns that start on every n-th tick.

  • we could try to paint fractional rectangles into the back of the cells to show patterns
  • we could add ellipsis to the label (or some other mark)

We should consider departing from using a GtkTreeView and having an own widget to show an edit the sequence.

Audio plugins

Buzztrax uses GStreamer for all the media processing. Work on the plugin is beneficial to all the apps using GStreamer.

Port the LV2 plugin to gstreamer 1.0 api

The lv2 wrapper plugin in gst-plugins-bad registers installed LV2 plugins as gstreamer elements. The current code has not been ported to the gstreamer 1.0 api. In addition the lv2 plugin was based on the slv2 library, but should now uses the newer lilv library.

The basics for how a wrapper plugin works have not changed from 0.10 to 1.0. Also the ladspa plugin has been ported and can serve as example code.

Expand the buzzmachine loader (bml) to use IPC on x86_64

The buzzmachine wrapper plugin can load win32 buzz plugins. In cases were binary only dll plugins are available, those only work on 32bit x86 linux systems. We could expand the bml library to use IPC to run load the plugins into a 32bit process.

Write a VST wrapper

VST is a major standard for audio plugins on windows. Many free vst plugins are available. It is possible to run vst using a similar technique as implemented in libbml for the buzzmachines. Alternatively a ready made solution like libfst can be used.

Application features

Some of the ideas listed below mostly come from feature requests. Most of them are easy to implement.

output scores

It would be nice to be able to get a printable score for a song. This could e.g. be done via LillyPond or GuidoLib). The main work of this task would be to format a song into a suitable input for the above tols/libraries. It would be implemented in buzztrax-edit.

data exchange with a sample editor

Editing capabilities in the waveform view are quite limited. It would be nice to write a sample to a temp file and fire of an external editor (e.g. audacity, marlin, ...). Once that terminates, we'll read the file back. Having a working mechanism here would be nice for the future when we have more asset lists (e.g. pictures and video clips).

Open questions:

  • how to ensure that the external app saves to the temp file
  • can we rely on the external app exiting?

importing tracker songs

Many people started making music using trackers (such as FastTracker or the original SoundTracker). Buzztrax already support song-io plugins. It would be nice to write an import plugin for tracker mod files. The main challenge here is to come up with a useful mapping of the song-structure in a tracker to the song structure in buzztrax, so that one can nicely edit the song. For this one probably needs to create single tracker machine instances (e.g. Matilde) per sample and extract events from the shared patterns.

pattern recording

The idea is to records slider movements from machine ui into the pattern. Right now we have a hot-key (',') to enter the current machine parameter into the pattern. This idea is about recording a whole column.

Open questions:

  • if there are multiple tracks for the machine, we need to select which track to record (e.g. the one the cursor is in)
  • should we play the pattern in a loop or just a single time?
  • should we trigger the playback by the first control-change?

machine templates

Buzz can import songs as templates. This would only import the setup part from the song.

more native machines

The gst-buzztrax module has base-classes and components for effects and synthesizers. There are a bunch of nice ideas fleshed out in the TODO file as well. Implementing these and more should be quite fun.

osc support

OSC is a network protocol. In buzztrax it would allow us to e.g. export the machines in a song and play the from hardware controllers (like we can already do with midi).

project generation for multitrack export

When rendering a song as multiple tracks, it would be nice to also generate a project file for a multitrack audio editor.

text event support

Right now we only support sound clips that can be used for audio. It would be nice to manage text assets as well. These can be used for the song-lyrics as well as for speech synthesis. See text support for more details.

video support

While Buzztrax is a music composer right now, it would we interesting to extend the concept to cover video rendering as well.

Core design

The topics in these category are mostly thing we don't have a good plan yet. Working on that is more difficult and might require interacting with other projects and submission of patches there.

embedded scripting engine for extensibility

Many UI related featurs are not time critical. If such features could be developed as an extension using a scripting language, these could be easily written by users. We've started to try some of the options as small examples. While technically this already looks quite doable, we need to work on the design (like what extension points to provide (menus), how to manage the extensions (discover, install, enable/disable, remove, configure)). For this one would take a look how extensions e.g. are managed in browsers and what kind of extension points are offered there. At the same time we need to collect ideas for plugins. This can be new features, but also moving existing features into plugins.

property hashmaps

Some objects (e.g. machine, setup) have a property hashmap, so that e.g. the ui can attach properties there. This almost replicates the g_object_(s|g)et_data (or _qdata) functionality. Problem is the persistence code - the data-list of objects cannot be iterated :/ We could propose new api for glib to query a list of strings that describe the keys on the data list of a given instance.

collaboration hierarchy and lists

Several of our classes have child-elements. Doing bt_child_new() adds it to the list. The new methods should get the parent to avoid bt_child_new() looking it up often.

What about making the parent parameter optional (if NULL it will be looked up):

bt_child_new(BtParent *parent, ...) {


  // add child to parent
  if(parent) {
  else {

This applies to:

  • bt_wire_new(const BtSong *song, const BtMachine *src_machine, const BtMachine *dst_machine)
  • bt_machine_new(BtMachine *self)
    • bt_processor_machine_new(const BtSong *song, const gchar *id, const gchar *plugin_name, glong voices)
    • bt_sink_machine_new(const BtSong *song, const gchar *id)
    • bt_source_machine_new(const BtSong *song, const gchar *id, const gchar *plugin_name, glong voices)
  • bt_pattern_new(const BtSong *song, const gchar *id, const gchar *name, glong length, glong voices,const BtMachine *machine)
  • bt_wave_new(const BtSong *song,const gchar *name,const gchar *file_name)
  • bt_wavelevel_new(const BtSong *song,const BtWave *wave)

handling id attributes

Elements that can be referenced have an id in the song file. Currently that is machines and patterns. To make the XML well-formed the ids need to be unique. For machines we have:

gchar *bt_setup_get_unique_machine_id(const BtSetup *self,gchar *base_name);

For patterns we concat machine-id and the pattern name.

gchar *bt_machine_get_unique_pattern_name(const BtMachine *self);

Shouldn't we generate pattern ids when saving ? E.g. by using the memory addresses of the objects. When loading object with ids, we use a hashmap in the song to resolve them. (get_object_by_id). Then its totally up to the user how to name items. It should be enough to generate unique id on save time.

Source code maintenance

Everything is changing. New apis appear, some get deprecated. Using an unsupported api is not good. Using new apis need some planning to ensure it is widely enough available. Some of the refactorings are straight forward, some of them next a bit of prototyping (e.g. moving from a larger deprecated api to a new library).


source code cleanups

These should be done and the conventions need to be added to the Coding Guidelines

  • care about song->unsaved (call bt_song_set_unsaved(); )
  • disconnect "notify::" handler when disposing the object
    • add tests to ensure this does not regress
  • swap comparisons with constants (result==TRUE becomes TRUE==result and result==5 becomes 5==result)
    • the advantage of doing so is that the compiler can detect a missing '=', because one can't assign something to a constant
    • what to do with '!=' as here it is not a problem
  • replace comparisons with plain numbers with symbolic constants
    • event->button.button== and event->button==
    • grid_density==
    • type == 0 -> !type
  • use something like G_DEFINE_TYPE for object construction to save typing
  • in bt-edit settings-dialog.c uses weak-ref on app, other -dialog.c files use hard-refs, which is better in this case?
  • use G_GNUC_INTERNAL in libs to mark internal helpers

review error handling

Our error handling is not very consistent. This would need to be reviewed and improved. The task requires initial review round with the core developers on the conventions.

  • g_assert() vs. g_return_if_fail()
    • precondition checks
      • each public method needs a g_return_(val_)if_fail() block at the begin to check incomming parameters
      • private methods can use g_assert(self) here (as this is an internal fault if it fails)
      • never use g_assert() for public API precondition checks as this is always fatal and thus e.g. aborts test-casse without letting us intercept the message
    • post condition checks
      • use g_assert as a failing post-condition check signals an internal error
    • other checks
      • when e.g. verifying the internal state of self->priv (own object) then also use g_assert()
  • if we need -1 return values in methods, we should better use an extra g_error out-arg
  • do tests runs with --g-fatal-warning to find untested code that fails
  • GError usage
    • remove/review GError from machine.c and wire.c
    • use GError for funtion that are called by e.g. UI and that require human readable errors (like song-loading)

generate setter and getter methods

We use g_object_set/get almost exclusively. This is short and needs no extra work, but has that disadvantage that we lack compiler-type checking. In addition sometimes we need atomic setters, where we update n-properties together. Writing setters and getters by hand is tedious though (they also need docs). As this is a common issue for all GObject based app, this would need to be discussed with the glib developers.

The general idea would be to have something like:

 * fullname: lastname,firstname
#include "person_fullname.h"

A generator would parse the comment above the include and generate the setters and getters including gtk-doc comments for them.

There are a few open quitions though:

  • we like to influence the generated docs (add a comment thats gets included)
  • we need to point the tool to the gtk-doc sections-file so that it an add the prototypes there
  • setters might need some code to be executed after all items have been set.


We'd like to deliver good quality software. Making use of exiting tools that can find bugs before software gets released is important. Below is a list of tools that we'd like to take a closer look at. We'd like to integrate them into the build process or document how to run them.


We have a quite extensive unit test suite. But there is nothing that cannot be improved. If you are test-infected, this is an area to get crazy at.

  • try more testing monitors (besides valgrind's memcheck)
    • try Diota
    • looking ASan/TSan
  • disable all negative tests when we don't have debug enabled
  • test more refcounts harder
    • do a checked_unref(song) first and the do checked_unrefs of the machines, wires, ...
    • will detect more ref-count issues
  • look at the coverage reports and write more test for uncovered areas
Support Us


GStreamer Logo
Become a Friend of GNOME
Linux Sound Logo
GNU Library Public Licence
GNU Free Documentation License 1.2