Buzztard

buzztard project status 01/05/2012

ensonic — Wed, 16 May 2012 15:05:36 +0000

More cruft removal this month. We dropped some more configure options (thanks Adrian) and removed more old/unused code. The project also got the first commits merged from Thomas – our GSoC student.

The pattern class had a boolean parameter to chose between command and data patterns. I refactored that into a proper class hierarchy. The downside of that is that we need more casts now :/

I also continued in the duplicated code cleanups. We have now a value-group, that holds the pattern portion for a parameter-group. This way I could remove lots of code from pattern and sequence. Finally I could also remove wire-pattern itself. I am not totally happy with the extra code for loading and saving now, but have some ideas here too.

The UI tests have a couple more helpers to synthesize events and saw a couple of cleanups. The tests have been really useful for all the refactorings.

97 files changed, 4684 insertions(+), 5279 deletions(-)

Buzztard UI Overview

ensonic — Tue, 17 Apr 2012 19:02:12 +0000

In the hope that this helps to get you started with buzztard, I present the high level UI Overview. Let me know if you have ideas to improve it.

buzztard project status 01/04/2012

ensonic — Tue, 03 Apr 2012 19:40:14 +0000

I started hacking on the transport settings. The idea here is to have a generic scheme for how to control playback (start, stop, seek) externally. This can be a midi-controller, but also qjackcontrol or a MPRIS applet. The setting now show the available modules and allow to enable master and slave mode as well as mode specific settings. I could remove the combobox from the toolbar again.

As a next big thing I started to refactor a big chunk of duplicated code in core. Machines have global parameters, per voice parameters and per incoming wire parameters. Now we have a parameter-group class that deals with those.

I spend the rest of the month cleaning up the test suite and the autofoo setup. On the latter I bumped the required versions. The policy now is to support the linux distributions from about the last two years. This allowed me to remove large chunks of conditional code. Unfortunately it is not easy to do that. The easy part is to check what versions we require, by looking at the pkg-config macros in configure.ac. Then we can also grep for conditional section in the code:
find . \( -name "*.c" -o -name "*.h" \) -exec egrep -o "[A-Z]*_CHECK_VERSION\(.*\)" {} \; | sort | uniq
Now the tricky part is to figure what distributions ship. It is somewhat easier for debian/ubuntu as they have pages like:
http://packages.debian.org/search?suite=all&arch=any&searchon=names&keywords=libgstreamer0.10-0 http://packages.ubuntu.com/search?suite=all&section=all&arch=any&searchon=names&keywords=libgstreamer0.10
For fedora Company suggested to look at the spec files in git and iterate over the branch names
http://pkgs.fedoraproject.org/gitweb/?p=gstreamer.git;a=blob;f=gstreamer.spec;hb=f17
For opensuse Vuntz suggested to use an osc query at which I failed misserably and in the end checked the packages in the repo and iterated over the versions:
http://download.opensuse.org/distribution/12.1/repo/oss/suse/i586/
Anyone know better tricks? Please share them!

One more motivation for doing this is upcomming gsoc. If I am lucky to get a student who will port buzztard to gstreamer 1.0. We’ll release a 0.7 of buzztard before we switch to the new gstreamer api.

212 files changed, 7954 insertions(+), 7778 deletions(-)

buzztard project status 01/03/2012

ensonic — Thu, 01 Mar 2012 20:49:29 +0000

