Soundplane for Norns

Branching off from the Approaching: norns thread where it was asked if the Soundplane could communicate directly with norns. No one has done it yet, but it seems very doable—if anyone wants to take it on, I’m here to answer questions.

I just made things easier, hopefully, by splitting the low-level Soundplane code into its own repository: . This comes with clear directions for getting started on MacOS.

A Linux version will require libusb. Various people have gotten it to work in a few distributions and what’s in the repo now should not be too far off the mark. I’m happy to incorporate pull requests and eventually to maintain a working norns version when I take the plunge.


Would make this Soundplane & Norns user very very happy!

Very cool! Now all I need is a Soundplane… I wonder which will come first, Crow or Model B?..

Perhaps we can broaden this effort to SoM in general.
( given the small number of soundplane users, and not all are going to want to spend $800 on a Norns., once the underlying ‘tech’ is working, then writing the Matron bit is easy)

I’ve been ‘playing’ in this area for quite a while, it started in 2015, when I was getting the Eigenharps to work on the rPI, and found a bug in the isosynchronous usb handling in the rpi kernel,
you can see that report here , this is relevant since it affected the soundplane as well.

fortunately, at some point it got fixed :partying_face:
but… ever since then, Ive found it can at times be a bit ‘fragile’, with slight odd issues.
e.g. randomly, some kernel releases , the Eigenharp Pico needs a usb hub, but next release and it doesn’t, repeat and rinse!

anyway… here is where I am at the moment, having tested the soundplane on a wide variety of boards!

PI based solutions

  • a CM3 based solution 4.14.93
    works perfectly
  • Norns Clone - rPI 3b+ (setup as Norns)- 4.14.62 (note: norns uses 4.14.52)
    did not appear to work, no data received BUT caveat!
  • Norns Clone - rPI 3b+ , upgrade kernel to latest 4.19.27
    this APPEARED not to work, and accidentally, I found that after 30-45 seconds, it starts to work - so initialisation (calibration?) was taking a very long time (its ‘instant’ on other board)
    (its possible the the 4.14.62 may have worked, but just taken a long time to initialise - though I thought id waited a while on it too !)
  • rPI ‘standard’ stretch, minimal install 4.14.48
    same slow initialisation.

Non rPI solutions

  • Organelle - 3.x kernel, arch linux
    does not work, submit_urb_error -28, I think its simply a bandwidth issue, though oddly it works with eigenharps - but its on a really old 3.x kernel - I need to re-test with a a 4.x kernel
  • Beaglebone Black w/ Bela include Bela Salt (Eurorack) - 4.4.113 xenomai
    always worked perfectly :slight_smile:
  • ASUS Tinkerboard 4.4.32
    appears to get NO data, but doesn’t matter how long you leave it, it doesn’t initialise,
    again an old kernel, so might work with a 4.6+ kernel
    note: as you’ll see in the bug report above, the fixed appeared to come around 4.4.48!

(macOS also works fine with my same code)


on the rPI platform, there seems to be some kind of minor issue with it taking a long time to initialise… lets, assume the ‘failed’ one is a testing issue, even though it seems unlikely.
the CM3 platform is interesting, its theoretically same setup as other rPI, but doesn’t have the issue… and the CM3 hardware should not matter, it uses the same BCM2835 as the rPI3.

anyway, I guess the Norns will work… perhaps with slow initialisation, and perhaps the kernel may need reviewing - but we will only know once its tested on an actual norns.

on my side, for SOM, I do want to test the Organelle and Tinkerboard on later kernels.
and I guess, I’ll break out usbmon and see if i can find out what’s going on with the initialisation on the rPI boards.

Im pretty excited in this area, as Ive got a couple things ‘coming’ , that are going to be awesome with the Soundplane (and Eigenharps)

enough words… getting rid of the computer, can be really liberating :slight_smile:

here is the Soundplane working without computer, supplying CV directly to an AE modular. (I also do the same for Eurorack with Bela Salt , but no video yet :wink: )

and, very similar tech (usb iso) , and same goal, ditching the computer!
… here is the Eigenharp pico with an Organelle,


An update on the Soundplane software: I’ve regrouped all of the source code to make it as clear as possible how to get started and to make compiling the Madrona DSP library and small Soundplane example much quicker. The full Soundplane app now has three components, each in its own repository.

madronalib is my C++ library for writing DSP applications. It contains a lot of useful DSP code as well as app support code for cross-platform, real-time apps. All of my software relies on this code so it gets frequently tested on Mac and Windows and soon, one hopes, Linux.

soundplanelib is the library for supporting the Soundplane hardware over USB. It does not require madronalib. It includes an example app, HelloSoundplane, that displays the Soundplane pressure as ASCII art in the terminal. If you do use the Soundplane on a Linux-based platform, please contribute any fixes to this repository via pull requests.

soundplane is the GUI-based app for working with the Soundplane on Mac OS: it supports options for touch detection as well as configurable zones that can send out notes and controls via OSC and MIDI. It requires both madronalib and soundplanelib.

@TheTechnobear if calibration is happening slowly, my first guess is that the driver is dropping most of the frames. The Mac driver keeps stats about this—you could add similar code to the libusb one. Also I note that the libusb driver has a mutex, which could possibly be slowing things down based on the platform—just a guess.

1 Like

An update: Greg Wuller has added libusb support to soundplanelib. He has tested this on Debian and Raspbian with libusb-1.0. I’ve incorporated that change and also updated the soundplane app code to use the latest madronalib.

Hopefully this paves the way for a canonical soundplane+norns integration.


Oh that is great news, it will help get things going again… now if I could find my notes :grinning:

UPDATE: I’ve coaxed current madronalib into compiling on norns so that leaves factoring out a headless soundplane as the next step.

UPDATE2: A bit of a progress report. I’ve extracted a portion of the soundplane code into a separate repository with the intention of creating both a GUI-less standalone client with the latest touch tracker and a library suitable for wrapping into a Lua module for norns.

Initial experimentation on a stock rpi4 + buster + 5.10 kernel has unfortunately uncovered that the usb transfers become unstable after about 30 seconds, frames with zeroed out values are being passed into the anomaly filter every 20-30 frames. The unpacker is consistently dropping transfers from one endpoint or the other at a rate of ~2-5 times per second throughout. When the zeroed out frames start it appears to be the result of the unpacker consistently dropping transfers from one endpoint or the other. The libusb based driver does not exhibit the same behavior on macOS so the hunt now becomes determining if this is a kernel related, rpi hardware related, or soundplanelib related…

UPDATE3: The linux instability at the 30 second mark appears consistent on both rpi3 + raspbian stretch + 4.19.x and nanopi neo2 + armbian buster + 5.10.x kernel. The neo2 case is interesting since it is an entirely different chipset and usb controller from the rpi family.

UPDATE4: Found the source of the Linux problems, further investigation regarding the number of seemingly empty packets included in transfers is probably warranted but this change prevents the Unpacker and anomaly filter from exploding: Discard unmatched packets with seqNum == 0 by ngwese · Pull Request #4 · madronalabs/soundplanelib · GitHub

UPDATE5: …and the touch tracker looks to be working (on norns and other platforms). Now the fun begins.