-
Notifications
You must be signed in to change notification settings - Fork 46
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
Comments
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. |
Even right now you can use FSMP + its integrated WinMM Multiport VSTi plugin to achieve this. FSMP also supports Midi In so you can create a 3rd software port and set game/DosBox Midi out to this port. @edit: Test Midi file: |
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 :) BTW, the inspiration was this Vogons topic: |
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, |
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. |
Hey all, I have a prototype of this feature working on my multi-instance branch here. This version can be run with |
Hi, 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). |
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. |
Hi. |
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.
The text was updated successfully, but these errors were encountered: