MIDI on Linux

A few years ago when I tried to connect MIDI devices to a Linux PC it got very fraught with a lot of manual configuration and tweaking necessary. However I tried it again recently and was pleasantly surprised how much just worked out of the box.

I’d previously been using Mac OS X and Garage Band as a sound generator / accompanist for my Yamaha WX5 Wind Synth and wanted to replicate the setup using FOSS on Linux. There is a specific sound generator for Yamaha wind synths, the VL70-M, but these were obsolete and not available when I bought the WX5. As second hand examples fetch big money on Ebay then I decided to use more generic MIDI sound generators ( and yeah my playing is nowhere near good enough to tell the difference 🙂 )

An alternative would be to use something like the Roland JV 1010 but this only has a single MIDI input and I eventually wanted to add a MIDI keyboard as well.

Getting the WX5 to generate sounds via Linux needs three things:

  1. A MIDI hardware interface for the PC
  2. A sound generator
  3. Some means of routing the MIDI commands to the sound generator

MIDI Hardware

Ted’s Linux MIDI Guide gives a very good introduction to the basics of getting things up and running. I generally followed the same process but I didn’t bother with the low latency kernel or installing JACK audio. Over the years I’ve found that a relatively powerful machine with plenty of memory that’s not doing anything else like Bitcoin mining will be fine. YMMV of course but a 3 GHz, i5 processor with 16 Gbytes of RAM was using <10% on all 4 CPU cores and <15% memory usage while playing a MIDI file with 4 instruments using Fluidsynth ( see below). At the very least it’s worth giving it a go before starting to replace kernels etc.

For the MIDI hardware interface I had an older M-Audio MIDISPORT 2×2 that I’d used very successfully with the Mac and was pleased to find that it worked just as well under Linux. All that was needed was to install the drivers:

sudo apt-get install midisport-firmware

I also wanted to connect an M-Audio 61 GS keyboard and this was just a case of plugging it into a USB port. No drivers necessary. Both devices then showed up as available:

john music $ aplaymidi -l
 Port Client name Port name
 14:0 Midi Through Midi Through Port-0
 28:0 MidiSport 2x2 MidiSport 2x2 MIDI 1
 28:1 MidiSport 2x2 MidiSport 2x2 MIDI 2
 32:0 Keystation 61e Keystation 61e MIDI 1
128:0 FLUID Synth (6781) Synth input port (6781:0)

I also installed a Virtual MIDI Piano Keyboard to make testing a little bit easier.

Sound Generator

A popular sound generator for Linux is Fluidsynth. It accepts MIDI input and uses SoundFont ( .sf2 ) files to generate the sound output. It has a command line interface although I think that there are some GUI front ends available. I’ve never tried any of these because the command line is pretty good even if it takes a bit of learning. There are a few powerful features, like the built in MIDI router, and it’s well worth spending some time reading the documentation.

I start Fluidsynth with a command similar to:

fluidsynth -a alsa -g 1 /usr/share/sounds/sf2/FluidR3_GM.sf2 

The “-g” option sets the gain, in case some of the SoundFont files are a little too quiet. Adding the “file.mid” causes Fluidsynth to play that MIDI file immediately.

By default Fluidsynth comes with a basic SoundFont file which covers the General MIDI instruments and is fine for experimentation. There are many, many SoundFont files, both free and paid for, available on the internet of varying quality. In my experience you just have to download and try them 🙂

Two that I’ve found useful are:

  • GeneralUser GS – I use this as an everyday direct replacement for the standard Fluidsynth file and it works fine.
  • Soundfonts 4U – This site has a number of mainly keyboard sounds but also includes a few other instruments. I’ve tried a couple of the files and they sound great but not all of the instruments use the standard General MIDI instrument number so it can be a bit tricky to configure. However if you want just a piano, for example, then it’s fine.

As far as I can see both of these have “free as in beer and speech” licences.

There are two other SoundFont file formats that are also used but Fluidsynth doesn’t directly support either of these:

  • sfz – This is a different sound file format which is used by some programs. I haven’t really investigated it but I have had some success in converting sfz files to sf2 using the Polyphone application.
  • sfArk – This is a compressed version of sf2 files but unfortunately it’s a custom compression algorithm written by a now defunct company ( Melody Machine? ). However the original software now seems to be available under the GPL – https://github.com/raboof. I tried unsuccessfully to build this utility but I didn’t spend too much time on it because I’d already found the two sf2 files that I mentioned above and they were working well.

Routing MIDI Commands

Once all the hardware is connected and configured and Fluidsynth is up and running as shown above then it’s just a matter of connecting the various ports together:

