MIDI for Hatari

I have recently struggled with efficient debugging of the MIDI routines in EPSS when using virtual Atari development (Hatari).

MIDI works in Hatari running on Linux (via ELSA) and Mac (via PortMIDI, dont know how good though) but it has never worked for Windows, which is the platform I use.

I decided to do something about that and after some tests I decide the quickest way would be to develop a "mapper" that could send and receive MIDI data from Hatari and pass it on to Windows MIDI.

I made the mapper in C# under Visual Studio Community and found a great MIDI library to work with: A MIDI File Slicer and MIDI Library in C# - CodeProject. Super credits for this goes to "honey the codewitch" for her excellent work with this!

I manged quite easily to get a file based communication for sending in MIDI to Hatari. Instead of the normal behaviour in Hatari, keeping the file set as MIDI in file open all the time, I instead change this to

  1. Hatari checks if the file exists
  2. If it exists, open it and read in the contents.
  3. After all is read, remove the file.

In the MIDI mapper I can then check if the file exist, in that case wait (as Atari then is reading the file) or else, create the file and fill it with the MIDI message received from the device set as MIDI in device.

This concept seems to work fine so that really solved my problem with EPSS debugging, as I then can generate true MIDI from my MIDI controller and see how EPSS reacts in real time in Hatari.

I wanted of course also solve MIDI out from Hatari in a similar way. This was a bit trickier though as I did not want to keep polling a file in Windows. I tried to use the FileWatcher but this never was accurate enough.

So I started to look at Named Pipes which seemed to be a much better concept. As this is pure Windows behaviour I was unsure how good this would be supported in Hatari when compiling it, but it showed that it was no problem including windows.h and then access the Windows specific functionality, like CreateFile with pipe flags, file handles and so on.

I thought the best would be to act as a pipe server on the C# side and let Hatari act as the client connecting to the server when it needs to pipe data. It was quite a big mess on the c# side before I managed to get a stable implementation of the Named Pipes and lots of trial and errors and googling different approaches.

After managing to get the MIDI bytes from Atari was the next issue, MIDI on PC always works with complete MIDI messages and I have not found any way of just sending the MIDI bytes byte by byte RAW to the MIDI interface. So I now collect the bytes more intelligent in the MIDI Mapper and when I see that I have a valid MIDI message I can forward it to the MIDI device and that works fine.

I recorded a clip on how it currently works and uploaded it to YouTube with some explanatory text here: (501) Hatari for Windows and MIDI - YouTube

If anybody are interested in testing this out, I can make the repos available and do a fork of the Hatari sources and put my changes there.

EPSS next version progress…

I thought I should write a little about what is planned for the next version of EPSS.

First of all we have a couple of minor changes already implemented and in test in what is internally called 1.09b:

  1. When EPSS Control is running as an ACC file, it will now load and initialize both patch (SPI) and MID file right at the start. This happened previously only when the main window was openened. It then caused a bit of confusion running with Cubase and MROS as no sound was played until EPSS Control was opened at least once.
  2. When changing screen resolution running TOS, EPSS always crashed. I think MultiTOS actually worked though. This was because I incorrectly try to wait for a sub message called "REZ_CHG" from GEM. But this message was not supposed to be received on the "AC_CLOSE" which I got when resolution was changed. After a bit of debugging I realized what the problem was and it was fairly easy fixed to work as it was supposed to. It is quite nice to allow resolution change on a TT for example where you have a few usable resolutions. ST is a bit more limited of course. I realized it is actually possible to start EPSS Control in ST Low just to load patches and play songs, but no other functions really not useful and may as well cause crashes.

I might release those two as a minor fix depending on how long the next task takes.

The next task is a bit more challenging and requires change to the whole system: EPSS is finally supporting standard MIDI Program Change. This will open up possibilities of for example making a full GM (General MIDI) compatible SPI patch file to be able to correctly play all the gazillions of .MID files that exists, something that has been a bit of a holy grail for EPSS since the start. It will also allow EPSS work better as a softsynth so you can play directly to EPSS with a MIDI keyboard and using Program Change to change between your sounds.

