The post on the site with the soundtracks and the comment tag of each music file have written with what version of both DosBox and MUNT they were recorded, so people can actually deduce it's not recorded with real hardware =)
While trying to use SMF2WAV to convert the attached (contrived, yet completely legal) MIDI file, the mysterious error message "Part 1 (Str Sect 2): Ran out of prerender space to abort poly gracefully" is displayed, and half the file is silent/missing.
Well, someone already beat me to it, it looks like, but I thought I'd add a couple of the tracks recorded with a CM-500 in CM-64 mode. Probably not useful any more.
Sorry about greatly delayed response. Had a lot of life happen the last couple weeks.
Still, I now have an MT-32(Old) and CM-500, so if more recordings are needed for comparison, I'll check back here from time-to-time.
I use Munt reloaded but I get always the MT32: Control ROM file not found.
I have putted the two files in the DosBox folder as in the config folder.
The sound sounds way off here.
So is there a solution?
wrote:I use Munt reloaded but I get always the MT32: Control ROM file not found. […]
I use Munt reloaded but I get always the MT32: Control ROM file not found.
I have putted the two files in the DosBox folder as in the config folder.
The sound sounds way off here.
So is there a solution?
Try updating to the latest version. I noticed that it now asks you to browse to the folder containing the ROM files.
I always thought the Reloaded was the Dosbox WITH builtin MT32 support. It seems I was wrong.
But how do I get this gui in the Dosbox to work so that I have the MT32 sound.
Or is there a newer Dosbox woth embedded Drivers?
Munt comes in two flavors:
1. A Windows MIDI driver, downloadable from the sourceforge project site.
Pros:
- Can be used with any program that is able to use Windows MIDI drivers.
- This version is probably your best option for the most up-to-date Munt version, unless you are a developer.
- Latest version has a GUI that asks you where your ROMs are, and which ones to use (e.g. MT-32 versus CM-32).
- Allows you to see MT-32 emulation status (including a simulated LCD) and alter some settings via a GUI.
Cons:
- May be harder to get working in Windows Vista and newer, as you will either need to configure each program to use it, or use a third-party utility to change the default Windows MIDI driver selection.
2. A library.
Pros:
- (developers only) Can be built into programs to provide built-in MT-32 emulation support.
- Generally easy to configure the application to use it (via configuration GUI or configuration file).
Cons:
- A copy of the ROMs must generally reside in the same folder (or a subfolder) of each program that uses them.
- The programs that use the library may not provide access to a GUI for monitoring or configuring MT-32 emulation status.
I've been doing #1 lately because projects using #2 don't generally pull the latest library source into their projects as often as the Munt team has been releasing driver updates.
If you want to do #2 for DOSBox anyways, I would suggest Ykhwong's excellent "DOSBox Daum Cafe" enhanced SVN build of DOSBox. He patches in the library flavor of Munt.
wrote:If you want to do #2 for DOSBox anyways, I would suggest Ykhwong's excellent "DOSBox Daum Cafe" enhanced SVN build of DOSBox. He patches in the library flavor of Munt.
+1
Oh, and for #2, you need to put the ROMs in whatever folder you install it to. If you name the ROMs correctly, it will automatically use whichever set it finds (MT-32 or CM-32).
wrote:I've found an instrument that plays incorrectly on 'Inferno - Planet 2' by Barry Leitch - the instrument in question pops up on channel 5 as a very short solo near the beginning and plays on channel 8 near half way.
MIDI file: http://la32.co.uk/music/midi/Inferno/planet_2.mid
CM-32L recording: http://la32.co.uk/music/midi/10%20Planet%202.flac
Hopefully fixed. The same patch btw is the distortion guitar in TFX. Updating the DP build...
wrote:Munt comes in two flavors: […]
Munt comes in two flavors:
2. A library.
Cons:
- A copy of the ROMs must generally reside in the same folder (or a subfolder) of each program that uses them.
To save space, you can use hardlinks
wrote:I've been doing #1 lately because projects using #2 don't generally pull the latest library source into their projects as often as the Munt team has been releasing driver updates.
Mine usually includes the latest code within days.
wrote:wrote:Munt comes in two flavors: […]
Munt comes in two flavors:
2. A library.
Cons:
- A copy of the ROMs must generally reside in the same folder (or a subfolder) of each program that uses them.To save space, you can use hardlinks
Sorry about it. Added mt32.romdir option to the "official" DOSBox patch. 😎
Yeah, I noticed that, thanks 😉
wrote:While trying to use SMF2WAV to convert the attached (contrived, yet completely legal) MIDI file, the mysterious error message "Part 1 (Str Sect 2): Ran out of prerender space to abort poly gracefully" is displayed, and half the file is silent/missing.
Prerenderer nuked, no more stupid messages is thrown. But the length of the resulting file remains. That sucks... Although, I see no problem with mt32emu_qt MIDI->Wav conversion. Looks like a bug in the libsmf... Basically, I don't encourage anyone to use SMF2WAV anymore as the new GUI seems more convenient for everyday use though some maybe-useful options are missing. Not a big deal as I personally always (except it is required not to) post-process the resulting wave anyway.
I figured it must be libsmf, because I have since found that when I convert to type 0 (single-track) MIDI file, the problem disappears. I prefer smf2wav to GUI though for batch-processing, converting 200 standard MIDI files or so with one click on a batch file. 😀
wrote:I figured it must be libsmf, because I have since found that when I convert to type 0 (single-track) MIDI file, the problem disappears. I prefer smf2wav to GUI though for batch-processing, converting 200 standard MIDI files or so with one click on a batch file. 😀
GUI also has command line arguments 😉
Looks like v1.0.3 was officially released on sourceforge.
Edit: Oops, 1.3.0.
wrote:Looks like v1.0.3 was officially released on sourceforge.
It's 1.3.0 actually...
Hmm, really wanted to add Linux packages. Tried rpm generated by CPack. It looks horrible though works. As I understand, the best option remains is when the packages are maintained for dedicated distros / OSes by some of their users 😒
I would've loved to make deb packages if I were able to use CrunchBang, but right now I have no possibility of using it so I'm stuck with the crummy Windows =(
SCO seems wanted to maintain packages for Ubuntu but they're dated now 😒
