MIDI sound emulation (Windows)

[badflame]

Hi,

I would like to know how the MIDI sound is emulated from Hatari Windows version, so I can enjoy this sound in compatible games.

In "Devices setup" I activate "Midi Emulation" and I must indicate the path of two files: "Read MIDI input from file" and "Write MIDI output to file".

Where do I get those files?

Thanks.

[Eero Tamminen]

I would like to know how the MIDI sound is emulated from Hatari Windows version, so I can enjoy this sound in compatible games.

In "Devices setup" I activate "Midi Emulation" and I must indicate the path of two files: "Read MIDI input from file" and "Write MIDI output to file".

Where do I get those files?

You Hatari version has been built with "raw" MIDI device files support. However, Windows does not support MIDI device files.

You would need to build Hatari with Windows version of portMIDI library, for MIDI support on Windows.

(Similarly to Hatari development, also Hatari Windows release binaries are built on Linux, using a cross-toolchain. That Linux build environment does not have Windows portMIDI, and no Windows user has contributed such thing, so Windows users are on their own with that.)

Other option for you could be using Hatari Linux version in Windows WSL, and use one of the many free Linux MIDI sound synthesis programs for the MIDI outputs (I like Qsynth/FluidSynth for general MIDI, and e.g. "Bristol" for funky Organ sounds).

[badflame]

Thanks for you kind reply Eero Tamminen.

On my Windows I have "Munt MT-32" installed, which for example uses WinUAE Amiga emulator to play midi sound, in the midi compatible games.

Is there a way to link Munt with Hatari?

Thanks again.

[Eero Tamminen]

Hatari uses only CPU core from WinUAE nothing else, so that does not help. But it's possible that "Munt MT-32" could work if you manage to build PortMidi library (or find prebuild binary) and build Hatari with it.

[robv]

I got MIDI working on Hatari Windows with the contents of the hatariMidiWindows1.0.zip file I got from Conny's site epss.copson.se/. I believe you need a free registration to get to the download section.
I have the zip here but it's to big to attach. It contains all you need (compiled Hatari for Windows plus Hatari Midi Mapper).

[AnthonyJ]

(Similarly to Hatari development, also Hatari Windows release binaries are built on Linux, using a cross-toolchain. That Linux build environment does not have Windows portMIDI, and no Windows user has contributed such thing, so Windows users are on their own with that.)

Well, as you say, you *are* building it in Linux, and so it's actually a Linux activity to configure your Linux build environment such that it has the required dependencies. Isn't it just a matter of installing PortMidi in the cross-mingw install that you're using for the builds? I'm not sure that anyone can resolve this other than the maintainer of the (Linux) build server?

Sure, Windows users *want* this to be done while Linux users don't care about it - and perhaps that is fine as you can choose what you work on. However I think it's a bit disingenuous to say that this needs a Windows user to contribute a fix, where as far as I can tell this isn't actually an issue in a Windows build environment?

[Eero Tamminen]

You obviously seem to think that it's not much work, so just do it. Like the Hatari Mac users did for Hatari Mac builds.

While I'm Hatari developer, I have no idea how the current mingw cross-builds for Windows work or where one would get PortMidi Windows version in the first place, and do not see why I should investigate or invest time in that. I've never used Windows at home, and do not really feel urge to touch anything related to it when I happen to have some free time for my hobbies.

Note: building things blindly with (cross-)mingw is not enough, somebody needs to test that the thing actually works one Windows, debug it when it does not work, fix whatever's the issue, and repeat that cycle until it works. It's IMHO clearly work for some some Windows user/developer using native Windows mingw (or Linux cross-mingw under Windows WSL) for the builds. Once that works, he / she can contribute it upstream.

[AnthonyJ]

You obviously seem to think that it's not much work, so just do it.

Well, as I said above, IMO the issue pretty much lies with the setup of the build server that is currently building it, since cmake on that setup fails to find portmidi and so doesn't enable it. It appears that all that needs to be done is install portmidi on the build server.

When I wrote the above I assumed that fix lies solely with the the maintainer of the build server, but I now see that it appears to be configured via Gitlab CI running Fedora Linux, as per https://git.tuxfamily.org/hatari/hatari ... lab-ci.yml - and as can be seen, care has been taken to ensure apt-get install libportmidi-dev is done prior to building the linux builds, but no similar line to install the mingw portmidi package before the mingw build.

