Would anything be gained by using the Reverb ROM at this point? The emulator uses the other ROMs inside these machines already.
http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog
wrote:wrote:- reverb mode 3 must be accurate but isn't thoroughly tested for now
It requires some tweaking. Try checking some games that heavily use mode 3 reverb, for example in The Humans level 1 music, echo is hardly audible compared to previous version (and LAPC recordings from http://cosmic-dreams.net).
Hi Mok! Great to see you around. We (especially SergM) have been working on reverb mode 3 extensively today, so I'm not sure which version you last tried. The timing's now 100% to-the-sample perfect, and the gain, feedback and filtering should be very close to correct. Would you mind re-checking songs/games that you're familiar with?
wrote:Would anything be gained by using the Reverb ROM at this point? The emulator uses the other ROMs inside these machines already.
Maybe! So far nobody has deciphered how it works (the reverb chip is a custom gate array) - there are only theories as to what the data in the ROM actually represents.
Reverb mode 3 is pretty much conquered, though, and I'm preparing digital captures so that SergM can get a good look at the other modes as soon as possible. I see no reason why his magic would fail him now.
wrote:The driver can be made to work on x64, but not by the INF install. I wrote an NSIS script that will install the driver on x64 as well as Win32. KingGuppy has the NSIS script, but it is up to him as to what to do with it. I don't know if he has had a chance to look at it yet or not.
Thanks again for this - I didn't have a chance to look through it thoroughly yet, but I do still hope to get to it this weekend (which is a long weekend for me).
Great work. I never thought I would see the day that I would seriously consider putting my old LA modules away, but now I'm holding my breath 😀
wrote:I'm also working on some documentation of how the MT-32 works internally and how accurately we model each part.
This should prove very interesting indeed. In particular, I'm going to be interested in these aspects of the MT-32's internal workings:
- MUNT sounds very clean, whereas the real MT-32 has what sounds like quantization noise, especially with instruments like "Soundtrack" at low volumes. I once thought it came from the DAC, but heard it in digital captures as well. How much do rounding errors in the LA32 chip contribute to this?
- The later models (CM-500, CM-32LN) produce a very annoying vibrato with some instruments. I have always wondered if the problem lies with the control ROM or the LA32 chip.
- Early modules seem to have a lot of trouble assigning voices properly, dropping more notes than later models. This is particularly odd since the author of the RealWorld modification claims in the mod description that later models have a "slower" CPU. MUNT doesn't seem to drop anything unless it's obvious that the song uses too many notes.
- Does the knowledge of the MT-32's inner workings reveal any design-specific reason why the pan directions are reversed from normal MIDI modules? I have always thought this to be a rather weird design decision. That even centered parts always sound slightly panned to the right has confounded me (and others) as well.
If your internal documentation project could touch on these questions, it would be much appreciated. Again, thank-you very much for your most impressive work.
wrote:Great work. I never thought I would see the day that I would seriously consider putting my old LA modules away, but now I'm hold […]
Great work. I never thought I would see the day that I would seriously consider putting my old LA modules away, but now I'm holding my breath 😀
wrote:I'm also working on some documentation of how the MT-32 works internally and how accurately we model each part.
This should prove very interesting indeed. In particular, I'm going to be interested in these aspects of the MT-32's internal workings:
- MUNT sounds very clean, whereas the real MT-32 has what sounds like quantization noise, especially with instruments like "Soundtrack" at low volumes. I once thought it came from the DAC, but heard it in digital captures as well. How much do rounding errors in the LA32 chip contribute to this?
- The later models (CM-500, CM-32LN) produce a very annoying vibrato with some instruments. I have always wondered if the problem lies with the control ROM or the LA32 chip.
- Early modules seem to have a lot of trouble assigning voices properly, dropping more notes than later models. This is particularly odd since the author of the RealWorld modification claims in the mod description that later models have a "slower" CPU. MUNT doesn't seem to drop anything unless it's obvious that the song uses too many notes.
- Does the knowledge of the MT-32's inner workings reveal any design-specific reason why the pan directions are reversed from normal MIDI modules? I have always thought this to be a rather weird design decision. That even centered parts always sound slightly panned to the right has confounded me (and others) as well.If your internal documentation project could touch on these questions, it would be much appreciated. Again, thank-you very much for your most impressive work.
Thanks for your interest and kind words 😀
Cool questions, that's absolutely the sort of stuff I want to cover in the documentation. In the mean time I'll cover your specific points:
- Regarding LA32 noise, we don't fully have a handle on that yet. We're doing a lot of things a lot closer to "mathematically perfect" than the LA32 right now, but I'm doing my best to work out exactly where rounding errors, LUT use and other sources of inaccuracy affect the real thing.
- Unlike the amplitude and filter envelopes, where the LA32 is configured to smoothly ramp up/down from one value to the next, dynamic pitch changes (including the LFO) are pretty much entirely under the control of the microcontroller. Therefore changes in the MCU or the control ROM can have an effect on the vibrato. We have some notes from Mok about differences, but I haven't yet made the alternative versions selectable.
- Partial management is similar: Many tweaks were made between control ROM versions, but I'm yet to make these selectable. I think right now we're using a more ideal approach than any of the control ROMs implemented, but I need to revisit this.
- Regarding pan, the LA32 internally only supports 8 panpot positions. The controller does the mapping between the sysex-addressable panpot parameter (which has the range 0-14) to a value in the range 0-7. Since 8 is an even number, and is directly proportional to the amplitude, the closest you can get to the centre is around 43% on one channel and 57% on the other. Note that there is justification for the 0-14 parameter range - it's not just there to mislead people - but I'll explain that another time.
- I think the pan directions are reversed only because the MT-32 predates General MIDI, so there was no real standard for this. I doubt that the MT-32 is alone in using what later became the "wrong" direction.
Thank-you for your answers. So the LA32 can't actually create a centered signal? If the explanation didn't fit the symptom so well, I wouldn't believe it. I'm probably biased by Space Quest 1's README file regarding the "proper" working of the panpot controller, where it outright claims that the MT-32 violates the MIDI spec. I can understand why it might be undesirable to have too many selectable options, as it may easily confuse the user.
Two last points, if I may:
1) There might be a problem in Ultima Underworld II's UWR12.XMI --- there's a low string note at the start that plays for a really long time. At about 00:30 or so into the song, the low note turns into a high-pitched squeak instead; once a new note on that channel is finally played, everything goes back to normal. I'm using the April 13th build with regular DosBox, MIDI Yoke and MT32EMU.exe. If the problem has been fixed in newer builds or is caused by Midi Yoke/MT32EMU.exe choking up on long-duration notes, please ignore this report. I have attached the XMIDI file.
2) How difficult would it be to allow the user to increase the number of voices from 32 to a higher limit? Some game songs really exhaust the polyphony limit, and some "improvement" options would help there. I understand however that the priority will of course always be getting the actual modules' sound and not any improvements.
wrote:1) There might be a problem in Ultima Underworld II's UWR12.XMI --- there's a low string note at the start that plays for a really long time. At about 00:30 or so into the song, the low note turns into a high-pitched squeak instead; once a new note on that channel is finally played, everything goes back to normal. I'm using the April 13th build with regular DosBox, MIDI Yoke and MT32EMU.exe. If the problem has been fixed in newer builds or is caused by Midi Yoke/MT32EMU.exe choking up on long-duration notes, please ignore this report. I have attached the XMIDI file.
Hmm, I'll have to add XMIDI support to mt32emu-smf2wav and get back to you on that. For Munt, April 13th is a *really* long time ago, though 😀
wrote:2) How difficult would it be to allow the user to increase the number of voices from 32 to a higher limit? Some game songs really exhaust the polyphony limit, and some "improvement" options would help there. I understand however that the priority will of course always be getting the actual modules' sound and not any improvements.
The core library (libmt32emu) can already be compiled with support for an arbitrary number of partials (currently 32, of course). I'll make this configurable at runtime in future.
I have converted the XMIDI file to Standard MIDI format (and verified that the problem persists); please find it attached to this post.
wrote:I have converted the XMIDI file to Standard MIDI format (and verified that the problem persists); please find it attached to this post.
Thanks - confirmed reproducible here with mt32emu-smf2wav. I'll take a look after some sleep (if SergM doesn't get there first).
The cause is in Bit16u TVP::nextPitch()
timeElapsed = timeElapsed & 0x00FFFFFF;
After 30 sec of sustaining timeElapsed gets value of 2^24 and goes around ...
If I make the mask wider, it sounds OK but I can't say whether it would be some side effects. Those tvX modules aren't so clear.... and I'd never find it without the debugger 😀
wrote:The cause is in Bit16u TVP::nextPitch() timeElapsed = timeElapsed & 0x00FFFFFF; After 30 sec of sustaining timeElapsed gets va […]
The cause is in Bit16u TVP::nextPitch()
timeElapsed = timeElapsed & 0x00FFFFFF;
After 30 sec of sustaining timeElapsed gets value of 2^24 and goes around ...If I make the mask wider, it sounds OK but I can't say whether it would be some side effects. Those tvX modules aren't so clear.... and I'd never find it without the debugger 😀
Fix pushed. The bug was very closely related to that, though the fix keeps the timer 24-bit as in the MCU.
It can be said that reverb is now implemented 😀
@ KingGuppy
How do you know that? Have you tested a single tune? 😀
Good point! Post updated.
😀
BTW, KingGuppy, congratulations on making a member on VOGONS!
But everyone's invited to please help with the testing....
BTW, KingGuppy, congratulations on making a member on VOGONS!
But everyone's invited to please help with the testing....
I would LOVE to help test. Since I'm running Win7 64, I'll have to wait for a intermediate build from ykhwong or something similar since I cannot run that mt32 munt driver alone.
Can't wait to hear all the newest updates! Great job!!
circletheory
If such a persistence, I've put a mt32-patched DOSBox 0.74 build at
https://github.com/sergm/munt_devel/downloads
At least I'm happy with this one 😀
And where is that CPU load?! ~2-3% @2.8GHz Athlon x2 Maybe, MSVC over-optimized the code 😀 And there is no Win MM API use for transferring MIDI messages though...
