combine 2 emus to increase polyphony about nuked-sc55

[Falcosoft]

Even right now you can use FSMP + its integrated WinMM Multiport VSTi plugin to achieve this.
Make sure you select channels Even for 1st port and channels Odd for the 2nd:

FSMP also supports Midi In so you can create a 3rd software port and set game/DosBox Midi out to this port.
And of course make sure that you start the 2nd instance of the emulator with the command line argument '-p:x' where x denotes the 2nd port.

@edit:
Here is a dual instance test video with everquest_theme that has serious polyphony problems with a single instance of SC-55:
https://youtu.be/C9_C7sQAnGk

Test Midi file:
everquest_theme.zip

[Falcosoft]

interesting test, but the everquest midis were composed for awe32 plus the soundfonts that came with the game. :)

Until luclin or so, this was a small one that fit on all awe32s.

so kinda pointless to play these particular midis.

If I had tried something that was composed for the SC-55 directly then It would not have shown harsh polyphony problems for the SC-55 since it was composed for it :)
So to show a case where a single instance of SC-55 is clearly not enough you almost certainly need something that was NOT composed for the SC-55. Don't you agree?
The point was to show a case where you can clearly hear the difference between a single and dual intsances of SC-55 because of polyphony limit. This example is a perfect case in this sense.

BTW, the inspiration was this Vogons topic:
https://www.vogons.org/viewtopic.php?f=62&t=86019

[jcmoyer]

Hey all, I have a prototype of this feature working on my multi-instance branch here. This version can be run with -instances:<n> for up to 16 emulators. Midi events are routed modulo number of instances so for e.g. -instances:2 every even channel will be routed to the first emulator, and every odd channel will be routed to the second. There's probably a more clever way but I haven't thought too hard about it yet. If there's any interest in this feature or the related work I did eliminating all the globals upstream I can submit a PR after a bit of cleanup.

[Karmeck]

I remember an application to have, what was it, you could use 3,4 midi sources at once. But I'm not a sure games could be setup to use thees.

[zaphod77]

interesting test, but the everquest midis were composed for awe32 plus the soundfonts that came with the game. :)

Until luclin or so, this was a small one that fit on all awe32s.

so kinda pointless to play these particular midis.

[roberttryton]

i was wondering, what if the game sends some sysex messages to program the device and it is sent i guess through only one for example first channel only. Then only one midi device gonna get it and will be programmed, while the second midi device won't get that sysex and will stay in its original unchanged state. As a result for example odd channels will play correctly and even channels will play not correctly.

[Falcosoft]

i was wondering, what if the game sends some sysex messages to program the device and it is sent i guess through only one for example first channel only. Then only one midi device gonna get it and will be programmed, while the second midi device won't get that sysex and will stay in its original unchanged state. As a result for example odd channels will play correctly and even channels will play not correctly.

Hi,
No, it does not work this way. SysEx messages are NOT channel messages (contrary to short/channel messages that always denote the destination channel in the 1st status byte).
SysEx messages have no channel context so they are sent to both synth/emulator instances.

[zaphod77]

gm level 1 actually only requires 24 voice polyphony, often implemented as 16 melodic+8 percussion. It wasn't until gm level 2 that 32 note polyphony was actually required. XG level 1 and XGLite also require 32, with other XG specs requiring higher, while gs didn't actually require more than 24, though in practice sc 88 and later would all do at least 32.

That said, many wavetable cards did go higher than 24, and they usually did go up to 32, which resulted in people just assuming they had that many to work with when composing for general midi.

Anyway, having proper multi-instance support inside the program would probably sound a lot better, as then we aren't dependent on the operating system's mixing.

I'm still hoping nuked sc88 ends up showing up as well, as that synth did go up to 32, and it uses the jv-1080 and it's plugin boards as a sample source, though with reduced fidelity to fit everything in. A LOT of games had their soundtracks composed and recorded from a JV-1080, and the sc-88 faked one well enough that people would make their game midi for it, especially in japan.

[Falcosoft]

Hey all, I have a prototype of this feature working on my multi-instance branch here. This version can be run with -instances:<n> for up to 16 emulators...

Hi,
It's an interesting concept. I have not been able to try it personally so far but I have taken a quick look at the source and I have noticed that you also route SysEx (long) messages. As I have written above (#29 (comment)) SysEx messages should be sent to all instances since they have no "channel context".
If I have read your code right currently you handle the status byte of SysEx messages (0xF0) the same way as channel messages. But this way all SysEx messages are sent only to the 1st instance that has channel 0 assigned to.

Also it seems that you should remove the outer for loop from midi_win32.cpp when you send SysEx bytes to FE_RouteMIDI() from MIDI_Callback() since this way you send SysEx messages multiple times (SysEx bytes times exactly).

[jcmoyer]

Thanks for the feedback @Falcosoft. I pushed fixes for both of those issues.

[Falcosoft]

Thanks for the feedback @Falcosoft. I pushed fixes for both of those issues.

Nice. I think even just for the backend/frontend separation alone this branch should be integrated into master. The multi-instance feature is just a big bonus. So I think you should send a PR by all means. Of course the final decision rests with Nukeykt.