Munt Reloaded - Development

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

Re: Munt Reloaded - Development

Postby sergm » 2017-4-14 @ 17:50

Yesterplay80 wrote:If I disable libmt32emu_SHARED and libmt32emu_C_INTERFACE in CMake, compilation of DOSBox fails with "Incompatible setting MT32EMU_API_TYPE=3".

Right, libmt32emu_C_INTERFACE must be enabled as this is now required by the patch. This
Code: Select all
#define MT32EMU_API_TYPE 0
is certainly not right. MT32Emu::Service is only defined with the other API types.

Yesterplay80 wrote:OK, I managed to build a static library using MSYS2/MINGW64-i686.

Not sure, are you linking the library with DOSBox compiled using another compiler? If so, I think it's always safer to link dynamically.
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-4-14 @ 17:58

I seemingly found an easier way to compile all with MinGW. There is a set of compiler options defined in CMakeLists.txt:
Code: Select all
if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER MATCHES "(^|/)clang\\+\\+$")
  add_definitions(-Wall -Wextra -Wnon-virtual-dtor -Wshadow -Wold-style-cast -ansi -pedantic)
endif()

Stripping out "-ansi" will allow the currently broken MinGW to compile the library successfully.
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-4-15 @ 12:26

NewRisingSun wrote:Here is more evidence of remaining problems with the v1.07 MT-32 ROM using smf2wav x64 from MUNT v2.1.0. The archive contains an initialization sysex and a MIDI file from "The Colonel's Bequest".

Here is how it sounds with CM-32L ROMs (correct). And here is how it sounds with MT-32 v1.07 ROMs. Note the strange low-frequency drone which is not supposed to be there. I don't know whether it's a reverb problem or something pecular to that swamp sound effect timbre.


If I got it right, this is kinda supposed. That static high-pitched noise in background is not how old MT-32 should sound. Well, fairly saying, munt doesn't sound exactly how a real MT-32, though. Anyway, see if this post is related.
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-15 @ 13:51

I suppose we are talking about the SwmpBackgr instrument. MUNT with CM-32L ROMs indeed emulates the new-type MT-32 faithfully, but when using the MT-32 ROMs, MUNT's output does not match any real module.

Here is a recording of the same song that I have just made from a real v1.07-ROM-bearing MT-32 unit. The high-pitched noise is indeed absent. But rather than reproducing the euphonic distortion of the actual module, MUNT with v1.07 MT-32 ROMs produces a low-pitched drone. (And yes, I have tried the integer renderer as well.) Maybe this aspect can be addressed in a future version. :)

And good thing I have not updated MingW yet. I'm planning on switching to MingW-w64, but am postponing it because I cannot be bothered to rebuild all libraries again, and risking trouble when recompiling DOSBox.
NewRisingSun
Oldbie
 
Posts: 727
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby sergm » 2017-4-15 @ 14:11

I really really really hope to get the old MT-32 quirks emulated properly soon. This is a shame that MT-32 emulator does not emulate these... ;)
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-15 @ 17:08

I have got a whole set of .SYX/.MID archives with descriptions that exhibit MT-32-specific differences, that I can upload if that is of any help to you.
NewRisingSun
Oldbie
 
Posts: 727
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby Yesterplay80 » 2017-4-15 @ 17:34

sergm wrote:Stripping out "-ansi" will allow the currently broken MinGW to compile the library successfully.

Thank you very much, this worked perfectly and I was able to compile DOSBox with MT32EMU 2.1.0 succesfully in MinGW! That's great because SDL_sound seems to have problems when compiled with MinGW64.
My full-featured DOSBox SVN builds (without debugger) for Windows and Linux: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 196
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: Munt Reloaded - Development

Postby sergm » 2017-4-21 @ 14:13

NewRisingSun

Oh, that sounds like being definitely helpful!
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-21 @ 23:53

The first archive demonstrates games that are sometimes mentioned as sounding different between MT and CM, but which MUNT (as far as I can hear) emulates correctly when using v1.07 ROMs.

