VOGONS


Munt Reloaded - Development

Topic actions

Reply 861 of 965, by Spikey

User metadata
Rank Oldbie
Rank
Oldbie
343 + if (synth->controlROMFeatures->quirkPanMult) { 344 + // MT-32: Divide by 9 345 + patchTemp->panpot = Bit8u(midiPan […]
Show full quote

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? 😀

Reply 862 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments

  • Filename
    lsl3_12.zip
    File size
    3.06 KiB
    Downloads
    60 downloads
    File license
    Fair use/fair dealing exception

Reply 863 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun 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. 😉

Reply 864 of 965, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

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

Reply 866 of 965, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
sergm 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

Reply 867 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Great Hierophant 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*

Reply 868 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

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 😉

Reply 870 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

It appears not too hard to make SwmpBackgr sound quite good.

Attachments

  • Filename
    SwmpBackgr.zip
    File size
    752.28 KiB
    Downloads
    63 downloads
    File comment
    This is how it sounds in munt :P
    File license
    Fair use/fair dealing exception

Reply 871 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 872 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

885 still clicks even when I set reverb to 0 0 0 (in 885a.mid).

Attachments

  • Filename
    885a.zip
    File size
    27.31 KiB
    Downloads
    53 downloads
    File license
    Fair use/fair dealing exception

Reply 874 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 875 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 879 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
sergm wrote:

New munt release rolled out!

For the lazy:

Notable changes since 2.1.0: […]
Show full quote

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.