[Bug 52220] TMIDI Player, Cherry: Playback with multiple MIDI ports is broken

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52220

--- Comment #11 from Jacek Konieczny <jajcus at jajcus.net> ---
> "aplaymidi" command (in alsa-utils) works as expected even when
> libfluidsynth's autoconnect feature is in use.
> (e.g. "aplaymidi -p [Qsynth port 1]:0,[Qsynth port 2]:0 /path/to/file.mid")
> 
> snd_seq_ev_set_subs() isn't used in the program.
> ("aseqnet" and "arecordmidi" use it)

Yes, I have seen that. Indeed aplaymidi does work the way wine worked before my
original changes. This is not a problem for aplaymidi, as I cannot think of a
scenario where people would really need this functionality. It is just a simple
MIDI player and an example tool for ALSA library.

Setting event destination directly has its advantage, that the event will only
reach the very specific port, but when someone uses wine to interact with a
Windows program or analyze the MIDI traffic it generates this may become a
disadvantage.

> * Qsynth/FluidSynth with autoconnect:
>    * Always able to open ports: OK
>    * Broken playback: I'm still not sure whether it's really expected

It depends how we look at that:

if we consider Windows application MIDI outputs just generic MIDI outputs that
can be connected to whatever one wants, no matter what is the Windows
application choice – then it works as expected. Qsynth auto-connecting is just
unfortunate use of this option.

if we consider Windows application output port choice final, then this might
be, indeed unexpected.

Either way it is understandable – both ports are connected, as qsynth is
configured to auto-connect. And that will be visible on any ALSA sequencer
connection list/graph.


> Is there a way to avoid this by modifying Wine...?

I am afraid the only way is to revert all my changes or make the connection
changes optional by using a registry key or an environment variable (both
options seem like a hack).

Reverting all the changes make it impossible to tap on Windows applications
MIDI traffic (useful for reverse engineering Windows software for various MIDI
hardware) or change the MIDI connections (useful to make better use of
application that do not provide the MIDI connectivity configuration wanted).

In my opinion wine project goal is not to replicate Windows with all its
limitations, but to allow easy use of Windows applications in Linux, to get
best of the two worlds. I would rather keep the flexibility of Linux with some
inconveniences in some rare use cases. But I can see your arguments too.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.