As a big leftover promise from my talk at the GStreamer conference in 2011 I spend more time to understand latencies inside GStreamer. For plain playback the latencies are not an issue, but for anything interactive, be it entering notes or changing parameters while the song is playing, we want much lower latencies. For the talk I did some measurements by having a pipeline with two branches – src1 ! sink and src2 ! fx1 ! … ! fxn ! sink. The fx elements where plain volume elements. The branches where panned hard left and right. For the experiment, I was pulling down the volume on the two sources down to 0 at the same time and recoding the audio on the sink. Looking at the wave, one could see the delay in the signal that went through the effect-chain. The longer the effect-chain the larger becomes the delay. Don’t misunderstand this, GStreamer is properly handling A/V sync. The buffers that get mixed in front of the sink have the same time stamps, the problem is that we have a lot more buffers traveling the the effect-branch. This is because of the queue elements. In buzztard one can freely link generators to effects, effects to effects and effects to sinks. This includes diamond shaped connections. Here we need queues to not stall processing on one branch. It is sufficient for the queues to keep only 1 buffer. Still even knowing the buffer duration, I could not tell a formula to explain the measured delays.
This month I looked at the issue with a new idea. I wrote a small example that build pipelines close to what I have in buzztard, but stripped of many details. In this code I add buffer probed to all pads. The probe is comparing the time-stamp on the buffer to the pipeline clock. This tells how early the buffer is. Ideally we want buffers to be generated and processed as much in time as possible. When generating audio one needs to configure audio-buffer sizes on the source elements and two properties on the audio-sink – buffer-time and latency-time. A good scheme is to use buffer-time = 2 * latency-time. That configures the sink to have two audio-segments. Initially I also set the buffer sizes on the source elements to have a duration of latency-time. Now one problem with that is that we will have one buffer waiting on each queue. Thus if there are two queues the actual latency is (n-queues + 1) * latency-time. One way to improve that a bit is to half the buffer sizes on the sources, then the 2nd buffer is calculated when the first one is needed. As the first one won’t be sufficient to fill the gap, the calculation of the 2nd buffer is scheduled right away. The disadvantage of this scheme is that one gets quite jittery latencies. In the end I settled on finishing the subtick timing in buzztard. Each tick will have n subticks, where n is setup so that we get down to the desired latency. So far I get nice low latency on all my machines (inlcuding a atom based netbook).

We also ported more buzzmachines and have 49 machines right now. When porting we often also fix bugs as gcc is quite good at warnings these days. Finally, the machines now also install docs (where available).

In the UI I got rid of the GtkRuler copy again. The analyzer window now has own code to draw the rulers. I think they look nice, a lot less noisy then the older rulers.

62 files changed, 1957 insertions(+), 1844 deletions(-)

buzztard project status 01/02/2012

ensonic — Sat, 11 Feb 2012 17:22:06 +0000

The first big change after releasing 0.6 was to move from svn to git. SourceForge offers git since a while, but does not provide any tips how to do the transition. Fortunately it is a popular topic though. I used svn2git for the main conversion. I fixed the author tags from svn commit messages (Patch-by:) manually using git rebase -i as I could not get a filter-branch script for it to work. A few times gitk got confused and I had to remove my .git/gitk.cache, one symptom are missing tags. I updated the enlistments on ohloh and tweaked the git hooks to have the same functionality as before.

A first code wise change was to move the bsl module into the buzztard one. It is a small module for the buzztard song-loader plugin and it is not needed if you don’t want to load buzz songs. But it is small and has no further dependencies and thus it is easier to just include it. Especially as we plan to add other loaders in the coming cycle(s).

In the editor I bumped the required gtk version to get rid of some #ifdef and be able to use newer API. I replaced the ruler widgets in volume and panorama popups with with scale markers. Those look nicer and take the scale handle size into account. Unfortunately they were almost untested. I made the needed patches for gtk-2-24, gtk-3-2 and gtk-HEAD [1],[2]. I could also made workarounds for the issue for the time being. So for the time being, don’t use inverted ranges on your scales and don’t use an adjustment with fractions (use 0 .. 100 instead of 0.0 to 1.0).

Most of the work went in the the interaction controller. The controller assignment in the UI is a bit more discoverable (content menu not only on main widgets, but also on the label and value label). Controllers can be assigned to combo-boxes too (mapped to enums). We have controllers for note-on midi messages and the velocity that comes with it now.

