Exercise Update

At the start of the year I set myself a goal around health and fitness:

  • Run a total of 1200km this year
  • Get my resting heart rate below 55 and keep it there
  • Get my weight below 80kg and keep it there

I started the year off with gusto, I was ahead of my weekly distance requirement, my heart-rate was dropping, and I was beginning to see some weight-loss. Then my knees started hurting.

It turns out I had missed some important muscles while stretching. Since then I’ve had to take a lot of time off running, and sometimes off all exercise. I’m now way behind my distance schedule, my heart rate has gone back up, as has my weight. I’m not giving up, but I’ve certainly had to stop and take a new approach. The lesson? Start easy, build up, you’ll meet your goals eventually. Don’t focus too much on pushing hard when you start off, get a base strength and fitness first.

Here’s a chart of my running to date:



Using Let’s Encrypt to Generate an SSL Certificate for Azure, on Mac

Today I needed to set up an SSL certificate for our company website. Being frugal, and interested, I decided to try Let’s Encrypt (a new organisation which aims to make SSL free, so that nobody has any excuses).

First step, get the client by cloning the git repository:

git clone https://github.com/letsencrypt/letsencrypt.git

Now, before you start: if you’re on a mac, you should make sure you have homebrew installed and working. Once that is done, install python through it (because the homebrew version comes with pip the python package manager):

brew install python

Then when that is installed, install virtualenv:

pip install virtualenv

Right, that’s all the dependencies for the letsencrypt client. Let’s move on to prepping your azure website. I assume that you have a running website under a custom domain already. The internet has plenty of documentation on how to get there. Let’s Encrypt uses a protocol called ACME to verify that you own the domain that you are trying to get a certificate for. It does this by asking you to serve a particular piece of content, unique to your request for a certificate. Getting Azure to do this is actually fairly simple, if you have the right documentation collated together, so here it is:

  1. Through your FTP access to your website create a directory called well-known as a sibling of the wwwroot directory, and within this new directory, create a directory called acme-challenge
  2. In the Application settings blade of your website, in the new Azure portal, right down the bottom of the blade, add an entry under Virtual applications and directories with the following values
    • Virtual Directory: /.well-known
    • Physical path rel: site\well-known
    • Leave the ‘application’ box unticked
  3. Next create a web.config file with the following contents:
    <?xml version="1.0"?>
                    <mimeMap fileExtension="." mimeType="text/plain" />
                    <mimeMap fileExtension=".txt" mimeType="text/plain" />
  4. Place the web config file into both the well-known, and acme-challenge directories.
  5. Create a .txt file with something in it, and place it in the acme-challenge directory, then try to access it. If you get the content of your text file showing up in your browser, you’re good.

Ok, now you’re good to go, so change to the directory where you cloned the letsencrypt repository

cd letsencrypt

The command is quite simple:

./letsencrypt-auto certonly -a manual --rsa-key-size 4096 -d domain.com --debug

If you’re using a Mac and you leave off the –debug flag, you’ll just get told to put it on. At this point you’ll go through a few screens with some prompts etc, and then you’ll get to this:

Make sure your web server displays the following content at
http://domain.com/.well-known/acme-challenge/KkRlmp5Y7Vtitd37tyZ3M7rtwrZ7b9KyoFf4-UdGMBI before continuing:


If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge

cd /tmp/letsencrypt/public_html

printf "%s" KkRlmp5Y7Vtitd37tyZ3M7rtwrZ7b9KyoFf4-UdGMBI.0XPKTuHHwF3vk2VV7czrfw72_Lnq8oEZPzXVPbkbk_E > .well-known/acme-challenge/KkRlmp5Y7Vtitd37tyZ3M7rtwrZ7b9KyoFf4-UdGMBI

# run only once per server:

$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \

Press ENTER to continue

I wouldn’t worry about the lower bit, telling you how to run a very simple python server, but the upper half is quite important, particularly this bit:

