collector wrote:

sergm wrote:

And who likes? 😀

Many do, but that still does not address the problem of the installer.

Well, then it'll be great to hear exactly what a problem you have encountered 😀
Though, it's not an installer, just a driver copying & registration tooly.

When you try to run it, Windows gives you the message that it probably did not properly install. I do not have UAC enabled, but would imagine that there may be further issues with it enabled. This is the same thing that happens with some older installers in Win7.

UAC _is_ supported, don't worry. But the message you mentioned relates to the fact the installer doesn't register any packages in the system registry. You can read about it more in the win 7 app compatibility help page. At least, I didn't find the installer performs any badly regardless of the message.

*UPD:* In fact, renaming drvsetup to any other name not containing setup / install (e.g. drvreg) makes Win7 compatibility happy.

<flame>
In reality, I've never find that compatibility helper any useful, but annoying. Most of the *real* compatibility problems are solved by:
1. Turning off UAC - most common 😀
2. setting correct permissions on files / registry entries
3. Using virtualization

That's why I love Win7 😀
</flame>

For me the installer worked perfectly in my win7 box (32bit). with UAC enabled.

sergm wrote:

<flame>
In reality, I've never find that compatibility helper any useful, but annoying. </flame>

I agree wholeheartedly. In fact, one of the first things I do to all my Win7 computers is typing this in the command line:

1sc stop "PcaSvc"
2sc stop "AeLookupSvc"
3sc config "PcaSvc" start= disabled
4sc config "AeLookupSvc" start= disabled

No more annoying and useless prompts!

PS: I have yet to find a compatibility problem that is solved by the darned assistant. Out of the about two dozen times I've seen it popup in my life, it has solved ZERO compatibility problems. That's for me an efficacy of exactly 0%.

Maybe other people have more luck, but for me is utterly and completely useless!

Does mt32emu work on windows 7 64bit SP1?
I copied mt32emu.dll, *.ROM, SDL.DLL, and SDL_net.DLL to c:\windows\system32.
I added my registry [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32] with MIDI3=mt32emu.dll.

So I can select MT-32 Synth Emulator in MIDI Mapper. (Putzlowitschs)
But if I run 'rundll32.exe mt32emu.dll, DllRegisterServer', I got a message like 'Errors in mt32emu.dll DllRegisterServer'.
And there is no mt32 driver in the device manager.

Did I miss something? Please, help!

Things are changing. mt32emu.dll included in current builds isn't a DMusic synth anymore, so it can't be registered using rundll32 and DllRegisterServer. It's still a Win32 app, therefore it can't be properly installed using .INF file on x64 system. And perhaps there's no need to register the driver in device manager manually since it'll be a part of driver + GUI app suit which will has corresponding entry in Add/Remove app wizard.
So, after you added the "MIDI3" entry to the system registry, it should begin working. Though, SDL.* files aren't need and the proper folder for all the files should be syswow64 instead (but if you used win32 file manager for copying, you actually placed the files right. win32 compatibility layer did the trick).
I also recommend using mt32emu.ini (place it to windows dir) file for tunings and specifying another path to ROM files.

Added CoreMidi support. I expect we'll need dedicated CoreAudio module as well since PortAudio sucks calculating proper timings on every platform I tested it and very likely will fail on Mac. 🙁 On the other hand, CoreAudio should give us excellent timing (at least the docs promise that).

Well, actually the path of ROM files was a problem.
(I copied *.ROM to '\Windows\SYSWOW64'.)

Thank you, Sergm!

While listening to this song through Munt, I noticed that the bass didn't sound quite the same as it does in the reference recording. I hope that can be fixed.

