Hi all,

I would like to to use it with a midi device (nanokontrol or behringer BCR2000) attached to the bigger USB port with SuperCollider.

MIDIClient.init called from sclang in the bela board does not detect the midi device:

sc3> MIDIClient.init
MIDI Sources:
MIDIEndPoint("System", "Timer")
MIDIEndPoint("System", "Announce")
MIDIEndPoint("SuperCollider", "out0")
MIDI Destinations:
MIDIEndPoint("SuperCollider", "in0")
MIDIEndPoint("SuperCollider", "in1")
-> MIDIClient

But the device does appear in the system:

root@bela ~$ lsusb
Bus 001 Device 003: ID 1397:00bc BEHRINGER International GmbH BCF2000
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@bela ~$ amidi -l
Dir Device Name
IO hw:1,0,0 BCR2000 MIDI 1
IO hw:1,0,1 BCR2000 MIDI 2
O hw:1,0,2 BCR2000 MIDI 3

root@bela ~$ find /proc/asound
/proc/asound
/proc/asound/BCR2000
/proc/asound/card1
/proc/asound/card1/oss_mixer
/proc/asound/card1/id
/proc/asound/card1/usbbus
/proc/asound/card1/usbid
/proc/asound/card1/midi0
/proc/asound/card1/usbmixer
/proc/asound/hwdep
/proc/asound/pcm
/proc/asound/timers
/proc/asound/cards
/proc/asound/devices
/proc/asound/version
/proc/asound/seq
/proc/asound/seq/timer
/proc/asound/seq/clients
/proc/asound/seq/queues
/proc/asound/seq/drivers
/proc/asound/oss
/proc/asound/oss/sndstat
/proc/asound/oss/devices

root@bela ~$ find /dev/midi*
/dev/midi1

root@bela ~$ find /dev/snd
/dev/snd
/dev/snd/by-path
/dev/snd/by-path/platform-musb-hdrc.1.auto-usb-0:1:1.0
/dev/snd/by-id
/dev/snd/by-id/usb-BEHRINGER_BCR2000-00
/dev/snd/controlC1
/dev/snd/midiC1D0
/dev/snd/seq
/dev/snd/timer

On the other hand aconnect -i -o doesn't show the device:

root@bela ~$ aconnect -i -o
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '

Any ideas on how I can get a midi usb device working with the bela and SuperCollider ?

board is running bela v0.2, board arrived two weeks ago.

Best,
Miguel Negrão

that's unfortunately a known issue.

@nescivi do you have any update on this?

A quick look at the supercollider code shows that it uses the ALSA snd_seq_ API, while MIDI on other Bela programs uses the lower level snd_rawmidi_API. I will try to have a look at it when I can, but I am not sure when that will be.

No, no updates from my side.

Unfortunately, I haven't had as much time as I'd like to, to look into the number of SuperCollider issues that are on the tracker... I have had to devote my time to projects that I'm paid for, or writing grants for my future projects.

Thanks, no worries, I will look into it at some point.

the "good" news is that it is not a supercollider issue, but it seems that it is a kernel module thing.

Ok, that's good to know. i'm not sure if this helps, but doing 'modprobe snd_seq_midi' did not solve the issue for me. Is as issue open for this in the bela linux image issue tracker ?

yeah I tried that as well, it looks like all the required modules are there and yet the interface does not show up. On the other hand, virtual devices do show up (try, e.g. to run qmidinet in one terminal and then do aconnect -io in another one)

So for the immediate future it's best to not count on midi working within SuperCollider ?

I am wondering whether using virmidi and then piping the hardware port to it would work. Let me give it a try.

Right, so I have a workaround which leads to a pretty usable solution. Takes about 10 minutes to setup.
This entails:

  • installing a kernel with support for virmidi (see below)
  • running modprobe snd-virmidi. This creates 4 virtual midi ports
  • in a terminal or a script, run stdbuf -i 0 -o 0 -e 0 cat /dev/snd/midiC1D0 > /dev/snd/midiC0D0 and leave it running. This will pipe the inputs from hw:1,0 to hw:0,0. In my case, these correspond to a USB MIDI keyboard and the first virmidi port, you'll have to check for your setup.
  • now Supercollider should be able to access MIDI by connecting to the first virmidi port. What I run in SC is:
    MIDIClient.init;
    MIDIIn.connectAll;
    (MIDIdef.noteOn(\noteOnTest, {arg vel, nn, chan, src;	[vel, nn, chan, src].postln;}))

The kernel that came with the image does not support virmidi. This one does. Installing it should be as easy as:

  • download the zip archive
  • copy it to the board
  • unzip xenomai-r81-interrupts-virmidi.zip && rm xenomai-r81-interrupts-virmidi.zip
  • needless to say, backup your important files before doing the following
    for a in linux-*3.8.13xenomai-xenomai-r81_1cross_armhf.deb;
    do
      dpkg -i $a;
      rm $a; done;
    done
    mv /boot/uboot/zImage /boot/uboot/zImage.bak
    cp /boot/vmlinuz-3.8.13xenomai-xenomai-r81 /boot/uboot/zImage
    (may take a few minutes, especially when installing the headers)
  • reboot
  • if you are lucky enough that it reboots (lol), you can check you are running the new kernel:
    root@bela ~$ uname -a
    Linux bela 3.8.13xenomai-xenomai-r81 #4 Wed Oct 26 20:25:54 BST 2016 armv7l GNU/Linux

The script that pipes the data could be something like this

#!/bin/bash
modprobe snd-virmidi
INPUT=/dev/snd/midiC1D0
OUTPUT=/dev/snd/midiC0D0
while sleep 1
do
  ls $INPUT &>/dev/null && ls $OUTPUT &> /dev/null &&\
  stdbuf -i 0 -o 0 -e 0 cat $INPUT > $OUTPUT
done

and this could go, e.g.: into ~/Bela_startup.sh (unless you have a project set to start on boot in there)
This will test whether the input and output ports exist before piping the one to the other. If it fails (at startup or while running), it will sleep for 1 second before retrying.

Let me know how it goes.

    Im a bit confused here... on other distros (e.g. ubuntu) a usb midi device is registered as both a raw device and a sequencer device.

    I had a quick look at the alsa modules source (3.8.13) and snd_midi.c does seem to have a method to register raw devices in the sequencer , see snd_seq_midisynth_register_port(), so I'm assuming snd-seq-midi should do this 'automatically'

    also comparing to another linux distro, I can see snd_rawmidi module is 'missing' - i guess because its been compiled into the kernel rather than a module, but perhaps that causes an issue with snd-seq-midi, which seems to be the 'problematic one' .... (you can see the dependancy is there, in alsa-base.conf in /etc/modprobe.c)

    a bit of search , others have reported the same with the beaglebone black... and one suggestion was to have all the snd modules loaded as modules.... this does seem consistent with other distros ive got that are working.
    (unfortunately, the suggestion was not acted on as I think the OP was not sure how to recompile the kernel)

    if you throw us another kernel build, id be happy to test.
    (are you compiling on the bela... or cross compiling... I guess If I grab the kernel sources, I should be able to build , or no? 🙂 )

    cross compiling on Linux, this kernel with this config file. Note: make sure you install ccache on your Linux machine, it will make newer builds much faster!

    anyhow, I am compiling now, so no point in you doing this as well ... 🙂

    Well I compiled it and I got a weird result: the SND_RAWMIDI is compiled as module ( CONFIG_SND_RAWMIDI=m, CONFIG_SND_RAWMIDI_SEQ=m) but is not listed with lsmod and I cannot unload it with modprobe -r snd-rawmidi because "FAILED: Module snd_rawmidi is built-in".

    🙁

    actually no there is something wrong in my build. Will try again.

    Great developments ! I'll try the workaround ! thank for looking into this.

    Any news on using the kernel compiled with the snd modules loaded as modules ?

    Thanks