Reply 860 of 965, by sergm
No, you're just missing something 😀
https://github.com/munt/munt/commit/e63345a99 … 942493d1208af2a
No, you're just missing something 😀
https://github.com/munt/munt/commit/e63345a99 … 942493d1208af2a
343 + if (synth->controlROMFeatures->quirkPanMult) { 344 + // MT-32: Divide by 9 345 + patchTemp->panpot = Bit8u(midiPan […]
343 + if (synth->controlROMFeatures->quirkPanMult) {
344 + // MT-32: Divide by 9
345 + patchTemp->panpot = Bit8u(midiPan / 9);
346 + } else {
347 + // CM-32L: Divide by 8.5
348 + patchTemp->panpot = Bit8u((midiPan << 3) / 68);
349 + }
What does this reference? 😀
I only found one possible issue:
The "HIT BOTTOM" instrument generally sounds right, but a real MT-32 starts with a crackle while MUNT doesn't. But that's probably too esoteric and unimportant to emulate. There's also the "ELEC SHOCK" instrument which has the same issue as Swamp Background, but we already talked about this. Is the hard-to-emulate LFO part of the MCU or part of the LA32 chip?
Otherwise, great work, and I'm looking forward to a regular release.
wrote:The "HIT BOTTOM" instrument generally sounds right, but a real MT-32 starts with a crackle while MUNT doesn't. But that's probably too esoteric and unimportant to emulate.
I'll see if this issue is really unimportant. It could suddenly be an indication of a horrible bug not yet noticed. Anyway, thanks a lot for your contribution!
Is the hard-to-emulate LFO part of the MCU or part of the LA32 chip?
Unfortunately, all the pitch-related stuff is solely controlled by MCU (as well as all the quirks of old MT-32 as we can see now). I tried to look closely at the pitch diagram of SwmpBackgr with no luck, though, I won't not say I stopped at that. 😉
I tried the latest test build and I must say that, Wow, am I impressed! My wedge-shaped MT-32 is taking up a lot of space where it could be adding a fair bit to my wallet. "Just kidding"
I believe that the audibility of SwmpBackgr is tied to the animation speed. When the animation speed is set to its fastest, the effect may be inaudible. It sounds as good as it gets with the default animation speed.
http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog
An update is available at https://sourceforge.net/projects/munt/files/munt/SNAPSHOTS/.
I think the topic about emulation of old MT-32 is closed now, isn't it? 😀
wrote:An update is available at https://sourceforge.net/projects/munt/files/munt/SNAPSHOTS/.
I think the topic about emulation of old MT-32 is closed now, isn't it? 😀
I suppose it is. Now comes the Roland SC-55 emulation, right? 😵
Even though SwmpBkgr may not be ideal to the old MT-32, it is far better than the new MT-32s and CM units, which output a nearly constant high pitched noise.
http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog
wrote:Now comes the Roland SC-55 emulation, right?
Most probably D-50 😜
I'll see if there is a chance to speedup MCU emulator, so it won't take up all the available CPUs as it does now *sigh*
Yes, if the LFO problem is unsolvable, then the old MT-32 emulation is otherwise complete. I think that for games, Roland CM-32P/CM-64 emulation would be more useful than D-50 emulation.
I still have a few ideas for additional optional features, but I guess I better shut up now because you've already done more than enough for me 😉
Heh, D-50 is useless for games, I think 🤣
Well, I'm looking at CM-64 on my table...
It appears not too hard to make SwmpBackgr sound quite good.
NewRisingSun
Snap 😉
That was a bit strange, actually. From what I know, amp and filter are always accurately ramped except some rare cases like partial termination.
On the other hand, reverb level is not ramped in munt by any means, and I suspect the real units behave similarly.
885 still clicks even when I set reverb to 0 0 0 (in 885a.mid).
Then it is even more interesting. I certainly wish to sort it out.
Well, the MIDI is a bit nasty.
I'm not 100% sure but it very much looks like the ramp gets broken when the volume changes in a direction opposite to the currently performing ramp. Here's what KingGuppy says about the ramping:
If the MSb (of "increment") is set:
- If "current" already corresponds to a value <= "target", "current" is set immediately to the equivalent of "target" and an interrupt is raised.
- Otherwise, "current" is gradually reduced (at a rate determined by the lower 7 bits of "increment"), and once it reaches the equivalent of "target" an interrupt is raised.
Otherwise (the MSb is unset):
- If "current" already corresponds to a value >= "target", "current" is set immediately to the equivalent of "target" and an interrupt is raised.
- Otherwise, "current" is gradually increased (at a rate determined by the lower 7 bits of "increment"), and once it reaches the equivalent of "target" an interrupt is raised.
There is no sense in setting volume bit-by-bit back and forth like that. You can set volume to 100, then lower it to 30, wait for the ramp to complete and then rise to 100, for example. I think we can opt to always ramp and never jump regardless of the direction, though.
OK, I think there is a bug in TVA implementation. When a partial is in sustain phase, and its amp target is updated due to volume/expression change, the ramp is assumed to be complete. However, it is far from being true (as 885.MID evidently shows). Instead of starting a new ramp blindly, MCU should check whether another ramp is in progress. It may only start a new ramp if that is safe (i.e. it would continue in the same direction). If not, either it should wait for the interrupt or re-start the current ramp with the maximum ramp speed, and then start a new one.
In our case, we can directly read the current ramp value and start a new ramp in correct direction, no problem. I also think that this behaviour should prevail over the accurate emulation likewise we set NICE DAC emulation mode by default.
I see you have updated the snapshot without telling anyone. You're sneaky. 😀 Sounds great.
🤣
It's hard to be sneaky updating files at SF.net
I assume you hate RSS and email subscriptions they offer, don't you? I do 😉
New munt release rolled out!
wrote:New munt release rolled out!
For the lazy:
Notable changes since 2.1.0: […]
Notable changes since 2.1.0:
mt32emu
=======* Added emulation of a number of MT-32 GEN0 quirks that is enabled when loading e.g. Control ROM v1.07,
so many patches specific for old MT-32 are now played correctly. Thanks go to NewRisingSun for providing
the test set of those patches. See Re: Munt Reloaded - Development for more details.
* Fixed sample format conversion implementation, so that integer samples are converted to normalised
float samples as well as float samples are still converted to full-range integer ones.
LA32FloatWaveGenerator now produces output at 0.25 volume that corresponds to the fact that each partial
in LA32 uses only 14-bit samples. Still, no clamping is applied in DACInputMode_NICE mode for floats,
so the output samples may overshoot a little for tunes with the volume set too high.
* Introduced "Nice Amp Ramp" mode intended to improve emulation of amplitude ramp in sustain phase.
Quick changes of volume or expression on a MIDI channel may result in amp jumps on real hardware.
When "Nice Amp Ramp" mode is enabled (default), amp changes gradually instead. Otherwise,
the emulation accuracy is preserved.mt32emu_qt
==========* Updated mt32emu library to version 2.2.0.
* Improved a bit the LCD emulation to better match behaviour of old MT-32 units.
* Improved synth profile handling. When a non-default synth profile is selected in the synth properties dialog,
it is now used during synth re-opening (provided that it is pinned or an active MIDI session persists).
* Added support for SysEx fragments in standard MIDI files played using the internal MIDI player.
* Added option "Nice Amp Ramp" in the Synth Properties dialog.
* Various improvements in "MIDI Player" and "Standard MIDI file converter" dialogs.mt32emu_win32drv
================* Updated mt32emu library to version 2.2.0.
* Added support for the synth profile setting "niceAmpRamp".
* Implemented selection of output audio device using the setting "DefaultAudioDevice".
Note, that audio devices listed for WinMMAudio API (a.k.a. "waveout") are only guaranteed
to have identical device names and to be engaged. Other audio deivces for other audio APIs
may provide slightly different device names. In such a case (or if the selected device
is no longer available), the default wave mapper is used.