EPSS

A new .zip file has been added with EPSS v1.08 split up into two .ST files made for 720kB DD floppys especially aimed to our Atari friends who don’t own a HD floppy for their Atari.

The first disk contains EPSS v1.08 as .ACC file and just booting with this floppy will load EPSS and the 8 channel module. The user is then prompted to change floppy to B: and after doing that, the default patch and midi song is loaded and starts automatically to play.

This should then require minimal effort to see EPSS in action on all Ataris. Of course if you have a hard disk, I recommend to follow the instructions in the README.TXT to store the files on C: for easier and faster access.

Download the file here.

I uploaded a new compiled version of EPSS Edit after Roland Zipfel kindly pointed out that the previous version needed an “EPSS Project” file to start with. I have probably done all my tests with already existing project files so this issue must have been missed.

But it is now tested on a clean install without any preferences or previous files started:

Initial startup without anything previously saved shows:

Pressing “No” will show the file selector where you have to type in what you project file should be called. EPSS need at least one project file to work with all the time, which is why you have to create it as early as possible:

After this you can start adding your samples.

Note that I now support sfz files (probably written about this before in some of the posts) so it is very quick importing existing sounds and mappings as long as you have sfz file. This needs more testing so if you encounter issues, please let me know and if possible send me sfz files that you have issues with and I will continue to improve the support for this format.

I have now put up the specialized version of Hatari that send and receives MIDI through my “Hatari Midi Mapper” as well as an installation package for “Hatari Midi Mapper”.

The complete installation can be downloaded from the Downloads page.

Known issues:

1. Hatari Midi Mapper has to be started first and then Hatari. Otherwise Hatari might not be able to find the named pipe that the mapper opens.
2. Not possible to change MIDI device when the mapper is running and receiving data. Solution is a restart of the mapper and Hatari, i.e. stop the mapper (possibly also exit the mapper), exit Hatari, start the mapper and change to correct devices and then start Hatari.
3. It needs some kind of MIDI input in Hatari Midi Mapper. If you dont have any devices, you can for example download and install LoopBe which is a free MIDI Virtual Device driver.

I might release some kind of bug fixes to these, but currently I think they are minor issues that has easy workarounds and once the mapper and Hatari has been started successfully, the setup works stable enough as far as I know.

Got some feedback from the quick proof of concept video I put on YouTube: “Does it work with MUNT MT-32”?

Never heard of MUNT before but downloaded it, found the ROMs, set the output in my Hatari MIDI Mapper as “MT-32 Synth Emulator”, started Hatari and Cubase and loaded up The Secret of Monkey Island.mid, which is specially made for MT-32, and it played great!

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.

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.

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.

…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