The other bigger change is that we now have persistent audio sessions (right now only enabled for jack). We’re basically keep the sink alive across songs and also keep it in a resource allocated state. This gives a little speedup on the playback startup, but the main motivation was to allow to configure linkage of buzztard with other jack client in qjackcontrol. This is also an enabler for transport sync support. I have landed initial support for this in gstreamer-git.

There were also a few smaller changes for user feedback on docs and new tips. The design folder got more experiments.

485 files changed, 2638 insertions(+), 2033 deletions(-)

buzztard project status 01/01/2012

ensonic — Fri, 13 Jan 2012 07:56:40 +0000

Finally after a long time, I managed to release a 0.6 of buzztard. So far only one regression was found and bml-0.6.1 was released to fix it.

A few things happened before the release still. At first after updating my distro, I made a lot of changes to avoid deprecated gtk+ api. For now we ship a copy of the ruler widget (that got removed in 3.0). The internal ruler widget is a lot saner than the upstream one too.

Another big change was to move from string parameter for notes to an enum. This is faster and lets us do things like blending of note ranges or transposing.

I also made quite a few bug-fixes – laspa effects work again, fluidsynth fixes, etc.

Now I look forward to a lot of new changes in 0.7.X.

ANN: buzztard 0.6.0 “black beats blue”

ensonic — Sun, 25 Dec 2011 11:00:18 +0000

The buzztard team has released version 0.6.0 “black beats blue” of its buzz-alike music composer. All modules got extensive improvements over the last release from more than two years ago. Give it a try, join hacking and report bugs.

bml
Improved machine compatibility.

bsl
Several bug fixes and better compatibility.

buzztard
Main feature of this release is full undo/redo support. Related to it is the journaling of edit action and the crash recovery. This way chances of losing changes in the song are quite low. Other UI improvements are: tip of day, improved spectrum analyzer, clipboard support, more commands in context menus and many more). This release features a gstreamer decoder that enables playback of buzztard songs in any gstreamer based media player.
We also kept the buzztard codebase clean and ported from deprecated APIs to the successors (gnomevfs->gio, hal->gudev). The libraries and the applications got performance improvements in many areas.
Also the docs have been improved a lot with tutorials, keyboard shortcut tables, better coverage and man-pages.

gst-buzztard
Lots of code cleanups. Get rid of the temporary help interface. Switch from liboil to orc. Performance improvements.

project-page: http://www.buzztard.org
screenshots: http://wiki.buzztard.org/index.php/Screenshots
downloads : http://sourceforge.net/projects/buzztard/files/

buzztard project status 01/12/2011

ensonic — Fri, 02 Dec 2011 21:28:06 +0000

Over the last 2 month I did quite a bit of work on the GStreamer side. Right now we’re working on 0.10 and 0.11 in parallel. I worked on the audiovisualizers and opencv elements in 0.10. I added a freeverb port to 0.10. In 0.11 I updated the controller susbsystem. If is now a lot easier to use and faster too. I also ported the audiovisualizers and fixed a few elements here and there.

In the beginning of November I gave a seminar about mobile multimedia using GStreamer. For that I wanted to have a few more examples. I have been polishing some examples in GStreamer and adding some more (simple audio-mixer with xfade). One example is a nice showcase for how easy you can do some things. It is called tonematrix. It is 497 lines of c, including comments, a GTK ui with an own widget and the whole GStreamer handling. The toy supports different sounds, different speeds and different scales.

Buzztard allows live control of audio elements. Right now can use midi and hid devices. The software that exposes the wiimote as a hid device uses uinput. This is a kernel device with a simple api that allows user-space apps to create hid devices. I wrote a small toy (280 lines of c) that can use different GStreamer pipelines containing analyzer elements and map the detected features to virtual joystick controls. The simplest example is to map the loudness of the mic-input to the x-axis. A similar example is to map the brightness of the
camera input to a joystick axis. Then you can control e.g. the filter-cutoff of a synthesizer by shielding the light from the camera sensor. Now the fun starts with the recently improved facedetect plugin in GStreamer. This can not only detect the faces, but also the positions of eyes, nose and mouth within the face. Unfortunately the detection is not very stable when drawing faces. The idea here obviously is to make grimaces and control sound with that. A very expressive performance

