Absolument.

I see no reason why the Windows driver control panel cannot use .NET. It's been out 3 years and doesn't make your machine 'unstable' after installation or when running .NET applications.

I've been developing .NET applications for almost 3 years now and it's a major productivity step forward when compared to the lash-it-up quick langauge of VB and 'cut grass with a pair of scissors' VC++. VS.NET 2005 with .NET 2 is a huge step again with lots of cool stuff for developers (shame some of this was missing from previous releases!).

Hi,

.NET is not without disadvantages. The easier development comes at a cost:

http://www.sysinternals.com/blog/2005/04/comi … -im-scared.html

http://www.sysinternals.com/blog/2005/04/net- … -follow-up.html

Cheers.

I have the utmost respect for Mark from SysInternals. I do beleive however he had make a small mistake in his comparison of Notepad written in .NET vs. Notepad as supplied by the operating system.

The one supplied by the OS was written in C and is therefore the lightest all languages out there. C++ would have been probably been slightly heavier (only down to the MS C++ library), VB would have been larger still and yes one produced in a .NET langauge the largest of all. However .NET is Microsoft's answer to Java and to a lesser extent its own VB6 development evironment. It is *not* an answer to 'real' Windows development tools and langauges (C/C++) (well, not just yet anyway!).

I've no idea how resource 'hungry' a Java version of Notepad would be. Perhaps as big as VB but maybe not as big as a .NET version? I don't know but I do know what would look and work a lot better out of those three choices!

Agreed the platform requirements for a .NET application is a significant increase on that of any previous environment. However .NET is loaded and JIT'd on demand so no resources are used unless something loads the application. You simply don't have a bunch of resources being wasted with the .NET Framework 'running in the background' - it just doesn't. There are different rules about memory management (yes, you *still* have to take care of it yourself) so the hype about a .NET app never 'leaking' was rubbish. Bad object lifetime management can cause significant memory overhead as can bad usage of a simple object like a string. The biggest 'problem' is developers not understanding exactly how the garbage collector is helping and also *not* helping them!

If a developer decided to provide something as a .NET application as it was easier for them to do so, it would probably mean two things 1) it would actually get finshed/released as it was planned and 2) the end product would most likely have richer/better functionality and especially the UI than it would have been with a language such as C++.

Anyways I do accept that it's not the tool for everything. It would seem 'ideal' for the driver control panel given we're all after a rich easy to use UI sometime in the next 'x' months 😀

Here is another comparison between the latest MUNT CVS and real MT-32 from Legend of Kyrandia.

Not sure what CVS you are using, but my build is current with the CVS and MUNT sounds almost nothing like what you produced. Attached is what a build from the CVS should sound like. Minus some overdriving clicking (which I didn't notice before) and some lacking reverb, it sounds almost identical to the real thing.

We're really way overdue for a release.

Crap. MP3 encoder isn't cooperating today. I'll post an new Mp3 when I get more time. Oh I wish I had time.

Aha! Time!!!

How strange. I'm using the one HunterZ posted and I have all the MT-32 files in the directory.

I'll try to dig out a copy of the game and test it out in the next couple of days to see what I get.

Marauder: You might try deleting your waveform cache files that Munt generates the first time you run DOSBox with a given MT-32 sampling rate. I've had things sound weird like that too for some reason, and I *think* deleting the cache file helps.

Hi, since I've already posted this in the wrong thread, I'll post again here 😀
Could someone update these patches for current CVS of both Dosbox and Munt?

Why don't you use the standalone driver version instead? That way, you will never have to use a self-patched DOSBox again.

I mostly wanted to be able to build newest versions whenever development might pick up again. But I'll try the driver 😀

Moe, I would agree except for two reasons:
- The standalone driver is Windows-only, while the patch allows MT-32 emulation on any platform supported by DOSBox
- The standalone driver is more out of date than the Munt CVS

ykhwong's dosbox cvs always contains mt32 emulation. I wonder whether he uses the latest munt cvs in it.

Probably. Munt CVS hasn't changed for quite some time as far as I know.

Moe, I would agree except for two reasons:
- The standalone driver is Windows-only, while the patch allows MT-32 emulation on any platform supported by DOSBox
- The standalone driver is more out of date than the Munt CVS

Now that I tried the driver I'm pretty sure about a third reason:
starting up Dosbox takes about ages to with this driver installed 🙁

are you sure? i think it takes ages only the first time when dosbox prepares waveformcache .raw files.

The driver uses libmt32, which is by definition always the latest munt available, and it is also available on Linux. OSX users are currently hosed, but I guess it won't be too difficult to start out with one of the two available drivers and use them to write an OSX-specific driver.

The waveform-cache is recreated every time if (and only if) munt can't write to the directory containing the ROMs.

The waveform-cache is recreated every time if (and only if) munt can't write to the directory containing the ROMs.

Ah, I see, as a security minded person I'm running Windows as normal user and not as Administrator. So no write access to the system32 dir (where the roms get installed to).
Something that might be good to mention in the docs.
If I run any midi with the Munt driver as Admin it should work, then. Thanks for bringing that to attention for me.

i think placing it in a doc is not a good solution.
I think munt should install itself into it's own folder and keep it's files in it.
Dosbox with inbuilt mt32 emulator keeps all the mt files in dosbox folder so there are no problems with it even if you are not an administrator.