Work has already started by defining how the extensions should be done in the SPI. The format is called Gen2 or just G2. The SPI has to both keep the original way of placing sounds directly on keys for a whole MIDI channel (which is necessary for the GM Percussion channel 10) and also being able to define the sounds and tones for a "Program". There can only be 128 programs by MIDI definitions so it will be just a list of 128 midi tones for sound+tone duplicated 128 times, one for each Program. I decided to use 4 bytes for sound + tone instead of the current 2 bytes to increase the maximum number of sounds in a patch at the same time. It will now support up to 65536 sounds instead of the current 256. As I am still using the original 2 bytes format for the MIDI splits for percussion channel 10, percussions sounds has to be placed on the lower 256 sounds which I think should be fine. So the patch size will increase by 128 * 128 * 4 = 65536 bytes to accomodate for the Program Change split maps, which is not that bad.

EPSS Editor is already implemented to save in the Gen2 format by using a checkbox "SPI Gen2". EPSS Editor should still work to create original format patches. But you can already prepare for the release by starting to create your new Program Change patches! Sorry, no ready compiled EPSS Editor yet so you have to download Visual Studio C# Community to compile it yourself. If you want a quick guide on this, let me know and I can write a post here explaining how you start from scratch to do this if you are not used to Visual Studio. No coding skills needed, I promise!

And mentioning EPSS Editor, recently I built in support for reading complete multisamples stored in sfz file format. I did not know about that format before, but I found some free sounds and started to investigate and liked the simplicity of the format and realized it would be easy to support it in EPSS Editor. See more here: Home - SFZ Format. So if you have a sfz file and a number of samples going with it, you can simply just drag over the sfz file to the left side of EPSS Editor to import them all at once. The information about the original keys and the low and high midi notes are preserved and when you then select all the samples you imported from the sfz on the left size, the MIDI note information will be used they will be placed automatically on the correct MIDI notes when you move them to the right side. It was when implementing this I realized that the number of sounds possible to map in a patch will soon become a restriction, as we basically had to use one midi channel per sound restricting a patch to max 15 sounds if one channel used for percussions. And that is why I started to look at supporting proper MIDI Program Change to allow more sounds in a patch.

The code for EPSS Sound Driver has been written to support this by first looking at the MIDI splits and when no split is defined on a tone, it will find the sounds from the current Program Change on that channel. By doing this I can keep the compatibility with the old MIDI Channel Split system, which is needed for channel 10 anyway, and the new MIDI Program Change. It will even be possible to have a midi channel with a mix of both MIDI Channel Split info and when nothing is defined, it will use the MIDI Program Change for that channel. I don't know how useful such a feature will be but at least it is possible within the format.

The MIDI player and MIDI message receiver have been rewritten to read Program Change and store it as the current Program for the MIDI channel it receives it on.

I doubt however than EPSS Control will support the new Program Change format in its built in Atari Editor. It might just show a message that SPI of this version cannot be changed inside EPSS. It will be so much work to try to rework all the logic and fit buttons etc in the current code base, as everything is written in 68000 assembler, but maybe some simpler editing might be possible, we will see.

Testing the whole chain is the tricky part, as it will probably not work first time, so I will try to build up some kind of unit test cases with known MIDI messages and then see if they pass. No unit tests has ever been done for EPSS so this might then be extended to other parts to find other issues as well and especially do regression testing when adding new functionality.

EPSS v1.08 released

An update to EPSS is released today.

The most important highlights are:

  • Sound patches can now use the full TT RAM when available.
  • Support for reading MIDI Pitch Bend both from live MIDI In, MROS and MID files.
  • Support of variable pitch (using the MIDI Pitch Bend) of the sounds on TT, Falcon and Mega STe. Sorry, stock STe unfortunately too slow to do this in EPSS when using 8 channels...

Direct download link is here or head over to the Downloads area to find the older versions and complete packages.

New version of EPSS-Ctrl v1.06…

...released today! Various bug fixes and enhancements, most important:

  1. MIDI Sequencers now supported with MROS or direct pacth. This was previously not enabled by a coding mistake
  2. MIDI Running Status supported for sequencer input.
  3. Working on Atari TT030 again

For more information, download the file here