Wine: Where did the MIDI input go?

By Kitsune

I’ve been working on my own Proton Fork focused on creative live applications (uh, FL Studio, Touch Designer, … - I don’t know how to put them all in a single “box”)

On September 21, I was looking into a report on Torbuntu/fl-studio-linux-setup#16: FL Studio 26.1.3 launched under GE-Proton11-6, but an Arturia MiniLab 3 described as connected through a Behringer UMC202HD wasn’t being detected as a MIDI device.

This was exactly the kind of problem I wanted to understand. The question was whether it pointed to a Wine/Proton integration issue, a regression relevant to the fork, or something about the setup.

The report alone didn’t settle that question.

Start with the actual connection

The first thing I wanted to establish was what “connected through” meant in this setup.

Device names are helpful, but they don’t completely describe the path from a key press to an application. I would want the precise cable arrangement, the devices attached to the computer, and which input the user expected FL Studio to show.

That avoids building a theory around an assumed connection. It also gives a way to simplify the experiment: test the controller’s most direct supported connection to the host and establish what the host can see before adding the rest of the application environment.

At this stage, that is a proposed diagnostic sequence. I don’t have the user’s answers or a completed test result to report.

Find the first place the input disappears

I would work through the layers in order.

First, can the Linux host see the expected MIDI endpoint and receive events from it? Next, can a minimal test in the same Wine/Proton environment enumerate and receive that input? Finally, does FL Studio expose and enable it in its own input configuration?

Those tests answer different questions. A device appearing on the host doesn’t establish that the compatibility environment exposes it correctly. Likewise, an application opening successfully says very little about whether its MIDI path works.

The important condition is “the same environment.” A test using another Wine installation might be useful as a comparison, but it would not reproduce the launcher, runtime, and prefix involved in the report.

Work through the observations

This worksheet follows the proposed test sequence. Mark which layers receive events and see which question comes next. Tests farther down the path are unavailable until the preceding layer receives input.

The controls don’t detect hardware or test a Wine prefix. They organize observations you would collect separately. A difference between runners is a lead; it still needs a controlled reproduction.

What would make it a regression?

To call this a regression, I would want a known-good comparison with the hardware and relevant configuration held steady.

For example, if one runner receives input and another does not, that narrows the investigation. If neither works and the host itself sees no events, the runner comparison is premature.

I would also want to record the exact runner, launch method, prefix, and device connection. Changing all of those together can make a problem disappear without explaining it, which leaves the next person with very little to reproduce.

The most useful follow-up would therefore be a short set of observations: the connection layout, host-side MIDI visibility, whether events arrive, and the result from a controlled comparison.

This remains an open investigation in these notes. There is no confirmed Wine bug or daw-proton-ge fix to announce from this report.

What it does illustrate is the level of compatibility I care about for creative software. Getting the window open is a milestone. The next question is whether the person sitting in front of it can actually make something.