That did not work for me when I tried it (error while building, I guess my source tree is a bit cluttered and needs some cleaning). But the workaround does work (around), so I would recommend you try that.

I tried again for a few hours, all sort of things seem to be falling apart as I change the config file, e.g.: this. Good news is that there is a 4.4.x kernel available with Xenomai 3.

So, as far as this issue is concerned, I'd say: please stick with the workaround!

    giuliomoro Good news is that there is a 4.4.x kernel available with Xenomai 3.

    that sounds like awesome news... do you think the changes to the kernel, or Xenomai 3 would have a large impact on the Bela codebase?! if we could get to this, then the 'gadget' interface is also upgraded, so we can have both networking support AND midi device support.

    looking forward to trying this out 🙂

        thetechnobear Yeah this is awesome news!

        Looking at the xenomai 2 -> 3 migration documentation, it doesn't look like there will be many changes to the codebase really, the only thing that is different that I can see is user-space interrupts, which we're not actually using in the release image anyway.

          I will create a dedicated discussion once I get the one of the kernels (3.14.x or 4.4.x) to compile.

          8 days later

          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.