Virtual Midi Out on linux (possible Juce 5 bug?)

1

I have a Juce app that connects to usb hardware (Snyderphonics Manta) and converts activity on that into Midi which it outputs over a virtual midi out.

It was originally made with Juce 4 and the Juce 4 builds work fine.

I want to make a new version and I have been working on getting it going on Juce 5.

However the versions built with juce 5 although they run, have a problem connecting to the system alsa midi.

The output seems to be created, but it doesn’t show up in the qjackctl control panel for alsa midi, and Kmidimon can see it as an option but fails to connect to it.

when jack tries to connect to the midi output i see the following in qjackctl messages:

02:51:53.998 ALSA connection graph change.
02:51:53.999 JACK connection graph change.
Wed May 16 02:51:53 2018: ERROR: can’t subscribe to 130:0 - Operation not permitted
Wed May 16 02:51:53 2018: port deleted: MantaJuce3:midi/playback_1

I have tried this on two different machines with identical results, although both were running Mint 18.3 and the environment was very similar.

Other apps with virtual outs work correctly, as do my old builds of this app.

I have changed nothing at all in my Midi code, and very little so far in the rest of the app.

So - has something changed in Juce 5 that could cause this?

Everything is running as the same user, and I’m not aware of any permissions differences between the working apps and my failing one.

Is anyone else successfully creating a virtual midi out on linux using Juce 5?

2

the code to do this is different in V4 and V5 - I don’t know if that’s the problem but…

from juce_audio_device/native/juce_linux_Midi.cpp

in V4 the method reads:

MidiOutput* MidiOutput::createNewDevice (const String& deviceName)
{
    MidiOutput* newDevice = nullptr;

    AlsaPort port (createMidiDevice (false, deviceName));

    if (port.isValid())
    {
        newDevice = new MidiOutput (deviceName);
        newDevice->internal = new MidiOutputDevice (newDevice, port);
    }

    return newDevice;
}

and in V5 the method reads:

MidiOutput* MidiOutput::createNewDevice (const String& deviceName)
{
    MidiOutput* newDevice = nullptr;
    auto client = AlsaClient::getInstance();
    auto* port = client->createPort (deviceName, false, true);
    jassert (port != nullptr && port->isValid());

    newDevice = new MidiOutput (deviceName);
    port->setupOutput();
    newDevice->internal = port;

    return newDevice;
}
3

I have done a completely fresh install of juce 4 and compiled my app with juce 4 and it works perfectly. So this would seem to be a bug in juce 5.

4

I’m still completely stumped on this.

The ONLY thing that is different is whether I build the app using juce 4 or juce 5, I’m using the same user, the same projucer and the same projucer settings.

JUCE 4 creates a working virtual midi out, JUCE 5 creates one, but nothing can connect to it.

So either

there’s some setting in the projucer that i have somehow missed that is different for the two builds (unlikely)

OR

JUCE5 sets up the midi out in a way that requires a different system configuration or permissions, if so I can’t find any info on it

OR

JUCE 5 has a flatout bug

I’ve confirmed this on 3 different computers, 2 Mint installs and one fedora.

could a dev have a look? Or can anyone at all say if they can get a working virtual midi out on JUCE 5? (on linux)

My code that creates the out looks like this:

void MidiIO::makeVirtualOut()
{       
        //create virtual midi out
        currentOutput = MidiOutput::createNewDevice ("MantaOut");
        if (currentOutput != nullptr)
        {
            deviceManager.setDefaultMidiOutput("MantaOut");
            //what does default do/mean anyway?
            cout << "created MantaOut virtual out \n";
        }
        else
            cout << "failed to create new device \n";  
}
5

Yes, I’ve been looking at this bug since last week. We are working on it…

6

OK that’s great! Does that mean you’ve been able to reproduce it and it is a bug, not an error on my part?

7

It’s a bug in our code. A simple typo here (it should read SND_SEQ_PORT_CAP_READ on that line). I’ve pushed a fix for this which will appear on develop with commit c967a39.

Our CI system is acting up a bit today so it might take a bit longer for the commit to appear on our public repo.

1 Like
8

Fantastic! I fixed it manually and recompiled and the port now shows up in alsa. thanks!

I haven’t tested actually sening any midi yet, but it looks fixed so far.

I can now move on with using JUCE 5 rather than 4