Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

combine 2 emus to increase polyphony #29

Open
roberttryton opened this issue Apr 7, 2024 · 12 comments
Open

combine 2 emus to increase polyphony #29

roberttryton opened this issue Apr 7, 2024 · 12 comments

Comments

@roberttryton
Copy link

could you make this emu combine 2 emus to increase polyphony?

I have read that there are games that play more instruments at once than this module can play so some instruments are just like muted.

@Karmeck
Copy link

Karmeck commented Apr 7, 2024

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.

@Falcosoft
Copy link
Contributor

Falcosoft commented Apr 7, 2024

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:

image

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

@zaphod77
Copy link

zaphod77 commented Apr 7, 2024

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.

@Falcosoft
Copy link
Contributor

Falcosoft commented Apr 8, 2024

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

@roberttryton
Copy link
Author

roberttryton commented Apr 8, 2024

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
Copy link
Contributor

Falcosoft commented Apr 8, 2024

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
Copy link

zaphod77 commented Apr 8, 2024

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.

@jcmoyer
Copy link

jcmoyer commented Apr 29, 2024

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.

@Falcosoft
Copy link
Contributor

Falcosoft commented Apr 29, 2024

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
Copy link

jcmoyer commented Apr 29, 2024

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

@Falcosoft
Copy link
Contributor

Falcosoft commented Apr 30, 2024

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.

@Rabanikk
Copy link

Rabanikk commented Sep 2, 2024

Hi.
is there some possibility to add for Nuked SC-55 a voice polyphony counting at least for SC-55/SC-55mkII devices?
Thisway we can see how many of voices ares used in real. For example S-YXG50 plugin displays it.
Thx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants