aliens

Author Topic: Improving MIDI music support (ALSA MIDI) on Linux?  (Read 214 times)

Offline Wild Penguin

  • Sergeant
  • **
  • Posts: 14
    • View Profile
Improving MIDI music support (ALSA MIDI) on Linux?
« on: February 27, 2024, 04:57:47 pm »
Hi!

Now I gather most users will either use Adlib emulation or some OGG/MP3/wav soundpack floating out there. MIDI is a thing of the past.

But then there are the outlier like me who may have HW MIDI synths (old soundcards), or just want to try out different SW synths =). I can see the feature to implement ALSA midi ports in SDL Mixer has been requested, but never implemented. It would shift the burden off implementing SW MIDI off from any project using SDL, and open up a lot (well, any) possibilities to the users.

Seems like currently the MIDI music options are quite limited in OpenXCOM. Both GM and MIDI (only in GIT/nightlies, release has only MIDI) do the same thing (but, from a few threads, they are different on Windows?). This stems from the fact that SDL_Mixer has always been limited and can only use the bundled timidity or fluidsynth =(. There used to be a native-MIDI support in SDL_Mixer, but it is obscure and not well documented. It seems it relies on OSS /dev/sequencer support which is not a thing anymore (I skimmed trough the source of the latest 1.2.12-12, and actually could not see how it is supposed to work; I'm not even sure the current package on Arch even has native MIDI compiled in).  It seems like SDL_NATIVE_MUSIC=ANYTHING should make SDL_Mixer relay MIDI data to ... something, but at least this is not ALSA. It would be cool if it (for example) open an output port in OpenXCOM and (optionally) try to connect to any input port it can find, but it seems SDL_Mixer knows nothing about ALSA MIDI.

EDIT: Oh, btw just in case someone comes along here wishing to use SW MIDI music: even using Fluidsynth on Linux in OpenXCOM is also a bit obscure and not well documented. Scouring the net I found out setting
Code: [Select]
SDL_SOUNDFONTS=/usr/share/soundfonts/SGM-V2.01.sf2 (or any other soundfont of your choice) makes and SDL_Mixer application use the internal Fluidsynth with this soundfont. I.e. run openxcom like this:
Code: [Select]
SDL_SOUNDFONTS=/usr/share/soundfonts/SGM-V2.01.sf2 openxcom Internal Timidity is broken with any modern timidity config files on any modern distribution, but could be worked around by editing this file, while breaking the more modern config in the process - but luckily, there is little reason since Fluidsynth should be superior. But as already stated, the crux of the problem or limitation  is there seems to be no way to relay the MIDI to an external SW or HW synth.

Now, enough of the chatter! To the questions:
  • Anyone got native MIDI working on Linux?
  • Any plans to add ALSA Midi support into OpenXCOM?

I'm not sure, but point 2. could be a low-hanging fruit. I may make an attempt later when I have the time (I have some rudimentary programming skills).
« Last Edit: February 27, 2024, 05:08:40 pm by Wild Penguin »

Offline Yankes

  • Commander
  • *****
  • Posts: 3210
    • View Profile
Re: Improving MIDI music support (ALSA MIDI) on Linux?
« Reply #1 on: February 27, 2024, 07:06:32 pm »
Code: [Select]
Any plans to add ALSA Midi support into OpenXCOM?Probably no, someone need to contribute it (write change and test it).
Another problem is that OXC will need to move away from SDL1.2, I do not know if MIDI is even possible in SDL2 or SDL3 way you want.

Offline Wild Penguin

  • Sergeant
  • **
  • Posts: 14
    • View Profile
Re: Improving MIDI music support (ALSA MIDI) on Linux?
« Reply #2 on: February 28, 2024, 01:14:45 pm »
I'm not familiar with SDL2 (nor 3). However I believe there is in principle nothing preventing using MIDI outside SDL part in any game using SDL in other parts. Not having coded any games or audio related stuff - so take this with a big grain of salt - I might say that MIDI (as in accessing an external port/driver) might not be the job of SDL. It seems like native MIDI was an afterthought even in SDL(1), and they focused on some way to render it internally.

I might take a look at this at some point as a coding exercise, but don't hold your breath ;).