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:
- 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.
- 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.