The second archive demonstrates games that MUNT does not seem to emulate correctly even with v1.07 ROMs. They consist of three groups:
1. Wrong pitch: Kick drum in Police Quest II (very audible), Flute-like bird sound in King's Quest 5 (only audible when in direct comparison), scratching sound in The Colonel's Bequest's 2.MID too low pitched.
2. Wrong envelope: Instruments decay too quickly: Guitar in Dune 2 (extremely audible) and Willy Beamish (still audible), "Taiko Cym" in Strike Commander (audible when you know what you're looking for)
3. Other: SpaceAlvin hardly audible in Space Quest 1; Swamp sound effect in The Colonel's Bequest is more of a rumble in 10/13.MID.
NewRisingSun
Oldbie
 
Posts: 727
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby sergm » 2017-4-22 @ 06:11

Thanks a lot! I'll investigate these three issues.

BTW, is there anything known about bugs of e.g. ROM v1.04 which were fixed in v1.07? Are you aware of any of those being abused in some games?
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-22 @ 09:23

Here is the changelog from the MT-32 Service Notes, Second Edition.
Code: Select all
CHANGE INFORMATION (変更情報)

EFF. SN 823200   ROM Program Revision
  IC27 ROM A
  IC26 ROM B   Ver. 1.04 to Ver. 1.05
 
Change the taper of VOLUME control by changing the programs in the ROMs. Result: Smoother volume change in response to VOLUME setting change.

製番823200以降 ROMバージョンアップ ◯Ver. 1.04→Ver. 1.05
マスターボリウムによる音量変化を聴感上自然なものとする。
--
EFF. SN 836200   ROM Program Revision
  IC27 ROM A
  IC26 ROM B   Ver. 1.05 to Ver. 1.06
 
To reset Bender Control change in rhythm section when All Parameter Reset (MIDI) is received or Active Sensing is not recognized.
To not change displays even Display Change exclusive MIDI message is recognized unless the current mode is Master Volume input made (e.g. Power-up default).

製番836200以降 ROMバージョンアップ ◯Ver. 1.05→Ver. 1.06
MIDI機能
オールパラメータリセットまたはアクティブセンスが切れた時リズムパートのコントロールチェンジをリセットするように。
表示変更のエクスクルーシブメッセージを受取ってもマスターボリウム入力モードでない限り表示を変えない。
--
EFF. SN 838700   ROM Program Revision
  IC27 ROM A
  IC26 ROM B   Ver. 1.06 to Ver. 1.07

For stable program operation.
If the program won't start after replacing SRAM IC29 or 31, use ROMs of Ver. 1.07.

製番838700以降 ROMバージョンアップ ◯Ver. 1.06→Ver. 1.07
プログラム安定化のためSRAM IC29 またはIC31交換後にプログラムがスタートしなくなった時は、Ver. 1.07のものと交換して下さい。
--
I have included the Japanese descriptions, as their Google Translations are more intelligible than Roland's own English.

I don't think that any of these changes can be used or abused by games. The VOLUME-related change appears to refer to the volume knob, not the MIDI volume controller 7 or the main volume system exclusive message.
NewRisingSun
Oldbie
 
Posts: 727
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby sergm » 2017-4-22 @ 10:40

NewRisingSun wrote:I don't think that any of these changes can be used or abused by games.

Yeah, especially that change from v1.06 ;)
Anyway, thank you for the useful info.
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby HunterZ » 2017-4-29 @ 21:26

I may have already asked this, but can someone write an idiot's guide to getting Munt (including the Qt GUI app) to build on Windows?

I was thinking of trying to write something that replicates the MT-32 LCD on my Logitech keyboard's LCD, but I couldn't get a combination of MSYS2, CMake, and QT Creator that would actually build Munt for me.

Edit: Eclipse also works for an IDE, but I figured Qt Creator might be easier due to the Qt dependency.
User avatar
HunterZ
l33t++
 
Posts: 6027
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby sergm » 2017-4-30 @ 07:10

Sorry, HunterZ, but I feel too biased to write an idiot's guide ;) Anyway, I'm glad to help otherwise.

First of all, I'd recommend using the whole Qt toolset. It seems nicely bundled comparing to customizing that stuff manually. So, I'd just get Qt from here. This way you get both QtCreator and MinGW 5.3 toolchain that is known to work just fine with munt. The standard installation of Qt should also be perfectly detected by CMake automatically, and the QtCreator should have the toolchain automatically configured upon first launch. So, I hope no special steps are required, except setting
Code: Select all
CMAKE_BUILD_TYPE:STRING=Debug
to be able to do debugging and
Code: Select all
CMAKE_BUILD_TYPE:STRING=Release
for release builds. If you don't want mt32emu_smf2wav and like to avoid bothering with GLib, you may also disable munt_WITH_MT32EMU_SMF2WAV option.
sergm
Oldbie
 
Posts: 646
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby HunterZ » 2017-4-30 @ 13:32

Thanks!

Actually, your suggested approach was what I tried first, but GLib is what killed me. It's also what continues to kill me, as MSYS2 CMake is able to find glib-2.0 via your package finder module, but something ends up building bad paths to it.

I guess I'll try putting MSYS2 aside again and following your instructions to skip mt32emu_smf2wav (which I indeed to not need).

Update: Got mt32emu + mt32emu_qt building in qtcreator! Now I have to figure out how to link in the Logitech .lib library; looks like this may require having qtcreator build via the Microsoft toolchain (ugh).