As it happens, I'm actually mostly a Linux developer myself these days. Like you, I've never set up a cross-mingw environment, nor configured a gitlab CI server, but I am reasonably familiar with at least how the cross-env would work. I have therefore considered testing whether I can myself cross compile from within Linux with PortMidi support enabled (which seems like it should work fine, although my time is very short at the moment so I haven't tried it).

I've never used Windows at home, and do not really feel urge to touch anything related to it when I happen to have some free time for my hobbies.

I get that, and as I said above, that is your choice. But I do still see a big distinction between the sentence "I don't want to spend time fixing that for you because you use Windows" and "only a Windows user can fix this", especially since it seems the problem is with the Linux cross-build environment and configuration. For someone with well a setup Windows build environment, I imagine that it "just works" - the only issue is that most Windows users do not have a build environment at all, let alone one with all the appropriate dependencies installed.

Note: building things blindly with (cross-)mingw is not enough

No, but blindly building versions that are known not to work because you've not got PortMidi even linked in can never get Windows users to test the port midi support tested, apart from those Windows users who are capable of building their own builds.

somebody needs to test that the thing actually works one Windows

Given the unofficial build that is referenced above (that is behind a account-creation-wall?), it sounds like it does work. Most Windows users don't see that though, and who knows how old a rev that is etc, and the same would be true of any build I were to create.

[Eero Tamminen]

as can be seen, care has been taken to ensure apt-get install libportmidi-dev is done prior to building the linux builds, but no similar line to install the mingw portmidi package before the mingw build.

Debian/Ubuntu include only very few mingw packages in addition to different compilers: https://packages.debian.org/search?keyw ... ection=all

Fedora seems to have quite a bit more, but even Fedora does not include mingw version of portmidi (only portaudio): https://pkgs.org/search/?q=mingw

(If it had, I'm sure it would have been already included into Hatari mingw builds.)

[robv]

I would like to know how the MIDI sound is emulated from Hatari Windows version, so I can enjoy this sound in compatible games.

If you just want to play games with midi sound, the easiest way would be to use STEem emulator as you can easily hook that up to GS Wavetable Synth that's included with Windows.

[badflame]

I would like to know how the MIDI sound is emulated from Hatari Windows version, so I can enjoy this sound in compatible games.

If you just want to play games with midi sound, the easiest way would be to use STEem emulator as you can easily hook that up to GS Wavetable Synth that's included with Windows.

Since really, I only want it to play it in one of the few compatible games, I think I will follow your advice of using another emulator.

Greetings and thanks to all of you who have answered me

[AnthonyJ]

Fedora seems to have quite a bit more, but even Fedora does not include mingw version of portmidi (only portaudio): https://pkgs.org/search/?q=mingw

It is, however, pretty simple to compile from code. In fact, the files in the hatari git repository actually make it easy to cross compile in this way. For me, running a completely fresh Fedora 39 (to match that github-ci.yml setup), I was able to compile portmidi and build Hatari using it with the following:

Code: Select all

dnf update -y
dnf install -y cmake make gcc mingw32-gcc mingw32-SDL2 mingw32-zlib mingw32-gcc-c++
git clone https://git.tuxfamily.org/hatari/hatari.git
git clone https://github.com/PortMidi/portmidi
cd portmidi
cmake -DCMAKE_TOOLCHAIN_FILE=../hatari/cmake/Toolchain-mingw32-win64_32.cmake .
make
cd ../hatari
cmake -DCMAKE_TOOLCHAIN_FILE=cmake/Toolchain-mingw32-win64_32.cmake -DPORTMIDI_INCLUDE_DIR=../portmidi/pm_common -DPORTMIDI_LIBRARY=../portmidi/libportmidi.dll.a .
make

(note, portmidi also requires g++ so you need to install the mingw package for that to allow you to compile PortMidi).

I saw that someone posted to the hatari mailinglist back in 2021, saying that you can simply unpack the msys package and link directly with that (from Linux) rather than build from source - I haven't tried that, but that is probably also possible if building from source isn't considered desirable.

So, the question remains, how do we get this into the build server that is used for the official builds, or the nightly builds made available at http://antarctica.no/~hatari/ ?

Looking closer, I see that that github-ci.yml probably isn't used for the "nightly" builds since that generates both 64bit and 32-bit builds, while the github-ci.yml only does the 32-bit.

FWIW, I've tested the binary I produced with the above using EmuTOS + a piece of freeware MIDI software and confirmed that music plays, so the build seems to fundamentally work (or at least a hell of a lot better than the non-functional midi device files).

I would attach the binaries here, but it seems they're too big for the forum and I don't have any public webspace available for hosting it.

[solskogen]

I can probably fix it (antarctica.no is mine)

[AnthonyJ]

I can probably fix it (antarctica.no is mine)

Excellent - that would be appreciated. Thanks

[solskogen]

all new builds are linked with portmidi now (I've not tested that it works) - could you report back, please?

[czietz]

all new builds are linked with portmidi now (I've not tested that it works) - could you report back, please?

Thank you very much! I have briefly tested the Win64 build from http://antarctica.no/~hatari/latest/windows/. I can confirm that MIDI out now works via PortMidi:

midi-works.png

(I have no way to test MIDI input, though.)

[badflame]

all new builds are linked with portmidi now (I've not tested that it works) - could you report back, please?

Thank you very much! I have briefly tested the Win64 build from http://antarctica.no/~hatari/latest/windows/. I can confirm that MIDI out now works via PortMidi:
midi-works.png

(I have no way to test MIDI input, though.)

Thanks a lot czietz, works perfect for me. Even selecting Roland MT-32, which improves the sound of the Microsoft GS.

By the way, is this version v2.5.0-devel? I ask this because, for some reason, it doesn't tell me the version in the window:



But it is indicated in your screenshot.

Thanks again.

[AnthonyJ]

all new builds are linked with portmidi now (I've not tested that it works) - could you report back, please?

Yep, worked for me too. Thanks

[czietz]

Thanks a lot czietz, works perfect for me. Even selecting Roland MT-32, which improves the sound of the Microsoft GS.

Don't thank me, thank @solskogen who makes those automated builds.

By the way, is this version v2.5.0-devel?

Every "developer" version newer that 2.4.1 will identify as v2.5.0-devel. So there are many different v2.5.0-devel. But yes, the one at http://antarctica.no/~hatari/latest/windows/ is always the most recent one (for Windows).

[badflame]

Thanks a lot czietz, works perfect for me. Even selecting Roland MT-32, which improves the sound of the Microsoft GS.

Don't thank me, thank @solskogen who makes those automated builds.

By the way, is this version v2.5.0-devel?

Every "developer" version newer that 2.4.1 will identify as v2.5.0-devel. So there are many different v2.5.0-devel. But yes, the one at http://antarctica.no/~hatari/latest/windows/ is always the most recent one (for Windows).

So, thanks to @solskogen too

Understood about the versions.

[robv]

all new builds are linked with portmidi now (I've not tested that it works) - could you report back, please?

Thank you very much! I have briefly tested the Win64 build from http://antarctica.no/~hatari/latest/windows/. I can confirm that MIDI out now works via PortMidi:

Excellent! Good to know we can do MIDI on Hatari Windows now.

[Eero Tamminen]

Thanks everybody for getting this fixed!

(Although I did not want to look into Windows stuff myself, having PortMidi functionality in Hatari, but not in all OS versions where it would actually be most useful, was annoying!)

[npomarede]

Hi
I added portmidi to my build chain for releasing Hatari for Windows.

I put 32 bit and 64 bit exe here as a test for next Hatari 2.5 :
https://download.tuxfamily.org/hatari/2.5_beta/

Code: Select all

hatari-2.5.0_windows.zip
hatari-2.5.0_windows64.zip

For the people using Windows in this thread, can you try these 2 versions and see if MIDI works ?

Nicolas

[Mikerochip]

Yup, works ok for me, getting output to midi, or to the microsoft midi mapper / ms gm synth

[npomarede]

Yup, works ok for me, getting output to midi, or to the microsoft midi mapper / ms gm synth

Thanks, then I will be able to include midi support in next Hatari