I also spend a lot of time to track down issues with dynamic linking. A few more fixes are done on buzztard side and GStreamer side. I think on the buzztard side things are good for a release. Everything is reviewed (docs, demo-songs, …) and make distcheck passes

buzztard project status 01/10/2011

ensonic — Tue, 04 Oct 2011 11:03:10 +0000

This month I focused on testing for the next release. My free time for the project was a big short anyway, as my family move to our new home and I had quite some janitorial work to do.

One lesson learned for the start. Some time ago I had problems with tests going crazy and eating memory. This can bring down the whole system which is bad. My solution at this time setrlimit(RLIMIT_AS,&rl) to cap the memory usage. While that works, that is also one way to shoot yourself in the foot. I was wondering why tests that work flawlessly on 32bit systems fail with “mmap() failed: Cannot allocate memory”. Doh, 64bit platforms need more memory than 32bit ones. Now I raised the limits unconditionally and everything is working again. Would be good to check the difference to see how much more memory 64bit apps that in average – its not twice as much I think.

I did lots of valgrinding and obviously found and squashed a few leaks. It would be really nice if each library would ship a suppression file as part of the dev package. The file could be installed to /usr/lib/valgrind/ .supp. The pkg-config file would have two variables: ‘vg_supp’ pointing to the suppression file and ‘vg_env’ setting extra environment variables easing valgrinding. This way one could just collect these from the libraries an application uses and be done. GObject based libs could suppress their singletons to improve the valgrind experience.

From time to time potential users show up on irc and get scared when I ask them to build the latest version from the sources. In the need for having an easy way to offer testers and translators the latest version, I took a look at glick. It is actually pretty straight forward. The resulting glick files where initially somewhat large, but after pruning development files, they are just about 6 Mb. I have two of them online – one for 32bit and one for 64bit systems. How to use them? Just download and run them – they don’t install anything. The only downside I can see so far is, that the glick bundle would use the same settings as the properly installed one, which could be harmful if different versions are run. Also the path to the example songs in the bundle is somewhat cryptic – /proc/self/fd/1023/share/buzztard/songs :/. Having better desktop integration of such bundles would be great too, but less see how glick evolves.

50 files changed, 836 insertions(+), 373 deletions(-)

buzztard project status 01/09/2011

ensonic — Wed, 14 Sep 2011 17:32:04 +0000

After lots of changes I have switched the code permanently to the new sequence model. It saves about 170 lines of code in the sequence-page source. There is some potential to save more though.

I also did more work on state persistence. A song now contains more information (selected machines, pattern, options) and these things are restored when loading a song.

Another good change was moving the song-unsaved flag from the song (core-library) to the edit application. This make the core library more light-weight. The editor application can now determine whether there is something to save by combining the unsaved-flag and the undo/redo stack. The unsaved-flag is still needed as I feel not everything needs to go to the undo/redo stack (like selecting a machine). Undo/redo looks quite complete now. I found a solution for my last issue, although I am still not entirely happy with it.

I also made a few startup time improvements. Found a weird issue with the interaction-controller library probing joystick devices. One ioctl on joy devices for hdaps devices is hanging for quite a bit.

Finally I did a huge cleanup on or somewhat uncommon header file setup. We always had a header declaring the types and one the methods. This helped with include conflicts. But now we have 50% less files to care and I just needed 2 forward declarations.

Again several bugs were fixed. I will check remaining reported bugs and hope that everything is fine to consider releasing 0.6.

253 files changed, 27205 insertions(+), 26602 deletions(-)