Update 2: Got it building & running with the MS toolchain via qtcreator, including linking the Logitech .lib. Now to start hacking on mt32emu_qt.
User avatar
HunterZ
l33t++
 
Posts: 6027
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby HunterZ » 2017-5-01 @ 06:00

Update 3: Got it working! Unfortunately I've got to go to bed, but I'll try to post some Youtube videos tomorrow evening. I want to capture (1) the Munt Qt GUI and the Logitech LCD emulator running side-by-side, and (2) the physical G15 v2 keyboard LCD display in action.

Right now it basically just replicates the physical MT-32 LCD + LED. It would be cool to have additional screens to provide the other emulator status from the Qt GUI, with cycling via the keyboard's LCD buttons, but I'm happy to get this far.

P.S. The Logitech LCD API is pretty dumb. It's all globally-scoped free-standing functions. You basically get a 160x43 pixel "background" layer that is sent as a byte-per-pixel (yes, byte, despite being a monochromatic LCD) array of unsigned 8-bit chars, and a "foreground" layer comprised of 4 lines of proportional font text. The background and text layers are independent, such that you have to actually set a text row to an empty string to prevent it from covering up the background, even when you are updating the background. You have to call an update function to commit changes to the physical display, which I guess is nice because it allows you to basically double buffer the output. The only real issue I ran into with all of this is that Munt's LCD and LED widgets update independently, but on the Logitech LCD they share an output buffer (unless I want to make the LED text-based, which I might try).

I'm also not sure how to package the damn thing, since I had to build it with the MSVC toolchain in Qt Creator. There end up being a ton of DLL dependencies, both Microsoft and Qt. I'll try to figure something out if people are interested in playing with it; otherwise I'll probably just put the source on a Munt fork. I did make sure to add this stuff into CMake as an optional feature+dependency.
User avatar
HunterZ
l33t++
 
Posts: 6027
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby Dominus » 2017-5-01 @ 06:42

Cool!
User avatar
Dominus
DOSBox Moderator
 
Posts: 7195
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby HunterZ » 2017-5-02 @ 05:30

Here are a couple of videos:
Side-by-side of mt32emu-qt GUI and Logitech LCD simulator: https://youtu.be/Rb38ZCy6MRc
Cell phone video recording of real Logitech LCD: https://youtu.be/ExRFasoLT7o

I'll get the source and a binary release out tomorrow. Took a long time to figure out what Qt DLLs I needed to include to get everything working right. Munt normally solves this by linking them all in statically, but apparently this is not an option when building with the MSVC toolchain (which I have to use in order to be able to link the Logitech LCD lib) because CMake insists on dynamically linking system libs :dead: The good news is I have fairly high confidence it will run for other people (well, except for Windows XP people), since I did all my recording on a separate machine than I built on.
User avatar
HunterZ
l33t++
 
Posts: 6027
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby HunterZ » 2017-5-03 @ 02:58

Logitech LCD prototype source is up on a fork here: https://github.com/HunterZ/munt/commit/ ... fd4e3bbe66

Do whatever you want with it.

Pre-built binary release is here: https://github.com/HunterZ/munt/release ... gitech-1.0

I should probably try switching back to MinGW now that I've found some potential options for converting the logitech .lib to .a format. I still don't understand why I couldn't get Qt Creator + CMake to link it with the 32-bit MinGW toolchain, as this is supposedly supported by MinGW (maybe CMake or Qt Creator are the problem?).
User avatar
HunterZ
l33t++
 
Posts: 6027
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-5-13 @ 11:24

Hi,
I would like someone to confirm whether this is a bug or an MT-32 feature (not known by me) that Munt emulates properly:
When a program change event happens Munt resets the Pitch Bend Sensitivity RPN (0, 0) to MT-32 default 12. It seems counter-intuitive for me and GM devices definitely do not do this.
I have made a test file :
Mt32_test.zip


The midi file only does the following:
1. Sents a Reset message.
2. Plays a note and changes the pitch (because of reset it uses MT-32 default Pitch Bend Sensitivity 12)
3. Changes Pitch Bend Sensitivity to GM default 2.
4. Plays another note and changes the pitch (so it uses GM default Pitch Bend Sensitivity 2)
5. Changes Program 0 to 1.
4. Plays another note and changes the pitch. I think it should use Pitch Bend Sensitivity 2 but instead it uses the default 12.
MT32_test.jpg


Thanks
You do not have the required permissions to view the files attached to this post.
User avatar
Falcosoft
Member
 
Posts: 255
Joined: 2016-5-21 @ 13:46
Location: Hungary

PreviousNext

Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest