I can confirm the workaround works fine ! Thanks !!!

14 days later
13 days later

So when it will be possible to use kernel 4.4.x? Looking forward to it ...

Good question, I don't have an answer just now. I got very close, but I didn't get the McASP to work properly. I will try again soon.

2 months later

Unlucklily it doesn't work with more than one midi for me?. Is there any need to change the (startup-)script?

#!/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

Note: please use triple backticks ( ``` ) to enclose your code (see my edit to your latest post).

As mentioned above:

giuliomoro 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.

if you need to loopback multiple devices, then you need to check what devices you have with amidi -l and then you would need many of these lines

stdbuf -i 0 -o 0 -e 0 cat `$INPUT > $`OUTPUT

with $INPUT and $OUTPUT set to different devices from time to time.
You can trial this by having multiple terminal sessions open and one of these on each. But if you want to set this at startup, it may be worthwhile to create a screen for each of these, e.g. this line may work (untested):

screen -S "midi-loopback-$INPUT" -d -m bash -c "stdbuf -i 0 -o 0 -e 0 cat $INPUT > $OUTPUT"

the easiest way to put this in a script would then be something along the lines of (untested):

#!/bin/bash
modprobe snd-virmidi

loopback_in_screen()
{
while sleep 1
do
  ls $INPUT &>/dev/null && ls $OUTPUT &> /dev/null &&\
  screen -S "midi-loopback" -d -m bash -c "stdbuf -i 0 -o 0 -e 0 cat $INPUT > $OUTPUT" && break
done
}

INPUT=/dev/snd/midiC1D0
OUTPUT=/dev/snd/midiC0D0
loopback_in_screen

INPUT=/dev/snd/midiC2D0
OUTPUT=/dev/snd/midiC3D0
loopback_in_screen

INPUT=/dev/snd/midiC4D0
OUTPUT=/dev/snd/midiC5D0
loopback_in_screen
    5 months later

    The first script I provided here blocks after it connects the interface:

    stdbuf -i 0 -o 0 -e 0 cat $INPUT > $OUTPUT

    However the script my last comment above waits for each of the listed interfaces to be active, then creates the pipe between the $INPUT and the $OUTPUT in a screen (that is, non-blocking) and then moves on to the next pair.
    However, if either of $INPUT or $OUTPUT does not exist, it will hang while waiting for them to come up.

    The solution should therefore be to use the latter script, but only call loopback_in_screen for those interfaces that you actually need and remove those you don't have/need.

    10 months later

    giuliomoro can I confirm this is still the current workaround? Or do the newer versions of the OS have this kernel as standard now?

      hmm haven't tried really, but ALSA should be working just fine on the new image, so try the canonical way first. If you need a workaround, then the above will need some refinements in the new image

      I think I missed the canonical ALSA way... is that written up somewhere?

        empeeby in any case, I'm experiencing the same basic issue detailed at the start of this thread - midi device does not appear to sc, but does appear to the bela through amidi -l...

            empeeby in any case, I'm experiencing the same basic issue detailed at the start of this thread - midi device does not appear to sc, but does appear to the bela through amidi -l...

            Yeah that was meant to be the canonical way I think. This will require some investigation.

                8 days later

                So I have had a quick look and the situation has changed with respect to what the OP described.
                Running

                root@bela:~# aconnect -i -o

                now gives:

                client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 16: 'f_midi' [type=kernel]
    0 'f_midi          '
client 20: 'MIDI Mix' [type=kernel]
    0 'MIDI Mix MIDI 1 '

                So the connected MIDI device (and the virtual one to the host, too) do show up as available I/O in the ALSA sequencer.
                Therefore, when running

                MIDIClient.init;

                inside sclang, it gives:

                MIDI Sources:
	MIDIEndPoint("System", "Timer")
	MIDIEndPoint("System", "Announce")
	MIDIEndPoint("Midi Through", "Midi Through Port-0")
	MIDIEndPoint("f_midi", "f_midi")
	MIDIEndPoint("MIDI Mix", "MIDI Mix MIDI 1")
	MIDIEndPoint("SuperCollider", "out0")
	MIDIEndPoint("SuperCollider", "out1")
	MIDIEndPoint("SuperCollider", "out2")
MIDI Destinations:
	MIDIEndPoint("Midi Through", "Midi Through Port-0")
	MIDIEndPoint("f_midi", "f_midi")
	MIDIEndPoint("MIDI Mix", "MIDI Mix MIDI 1")
	MIDIEndPoint("SuperCollider", "in0")
	MIDIEndPoint("SuperCollider", "in1")
	MIDIEndPoint("SuperCollider", "in2")
	MIDIEndPoint("SuperCollider", "in3")
	MIDIEndPoint("SuperCollider", "in4")

                Now, I don't know much of Supercollider or of how sclang should handle MIDI, but the above seems promising. Can you reproduce the above? How can I reproduce your problem?

                5 days later

                When I run those commands,

                root@bela ~/Bela# aconnect -i -o
                gives

                client 0: 'System' [type=kernel]
    0 'Timer           '
    1 'Announce        '
client 14: 'Midi Through' [type=kernel]
    0 'Midi Through Port-0'
client 16: 'f_midi' [type=kernel]
    0 'f_midi          '
client 20: 'SSCOM' [type=kernel]
    0 'SSCOM MIDI 1    '
    1 'SSCOM MIDI 2    '

                which is as I would expect. (SSCOM is the device I'm trying to use)

                in SC, remotely connected MIDIClient.init; gives:

                MIDI Sources:
	MIDIEndPoint("USB MIDI Device", "USB MIDI Device", 1775184198)
MIDI Destinations:
	MIDIEndPoint("USB MIDI Device", "USB MIDI Device", -197585814)
-> MIDIClient

                I don't recognise what these devices are, but they're definitely not my SSCOM device. If I run MIDIMonitor.start; I don't pick up any messages sent by my device...

                The response I'm getting from SC is very different from you, which concerns me - I'm not seeing any of the MIDI ports that show up to the linux system.

                right, so I think this is somehow expected behaviour:
                from what I understand, you are running sclang on the host computer (as you are live-coding from the IDE). This means that MIDIClient.init will pick up the MIDI devices connected to the host computer, and not those connected to Bela. The "USB MIDI Device" that you see there is actually the Bela board itself (Bela shows up as multiple devices on your computer: Ethernet, Storage and MIDI!).

                I think this is expected behaviour, because the MIDI devices are handled by sclang and not by the sound server (scsynth). So my understanding is that you should be connecting your MIDI device to the host and not to Bela.