Playing with my new wavetable WG I've noticed that when using IIR (even bi-directional) the waves generated are never symmetrical. They clearly differ in positive and negative semi-periods since the infinite filter response. So, perfect waves (as I suppose MT-32 generates) can be made only using FIR filter or, again, the phase distortion.
One more idea on improving sounding for partials with cutoff < 50: in this case we can bypass filtering at all and utilize an exact law that MT-32 use for the wave attenuation. Here the patch for partial.cpp:
...
Bit32s filtval = getFiltEnvelope();
float freqsum = synth->tables.tCutoffFreq[filtval] * freq;
if(freqsum >= (FILTERGRAN - 500.0))
freqsum = (FILTERGRAN - 500.0f);
if(filtval < 128)
freqsum = freq; // even don't filter the wave for low cutoff
sample = (floorf((synth->iirFilter)((sample), &history[0], synth->tables.filtCoeff[(Bit32s)freqsum][(int)patchCache->filtEnv.resonance])));
// This should correspond to real hardware law for signal fading below the cutoff point
if (filtval < 128) {
sample *= fpow2((filtval - 128) / 32);
}
// In case of overdriving prevent clicks
...
Now we needed to find that law that exactly correspond to hardware behavior...
wrote:wrote:I agree with everything you've described here. Even with a square wave generator, those can be made by subtracting sawtooth points given a particular pulse width. The mystery remains, however, where did those samples come from to start? They aren't found on any of the ROMs.
<skip>
Oops, the microcontroller in MT-32 is Intel's C8095-90 or P8098 and they both are ROMless. If it's true the wavetable must be in one of the ROMs or may be generated in run-time. I still don't believe Roland use waveshaping or phase distortion but who knows. The Control ROM must contain all the software the microcontroller runs, is it right?
P.S. There is definitely no time for computing digital filter. The latency of mul / div operations is 6.25 microseconds and there must be processed 32 x 32,000 = 1,024,000 samples per second. How can they afford it?
Even more, there is no time to do mixing (or any other processing applied to every sample) in software since 1 microsecond is the latency of a typical operation like addition. As the number of partials is strongly limited to 32, I do believe each partial is played by hardware from a preallocated buffer the microcontroller fills, then they all mixed by hardware, and finally mixed samples go to the DAC. So, buffered partials cannot be processed in DSP way. Applying of amp and pitch by hardware is questionable.
When the pitch, waveform (filter parameters) or amp is changed according to the envelope or LFO, all the microcontroller does is just updating single-period wave buffer (or PCM wave cache if the pitch isn't controlled by hardware).
Concluding the above, we can state that:
- the hardware does very simple form of the wavetable synthesis due to limited processing capabilities
- it's still unknown how the waveforms are generated. I think only disassembling the control ROM could give the answer.
- we can use the same technique to implement WG+filter pair in MUNT. Even for time-consuming WG (using BLIT) or filter (e.g. window-sync) we can speed things up by caching generated single-period wave instead of recomputing it every sample or saving pregenerated semitones in the big wavecache.
- the use of the filter is not required. Using of BILT - derived WG we can produce bandlimited squarewave without unwanted harmonics corresponding to the filter value. Again, the filtered wave can be constructed from positive and negative cosine waves on the slopes which is much faster than window-sync or FFT. Moreover, we know that cosine IS used to form the sawtooth. This explains "strange" hardware behavior in signal amp after the filter.
Sorry if this is off-topic, but I think you mentioned that you don't currently have a physical MT-32 module.
There's an auction right now on eBay offering one:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem … em=250783976543
That ships internationally, if you are interested.
Regards.
Hi sergm!
I only just became aware of these developments, and it's awesome to see some new people interested in the development side of MT-32 emulation.
Although signs may point to the contrary (19 months without a commit...), the Munt project isn't dead. We even have a few things on the burner:
- I've sent an MT-32 to some very kind people who will make die scans of the LA32 and reverb chips. We've been waiting quite a while for this to happen, and reverse engineering from that will be a HUGE undertaking, but it should ultimately answer all our remaining questions about MT-32 internals.
- I have a few outstanding changes that I've been reluctant to commit because they complicate the build system (such as multithreading), but I'll get on that as soon as possible.
- We've been planning for some time to switch to a DVCS (probably git) for Munt, which will make it a lot easier to share code between the forks. I'd also be thrilled if sergm and any other developers would contribute directly to the Munt project, but that's entirely their choice.
Taking a look to the work completed by the Munt team, one may come to conclusion that it’s hardly possible to achieve for the emu exactly the same sounding as the hardware. We plan to change things some way.
We never came to that conclusion ourselves - we've just been working very very slowly towards the goal of 100% accurate emulation.
It would be surely an advantage if you could share the results of reverse engineering the Team has already performed.
The source code is the only formally released result of our RE efforts. There are a fair few comments in the code indicating what's guesswork and what's known to be 100% accurate, but I'll make an effort to go through all relevant parts of the code base and document their accuracy. I have copious notes that I've been meaning to clean up and host online for some time, but that's a big project that it will take me some time to get to. I'll write more about accuracy in general terms later in this post.
It’s obvious, people who want the emu sounds correct the most do not have the hardware.
Ouch! I can assure you that there are also people with hardware who are very eager to have correct MT-32 emulation...
If only KingGuppy could help in the research with use of his digital sampling hardware…
Unfortunately the sampling hardware is flakey and non-functional on any PCs I have access to at the moment (it's highly dependent on USB host hardware). I'll have another go at getting something useful out of it, though. I'm always on the lookout for alternative low-cost capture devices, and may end up building my own (despite my incredibly limited knowledge of electronics).
It would be helpful if you sent me a MIDI file with the sysex and other messages that you want recorded, in case I get the device working. I also have a lot of code to analyse the analogue audio, so if you give an explanation of what you want to know I'll try to get you the information.
Sadly, but it seems that nobody else is willing / able to help with detailed analysis of hardware behavior.
There are lots of great people willing and able to help on the hardware analysis side.
Thanks to various people such as Lord Nightmare and The Guru, we have a multitude of ROM dumps and schematics. Thanks to the incredible clean-room reverse-engineering of Mok, we now have pretty darn accurate emulation of everything but the LA32 chip and reverb chips. And as I mentioned above, we'll be getting die scans of those "soon". Don't take a lack of responses here to mean that nobody cares. I didn't even know about the fantastic work you've been doing until a forum reader emailed me about it 😀
What it's really needed is build up the model that can be realized in MT-32 hardware. As I understand, KingGuppy isn't succeeded in disassembling the software of the MT-32 microcontrollers. So, I propose to make hypothesis, compare and use the most relevant to what we observe in reality.
Mok provided us with specifications and pseudocode based on disassembly of the MT-32's control ROM. There are a few small gaps in both specifications and implementation, but generally not in areas that are important (e.g. retrieving data FROM the MT-32 via sysex messages).
Barring bugs, all these should be accurate thanks to Mok's disassembly: handling of all MIDI (including sysex) write messages; timbre/part/partial management; time and value parameters for pitch, filter and amplitude envelopes; reverb parameters; mixing parameters and much more I'm forgetting. We've even emulated and documented the bugs and version discrepancies in many cases.
The problem is, the MT-32 does *not* just use a microcontroller. It has a custom ASIC doing its DSP: The famous LA-32 chip. This performs the PCM playback, synthesis, filtering, partial mixing and in some cases timing based on the parameters the microcontroller gives it. That's where our implementation is currently based on educated guesswork and analogue samples. I haven't really been involved in these parts of the code because my DSP-fu is weak and I'm too obsessed with bit-accurate perfection. That's where the die scans will be invaluable, although it sounds like your efforts in these areas will get us very close until then. There's also the BOSS reverb chip, of course.
It's very nice to hear that you enjoyed our work. I didn't really understand reasons why KingGuppy and Canadacow just abandon such a promising project after so huge and hard work they've done in 2009 making current Munt almost perfect.
We really didn't abandon it. I don't regularly visit Vogon forums, and my spam filter suffers from extreme enthusiasm, so did you perhaps try to contact me and I missed it? If you look before the 2009 work there was a long gap there also. We stripped out many of the optimisations (lots of LUTs and multiplatform SIMD code) in order to focus on accuracy, and the emulator became (as expected) too CPU intensive to push out as a new release. Personally, I've been waiting for the die scans in order to get 100% accuracy before heavily optimising, but I do have some changes lying around to improve performance a bit. These aren't in areas you've been working on, so you can easily benefit from them if you keep the fork - I'll try to commit them soon ("soon" in my world means "within a month or so"). I also have some changes to pulse width parameters, if I remember correctly, so you can have a more accurate parameter to apply guesswork to 😀
Again, we'd love to have you (and any other Munt Reloaded developers) on the original Munt team. Your skills and enthusiasm are exactly what we need, and I personally don't think a fork is good for such a specialist project. But again, it's up to you. I would ask - if you keep the fork - that you prevent conflicts with the static library name/include directory, though, and generally try to prevent confusion between the projects.
Regards,
KingGuppy
P.S.: In tvp.cpp, you changed this line:
basePitch += 37133; // 33037;
I can confirm that based on the ROM, 33037 is indeed the correct value. That might give you a hint about the way the sawtooth generation works...
Hi! I don't even expect hearing from you, KingGuppy, as my first (and my bad the single) attempt to join as a MUNT developer was failed approx. a month ago. And, of course, I'd be happy to do this. The "fork" (more accurate to say "a long waited release") was made as a simple way to share it with minimum effort e.g. by searching on sf.net "MUNT" etc... So, if we share the same approach to emulation, we can transform "Reloading" into MUNT release (or if you more like it "pre-release"). As I mention above, it is not only my opinion that the project was stopped for a long time... 🙁
But as a newbie to the project, I strongly feel a lack of information you'd make available to any project reader. Studying the sources gives almost no information about the device design but only on accepted choices and realized algorithms. For example, I do not know why the BLIT algorithm was preferred over the others for bandlimited WG, why Canadacow hardly attacks filter emulation with IIR but not using another filtering technique, etc. This can only be seen from project documentation, but alas, I've never found such a chapter on almost every GNU/GPL/OSS project (except maybe FreeBSD) Thus, the sources are available, but they still are the "code" to the reader ;( The Munt project forum is a pity as well 🙁(( Even feature request are not answered for a long time... 8( Please, get me right on my impression of all this...
As for my attempts in improving the sound accuracy I must say that I'm trying to analyze the hardware without the MT-32 itself, its schematic, even the microcontroller type I discovered only in your post on the forum and the WiKi. I'm simply trying to redesign the device if I would do this in 1987 in order to understand how it works to emulate it properly... As I've posted, the microcontroller isn't capable to do mixing, so there is a need in some sort of hardware acceleration (FPGA, or programmable logic, or else). I didn't know of the LA-32 chip but it is strongly needed. And I still believe the LA-32 chip isn't capable to do real-time filtering for every sample, just optionally looped playback of samples with varied pitches and amp, perhaps using more than linear sample interpolation to achieve the superior quality of playback. Maybe if there was a number of those chips...
As for that change in tvp.cpp, maybe you've noticed that I replace the BLIT WG with my own designed. It just takes care of the doubling frequency for sawtooth waves by itself. If the correct value is 33037 then I must change that frequency correction in opposite...
So, if the Munt team is ready to overlook the concept of emulation in order to get closest to the real hardware behavior, there is definitely no need in any forking of the project. I'll just resend a request to become Munt developer... What you think?
P.S. KingGuppy, I do compile MUNT Reloaded releases with VS2008 Express. I've installed WinDDK and grab 2 more files for dmusic (dmplugin.h & dmusici.h) it lacks. Also I updated the project files accordingly.
P.P.S. I'll simply remove my project as soon as you can grand me membership in MUNT. Perhaps I could do release engineering and write some project docs as well.
wrote:Sorry if this is off-topic, but I think you mentioned that you don't currently have a physical MT-32 module. […]
Sorry if this is off-topic, but I think you mentioned that you don't currently have a physical MT-32 module.
There's an auction right now on eBay offering one:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem … em=250783976543That ships internationally, if you are interested.
Regards.
Thanks, Leolo, but I'm afraid this is too late to make a use of it. The development is already in such a stage that it's low or none point of playing with analogue sampling. And I doubt I can afford digital sampling equipment to work with.
Yesterday, KingGuppy was so kind and made me a member of MUNT project. Many of my proposed changes are going to be committed into the MUNT or at least in a separate branch. So, development of Munt Reloaded will surely be closed.
I'm sure the upcoming release of MUNT will be appreciated.
I told you this would be the better way 😉
Good luck and please keep us posted...
wrote:I told you this would be the better way 😉
Good luck and please keep us posted...
Of course, if KingGuppy didn't get lost for such a long time without any sign, I'd surely be more persistant
Please keep us posted with the progress you make.
wrote:Please keep us posted with the progress you make.
Corrected wrong sounding of SynBrasses in Police Quest 2 intro theme reported by Ykhwong. There was incorrect handling of pulsewidth parameter for sawtooth waves. Those SynBrasses sounds 1 octave upper then needed.
BTW, the current sources are moved to GitHub and can be found at:
https://github.com/munt/munt/tree/munt_reloaded_import
wrote:Corrected wrong sounding of SynBrasses in Police Quest 2 intro theme reported by Ykhwong. There was incorrect handling of pulsewidth parameter for sawtooth waves. Those SynBrasses sounds 1 octave upper then needed.
BTW, the current sources are moved to GitHub and can be found at:
https://github.com/munt/munt/tree/munt_reloaded_import
Thanks, sergm. You did a great job. 😀
But alas, partial volume now is an issue again. Normalization needs to be turned on. Basically, this is misleading way indeed. Now, we discuss several new approaches to wave generation, but this is another story...
Excellent, thanks 😀
These are tiny changes customized for DOSBox, reflecting the recent modifications from sergm's munt-reloaded git branch:
- Set sample rate to 32000 as default - sergm recommended for the best tune. (midi_mt32.h)
- In order to remove intermittent noises in some games, delayreverb is used instead of freeverb. (partial.cpp)
- Set stereo volume to higher in "bool Partial::produceOutput()", providing higher volume without introducing crackles. (partial.cpp)
- Set MT32EMU_MAX_POLY to 128 (just a test case)
Dominus, the birds chirping seems to be correct now in the intro of Ultima 7.
wrote:But alas, partial volume now is an issue again. Normalization needs to be turned on. Basically, this is misleading way indeed. Now, we discuss several new approaches to wave generation, but this is another story...
Found the cause. Filter was set to a half-frequency for sawtooth and thus attenuated almost all the sound. But it's still incorrect I suppose. Still lack of information. D-50 User Guide is "precious" about that 🙁((
I hope, KG will throw at me tons of samples this weekend...
I've made a CLR version of my mt32emu_win32app just for fun... Its cool features include the possibility for on-the-fly parameter applying (such as samplerate and latency). And the master volume can be changed with a gain factor up to 10 😉
Thought I could capture some digital data, but it turns out this Rev 00 MT32 produces 15-bit data at ~123KHz (3x sample&hold x2 channels) which is a bit much for the parallel port...
1+1=10