aconnect 28:0 128:0  # <-- MidiSport to Fluidsynth
aconnect 32:0 128:0  # <-- M-Audio keyboard to Fluidsynth

… and start playing.

Experiments with Raspberry Pi

My original intention was to try and replicate a VL70-M or JV 1010 unit by using a Raspberry Pi and FOSS. I’d already got a Pi Mk1 and a HiFi Berry DAC for a different project but I came across two main problems:

  1. The Mk1 Pi just doesn’t have the horsepower to run Fluidsynth with enough MIDI polyphony and I also had trouble with latency. By tweaking the RATE/NUM/SIZE parameters as described in the Fluidsynth documentation I could get one channel playing with no latency but no more than that really.
  2. There’s quite a lot of additional hardware to build on top of the basic Pi, ideally one would need:
    1. MIDI hardware interface. This is not complicated but needs a few non-standard components and a pcb to build it on. The Pi also only has one spare serial port so multiple MIDI inputs would need yet more hardware, probably based around I2C UARTs.
    2. A user interface. This is mainly needed to select the various MIDI instruments but could also be used to change Fluidsynth parameters. I did think of a web based interface, I have a Pi WiFi adaptor which could be used to set up a local wireless network which could be convenient. The alternative is something like a 2×16 LCD display and some buttons – which of course needs more hardware 🙂
    3. A box to put all this in and a power supply.

Problem 1 was the show stopper really, although later models of the Pi which are more powerful could solve this issue. I may re-visit the project if I decide that using the PC is too inconvenient.



Posted in FOSS, MIDI | 4 Comments

3D Printed ‘L’ Bracket for a Camera

As I mentioned in the post on panorama images the best results often come from using a tripod. However one of the restrictions of a tripod is that they’re generally designed for a camera to be mounted in a landscape format. My tripod has an adjustment that tilts the camera into portrait format but, annoyingly, doesn’t tilt to quite 90°. It’s only a few degrees off but it’s enough to mess things up. Also in the portrait position the camera centre of gravity is off to one side which, especially with longer lenses, means a less stable tripod.

The obvious solution is an ‘L’ bracket and these are readily available from the usual sources on the internet. However, having access to a 3D printer I decided to see if it would be possible to make one instead.

Knowing that this was going to be an iterative processes I first decided to see what I could find online rather than try to design from scratch. I found a possible candidate on the YouMagine site – https://www.youmagine.com/designs/l-bracket-for-dslrs. My version was printed using 0.2mm layers and a 50% infill in PLA rather than the Carbonfiber PETG suggested on the YouMagine page but it certainly seemed stiff enough.

For this test I made a couple of mods:

The original design suggested screwing the tripod mount directly into the plastic but I was concerned about excessive wear if this was done repeatedly. Fortunately I had a couple of spare tripod mounting plates so I screwed one of these into the base instead.

I didn’t have the right screw to mount the camera to the ‘L’ bracket so I modified one that was part of a second spare tripod mounting plate. ( I don’t have a metal working lathe so I mounted the screw in my wood turning lathe, rotated it slowly and gently took off the excess metal with a small grinding disk in a Dremel type tool. It worked a lot better than it sounds 🙂 )

The final proof is, of course, whether it works on a tripod. For a test I decided to try a panorama photo – using a camera in portrait format has advantages here because it gives more vertical pixels than when in landscape format.

After having imported the images into Hugin the preview window looked as follows:

I think that the tripod/camera wasn’t quite levelled properly as can be seen by the arrowed sections. However using 8 images I got a final stitched photo of 7588 x 2795 pixels. The camera image dimension along the longer side should be 4608 pixels so there’s some scope for getting more vertical resolution with more careful set up.

As a first experiment I was quite pleased, the PLA plastic was certainly stiff enough to mount the camera and there was no wobbling or shaking. However there were a couple of problems that need to be fixed:

  1. Screwing a tripod mounting plate into the ‘L’ bracket is not the best way of doing it. Ideally the dovetail profile to clamp into the tripod should be printed as part of the bracket.
  2. Mounting the camera in the ‘L’ bracket in this way means that access to the remote shutter release and external power socket is blocked by the bottom of the bracket. This is a more serious problem as I prefer to use a remote release if the camera is on a tripod. There are two obvious solutions, firstly I could mount the camera the other way round so that the ports are on the top. Access to the memory card slot would then be blocked as it would now be on the bottom but that’s not an issue really. The other option would be to redesign the bottom of the bracket so that the cables can be passed through when it’s mounted on the tripod. I want to redesign the bottom of the bracket anyway for point 1 above so this may be the better route.


Posted in 3D Printing, Photography | 2 Comments