printf "%s" KkRlmp5Y7Vtitd37tyZ3M7rtwrZ7b9KyoFf4-UdGMBI.0XPKTuHHwF3vk2VV7czrfw72_Lnq8oEZPzXVPbkbk_E > .well-known/acme-challenge/KkRlmp5Y7Vtitd37tyZ3M7rtwrZ7b9KyoFf4-UdGMBI

If you try to copy-paste the content into a file, you’ll probably get a newline in the file which will cause your attempt to fail. I didn’t read instructions properly the first three times, and I failed each attempt, until I looked more closely and realised they were telling me how to make the file I wanted in the first place!

Once you have a file generated as above, copy it into the acme-challenge directory you created via ftp. Now double check that it downloads correctly, but visiting the url they give you. If you get what they’re telling you they expect to see, then you’re good to go: press ENTER.

If you’re successful, you’ll get something like this:

    - Congratulations! Your certificate and chain have been saved
      at /etc/letsencrypt/live/mwabu.com/fullchain.pem. Your cert will
      expire on 2016-04-17. To obtain a new version of the certificate in
      the future, simply run Let's Encrypt again.
    - If you like Let's Encrypt, please consider supporting our work by:
        Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
        Donating to EFF:                    https://eff.org/donate-le

Now, that’s a really sucky place for them to put the certificates. I went in through finder and gave myself permissions to those directories. While you’re doing the ‘live’ directory, also do the ‘archive’ directory, as that is where the files really live – they’re just symlinked into live. I copied the archive folder elsewhere to do the next step, but you could do it in-place as well.

Ok, great so now you have a bunch of PEM files, but azure wants a PFX. That’s ok though because we can manage that with openssl. You might need to install this via homebrew, but try it first:

openssl pkcs12 -export -out /path/to/output/file.pfx -inkey /path/to/archive/privkey1.pem -in /path/to/archive/fullchain1.pem

Put in a password, as this file has a private key in it, so you don’t really want it lying around unprotected. I’ve subsequently deleted the extra copies I made, and I’ve removed my permissions from those directories as well. That way someone has to get into my computer, and log in as root in order to even see the files.

Ok, nearly there. Now you can upload the certificate to Azure, and once it is uploaded you can set up a binding to it. There are already plenty of docs out there about those two steps.


  1. https://community.letsencrypt.org/t/installing-and-configuring-letsencrypt-on-a-mac-os-x-client-server/8407
  2. https://community.letsencrypt.org/t/how-to-use-letsencrypt-on-basic-webhosting-without-ssh-access/4608/7


Don’t forget the cross-fade

A quick post about a little lesson I learned tonight whilst editing some audio: don’t forget the cross-fade.

I recorded some synth drum tracks to audio (so that I wouldn’t have to open up the drum machine again), and then trimmed the tracks down so that they ended tidily at the end of the bar: BAD! When I later when to loop those tracks I realised that I hadn’t left room for the quick fade from one clip to another that you generally need when putting clips right next to eachother. What I needed to do was leave a tiny bit extra on the end so that the clips could overlap without messing up the timing.

Luckily my trimming wasn’t destructive, so I could extend the clips back out.

Here’s a screenshot of what I mean.

Ardour Clip XFade

More valgrind goodies

Today I encountered the following error out of valgrind:

Syscall param recvmsg(msg.msg_iov[0]) points to unaddressable byte(s)

I’ve had some variant of this a couple of times now. The first time it was a pseudo-false-positive: in resorting to culling code until the error went away I found it was replaced my a memory leak. After fixing the leak and putting all the culled code back, the board was green.

Today I had it in another situation. Take the following classes:

class A {
     A(shared_ptr<B> b) : b(b) {}
class B {
     virtual void foo() {}
class C : public B {
     virtual void foo() {}

The substantial change I made was to introduce an extra parameter into the signature of B::foo:

class B {
     virtual void foo(int arg) {}

But I forgot to update it in C. The error was supposedly happening when A was constructed, which made little sens because there were no changes to A that would affect the layout of an A instance. So, I tried progressively reverting changes until the function signature was the only change left, and then it dawned on me that the error was in a unit test so it might be something with the mock (in this case C). I updated the signatures in the mock, and the error went away. At this point I delve into hearsay: I can only conclude that the uninitialized bytes were to do with the v-table, and because I had a weird situation with effectively an overload on a subclass that didn’t exist on the superclass the v-table must have been a bit odd-looking to valgrind.

Anyhow, the point of this post is not to get into the nitty gritty, because I just don’t have that level of compiler-foo, rather to note that this particular valgrind error is often quite cryptic, and that one of the possible causes is subclasses not properly extending their parents.

The value of valgrind

This weekend I got quite a lot done on liboca, mainly working on the network stack, and the basic implementation of OCP.1, which is the TCP/IP-based protocol for OCA (There is room in the OCA standard for other transports). Anyhow, at one point, my unit tests broke in a suite of tests that tested code that should not have been affected by the code I was working on. In the end the fact that I had set up Valgrind, ended up showing me how to solve my problem, so I learned that hard way that it is an essential tool to run along with your standard test suite.

What is Valgrind?

"Valgrind is an instrumentation framework 
for building dynamic analysis tools. There 
are Valgrind tools that can automatically 
detect many memory management and threading 
bugs, and profile your programs in detail. You 
can also use Valgrind to build new tools. " 
                                      - valgrind.org

In its simplest form, it takes your code, instruments it and runs it on a processor emulator, and tells you if you’ve leaked memory, accessed memory you shouldn’t have, and a whole bunch of other stuff – I encourage you to check out the website for more detail.

So what happened?

So we already got to the fact that I had a theoretically non-impacted test stubbornly crashing with:

Segmentation fault (Core Dumped)

Frustratingly, I couldn’t reproduce the crash in a debugger, which left me thinking it was a race condition for a while, but all the tricks I tried to hunt down the race didn’t give me any inclination as to what was going on. Also, the core was not being dumped, by default Ubuntu doesn’t do that. You need to enable core dumps with:

$ ulimit -c unlimited

Anyhow, I then debugged the core dump:

$ gdb build/tests/all core

Finding that the Seg-fault was inside Google Test! Googling for this issue showed no known issues around this part of the code, so I was a little stumped.

So what next?

Looking further up the stack trace showed that it happened inside _malloc_consolidate which previous investigations have lead me to attribute to memory corruption, most often heap trashing. Anyhow, I have a bunch of verification scripts set up to automatically run the unit tests, static analysis and dynamic analysis (valgrind!), and was indeed running them. Lo and behold, valgrind (memcheck) was turning up 47 issues, all of which were relating to a few lines of code (that I had been working on) where I was deleting an object which was still needed by an asynchronous process. I fixed the errors rather easily, and hey presto! No more Segmentation Fault.

You see the problem was not even the unit test in question, but about 10 tests earlier, the heap was getting trashed, which was causing the test runner to seg-fault later on.

So what did I learn?

In the past I’ve had policies on repositories that no code makes it in without a successful build and test-run. Usually I compile with -Werror (or similar) so that my code never has any warnings (because I have to fix them, since they’re treated as errors). This time I added cppcheck and valgrind because I figured they would be useful. This experience taught me that if I ever encounter weird issues while I’m working, I should run the full verification suite because I will probably find something related to the weird issues that way.

My first ever audio plugin

I’ve been procrastinating working on the OCA library project that I’ve started, so I ended up writing a really naive distortion plugin.

My SI-D1 distortion running as a standalone JACK application.
My SI-D1 distortion running as a standalone JACK application.

It works as a LADSPA, LV2, VST (untested) plugin, or as a standalone application (as pictured above). I used the DISTRHO Plugin Framework which is how I can target all the platforms. It should, in theory, build on Windows as well.

The code itself is quite simple: it pre-amplifies the signal, and then applies a very hard clipping algorithm. The clipping levels are determined by the “Range” and “Bias” parameters. Range sets the distance between the thresholds, around 0.0, and then Bias moves those thresholds up or down. It doesn’t sound great but its a start.

I haven’t provided a binary download as yet, but you can get it on github.

Try it out and let me know what you think.

Towards a cross-platform C/C++ dev environment

As you’ve probably read in my recent posts, I’ve been getting involved in the linux audio community. I’ve discovered that I really like linux – especially the concept of a system-wide package manager, I wish Windows had one that everybody used.

What I miss is Visual Studio. I really can’t overstate the hit my velocity has taken without intellisense. Its not that I’m incapable of programming without it, but it takes such a long time to look through html SDK/API docs. So, I’ve been trying to sort out a system where I can lint my code, build my projects, get some form of auto-complete, and have a few other C/C++ specific conveniences, like switching between .h* and .c* files with the same base name. I also don’t want to be tied to a build system. I’m kinda greedy, I want a graphical debugger if I can. I’ve got a solution now which shows potential.

As text editors go, I’ve grown to like Atom by GitHub over the last year or so. It is built in JavaScript (mostly, they moved a few things down to native code for performance, it is now quite slick, and a lot better than it was even 6 months ago), and it is super extensible, but in a nice way, not like Eclipse.

Triggering builds

One of the challenges with Linux is that there are quite a few build systems in common use: autotools, scons, waf, cmake to name a few. I like waf, but autotools is super common. Anyway, I didn’t want to be tied to a build system, but I do want to do basic things like build or configure my project from a keyboard shortcut. There’s a nice plugin for this: build. It has a bunch of built-in build systems that are mainly web-focused, but it lets you basically tie any shell command to the keyboard shortcut if you want, by providing a file called .atom-build.json.

Here’s what mine looks like:

     "cmd": "./waf",
     "name": "Build",
     "sh": "true",
     "targets" : [
               "cmd": "./waf configure",
               "name": "Configure",
               "sh": "true"

It’s not perfect – if you switch target it remembers which is a pain for doing things like configure, or clean, which you do once in a while, then go back to building. I’ll probably fork it and make a more C/C++ centric version one day, but it works well enough. Install it as follows:

> apm install build

Ok, so I can build, and each time I build, I get to see what’s wrong but sometimes deciphering a big blob of compiler output is difficult, and slow. Atom has a plugin which gives a generic linting infrastructure. I guess it was originally built for JSLint or something. Users can create providers to this linter to handle various languages, and it just so happens there is one which uses GCC, and one which uses Clang, so take your pick. I’m using the GCC one.

> apm install linter linter-gcc

You can change the default compiler flags, so I added -Werror, to make warnings appear as errors – I use that in my build script as well. linter-gcc supports a per-project config file which allows you to configure the settings per project, called .gcc-flags.json. I haven’t had to add any flags to it as yet, but at some point I’ll write a waf plugin to dump my CFLAGS and CXXFLAGS into this file whenever I configure. If you use autotools, I’m sure your configure script could do something like that too. A note about this one: at the time of writing (version 0.36.0), this plugin is actually a little broken. I fixed it and the PR was merged, so you should probably get it from source instead, or install it with apm and then replace the main.js with one from github.


Again, Atom has existing auto-complete infrastructure in the form of the autocomplete-plus plugin, which can be extended by providers – in this case autocomplete-clang. Now this is one of the key reasons LLVM and Clang were created, to be used in tool integrations. You’ll need to have Clang installed such that the clang executable is on your path, but that’s easy on all platforms. Install the plugins with:

> apm install autocomplete-plus autocomplete-clang

You can customize your cflags etc per project with a .clang_complete file, which is the same file used by the clang-complete plugin for VIM, which is neat. Again, I haven’t had to modify these yet, but getting waf to auto-generate the file should be pretty easy.

Switching files

Ok, so we can build, lint, and auto-complete now. All that’s left from my wish-list is switching between header and source files with the same name, and debugging. Lets deal with the former, there’s a plugin for that.

> apm install switch-header-source

This one is probably the least satisfying. I’ve installed a plugin called atom-debugger, which basically bootstraps gdb. At the moment it is very basic, but I think it could be improved quite quickly, so I’ll probably find myself contributing to it. Install it with:

> apm install atom-debugger

Linux is actually a really awesome environment to write code in, mainly because of system wide package management, and a defined scheme for where libraries, headers etc go, which means that you very seldom have to add special include or lib directory paths to your compiler flags. Visual Studio is an incredibly powerful IDE, which you miss when you are relegated to a mere text editor. Atom, is a great, highly extensible text editor which can be extended to give you quite a functional IDE for developing in C/C++, without being tied to a buildsystem or compiler, and it can be done on Linux, OSX and Windows. Boom.


Building Ardour on Windows with MSYS2

NOTE: This post was written for Ardour 4. There is at least one more dependency (liblua, possibly more). Since I wrote this article, I’ve mostly shifted my development environment to linux, hence I haven’t kept this post up to date. So, caveat emptor, YMMV, and other suitable disclaimers. If you just want to use Ardour on Windows, it is now supported on Windows, so why not donate to the Ardour developers and get an official download? I’m currently toying with building Ardour for Windows via the Windows Subsystem for Linux on Windows 10, but a post on that is a bit far away.

Building Ardour on Linux is quick and easy. Building Ardour on Windows…isn’t. That being said, I bashed my way through it, and have come up with a strategy that will get you up and running.

Who is this post for?

This post is most definitely for developers, familiarity with MSYS2 is handy, but as I was basically learning how MSYS2 works as I went, this post won’t assume terribly much on that score. If you just want to use Ardour on Windows I highly recommend downloading a nightly build and using that instead. Keep in mind that Ardour is un-ashamedly built for linux, and it is fantastic on that platform, so if you want the most out of Ardour, use it on linux. If you MUST use windows, know that at present it isn’t supported, and sometimes the nightly builds might be broken. That being said the Ardour developer community is looking into how support could become possible one day.

Other things you might want installed

I find it is handy to have JACK and ASIO4ALL installed.

Getting Started

The first thing you’ll need to do is install MSYS2, but what is MSYS2? Google says this:

MSYS2 is a successor of MSYS and MinGW-builds. 
MSYS2-shell uses “pacman” for downloading packages from
repo, and these are GPG signed & verified. Packages are
by developer: lexx83 (Alexpux), mingwandroid, niXman.

Essentially it is a very light gnu-like environment for Windows, like a very stripped down cygwin. It makes it a lot easier to build linux programs and libraries for windows that don’t use Cmake. There is a good set of instructions here on how to install it and set it up, so I won’t copy them.

Great, now that you’ve followed all the way through that, you should have an up-to-date msys2 system. Now we have a few packages that need to be installed, well, quite a few, most of them from source, but we’ll do it in four batches: tools, prebuilt dependencies, source dependencies, and then some more pre-built packages which require some of our source packages. Before that we should discuss the three shells available to you:

  • MSYS2 shell
  • MinGW-w64 Win64 shell
  • MinGW-w64 Win32 shell

Essentially, the MSYS2 shell is a runtime environment with full posix support. This is most useful for the unix tools. The other two shells have less posix compliance, but play much nicer with the windows APIs, so if you want to build a windows application, you’ll use these. Of these latter two, I’m only using the MinGW-w64 Win64 shell, which uses a 64bit toolchain. That being said, it is easiest of you do all of the package installation (both pre-built, and from source) in the MSYS2 shell. There’s a bunch more detail here.

Install various tools
> pacman -S mingw-w64-x86_64-toolchain python3 \
python3-setuptools mingw-w64-x86_64-python3 \
mingw-w64-x86_64-python3-setuptools python2 \
python2-setuptools pkg-config \
mingw-w64-x86_64-pkg-config autoconf automake perl \
gtk-doc flex bison patch libtool \
mingw-w64-x86_64-libtool wget git nasm \
mingw-w64-x86_64-nasm dos2unix mingw-w64-x86_64-cmake

This will take a while based on your internet connection, etc.

Install pre-built dependencies
> pacman -S mingw-w64-x86_64-glib2 \
mingw-w64-x86_64-gobject-introspection \
mingw-w64-x86_64-pkg-config mingw-w64-x86_64-c-ares \
mingw-w64-x86_64-ca-certificates \
mingw-w64-x86_64-gnutls mingw-w64-x86_64-libidn \
mingw-w64-x86_64-libssh2 mingw-w64-x86_64-rtmpdump \
mingw-w64-x86_64-gnutls libgnutls-devel \
libutil-linux-devel gtk-doc \
mingw-w64_x86_64-docbook-xsl intltool \
mingw-w64-x86_64-libjpeg-turbo \
mingw-w64-x86_64-jbigkit \

Build and install source dependencies

So the thing about MSYS2 is that it stays very “bleeding edge”, whereas most of the Ardour devs use Debian, which has quite a long update cycle. Both approaches have their merit, but they come into conflict when you want to build something that expects debian-ish packages, but have only the most up-to-date packages available. Thankfully, others have blazed this trail before me and have created repositories of package build scripts for most of the packages you’ll need for Ardour. Most of these are quite straight-forward to install, but there are some mighty strange quirks, which we’ll discuss as we get to them.

To get these package scripts, clone my github fork of them:

> git clone https://github.com/guysherman/MINGW-packages

NB: Make sure to switch to the guypkgs branch!

As the README says, to make a given package do the following:

> cd ${package-name}
> makepkg-mingw

And to install it do:

> pacman -U ${package-name}*.pkg.tar.xz

Alternatively, you can do this to build and install at once:

> cd ${package-name}
> makepkg-mingw --install

There are also a few useful flags that you’ll need at times:

--nocheck - disables the 'check' step, which is usually
            unit tests
--nodeps - disables dependency checking, which is 
           useful because a few packages have cyclic 
           runtime dependencies
--skippgpcheck - doesn't check the signature of the 
                 package, I needed this on a couple of
                 packages, only use it if you have 
                 errors relating to unknow public keys,
                 or the pgp part of the process.

So, now that we’ve covered how to build and install the packages, build and install the following list of packages:

 mingw-w64-x86_64-pcre with --nocheck
 mingw-w64-x86_64-gobject-introspection with --nodeps

These should all be straight forward, but some of the will take a long time. Next we get into the weirdest quirk I’ve seen in a while. There are two libraries, harfbuzz and freetype. Turns out they have a circular dependency on eachother. So what you have to do is

First, build and install harfbuzz with –nodeps

> cd mingw-w64-x86_64-harfbuzz
> makepkg-mingw --nodeps --install

This will end up installing the following packages from the pre-built repositories, but the freetype will have no harfbuzz support:


So, next step delete the harfbuzz package that you already built and rebuild it (assuming your still in the harfbuzz directory):

> rm -rf mingw-w64-x86_64-harfbuzz*.pkg.tar.gz
> makepkg-mingw --nodeps --install

Next build and install the following packages:


Ok, now that’s the harfbuzz freetype weirdness out of the way. You should be good to go ahead and install the rest of the source packages:


The second wave of pre-built packages

Ok, so now there are two more pre-built packages that you need to install:

> pacman -S mingw-w64-x86_64-rubberband \
Actually Building Ardour

Ok, so now you have all the dependencies you need to build and run Ardour (although we’ll discuss one other work around a bit later which solved a problem that I had, that I’m not sure if you will encounter or not).

For now you’ll need to clone my fork of Ardour. I’ll update when my pull request is accepted. Get the ardour code (do this from somewhere you’d like the code to go):

> git clone https://github.com/guysherman/ardour.git
> git clone git://git.ardour.org/ardour/ardour.git
> cd ardour

Ardour uses the waf build system. I found there was a tiny quirk with running it under MSYS. Run it as follows to configure Ardour:

> ./waf configure \
  --dist-target=mingw \
  --prefix=/mingw64 \

Then to build it, run

> ./waf

If you want to install it you can do so with

> ./waf install

I’m more interested in running it:

> cd gtk2_ardour
> ./ardev-win

Now, you might find that you get white text on white buttons, like I did, and you’ll probably see warnings about the gtk ‘clearlooks’ engine. I worked out a weird work around for this.

Weird clearlooks workaround

Go to a folder somewhere (ie ~/), and get the gtk-engines source code:

> cd ~/
> wget http://ftp.gnome.org/pub/GNOME/sources/gtk-engines/2.20/gtk-engines-2.20.2.tar.gz
> cd gtk-engines-2.20.2
> ./configure \
  --build=x86_64-w64-mingw32 \
  --host=x86_64-w64-mingw32 \
> make
> make install

You’ll get a whole lot of warnings that it can’t find various dlls. That’s no biggie in this case.

Next you’ll want to download a nightly build of ardour for windows and install it.

Then copy C:\Program Files\Ardour4\lib\gtk-2.0\engines\libclearlooks.la to C:\msys64\mingw64\lib\gtk-2.0\2.10.0\engines. It’ll want to over-write a file, which is all good. Now if you go back and run Ardour, it should look fine.


It occurred to me after I wrote this that I should have acknowledged all the help the Ardour devs gave me while I was asking pesky questions. They are a very helpful and welcoming group.

Building Ardour on Ubuntu

[UPDATE] I’ve found that the instructions below cause jackd2 to be uninstalled, which causes some problems. Reinstalling the jackd2, libjack-jackd2-0, libjack-jackd2-dev and pulseaudio-module-jack packages should fix those issues[/UPDATE]

I’m taking a journey into audio software, and I’ve been playing around on Linux because there’s quite a good open-source audio community out there. The shining star (in my opinion) is Ardour, a really excellent, open-source DAW. In fact Harrison Mixbus is based on it.

Anyway, many of the developers who work on Ardour use Debian, but I prefer UbuntuStudio, so here are some simple steps to building on Ubuntu. I’m assuming that you already have a dev environment set up (ie you’ve gone ahead and installed build-essentials, git etc).

These instructions are pulled largely from the Ardour instructions, with a few other useful tips given to me by Robin Gareus and Paul Davis in IRC.

I’m running Ubuntu Studio 15.04.

Step 1 – The dependencies

The Ardour website has a list of Ardour’s dependencies. You’ll notice that there are a few libs which they have modified versions of. You don’t need these special ones – you can get by without them. I learned yesterday that APT has very neat mechanism for installing these dependencies. A package maintainer can specify the list of dependencies required to build the package, not just to install it. So, to install the dependencies do the following:

> sudo apt-get build-dep ardour3

On Debian, that would actually give you all the dependencies for Ardour 4 (their Ardour3 package is actually version 4.x). On Ubuntu there are a couple more dependencies you need to install:

> sudo apt-get install vamp-plugin-sdk libtag1-dev libaubio-dev liblrdf0-dev librubberband-dev

Now you should have all the dependencies for Ardour.

Step 2 – Get the code

Assuming you have already changed to the directory where you want to clone ardour

> git clone git://git.ardour.org/ardour/ardour.git

Alternatively you could go to their github mirror and fork that, and then clone that to your machine. If you want to submit changes doing them via github PRs is by far the easiest way.

Step 3 – Build

Next change into the ardour directory that was cloned

> cd ardour

Then we build

> ./waf configure
> ./waf

If you are missing any depenencies then you should find out during the waf configure step.

Step 4 – Run

To run the version you just built

> cd gtk2_ardour
> ./ardev

Waf also lets you do install/uninstall/clean etc.

Linux Audio

I’ve recently started learning about signal processing, and a programming language called faust. They are very linux focused, and so I figured the best way to get up and running with it would be to dive into linux, it’s been a while since I really gave linux a fair look, so I was due for it.

Without digressing too far, I would like to announce that I now quite like linux, and I could pretty much use if for all of my home computing apart from gaming.

Anyhow I’m running Ubuntu Studio which is an audio-focused Ubuntu derivative, and there was one little snag Continue reading “Linux Audio”