We are about to switch to a new forum software. Until then we have removed the registration on this forum.
I've a sketch that listens for MIDI messages and displays animated GIFs based on notes and velocity. The MIDI is driven by a program called Renoise. Since this is app-to-app communication (i.e. there is no actual MIDI keyboard here) I needed to use some internal MIDI routing. On WIndows I use LoopBe and it works fine.
On Ubuntu I'm using virmidi to create virtual MIDI ports. When I run my sketch, which used The MidiBus library, it does not detect any of these virtual devices. (Renoise, OTOH, sees these virtual devices just fine.)
I thought this might just be a Java thing but I have other Java code running on the same machine that does find and interact with these virtual devices (and can receive the MIDI messages sent by Renoise over a virtual MIDI device).
In digging though some code I learned that an available virtual MIDI input device can be detected by checking getMaxTransmitters. For real devices this should return a positive value. Available virtual devices return -1.
When the MidiBus code runs all the virtual input devices have getMaxTransmitters == 0. In the other Java code (a JRuby program that uses the same underlying Java system libs as MidiBus) these devices have getMaxTransmitters == -1.
Has anyone else run into this? It may well be some quirk of my setup, so I'm curious to hear from anyone else who has virtual MIDI devices on Ubuntu with the MidiBus library.
Answers
Here's a simple Java program that lists the available input devices.
The code in the MidiBus seems to do essentially the same thing. One method does this:
Then later
Yet the results are quite different.
To answer my own question: This seems to be a matter of 32 v. 64 bit. The Java ( and JRuby code) was being run using 64-bit Java.
I've apparently been using a 32-bit install of Processing. I now installed the current 32 and 64-bit versions of Processing, and the 32 bit version does not show the virtual devices while the 64-bit version works fine.