Quick update: Qt-based synth app uploaded (@ https://github.com/downloads/sergm/munt_devel … _2012-02-21.zip) with the fresh win32 driver. In the improvements list:

- support for platforms: Win, *nix (ALSA and OSS4, partially OSS3) and Mac
- UI improvements (menu, better configuration)
- multisession support for all the platforms we currently handle
- on Windows, almost sample-accurate synthesis, on others - it depends...
- some bugs fixed & added 😀

Tested on WinXP, Win7-x64, Ubuntu 11.10, Fedora 16-x64, FreeBSD 8.2 & 9.0 and Snow Leo (still needs more comprehensive testing).

Even on FreeBSD (famous for its scarce MIDI support), I get vanilla DOSBox working just using a FIFO symlinked to /dev/sequencer, i.e. almost out of the box, with the help of partial OSS3 MIDI support. 😀 I also adopted the DOSBox's OSS MIDI driver to support OSS4 MIDI ports (basically by throwing out excessive code).

Thanks for this amazing product. I just compiled Qt version for Mac, using Mac OSX 10.6.8.

If I run mt32emu-qt, everything seem to work, the UI comes up, I can select ROMs and stuff. If I select "Tools->Test Midi Driver" I will see the lcd of MT-32 and numbers scrolling in the console window, but I don't hear any sound. Should I hear something?

I can do some additional testing on Mac OSX as time permits, if needed. I also have a genuine MT-32.

It's great to hear you're able to help with testing on the Mac platform.
Though, this app isn't a product quality yet, I believe it'll become a product soon (maybe this year) 😎 Anyway, I'd like to know how it performs for you.
If it comes to be related to the UI app, I suggest to move the discussion to another thread (I suppose this one is for core mt32emu synth issues).
mt32emu-Qt cross-platform UI-enabled application development

Hi!

I've been following the development of Munt for a very long time now, and there's one thing I'm curious about, namely multithreading or parallelization. Would it be possible to parallelize Munt, either with say OpenMP or even Cuda/OpenCL? I've looked at the code, and I guess the main function to parallelize is Partial::generateSamples.

How feasible do you think it would be to do this?

Oh, an interesting question. Though, I don't think this is the simplest way to add multiprocessing there, this function is the main CPU consumer, actually. Apparently, generateSamples() is quite complicated to split the processing over samples since every next sample is dependent on those TVx functions which are needed to rework in order.
Much easier way is to render several channels in different threads. Both KG and I have had independent solutions for this way but we aren’t rushing to include them. We (or me, at least) don’t see the need to go to multithreading while we haven’t reached the point for starting optimization.
By the way, personally, I felt the strong need of multithreading early in times of hard BLIT synth engine (that’s why mentioned threading channel renderer appeared), but after we reworked the synth algorithm, I feel no more such need. There’s almost no CPU consumption noticed on my “monster” desktop PC even with single threading, and fairly acceptable CPU load on my laptop in maximum power saving mode (constant CPU freq at 800 MHz).
So, I don’t think this is urgent for now. It’s likely to be crucial for multicore and slow CPUs, though, I don’t know such even in smartphones. 😀

Yeah, did some profiling, and most of the code is spent in generateSamples and LA32 ramps. I'm guessing branching is also a pretty big performance eater too, as my 1.5 Gig eeepc grinds to a halt very quickly, even with 22050 Hz sampling rate.

I actually had this idea to put Munt on a smartphone, and just plug it to a computer and voila, instant MT-32 device, display and everything 😀 Of course, after some more investigation, I found out that OpenCL has very limited support on desktops, and practically none on embedded devices. Too bad, would've been a very cool project...

Btw, has anyone tried to port Munt to say Android?

It shouldn't halt even on 800 MHz CPU. I suppose, you set all possible optimization options on. Note, that CMake generates MakeFiles and project files with no optimization by default. You should set CMAKE_BUILD_TYPE:STRING=Release or similar to get best possible performance optimization out of your compiler.

Another thing concerning the performance is the speed of math functions. We use exponents havily there, so we have an option in mt32emu.h MT32EMU_ACCURATE_WG enabling the use of LUTs if you have brakes in maths. Though, the output accuracy is slightly degraded, it can be closer to the real thing since the h/w modules are known to use LUTs. To get maximum performance, I suggest setting MT32EMU_ACCURATE_WG to 0, though I have been reported that one Mac performs better with the default setting (perhaps due to cache poisoning or whatever, current LUTs implementation intended for recent CPUs and suboptimal in terms of size).

I hope this notes will help.

Heh, I'm not really familiar with CMake, and it seems I didn't properly set the optimizations when I first compiled 😦 . I can actually play MT-32 music on my eee now, though there are still lags (but it's something I've come to expect from the machine, it's notoriously slow!). So thanks 😀

To further improve output quality, you can also set audio latency higher. And generally, try different audio drivers to find the one that suit best for your configuration.

sergm, I see you're quite active these days on the emulator - that's great.
Can you please explain to a layman like me why you are developing so many different audio drivers (winmm, port, alsa, oss, pulse, qt) and what is the difference between them?