The new and improved method of real-time MIDI control of MATLAB (or Python, or ... whatever!)

In an older post on my blog, I had this method to get the state of a MIDI controller into MATLAB (though readable by pretty much anything that can read files).  This method is quite clunky and when I wanted to do something similar again, I re-thought the problem and came up with a better method based on memory mapped files. You can find the code on GitHub.

Basically, I'm creating a file of fixed length (260 bytes, in /tmp), mmap() it and update the contents based on the MIDI stream I'm receiving.  The first 128 bytes are for keys, where each byte is the last seen velocity (0 means "off").  The following 128 bytes are for the cc messages.  Bytes 257 and 258 store the pitch bend, a 14-bit value with MSB in byte 257.  Byte 259 is the last received program change value and 260 is the channel aftertouch.

MATLAB Access

Accessing the values from MATLAB does not require any special functions, it can simply be done using

mm = memmapfile('/tmp/midibroadcast');

then the data can be obtained in real-time from mm.Data.  As described above, mm.Data(1:128) are the last seen key down velocities (0 meaning key is not pressed) and mm.Data(129:256) are controllers 0..127.  The pitch bend value can be obtained as mm.Data(257)*256+mm.Data(258) (note this may be buggy; my cheap controller (KeyRig 25) does not let me set and hold precise pitch bends, so I can't test it properly). mm.Data(259) is the program change and mm.Data(260) shows the current aftertouch amount.

Python Access

From Python the values can be accessed as easily:

import os
import mmap
mfd = os.open('/tmp/midibroadcast', os.O_RDONLY)
mfile = mmap.mmap(mfd, 0, prot=mmap.PROT_READ)

Remembering that Python counts from 0, the controllers can be read in real-time as mfile[128] to mfile[255]: just subtract 1 from the descriptions above.

Any language which can do memory-mapping should be able to do the same, but it should even be possible to read the current state just by re-reading the /tmp/midibroadcast file.

Enjoy!

Using an ARM Chromebook for Scientific (and Academic) Computing

Samsung ARM Chromebook

A couple of months ago, I decided to get myself a Chromebook. The Samsung ARM Chromebook is cheap (to the point of being almost disposable) and it's got an ARM CPU - and for performance at the least possible amount of juice it's hard to beat. I really like the fact that this thing emits no noise that I can detect even in a very quiet room.

But how useful is it, for someone in a standard engineering/academic setting? The answer is that it works well, for me at least - with some special considerations. Especially for the last few weeks, it has been my primary laptop, having been dragged to research cluster meetings and one conference. I will explain the details of a few typical things I do, such as (LaTeX) document editing, intensive numerical computation, etc. Read below the break for details.  

Transplant: yet another bridge between MATLAB and Python, but a good one!

This post is basically just an advertisement for a project done by a Master's student that I'm co-supervising at the moment.  While there are numerous methods already out there to link MATLAB to Python (and rumour has it that the next(?) release will make it easier to call Python from MATLAB), I think Basti's "transplant" (github link) strikes a good balance between simplicity and capability.  Bastian's code is elegant and reliable.  My own contribution has just been a small bug fix, the ability to transfer logical (boolean) matrices, and an attempt to add the ability to capture MATLAB's stdout (Bastian came up with a much better solution).

For me the resulting killer feature is that I can write IPython notebooks that call MATLAB code in a sane way.  Complex code which would take too much effort to convert to Python can be called, then the results can be plotted in the Notebook, which is great when working remotely (a longer post on my workflow is in the works...).  Results become more accessible, with a lot of the complexity hidden away in .m files.

So, check it out and spread the word!

My workspace for the next month or two

The two arc source positioning system in the anechoic chamber
of the Carl-von-Ossietzky University of Oldenburg

Yeah, I'll be doing HRTF measurements on dummy heads with multichannel hearing aids. Should be fun.

Samsung ARM Chromebook XE303 with VGA adapter - power problems

I have a Samsung ARM Chromebook (the 303 series) which is pretty nice, and I really like it for its size, weight and complete lack of fan and hard drive noise.

Samsung XE303C12-H01DE Chromebook: with 3G modem and
a German keyboard which I'm still not used to.

However, I need to give presentations on occasions.  No problem, I just get one of these:

HDMI to VGA adapter from DX.com (SKU 156981)

For less than $10, that's hard to beat.  Unfortunately, I found it doesn't work as-is with the Samsung Chromebook.  Already thinking I need to either give up on the idea of using the Chromebook for presenting or getting a more expensive adapter, I decided to try and see why the bloody thing doesn't work. I verified it does work with my Raspberry Pi, so the problem must be with the Chromebook - perhaps a power problem?  According to Wikipedia, HDMI should have +5V on pin 18.  I opened up the adapter, which can be done with nothing more than one's fingernail, running it along the seam around the VGA socket, then confirmed the absence of 5V on the HDMI port.  Lukily, getting 5V is no problem if you have a USB port nearby and here is my solution to this particular annoyance:

HDMI to VGA adapter with power bypass fitted

I take no responibility for damage you might be inflicting to your Chromebook or any other device you might want to use this mod on. Try this at your own risk, there is a good chance of frying delicate electronics. 

How to solder the power onto the adapter: +5 on
pin 18, ground to wherever convenient.

Basically, take a USB plug and solder two wires to just the outside pins.  Drill a hole through the plastic and the rubber fitting of the HDMI to VGA adapter (slide the insides out first!)  Solder the 5V wire to the pin 18 endpoint of the cable and the ground to a ground point on the adapter PCB.  Done!  I put a knot into the cable for strain relief, to prevent the solder points being ripped off.

That's it! It works nicely, although I don't think the adapter queries the monitor for modes, a decent selection is given to the ChromeOS as soon as the adapter is plugged in.  I've only tried it with one projector so far, but there is no reason it should not work with just about any that accept VGA signals.

Hopefully this information is useful to other (ARM) Chromebook users, but note this is a no-name adapter - yours may look entirely different.  Just remember these adapters are active devices which need power (even if very little), and since the Chromebook isn't delivering it on its HDMI port, you need to get it there somehow.

Hello Lisbon! EUSIPCO 2014, here I come!

Downtown Lisbon, picture by
Keiran Thomas via Wikimedia Commons

As hinted in a previous post, together with Menno Müller I had a paper submitted to EUSIPCO 2014, and yesterday we finally got the review results.  It got accepted by all reviewers, and several of those six (SIX!?!!) really liked the paper, so naturally I'm pleased as punch about it.  And of course I'm already looking into how to get to Lisbon and what else to go see when I'm there.  So while I can't publish the paper on my own homepage until after the conference is over (and besides, the reviewers did ask for some minor corrections that I still have to put in), I can now refer to: J. Thiemann, M. Müller, and S. van de Par, "A Binaural Hearing Aid Speech Enhancement Method Maintaining Spatial Awareness for the User", to be presented at EUSIPCO 2014.

A Sudoku solver in Python

I'm not that great at Python yet.  But practice makes perfect, so just to see if I can do it, I wrote this Sudoku solver in Python (needs v3).  The algorithm is my own though I don't think it is very (or at all) novel, just actually looking for other solvers would spoil the fun!

The implementation is also probably overly byzantine, mostly due to the way the state is stored.  This is done as follows: at the bottom is a list of states for each symbol in a given cell, the states are one of "this symbol is possible here", "this symbol is impossible here", "this symbol is here (set by specification)", and "this symbol is here (set by the solver)".  The last two are really the same for the algorithm but eased my own understanding and debugging - but this adds lines to the code since both states need to be checked in some cases.

The set of states for each cell are then bunched into a list for each row, and then all rows are bunched into a list.  So, to find out if the "4" is possible in column 3, row 7, check if state[3][7][4] is set to 0.

The solver algorithm can now be simply described by three steps: 

1. After setting a cell to some symbol, mark the same symbol as being impossible in cells in the same groups (row, column box). 
2. For all cells, check if there is the case where a single symbol is not impossible.  If so, set the cell to that symbol.
3. For all groups, check where within a group a given symbol is possible in only one cell.  If so, assign that symbol to the open cell.

If in either of step 2 or 3 a cell was set to some symbol, restart from one.  Repeat this until neither of the two last steps sets a new cell to a symbol, at which point the puzzle is solved, it's not completely specified, or there is an ambiguity that I don't handle in this code (I think it is possible for some sort of circular ambiguity to exist).

Spatial properties of DEMAND

One of the nice plots from the presentation,
which didn't make it into the paper for space
reasons. The plots show the fit of the measured
coherence to the theoretical prediction.

Here is my primary DAGA 2014 paper, where I examine some of the intermicrophone coherence of the DEMAND recordings.  Also, I experiment a little with calibration, using multidimensional scaling.  Not much one can squeeze into two pages.

The presentation was a bit of a bust - they put me in a session more about policy and noise pollution etc. ("Psychoakustik - Lärmschutzpolitik"), so there was not much useful interaction.  Oh well, it happens.

The paper is here, and the presentation slides here.  This might be quite useful if you're using DEMAND.  The question if anyone is actually using DEMAND (other than me) is still open - I would love to hear from anyone who is.

A bit more interesting is a paper written by a M.Sc. student in our lab, on the test results of a hearing aid algorithm we've been working on. The paper is "Erhaltung der räumlichen Wahrnehmung bei Störgeräuschreduktion in Hörgeräten", by Menno Müller, Joachim Thiemann, Daniel Marquardt, Simon Doclo and Steven van de Par, and the method we use to do binaural noise reduction with preservation of spatial awareness is outlined.  A more detailed paper has been submitted to EUSIPCO 2014, and in about 2 or 3 weeks I should find out if that has been accepted.

DAGA 2014

Attending DAGA 2014 - doesn't require much travelling since it's right here in Oldenburg. I just have just one small presentation (some more DEMAND stuff).  Pretty much all the senior profs of the Hearing4All cluster are somehow involved in the organisation of this event, so for all of us peons it is pretty much de rigeur to attend.  It's a pretty fun conference (so far) - and tonight the big social event is The Barber of Seville at the Oldenburg Staatstheater.