November 25, 2015

Libre Music Production - Articles, Tutorials and News

November 24, 2015

Linux Audio Announcements -

[LAA] The Open Source Musician Podcast is back!

After an unintentional hiatus, the show is back! We've moved hosts away
from libsyn to which allows us to provide alternative download
formats like flac and ogg. All 71 episodes can now be found at

71 you ask?
That's right, a new episode is now out! I chat with falkTX about MOD and
sundry other things. We also announce the opening of a new tunestorm due 1

OSMP Episode 71 - Talking with Filipe about MOD
We've moved to! You can find all the episodes now at
and each episode is at etc.

Interview with falkTX and we talk a lot about the MOD pedal (

We decide to do another tunestorm. Tunestorm 13 is themed "holiday." Record
an original composition about any holiday and send it in by 1 Jan 2016!
(See for more info).

Send entries to contributions at opensourcemusician dot com

Contact Info:
Email: contributions at opensourcemusician dot com


by at November 24, 2015 06:50 PM

OSM podcast

November 20, 2015

Create Digital Music » Linux

Use a hardware synth like it’s a plug-in – in a $60 DAW


With a little setup, you can integrate a hardware synth with Reaper as if it’s a software plug-in. Check out the video tutorial from The Reaper Blog to see how.

Reaper is a terrific “indie” DAW for the budget-conscious. Just $60 buys you an individual personal license with a bunch of free upgrades. (“Commercial” use is described as anyone making more than $20k a year – plenty of very serious musicians make less than that.)

The price is nice, but an even better reason to respect Reaper is that the developers at Cockos consistently pack in lots of engineering details. The ReaInsert plug-in seen here is a good example. ReaInsert lets you individually map sends and returns for audio, remap MIDI channels, define volume for sends and returns, and even “ping” to automatically set delay compensation, all via a single interface. All of this is possible in other DAWs, but typically with more manual configuration in different locations, not what’s available here in this integrated interface.

And the upshot of all of that is, after configuring the tutorial, you can “set it and forget it” – using any synth as if it’s software. (Kudos to Elektron for their cool Overbridge tech, but this can cover everything else.)

So let’s add up costs: Reaper is sixty bucks, our newest MeeBlip anode will set you back $120 (now, ahem, with free shipping, the Marketing Department would like to remind you, that department also being, erm, me) — throw in an audio/MIDI interface and you’re ready to go.

Thanks, Jon, for the tutorial and the opportunity for some blatant synth promotion. Now I’m going to check out these other tutorials, and consider doing the next track in Reaper.

Using Hardware Synths with ReaInsert

The post Use a hardware synth like it’s a plug-in – in a $60 DAW appeared first on Create Digital Music.

by Peter Kirn at November 20, 2015 11:33 AM

November 19, 2015

OSM podcast

November 18, 2015

OSM podcast

Pid Eins

Introducing sd-event

The Event Loop API of libsystemd

When we began working on systemd we built it around a hand-written ad-hoc event loop, wrapping Linux epoll. The more our project grew the more we realized the limitations of using raw epoll:

  • As we used timerfd for our timer events, each event source cost one file descriptor and we had many of them! File descriptors are a scarce resource on UNIX, as RLIMIT_NOFILE is typically set to 1024 or similar, limiting the number of available file descriptors per process to 1021, which isn't particularly a lot.

  • Ordering of event dispatching became a nightmare. In many cases, we wanted to make sure that a certain kind of event would always be dispatched before another kind of event, if both happen at the same time. For example, when the last process of a service dies, we might be notified about that via a SIGCHLD signal, via an sd_notify() "STATUS=" message, and via a control group notification. We wanted to get these events in the right order, to know when it's safe to process and subsequently release the runtime data systemd keeps about the service or process: it shouldn't be done if there are still events about it pending.

  • For each program we added to the systemd project we noticed we were adding similar code, over and over again, to work with epoll's complex interfaces. For example, finding the right file descriptor and callback function to dispatch an epoll event to, without running into invalidated pointer issues is outright difficult and requires non-trivial code.

  • Integrating child process watching into our event loops was much more complex than one could hope, and even more so if child process events should be ordered against each other and unrelated kinds of events.

Eventually, we started working on sd-bus. At the same time we decided to seize the opportunity, put together a proper event loop API in C, and then not only port sd-bus on top of it, but also the rest of systemd. The result of this is sd-event. After almost two years of development we declared sd-event stable in systemd version 221, and published it as official API of libsystemd.


sd-event.h, of course, is not the first event loop API around, and it doesn't implement any really novel concepts. When we started working on it we tried to do our homework, and checked the various existing event loop APIs, maybe looking for candidates to adopt instead of doing our own, and to learn about the strengths and weaknesses of the various implementations existing. Ultimately, we found no implementation that could deliver what we needed, or where it would be easy to add the missing bits: as usual in the systemd project, we wanted something that allows us access to all the Linux-specific bits, instead of limiting itself to the least common denominator of UNIX. We weren't looking for an abstraction API, but simply one that makes epoll usable in system code.

With this blog story I'd like to take the opportunity to introduce you to sd-event, and explain why it might be a good candidate to adopt as event loop implementation in your project, too.

So, here are some features it provides:

  • I/O event sources, based on epoll's file descriptor watching, including edge triggered events (EPOLLET). See sd_event_add_io(3).

  • Timer event sources, based on timerfd_create(), supporting the CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_BOOTIME clocks, as well as the CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM clocks that can resume the system from suspend. When creating timer events a required accuracy parameter may be specified which allows coalescing of timer events to minimize power consumption. For each clock only a single timer file descriptor is kept, and all timer events are multiplexed with a priority queue. See sd_event_add_time(3).

  • UNIX process signal events, based on signalfd(2), including full support for real-time signals, and queued parameters. See sd_event_add_signal(3).

  • Child process state change events, based on waitid(2). See sd_event_add_child(3).

  • Static event sources, of three types: defer, post and exit, for invoking calls in each event loop, after other event sources or at event loop termination. See sd_event_add_defer(3).

  • Event sources may be assigned a 64bit priority value, that controls the order in which event sources are dispatched if multiple are pending simultanously. See sd_event_source_set_priority(3).

  • The event loop may automatically send watchdog notification messages to the service manager. See sd_event_set_watchdog(3).

  • The event loop may be integrated into foreign event loops, such as the GLib one. The event loop API is hence composable, the same way the underlying epoll logic is. See sd_event_get_fd(3) for an example.

  • The API is fully OOM safe.

  • A complete set of documentation in UNIX man page format is available, with sd-event(3) as the entry page.

  • It's pretty widely available, and requires no extra dependencies. Since systemd is built on it, most major distributions ship the library in their default install set.

  • After two years of development, and after being used in all of systemd's components, it has received a fair share of testing already, even though we only recently decided to declare it stable and turned it into a public API.

Note that sd-event has some potential drawbacks too:

  • If portability is essential to you, sd-event is not your best option. sd-event is a wrapper around Linux-specific APIs, and that's visible in the API. For example: our event callbacks receive structures defined by Linux-specific APIs such as signalfd.

  • It's a low-level C API, and it doesn't isolate you from the OS underpinnings. While I like to think that it is relatively nice and easy to use from C, it doesn't compromise on exposing the low-level functionality. It just fills the gaps in what's missing between epoll, timerfd, signalfd and related concepts, and it does not hide that away.

Either way, I believe that sd-event is a great choice when looking for an event loop API, in particular if you work on system-level software and embedded, where functionality like timer coalescing or watchdog support matter.

Getting Started

Here's a short example how to use sd-event in a simple daemon. In this example, we'll not just use sd-event.h, but also sd-daemon.h to implement a system service.

#include <alloca.h>
#include <endian.h>
#include <errno.h>
#include <netinet/in.h>
#include <signal.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <unistd.h>

#include <systemd/sd-daemon.h>
#include <systemd/sd-event.h>

static int io_handler(sd_event_source *es, int fd, uint32_t revents, void *userdata) {
        void *buffer;
        ssize_t n;
        int sz;

        /* UDP enforces a somewhat reasonable maximum datagram size of 64K, we can just allocate the buffer on the stack */
        if (ioctl(fd, FIONREAD, &sz) < 0)
                return -errno;
        buffer = alloca(sz);

        n = recv(fd, buffer, sz, 0);
        if (n < 0) {
                if (errno == EAGAIN)
                        return 0;

                return -errno;

        if (n == 5 && memcmp(buffer, "EXIT\n", 5) == 0) {
                /* Request a clean exit */
                sd_event_exit(sd_event_source_get_event(es), 0);
                return 0;

        fwrite(buffer, 1, n, stdout);
        return 0;

int main(int argc, char *argv[]) {
        union {
                struct sockaddr_in in;
                struct sockaddr sa;
        } sa;
        sd_event_source *event_source = NULL;
        sd_event *event = NULL;
        int fd = -1, r;
        sigset_t ss;

        r = sd_event_default(&event);
        if (r < 0)
                goto finish;

        if (sigemptyset(&ss) < 0 ||
            sigaddset(&ss, SIGTERM) < 0 ||
            sigaddset(&ss, SIGINT) < 0) {
                r = -errno;
                goto finish;

        /* Block SIGTERM first, so that the event loop can handle it */
        if (sigprocmask(SIG_BLOCK, &ss, NULL) < 0) {
                r = -errno;
                goto finish;

        /* Let's make use of the default handler and "floating" reference features of sd_event_add_signal() */
        r = sd_event_add_signal(event, NULL, SIGTERM, NULL, NULL);
        if (r < 0)
                goto finish;
        r = sd_event_add_signal(event, NULL, SIGINT, NULL, NULL);
        if (r < 0)
                goto finish;

        /* Enable automatic service watchdog support */
        r = sd_event_set_watchdog(event, true);
        if (r < 0)
                goto finish;

        if (fd < 0) {
                r = -errno;
                goto finish;
        } = (struct sockaddr_in) {
                .sin_family = AF_INET,
                .sin_port = htobe16(7777),
        if (bind(fd, &, sizeof(sa)) < 0) {
                r = -errno;
                goto finish;

        r = sd_event_add_io(event, &event_source, fd, EPOLLIN, io_handler, NULL);
        if (r < 0)
                goto finish;

        (void) sd_notifyf(false,
                          "STATUS=Daemon startup completed, processing events.");

        r = sd_event_loop(event);

        event_source = sd_event_source_unref(event_source);
        event = sd_event_unref(event);

        if (fd >= 0)
                (void) close(fd);

        if (r < 0)
                fprintf(stderr, "Failure: %s\n", strerror(-r));

        return r < 0 ? EXIT_FAILURE : EXIT_SUCCESS;

The example above shows how to write a minimal UDP/IP server, that listens on port 7777. Whenever a datagram is received it outputs its contents to STDOUT, unless it is precisely the string EXIT\n in which case the service exits. The service will react to SIGTERM and SIGINT and do a clean exit then. It also notifies the service manager about its completed startup, if it runs under a service manager. Finally, it sends watchdog keep-alive messages to the service manager if it asked for that, and if it runs under a service manager.

When run as systemd service this service's STDOUT will be connected to the logging framework of course, which means the service can act as a minimal UDP-based remote logging service.

To compile and link this example, save it as event-example.c, then run:

$ gcc event-example.c -o event-example `pkg-config --cflags --libs libsystemd`

For a first test, simply run the resulting binary from the command line, and test it against the following netcat command line:

$ nc -u localhost 7777

For the sake of brevity error checking is minimal, and in a real-world application should, of course, be more comprehensive. However, it hopefully gets the idea across how to write a daemon that reacts to external events with sd-event.

For further details on the functions used in the example above, please consult the manual pages: sd-event(3), sd_event_exit(3), sd_event_source_get_event(3), sd_event_default(3), sd_event_add_signal(3), sd_event_set_watchdog(3), sd_event_add_io(3), sd_notifyf(3), sd_event_loop(3), sd_event_source_unref(3), sd_event_unref(3).


So, is this the event loop to end all other event loops? Certainly not. I actually believe in "event loop plurality". There are many reasons for that, but most importantly: sd-event is supposed to be an event loop suitable for writing a wide range of applications, but it's definitely not going to solve all event loop problems. For example, while the priority logic is important for many usecase it comes with drawbacks for others: if not used carefully high-priority event sources can easily starve low-priority event sources. Also, in order to implement the priority logic, sd-event needs to linearly iterate through the event structures returned by epoll_wait(2) to sort the events by their priority, resulting in worst case O(n*log(n)) complexity on each event loop wakeup (for n = number of file descriptors). Then, to implement priorities fully, sd-event only dispatches a single event before going back to the kernel and asking for new events. sd-event will hence not provide the theoretically possible best scalability to huge numbers of file descriptors. Of course, this could be optimized, by improving epoll, and making it support how todays's event loops actually work (after, all, this is the problem set all event loops that implement priorities -- including GLib's -- have to deal with), but even then: the design of sd-event is focussed on running one event loop per thread, and it dispatches events strictly ordered. In many other important usecases a very different design is preferable: one where events are distributed to a set of worker threads and are dispatched out-of-order.

Hence, don't mistake sd-event for what it isn't. It's not supposed to unify everybody on a single event loop. It's just supposed to be a very good implementation of an event loop suitable for a large part of the typical usecases.

Note that our APIs, including sd-bus, integrate nicely into sd-event event loops, but do not require it, and may be integrated into other event loops too, as long as they support watching for time and I/O events.

And that's all for now. If you are considering using sd-event for your project and need help or have questions, please direct them to the systemd mailing list.

by Lennart Poettering at November 18, 2015 11:00 PM

OSM podcast

Create Digital Music » open-source

MeeBlip at five: better, and at a new lower price


Five years ago this month, CDM unveiled the MeeBlip project. It was a chance to put our love of synthesizers into a physical form we could share. And we had no idea where it would take us.

Five years later, we’ve sold thousands of the musical instruments, all engineered by their creator James Grahame in Calgary, and all fully open source. In that time, we’ve also worked hard to make the MeeBlip constantly better, and easier for more people to get their hands on and use. Today, we celebrate five years, and what we think is our best MeeBlip yet. We’re also lowering the price.

The newest MeeBlip anode includes all the features the anode has brought (and that has won rave reviews from the likes of Sound on Sound, Keyboard, and Resident Advisor). That includes its edgy bass sound and analog filter, plus updated features like hands-on control of filter and amplitude envelope, improvements to filter performance, and different built-in wavetables for a wide variety of sound possibilities.

anode is now US$119.95, in celebration of five years of MeeBlip.

Buy one here:
Buy direct

(We’ll also soon have something to announce for European customers wanting faster shipping and all taxes and duty included.)

We’re just getting started. We’ve learned a lot in those five years, and that’s given us ideas for how we can do everything we do a bit better. So thanks for staying with us, and stay tuned for more.

In the meantime, here’s a look back…

The anode is the second major MeeBlip model. Here are three variations together: the SE generation, the original anode, and the special edition anode with wavetables.

MeeBlip generations

The very first MeeBlip had a quirky faceplate designed by Tasmanian designer Nathanael Jeanneret. If you’ve got one of these, they’re pretty rare.


Building on the simple, hackable, open nature of the instrument, projects over the years have included all sorts of fanciful designs. Gwydion ap Dafydd of Konkreet Labs even placed one inside a cookbook:

Synth in a Book from Konkreet Labs on Vimeo.

And Dutch industrial designer / media artist Arvid Jense, while interning with us, made an incredible DIY sequencer/MeeBlip combination to support jamming (see Instructables:

There have been wild mods, like Shawn Rudiman building an entire control voltage-controlled model and an aluminum, rack-mounted case:

It’s been a frequent guest in hack days and hack-a-thons, talking to plants, or to the Internet at SONAR (even before Internet of Things was such a buzzword):


Countless other models have appeared in wild and novel enclosures, as documented on our Pinterest page.

And then came anode. The goal was to design a MeeBlip that was smaller and had fewer knobs – but felt like it had greater, richer sound potential. That meant lots of attention to how parameters were designed, so that each knob turn was satisfying. And we’ve been pleased that reviews from users and press understood and appreciated what we worked on.


But in the end, this is a personal journey. James and I have learned that making instruments means discovering what musicians can do with devices you imagine. The goal is to create objects that become something more than what we can do on our own. That’s why we’ve stayed with it, and why we’ll keep staying with it. So the best part of this job, without question, is seeing what people do – and hearing the results.

There are many examples like that, like this all-anode track produced by Andrius Mamontovas.

We could use your help. Let us know what you think of what we’re doing, and what we can do to do it better. And if you like the MeeBlip, help us spread the word, and get synthesizers in more hands.

MeeBlip anode is in stock and shipping worldwide right now.

And most of all: thank you.

The post MeeBlip at five: better, and at a new lower price appeared first on Create Digital Music.

by Peter Kirn at November 18, 2015 07:29 PM

OSM podcast

November 17, 2015

OSM podcast

November 16, 2015

OSM podcast

Hackaday » digital audio hacks

Pea-Whistle Steganography

Do you see the patterns everywhere around you? No? Look closer. Still no? Look again. OK, maybe there’s nothing there.

[Oona Räisänen] hears signals and then takes them apart. And even when there’s nothing there, she’s thinking “what if they were?” Case in point: could one hypothetically transmit coded information in the trilling of a referee’s whistle at the start of a soccer match?

acme-spektriTo you, the rapid pitch changes made by the little ball that’s inside a ref’s whistle sounds like “trilling” or “warbling” or something. To [Oona], it sounds like frequency-shift key (FSK) modulation. Could you make a non-random trilling, then, that would sound like a normal whistle?

Her perl script says yes. It takes the data you want to send, encodes it up as 100 baud FSK, smoothes it out, adds some noise and additional harmonics, and wraps it up in an audio file. There’s even a couple of sync bytes at the front, and then a byte for packet size. Standard pea-whistle protocol (PWP), naturally. If you listen really closely to the samples, you can tell which contains data, but it’s a really good match. Cool!

[Oona] has graced our pages before, naturally. From this beautiful infographic tracing out a dial-up modem handshake to her work reversing her local bus stop information signs or decoding this strange sound emitted by a news helicopter, She’s full of curiosity and good ideas — a hacker’s hacker. Her talk on the bus stop work is inspirational.. She’s one of our secret heroes!

Filed under: digital audio hacks, misc hacks, radio hacks

by Elliot Williams at November 16, 2015 09:00 PM

OSM podcast

Linux Audio Announcements -


Zynaddsubfx 2.5.2 - “The Space of Two Weeks” Release

A mere three months after the last release, the Zynaddsubfx team proudly
announces Version 2.5.2, the “Space of Two Weeks” release. In addition to
stability improvements, it adds some exciting and useful new features:

* Add MIDI-Learn serialization - this allows for midi mappings to be saved
and loaded, a huge boon for midi control workflow.

* Add pink noise source - pink noise is usually considered the most
“musical” or natural of noise sources, like rain, waterfalls, or ocean

* Restore mousewheel functionality - a sorely missed feature, provides easy
and consistent course and fine tuning of parameters. Mouse drag has
matching behavior now as well.

* Restore bank LSB/MSB MIDI support - makes all presets in a bank
selectable by MIDI.

* Improve tip windows - if enabled, shows you helpful tips you never knew
on startup.

* Improve oscdoc output - this utility documents all the OSC messages that
can control zyn and lists and describes them at These messages could be used by OSC
apps on remote machines, android or iOS devices to control zyn.

* Restore External Oscillator/Modulator functionality - now you can use
external sources for new audio waveforms, or modulation signals.

* Remove remaining globals - a feat in itself, this results in safer,
cleaner, better designed code, additional stability, and sets the stage for
using zyn as a plugin.

* Fix UI connection bugs - this improves the workflow and reliability for
those using zyn in headless systems, controlling it through the zyn user
interface on a remote machine.

* Added shortcuts on edit buttons - holding shift or control when opening
the edit window of several features now opens a different, commonly useful
window (i.e. shift+click of the ADsynth edit button brings up the voice
list window).

* Other miscellaneous bug fixes

For more detail on these improvements read the in-depth announcement on the
mailing list (

Thanks to all who contributed bug reports and feedback! We can always use
more! This release has commits from Mark McCurry, Christopher Oliver,
Filipe Coelho, Johannes Lorenz, and Hans Selasky, with translation from
Oliver Humbert. Naturally, we recommend all users and packagers update to
take advantage of these fixes and features.

Now go make some noise!

--Team Zyn.

Project Page:


Mailing List:


Bug/Feature Tracker:

##zynaddsubfx on FreeNode

by at November 16, 2015 08:07 PM

m3ga blog

Forgive me Curry and Howard for I have Sinned.

Forgive me Curry and Howard for I have sinned.

For the last several weeks, I have been writing C++ code. I've been doing some experimentation in the area of real-time audio Digital Signal Processing experiments, C++ actually is better than Haskell.

Haskell is simply not a good fit here because I need:

  • To be able to guarantee (by inspection) that there is zero memory allocation/de-allocation in the real-time inner processing loop.
  • Things like IIR filters are inherently stateful, with their internal state being updated on every input sample.

There is however one good thing about coding C++; I am constantly reminded of all the sage advice about C++ I got from my friend Peter Miller who passed away a bit over a year ago.

Here is an example of the code I'm writing:

  class iir2_base
      public :
          // An abstract base class for 2nd order IIR filters.
          iir2_base () ;

          // Virtual destructor does nothing.
          virtual ~iir2_base () { }

          inline double process (double in)
              unsigned minus2 = (minus1 + 1) & 1 ;
              double out = b0 * in + b1 * x [minus1] + b2 * x [minus2]
                              - a1 * y [minus1] - a2 * y [minus2] ;
              minus1 = minus2 ;
              x [minus1] = in ;
              y [minus1] = out ;
              return out ;

      protected :
          // iir2_base internal state (all statically allocated).
          double b0, b1, b2 ;
          double a1, a2 ;
          double x [2], y [2] ;
          unsigned minus1 ;

      private :
          // Disable copy constructor etc.
          iir2_base (const iir2_base &) ;
          iir2_base & operator = (const iir2_base &) ;
  } ;

November 16, 2015 11:22 AM

November 14, 2015 » LAD

Git migration

I have finally migrated all of my software to git. This was not a very fun process due to the nested nature of my “drobillad” repository, but now all projects live in their own git repositories with history and tags from SVN preserved.

It is still possible to build all my audio software in one step, the top-level repository is now a skeleton with git submodules for each project. Anyone using SVN should switch immediately, the SVN repositories will remain in their current state for the foreseeable future but all development activity will move to git.

All the repositories are available in cgit, but changes and tickets and so on are in Trac as always. Happy hacking.

Flattr this!

by David Robillard at November 14, 2015 09:46 PM

November 10, 2015

Scores of Beauty

The Future of openLilyLib

Some time ago Matteo Ceccarello appeared on the LilyPond stage and announced a new library that merged several ideas from this blog. My own posts about a grid approach and two posts by Jan-Peter Voigt had inspired him to develop a library where the “cells” of the grid can be directly stored in a tree-like Scheme object. I helped him integrating this library in openLilyLib where it now lives as GridLY. This process and collaboration produced some significant by-products, for example an automated testing infrastructure for openLilyLib. And now Matteo presented a new tool that opens up some important perspectives for openLilyLib.

In a post on his blog Matteo describes some of the aspects of openLilyLib undergoing significant infrastructure modifications. One seemingly secondary aspect of this is that openLilyLib now has a notion of versions. openLilyLib itself as well as the contained libraries can now have specific versions, and there is already a kind of support for tagging a score with these versions. I won’t give a summary of Matteo’s post and encourage you to read it for yourself instead – ideally you’d do that now and return later to complete my post.

I think Matteo put his finger on an inherent problem that would inevitably show up in a quite ugly manner if openLilyLib would become “mature” and even started “aging”. And the script he presented in his post is an interesting approach which – despite being not sufficient on the long run, as he states himself – will boost our development as an inspiration.

In addition to managing the included openLilyLib version I would add another problem that is waiting for a long-term solution: Sometimes changes in openLilyLib or a library are “breaking”, that is they require the LilyPond files that use the library to update their input syntax. I think we need something like LilyPond’s own convert-ly for openLilyLib as well, either as a standalone tool or by somehow ”hijacking” convert-ly.

In his closing remarks Matteo points out that in order to manage versions of the libraries contained in openLilyLib independently (say, GridLY 0.6 and ScholarLY 0.5) a package manager would be needed. I have to say this idea comes at the right moment – as I have just started to think in a similar direction recently. The issue that bothered me is that the new infrastructure in openLilyLib seems at risk of becoming unmaintainable quite soon. As it stands we have a directory structure similar to

├── comptools
│   ├── partial-compilation
│   ├── unit-tests
│   └── usage-examples
├── gridly
│   └── usage-examples
├── _internal
│   └── utilities
├── scholarly
│   ├── annotate
│   │   └── examples
│   └── usage-examples
├── stylesheets
│   ├── fonts
│   └── usage-examples
├── tablature
    └── usage-examples

This looks quite nice with currently five libraries and an _internal core being present. But when we expect openLilyLib to become as comprehensive as it should there will presumably be dozens of libraries, maybe even heading towards a three-digit number. This will have a number of implications:

  • The main directory and Git repository will become quite crowded and big. Which isn’t a problem in itself as any average software project will still be bigger, but:
  • Any user will have to fetch the whole repository even when she’s only interested in a certain library.
  • The openLilyLib project will have to manage a significant number of project members and “sub-maintainers”, there’s not a natural separation of responsibilities between maintainers of different libraries.
  • This will also bloat the issue tracker, and if only by having to add dozens of labels for the individual libraries.

All those points indicate that openLilyLib should be disentangled and the individual libraries be developed in their individual repositories. One main concern with such an undertaking would be to manage “installations”, paths and versions among the different libraries. And I think that a package manager would be exactly what we need for that. Apart from keeping track of versions and dependencies such a tool would also be useful to actually deploy the libraries. Currently users are encouraged to clone the repository using Git – which is quite an obstacle for someone not using Git already. The alternative of using the archive downloads provided by Github aren’t really acceptable either.

By pure coincidence I was recently approached by a LilyPond user who is developing several promising tools with and for LilyPond (he’ll tell us about them when they’re sufficiently ready). Among the topics that came up besides these ideas was – a package manager, something he has already been experimenting with lately!

So I encourage anyone who is interested in the future of openLilyLib (and to some extent also of LilyPond itself) to join us with discussion, testing and maybe also actual contributions. openLilyLib was originally conceived as a community project, and I think it can really become an important part of the LilyPond ecosystem once the mentioned restructuring has been completed. But it is definitely a task that is too big for one or two developers.

by Urs Liska at November 10, 2015 05:24 PM

November 09, 2015

Ubuntu Studio » News

Want to help making Ubuntu Studio a great OS for creative humans?

Most of the work we do does not require any special skills, so more or less anyone can contribute! To start contributing right away, simply read and follow instructions. If you’d like to get up to speed on what is happening right now, please read on. In order to survive as a volunteer project, […]

by Kaj Ailomaa at November 09, 2015 11:17 AM

Libre Music Production - Articles, Tutorials and News

New release of Guitarix

Guitarix version 0.34.0 has just been released. One of the most interesting new additions includes the ability to download Guitarix presets directly from, without leaving Guitarix's interface. You will now see a new 'Online' button in the preset selection area of Guitarix. Clicking on this will pop up a window from which you can download presets.

by Conor at November 09, 2015 10:39 AM

November 08, 2015

Pid Eins

systemd.conf 2015 Summary

systemd.conf 2015 is Over Now!

Last week our first systemd.conf conference took place at betahaus, in Berlin, Germany. With almost 100 attendees, a dense schedule of 23 high-quality talks stuffed into a single track on just two days, a productive hackfest and numerous consumed Club-Mates I believe it was quite a success!

If you couldn't attend the conference, you may watch all talks on our YouTube Channel. The slides are available online, too.

Many photos from the conference are available on the Google Events Page. Enjoy!

I'd specifically like to thank Daniel Mack, Chris Kühl and Nils Magnus for running the conference, and making sure that it worked out as smoothly as it did! Thank you very much, you did a fantastic job!

I'd also specifically like to thank the CCC Video Operation Center folks for the excellent video coverage of the conference. Not only did they implement a live-stream for the entire talks part of the conference, but also cut and uploaded videos of all talks to our YouTube Channel within the same day (in fact, within a few hours after the talks finished). That's quite an impressive feat!

The folks from LinuxTag e.V. put a lot of time and energy in the organization. It was great to see how well this all worked out! Excellent work!

(BTW, LinuxTag e.V. and the CCC Video Operation Center folks are willing to help with the organization of Free Software community events in Germany (and Europe?). Hence, if you need an entity that can do the financial work and other stuff for your Free Software project's conference, consider pinging LinuxTag, they might be willing to help. Similar, if you are organizing such an event and are thinking about providing video coverage, consider pinging the the CCC VOC folks! Both of them get our best recommendations!)

I'd also like to thank our conference sponsors! Specifically, we'd like to thank our Gold Sponsors Red Hat and CoreOS for their support. We'd also like to thank our Silver Sponsor Codethink, and our Bronze Sponsors Pengutronix, Pantheon, Collabora, Endocode, the Linux Foundation, Samsung and Travelping, as well as our Cooperation Partners LinuxTag and, and our Media Partner

Last but not least I'd really like to thank our speakers and attendees for presenting and participating in the conference. Of course, the conference we put together specifically for you, and we really hope you had as much fun at it as we did!

Thank you all for attending, supporting, and organizing systemd.conf 2015! We are looking forward to seeing you and working with you again at systemd.conf 2016!


by Lennart Poettering at November 08, 2015 11:00 PM

Linux Audio Announcements -

[LAA] [LAU] Guitarix 0.34.0 release

Release 0.34.0 is out,

Guitarix is a tube amplifier simulation for
jack (Linux), with an additional mono and a stereo effect rack.
Guitarix includes a large list of plugins[*] and support LADSPA / LV2
plugs as well.

The guitarix engine is designed for LIVE usage, and feature ultra fast,
glitch and click free, preset switching and is full Midi (learn)
and remote (Web-interface/ GUI) controllable (bluez / avahi)


add BOSS OC-2 partial emulation LV2 plugin (by drgreenthumb)
add gx_hogsfoot.lv2 gx_mole.lv2 and gx_rangem.lv2
add gx_plugins AxeFace, BassFuzz, Buzz and the Mole
add Gx_Wah.lv2 plugin
add colorsound bass wah plugin emulation
add Roland Wah add Jen Bass Wah emulation
add bitdowner distortion plugin (by Viacheslav Lotsmanov)

add volume control to gcb95 plug
add file browser and file load support to dubber (livelooper) plugin
add play all button to the dubber (livelooper) plugin
add support to import LV2 plugin presets into guitarix
add 24-edo tuner option
add 53-edo tuner option

disable LILV_OPTION_DYN_MANIFEST to avoid crashes from naspro-bridges

add online preset download widget (requires libwebkit-1.0)
thanks to lfz for creating

fix GxAmplifier-x GxAmplifierStereo-X and GxCabinet for the new ardour
buffersize behave.

implement double click on plugin handle remove plugin from rack

fix guitarix build for the new libsigc++ library and the new GCC5 compiler.
guitarix use now the default build flag -std=c+11
(you can disable it, see ./waf --help for more optional flags)

Guitarix is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.

Please refer to our project page for more information:

Download Site:

Linux-audio-user mailing list
Linux-audio-announce mailing list

by at November 08, 2015 04:05 PM

November 06, 2015

Nothing Special

Easy(ish) Triple Boot on 2014 Macbook Pro

UPDATE* Feel free to read, but I've since renounced this process and made a new one here.
Nothing is easy. Or perhaps everything is. Regardless, here is how I did it, but first a little backstory:

I got a macbook pro 11,3 from work. I wanted a lenovo, but the boss wants me to do some iOS stuff eventually. Thats fine, cause I can install linux just as easily on whatever. Oh wait.. There are some caveats. Boot Camp seems to be a little picky. Just as well. MIS clowns set up boot camp so I had windows 7 and Yosemite working, but they told me I'm on my own for linux. It seems from the posts I've read about triple booting is that you have to plan it out from the get-go of partitioning, not just add it in as an afterthought. But I also found suggestions about wubi.

I've used wubi and didn't really understand what it did, but its actually perfect for setting up a triple boot system in my situation (where it's already dual boot and I want to tack on linux and ignore the other two). There is a lot of misunderstanding that wubi is abandoned and no longer supported bla bla. The real story is that the way wubi works doesn't play nicely with windows 8. Therefore if it doesn't work for everybody Ubuntu doesn't want to advertise it as an option. Its there, but they'd rather have everyone use the most robust method known: full install from the live cd/usb. Not that wubi is rickety or anything, but only works in certain situations (windows 7 or earlier). The reality is its on every desktop ISO downloaded, including latest versions (more on that later).

The way wubi works is important to note too (and its the reason that its perfect for this situation). Wubi creates a virtual disk inside the NTSC (windows) partition of the disk. So instead of dividing the hard drive space into two sections (one for linux, one for windows, and/or a third for OSX if triple boot) it doesn't create disk partitions at all,  just a disk file inside the existing windows partition. The windows bootloader is configured to open the windows partition then mount this file as another disk in whats called a loopback mode. This is distinctly contrasted to a virtualized environment where often a virtual disk is running on virtual hardware. You are using your actual machine, just your disk is kinda configured in a unique but clever way.

The main downside it sounds like is that you could have poor disk performance. It sounds like in extreme cases, VERY poor performance. Since this machine was intended for development its maxed out with 16GB ram, so I'm not even worrying about swap, and the 1TB hdd has plenty of space for all 3 OSes and its a fresh install so shouldn't be too fragmented. These are the best conditions for wubi. So far it seems to be working great. Install took a little trial and error though.

So I had to at least TRY to teach you something before giving you the recipe, but here goes:

  1. I had to install bootcamp drivers in windows. MIS should have done that but they're clowns. You'll have to learn that on your own. There are plenty of resources for those poor mac users. This required a boot into OSX.
  2. Boot into windows.
  3. Use the on screen keyboard in the accessibility options of the windows to be able to hit ctl+alt+delete to make up for the flaw that macbooks have no delete key (SERIOUSLY?) Also don't get me started on how I miss my lenovo trackpoints.
  4. I installed sharpkeys to remap the right alt to be a delete key so I could get around this in the future. I know sooner or later Cypress will make me boot into windoze.
  5. Download the Ubuntu desktop live CD ISO (I did the most recent LTS. I'm not in school any more, gone are the days where I had time to change everything every 6 months).
  6. In windows install something that will let you mount the ISO in a virtual cd drive. You could burn it to CD or make a live USB, but this was the quickest. I used WinCDEmu as it's open source.
  7. Mount the ISO and copy wubi.exe off of the ISO's contents and into whatever directory the ISO is actually in (i.e. Downloads).
  8. Unmount the ISO. This was not obvious to me and caused an error in my first attempt.
  9. Disable your wifi. This was not obvious to me and caused an error in my second attempt. This forces wubi to look around and find the ISO that is in the same folder rather than try to re-download another ISO.
  10. Run wubi.exe .
  11. Pick your install size, user name, all that. Not that it matters but I just did vanilla ubuntu since I was going to install i3 over the Unity DE anyway. Historically I always like to do it with xubuntu, but I digress.
  12. Hopefully I haven't forgotten any steps, but that should run and ask you to reboot. (I'd re-enable the wifi before you do reboot, or else you'll forget like I did and wonder why its broken next windows boot).
  13. The reboot should complete the install and get you into ubuntu.
  14. I believe the next time you reboot it will not work. For me it did not. Its due to a grub2 bug I understand. Follow the solutions in these two threads: 
  15. To roughly summarise the process, hit the e key to edit the grub config that will try to load ubuntu. Edit the line
    linux /boot/vmlinuz-3.13.0-24-generic root=UUID=bunchofhexidec loop=/ubuntu/disks/root.disk ro

    ro should be changed to rw. This will allow you to boot. The first post tells you to edit an auto-generated file. Thats silly. what happens when it gets auto-generated and again and overwrites your fix? It even says not to edit it in the header. Instead you need to make a similar change to the file that causes it to have that error and then generate those files again as described in the second link.
  16. Once that is sorted out you'll probably notice that the wifi is not working. You can either use an ethernet port adapter or a USB wifi card (or figure out another way) but get internet somehow and install bcmwl-kernel-source and it should start working (maybe after a logout. I don't remember).
  17. Another tweak you will need is that this screen has a rediculously high DPI so the default fonts are all teensy-tiny. The easiest workaround is just to lower the screen resolution in the displays setting of unity-command-center, but you can also edit the font sizes in that dialog and/or using unity-tweak-tool. I'm still ironing that out. Especially since my secondary monitors are still standard definition. xrandr --scale is my only hope. Or just lower the resolution.
  18. You might find that the touchpad click doesn't work as you expect. Try running the command:
    synclient ClickPad=0
    and see if you like it better. I sure do. Also enable two finger scrolling in the unity-control-center.
  19. Also, importantly, wubi only allows up to 30GB of virtual disk to be created. I wanted a lot more than that. So I booted off a USB live stick I had laying around and followed the instructions here to make it a more reasonable 200GB.
  20. Finally install i3-wm, vifm, eclipse, the kxstudio repos and everything else you love about linux.
So I love my macbook. Because its a linux box.

by Spencer ( at November 06, 2015 01:18 PM

Easyish Triple Boot on a Macbook Pro, Round 2

So my "easyish" install using Wubi finally crashed when I was trying to change things and install Ubuntu 15.10. If I'd have left it at 14.04, it probably would have been ok for a long time. However I was getting tired of the poor disk performance when creating large archives for work. So once it was broken, I had no reason not to just try and get a full triple boot (luckily I had backed everything up before trying anything). I found this recent article about triple booting, but its process has the deal-breaking requirement to install ubuntu before windows. What if you're handed a machine already set up for dual boot (without the recovery disks, mind you)? Funny that with 2 operating systems to choose from I wasn't happy with either....

Well it can be done (at least on my MBP 11,3 with yosemite and a windows7 bootcamp partition), and the secret sauce is rEFInd. I don't understand EFI at all. And every time I start going through the docs (rEFInd has a lot of GREAT documentation) I get distracted with needing to do work or something. Anyhow, before, I couldn't boot any Ubuntu live usb drives after 14.10 (I think the switch to systemd maybe?) but once I installed rEFInd I could... When I resized the bootcamp partition using a 14.04 live usb, booting windows didn't work any more. But once I installed rEFInd it did... After installing 15.10 from the liveUSB I couldn't boot osx or windows from the grub bootloader. But once I held the option key and used apple's boot selector to boot into OSX again and installed rEFInd again I could... boot from rEFInd's boot selector that is. Somehow rEFInd is magical.

So in a recipie:
  1. Boot a live usb (I had to use 14.04)
  2. Use gparted to shrink down the bootcamp/windows partition (make sure you've defragmented the partition in windows first).
  3. Install rEFInd by downloading in OSX and running the from the OSX terminal
  4. Boot  windows just to make sure you still can (when you have to)
  5. Boot from a live usb of ubuntu 15.10 and install with the empty space turned into the / directory (root)
  6. After the ubuntu install hold option next time you boot and boot into OSX, install rEFInd again (the grub configuration messes it up somehow)
  7. Enjoy using linux but still having 2 other operating systems to choose from (though you'll have to twist my arm to get me to boot anything other than linux).
Hopefully this helps. Its not as detailed as my last post, but I'm much more satisfied with the results so far. I'm still amazed that a free and open source project does boot management so much better than the expensive proprietary options.

Oh ya, and do all this at your own risk. Please make backups.

by Spencer ( at November 06, 2015 01:17 PM

Hackaday » digital audio hacks

Tricking an Ancient Protocol To Play Tunes

A lot of technological milestones were reached in 2007. The first iPhone, for example, was released that January, and New Horizons passed Jupiter later on that year. But even with all of these amazing achievements, Volvo still wasn’t putting auxiliary inputs on the stereo systems in their cars. They did have antiquated ports in their head units though, and [Kalle] went about engineering this connector to accommodate an auxiliary input.

The connector in question is an 8-pin DIN in the back, which in the days of yore (almost eight years ago) would have been used for a CD changer. Since CDs are old news now, [Kalle] made use of this feature for the hack. The first hurdle was that the CD changer isn’t selectable from the menu unless the head unit confirms that there’s something there. [Kalle] used an Arduino Nano to fool the head unit by simulating the protocol that the CD changer would have used. From there, the left and right audio pins on the same connector were used to connect the auxiliary cable.

If you have a nearly-antique Volvo like [Kalle] that doesn’t have an aux input and you want to try something like this, the source code for the Arduino is available on the project page. Of course, if you don’t have a Volvo, there are many other ways to go about hacking an auxiliary input into various other devices, like an 80s boombox or the ribbon cable on a regular CD player. Things don’t always go smoothly, though, so there are a few nonstandard options as well.

Filed under: car hacks, digital audio hacks

by Bryan Cockfield at November 06, 2015 12:00 PM


Reflections on the Loop summit

The last weekend of October 2015 found me at Loop, a "summit for music makers" organized by Ableton AG, the makers of Live, and taking place in Berlin. The summit gathered a wide range of notable people from many different intersections of music, technology and creativity, including musicians, producers, engineers, designers, researchers and more.

read more

by paul at November 06, 2015 02:27 AM

November 05, 2015


Announcing ofxAubio

It has been a long time since I wanted to create an add-on for OpenFrameworks, the mighty open source toolkit for creative coding.

Recently, my friends at Hand Coded asked me if they could use aubio in their application, Ledotron, to have the live music controlling the visual in real time. I can't say much more, but it's going to be something really nice.

Some people had already written addons using the aubio library to do pitch or onset detection using aubio, but I figured it would be easier to start a new project from scratch.

read more after the break...

November 05, 2015 03:47 PM

November 04, 2015

Create Digital Music » Linux

The next prank call you get could come from this crazy synth

::vtol:: prankophone from ::vtol:: on Vimeo.

If you pick up the phone and instead of a robocall or someone pocket dialing you, you get what sounds like a synthesizer that’s lost its mind, blame the Prankophone.

Since we’re going to cover the latest from Ableton and Korg and so on in detail, we practically need a column for the quirky, prolific inventions of one vtol, aka Dmitry Morozov. Call it the Internet of Insane Things. (IoIT?)

Prankophone is a synthesizer plus telephone plus logic module. It sits alone in a gallery, and dials up recipients at random (or, if you prefer, pre-selected victims), then plays them generative sounds, composing an algorithmic tune from their phone number, and relaying sound from whomever picks up. You can also “communicate” with the caller from a music keyboard, if you’d like to talk to them in song. (Close Encounters, anyone?)

Now, this might sound weird – okay, it is pretty weird. But believe it or not, there’s some history inspiring it.



Elisha Gray’s Musical Telegraph attached a piano/organ keyboard to a telegraph for relaying melodies. Thaddeus Cahill’s Teleharmonium could be played over phone lines. That instrument was a precursor to the Hammond Organ, an additive tonewheel synth, but decades before live Internet streaming, the Teleharmonium could transmit its noises via phone line. And Dmitry notes that because of poor interference protection, it was very likely some callers got an unwanted and unexpected organ performance while trying to make calls.

And while it’s hard to imagine a world before the typewriter keyboard (like the one on my MacBook as I write this), early telegraphs like David Hughes’ printing telegraph also made use of piano-style keyboards.


All of this makes for a fascinating project. And the readiness of embedded computer tech like the Raspberry Pi means other similarly weird inventions and projects can be yours, too. That could get interesting. By the way, is your refrigerator running? Have you got Prince Albert in a can? Never mind.

The latest on this project in Portugal:


– raspberry pi 2
– arduino mega
– Nokia mobile phone
– 2 channel sound system
– GE telephone as button board
– 1 octave keyboard


– Pure Data
– Python scripts

Oficinas do Convento, Montemor-o-Novo, Portugal, 2015

And I’ll see you with Dmitry in Moscow later this year. Can’t wait. More on that soon.

The post The next prank call you get could come from this crazy synth appeared first on Create Digital Music.

by Peter Kirn at November 04, 2015 03:13 PM

Libre Music Production - Articles, Tutorials and News

LMP Asks #14: An interview with Babis Kouvalis

This month LMP talked to Babis Kouvalis, guitarist and FLOSS enthusiast. Babis has a YouTube channel where he demos FLOSS software, primarily Guitarix.

Hi Babis and thank you for taking the time to do the interview. Where do you live, and what do you do for a living?

I live in Athens, Greece with my girlfriend at her house. At the moment I'm unemployed due to the economic crisis, but I have much more time to work with music and live from it.

by Conor at November 04, 2015 09:20 AM

November 01, 2015

Linux Audio Announcements -

[LAA] QMidiArp-0.6.3 bugfix release

Dear all,

QMidiarp-0.6.3 fixes an annoying regression in the Arp LV2 module, where the
pattern display did not follow changes made in the pattern field or when
selecting a preset.
It also fixes the LV2 plugin user interfaces when building with --enable-qt5.

NOTE (again) that when built against Qt5 these plugins will work only in Qt5
plugin hosts at this time (i.e. Rui's Qtractor or drobilla's jalv.qt5, but no
longer Ardour), however updates of drobilla's suil library also seem to be on
their way.

Please update to this version and....


qmidiarp-0.6.3 (2015-11-01)

Fixed Bugs
o LV2 Arp: Regression: Display updates no longer worked when changing
arp patterns
o Configure script caused trouble on certain build systems (bug #15
raised by the Mageia team)
o LV2: Qt5 UIs did not have the correct UI type entry in ttl files

o LV2 Arp: Factory pattern presets are now accessible as LV2 presets
o LV2 Arp: Latch mode now also available in LV2 plugin


QMidiArp is a MIDI arpeggiator, phrase generator and controller LFO for JACK
and ALSA. It can run multiple synchronized arpeggiators, LFOs and step
sequencers. The modules are also available as LV2 plugins with Qt user
interface. All in all it is a handy live tool.



There is now also a github repo that will be kept in sync with the sf repo for
the time being
Linux-audio-announce mailing list

by at November 01, 2015 08:45 AM

Recent changes to blog


With the latest transition to GCC5 the std, glib and sigc++ libs in debian/sid and arch switched to use the C++11 standard which leads to build failuers for guitarix.
To cover that, guitarix-git use now as well the C++11 standard for it's build.
Some changes in the source have been done to reach that.

by brummer at November 01, 2015 06:10 AM

October 31, 2015

Linux Audio Announcements -

[LAA] Praxis LIVE v2.2.0

Hi All,

Praxis LIVE v2.2.0 is now available for download from

This is the first release to upgrade the OpenGL renderer to Processing
v3. Feedback on whether this is working well would be appreciated.

Full change log -

* OpenGL video pipeline updated to Processing v3.0.1 / JOGL v2.3.2.
While providing major performance and stability improvements, this is
a major change and there is the possibility for some regressions.
Please update carefully and report any issues.

* Optional support for GStreamer 1.x. This can be set under Tools /
Options / Video / GStreamer (requires restart). Unlike GStreamer 0.10
support, this requires a system installed version of the GStreamer
library on all platforms. Windows and OSX users who want to experiment
with this feature can download GStreamer from

* New core:tracker component, and simple table-based tracker editor
(use popup menu and Edit patterns to access). More advanced editing
features to follow.

* New routing components - core:routing:every for allowing through
every n-th message, and core:routing:order to prioritise dispatching
of messages.

* New audio:clock component for more stable timing in BPM (quantized
to internal processing buffer size).

* Internal (and outdated) help removed and replaced with link through
to online manual at

* TinkerForge bindings updated to v2.1.5.

* Added ready and error ports to video:capture and video:player. Can
be connected to play or pause to auto-start playback when new file or
pipeline loaded.

* Many minor bug fixes (see commit log).

Downloads -
Source code -

Best wishes,


Neil C Smith
Artist : Technologist : Adviser

Praxis LIVE - hybrid visual IDE for creative coding -
Digital Prisoners - interactive spaces and projections -
Linux-audio-announce mailing list

by at October 31, 2015 12:40 PM

October 30, 2015

GStreamer News

GStreamer Core, Plugins, RTSP Server, Editing Services, Python 1.6.1 stable release

The GStreamer team is proud to announce the first bugfix release in the stable 1.6 release series of your favourite cross-platform multimedia framework!

This release only contains bugfixes and it is safe to update from 1.6.0. For a full list of bugfixes see Bugzilla.

See for the full release notes.

Binaries for Android, iOS, Mac OS X and Windows will be provided separately by the GStreamer project.

Check out the release notes for GStreamer core, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, gst-rtsp-server, gst-python, or gst-editing-services, or download tarballs for gstreamer, gst-plugins-base, gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, gst-libav, gst-rtsp-server, gst-python, or gst-editing-services.

October 30, 2015 03:00 PM

October 28, 2015

QjackCtl 0.4.1 is out!

Yup, that's true:

QjackCtl 0.4.1 (fall'15) is out!

QjackCtl is a(n ageing but still) simple Qt application to control the JACK sound server, for the Linux Audio infrastructure.



  • Probing portaudio audio device in a separate thread (by Kjetil Matheussen, thanks).
  • Messages standard output capture has been improved again, now in both ways a non-blocking pipe may get.
  • Regression fix for invalid system-tray icon dimensions reported by some desktop environment frameworks.
  • New hi-res application icon (by Uttrup Renzel, Max Christian Pohle, thanks).
  • System tray icon red background now blinks when a XRUN occurs.
  • Desktop environment session shutdown/logout management has been also adapted to Qt5 framework.
  • Single/unique application instance control adapted to Qt5/X11.
  • Prefer Qt5 over Qt4 by default with configure script.
  • Override-able tool-tips with latency info (re. Connections JACK client/ports: patch by Xavier Mendez, thanks).
  • Complete rewrite of Qt4 vs. Qt5 configure builds.
  • French (fr) translation update (by Olivier Humbert, thanks).


QjackCtl is free, open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

From the footnote department: for quite some time there's an alternate repository which is kept in sync with the one. However, this doesn't mean that the QjackCtl project is about to migrate to a brand new hosting whatsoever: the original upstream source code repository is, will be, as ever was, always kept somewhere else still in this world and universe.

Enjoy && keep the fun!

Flattr this

by rncbc at October 28, 2015 07:00 PM

Linux Audio Announcements -

[LAA] QjackCtl 0.4.1 is out!

Yup, that's true:

QjackCtl 0.4.1 (fall'15) is out!

QjackCtl [1] is a(n ageing but still) simple Qt [3] application to
control the JACK [2] sound server, for the Linux Audio [4] infrastructure.



- source tarball:

- source package:

- binary packages:

- Probing portaudio audio device in a separate thread (by Kjetil
Matheussen, thanks).
- Messages standard output capture has been improved again, now in both
ways a non-blocking pipe may get.
- Regression fix for invalid system-tray icon dimensions reported by
some desktop environment frameworks.
- New hi-res application icon (by Uttrup Renzel, Max Christian Pohle,
- System tray icon red background now blinks when a XRUN occurs.
- Desktop environment session shutdown/logout management has been also
adapted to Qt5 framework.
- Single/unique application instance control adapted to Qt5/X11.
- Prefer Qt5 over Qt4 by default with configure script.
- Override-able tool-tips with latency info (re. Connections JACK
client/ports: patch by Xavier Mendez, thanks).
- Complete rewrite of Qt4 vs. Qt5 configure builds.
- French (fr) translation update (by Olivier Humbert, thanks).

QjackCtl [1] is free, open-source Linux Audio [4] software,
distributed under the terms of the GNU General Public License (GPL [5])
version 2 or later.

From the footnote department: for quite some time there's an alternate repository [6] which is kept in sync with the one [7].
However, this doesn't mean that the QjackCtl project is about to migrate
to a brand new hosting whatsoever: the original upstream source code
repository is, will be, as ever was, always kept somewhere else still in
this world and universe.

See also:


[1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface

[2] JACK Audio Connection Kit

[3] Qt framework, C++ class library and tools for
cross-platform application and UI development

[4] Linux Audio consortium of libre software for audio-related work

[5] GPL - GNU General Public License

[6] QjackCtl Git repository on

[7] QjackCtl Git repository on

Enjoy && keep the fun!
rncbc aka. Rui Nuno Capela
Linux-audio-announce mailing list

by at October 28, 2015 04:53 PM

Nothing Special

JACK Midi Control from your Android Phone over WiFi

Since my fundraising for my plugin GUIs is more or less bust, I've been thinking more about making music. I can't really stop developing, cause I'm fairly addicted, but I'm trying to ween myself back to just making whatever I want, rather than trying to develop stuff that will change the world. The world doesn't care that much. Anyhow, this blog is no place for bitterness.

But I have been playing with synths a bit more lately and still am really missing my expression controls. Now I could try to use the old touchmidi app I developed, but it only works with my laptop, and I now have a dedicated desktop in the studio to host my synths so I don't have a touchpad to use. I do have several android devices though. They should be great input interfaces. They can display whatever they like on the screen and have a touch interface so you can have arbitrary configurations of buttons, sliders, knobs, whatever. So I decided to figure out how.

There are a few tools you need, but first: an overview. The key to sending control information from one device to another is OSC (Open Sound Control), which in a nutshell is a way to send data over a network, designed for media applications. We need something to interpret touch input on the phone or tablet and send an OSC message. Then something needs to receive the message, interpret it, convert it to a midi message and send it out a JACK midi port. Well, we aren't inventing the wheel, there are several programs that can do these or related tasks.

One closed source system is TouchOSC. They have a free desktop app and the android app is a few dollars. But its closed source and doesn't actually work on linux. UNACCEPTABLE.
There are really several other apps, many of them free and none of them have had updates in the last few years. Ardroid is an OSC controller, but it is meant for ardour, you can't make custom interfaces like you can with TouchOSC.

What we want is Control. It hasn't been updated for a few years and its kinda buggy, but its OPEN. I could go fix it from the github source (but it would take me a bit of research on android stuff and I'm not a java fan) but its good enough as it is to get by. It uses customizable interface layouts written in JSON and you can add scripting to the interface through javascripts, so no crazy new formats. The real bugs are just in the landscape and portrait mode switching, so I have to open and close the interface a couple times before it gets it right. It's also cross platform.

I was able to make an interface after a few infuriating late night hours of trying to edit one of the examples (that I'm pretty sure had a lot of iOS specific JSON tags), then trying again next morning using the blank template and getting it done in about an hour. I never learn. Its a little involved to make a custom interface but there are good examples and decent documentation. It seems after a while of development the author focused much more on iOS and neglected the Android side, so there are several tags like color that don't work on android and make the interface much buggier if you attempt to use them. If someone wants to be super rad they would take this app and fix it up, make it a bit more robust and report json errors found in layouts etc... But its good enough that I'll just keep using it as it is.

For starters, you can just use the interfaces the app comes with. Go ahead and install it from google play. They have a pretty good variety of interesting interfaces that aren't all exactly conducive to midi control (remember apps CAN have built in OSC support like ardour and non-mixer do) but any of the interfaces built into Control will work. I'll tell you a bit about some other interfaces later.

UPDATE: Since I started writing this, another open source android app has come up: andrOSC. Its much simpler but allows you to edit everything in the app. Its a great option for anyone who wants a custom interface without any sort of file editing or extra uploading. Its a little too simple for what I want so I'm going to stick with Control for now.

Now we just need someplace to send the OSC data that the Control interface will output. Well I thought mididings was the tool for this job but it only accepts a few arbitrary OSC commands and there is no way to change the filtering through OSC aside from making scenes and switching between them. So that was a dead end.

But, the libraries used by mididings are openly available, so I figured I'd just make a python script to do the same thing. Except I've only edited a few python scripts and this is a few steps beyond that. The libraries used are actually c libraries anyway, so c wins. Hold on a sec, I'll just whip up a C program.

(Months go by)

Ah that was quick, right? Wait, Christmas is in how many days?!
Oh well. It works. And its completely configurable (and more features on the way). This new program, OSC2MIDI, gives you the flexibility to change the mapping wherever its easiest, in your OSC client app (i.e. our Control interface), in the osc2midi converter map file, or in the midi of the target program. In another post I'll describe how to use osc2midi more fully (with custom mappings) for now the default one works (because I wrote it to work with all the example interfaces that come with Control).

Download a snapshot, (EDIT: I just released the first beta, from now on, download the files, 2nd edit, updated link) extract them, and install them:
cd osc2midi
cd build
cmake ..
sudo make install

Then run:

Not too bad (if it didn't work cmake should help you, or just check the README for the dependencies). This gives you a jack midi client and opens an OSC host at 192.168.X.X:57120 (Your computer's IP address : Default port). If you don't know your ip address you can get it with the terminal command ipconfig. Connect the jack midi out port to Carla or whatever you like (I'll proceed with assuming you are using Carla).

Now we need to connect the Control app to the OSC server. Click the destinations tab and the plus sign at the top to enter in the address of the OSC host. From there go back to the interfaces tab and select whatever interface sounds like it will tickle your fancy. For this exercise we'll go ahead and use the mixer interface. If it looks squashed or doesn't fit on the screen you probably have to go back to the menu and open the interface one more time. I always have to open it twice like that (obnoxious, right? you should really go fix that!).

In Carla, load a plugin. Simple amplifier is perfect. First connect the osc2midi output port to the simple amplifier events input port. Open the editing dialog for the plugin and click the parameters tab at the bottom. Simple amplifier only has a single parameter (gain) and so you'll see a single horizontal slider and 2 spinboxes right of it. These numbers select the midi control number (CC) and channel.

Since we called osc2midi without arguments it defaults to channel 1 (or 0 if you prefer 0 indexing) and the first slider in the mixer interface on your android device will send midi CC 1 so select "cc #1" in the middle numeric box. You just bound that midi control to change the amplifier gain. If your jack ports are all set up correctly you should be able to change the first slider on your phone/tablet and watch the slider in Carla wiggle up and down with it. You have CONTROL!!!

The setup
 The other sliders are just sequentially mapped through CC 12. You can figure out what anything is mapped to by either using kmidimon to look at the midi output or running osc2midi in verbose mode (osc2midi -v). You can add other plugins and control them by the same method. Get creative with it.

For my next trick, we'll make some sounds with Control. Hit the menu button on Control and select the Conway's Game of Life interface. The default mapping works but I include a better one with the installation. So in the terminal hit Ctl+C to stop osc2midi. We'll start it again specifying a different map file. Type in:
osc2midi -m gameOfLife.omm
And the server will be restarted on the same port so you won't need to change anything else.

Now lets load an instrument plugin into Carla. I like amsynth but you can use any you like (though a polyphonic one will probably be more fun for this exercise). With an instrument plugin loaded just connect the midi-in port of the instrument to the osc2midi output the the audio output from your plugin/carla to your soundcard. Click several of the buttons on the grid in Control and you should hear some notes start playing. They will stay on till you click it again. Or click the start button and the notes start toggling themselves and you have a nice random sequencer.

This isn't quite enough for simulating all the expression you can get out of a good synthesizer or midi controller, but its a start. The best part is these open tools are all highly configurable, so we have a working system with just using all the defaults. But we can also setup very powerful and custom configurations by tweaking the interface in Control, the mapping in osc2midi, and often the midi bindings in your destination program (like Carla). But we'll save the rest for another post. In the mean time, try all the templates and get creative with these tools.

by Spencer ( at October 28, 2015 12:27 PM

October 26, 2015


ArtyFX Progress

ArtyFX Progress

The past few weeks have been coding on the new UI for ArtyFX. They’re almost done! What else has been going on at OpenAV? Lots of music, and thoughts about live-performance workflow. Its hard to innovate workflow – how musicians actually produce music, but we’re confident that there’s room for improvement over the current state-of-the-art… Luppp has had contributions –… Read more →

by harry at October 26, 2015 03:32 PM

October 25, 2015

Linux Audio Announcements -

[LAA] mcpdisp 0.0.5 released

The Mackie Control Display Emulator has a new release 0.0.5.

This adds the scribble display to control surfaces that use the Mackie
Control Protocol but do not have their own display such as the BCF2000 and

mcpdisp presents a jack midi port that will accept mackie control protocol
display messages that would normally appear on the surface "scribble
strip" and displays them on the screen. The strip LEDs and meters are
displayed as well.

New things:

* Fixed INSTALL file for no
* Added Assign display.
* Added timecode/beats display.
* Added Strip meters.
* Added command line parameters for help, version, master and time.
* Made window title more descriptive.
* jack client name shows mcpdisp-ext if no -m
* Start work on global buttons.
* Finished Transport LEDs and flip, assign and View LEDs.
* Set MIDI in port to type Terminal/Physical.
* Set Display in to accept whole display of text at a time.
* Move midi parsing out of real time.
* Only update time/beats when new time/beat data comes in.

Source is available from:

Home page:

Len Ovens

Linux-audio-announce mailing list

by at October 25, 2015 02:38 PM