Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_midi and MUNT issue (Read 3441 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_midi and MUNT issue

I guess it's a question to kode54 

It sounds wrong compared to MUNT in DOSBox-SVN-Daum or the commandline encoder here.

I have all the needed ROMs ant the path is set up correctly.

MIDI file for comparison is here.




Any clues?

foo_midi and MUNT issue

Reply #1 –
Your MIDI file does not contain any MT-32 System Exclusive messages. There is the problem right there.

My version of MUNT is modified with enhancements. In enhanced mode, it supports playing back up to 256 voices worth of polyphony, and mapping a virtual set of extended channels to the 7 MIDI channels not already mapped to normal MT-32 channels.

Any MIDI file detected as a particular system type by its System Exclusive messages will display a $info(midi_type) variable, visible in the Properties tab of the file's Properties dialog as MIDI_TYPE. In the case of MT-32 files, detected by one or more MT-32 System Exclusive messages, this variable will be set to "MT-32".

foo_midi will automatically use MUNT in basic 9 channel 32 polyphony mode if a file has midi_type = "MT-32", regardless of whatever MIDI output mode you have set in preferences. So you don't need to select MUNT specifically if you're playing any MT-32 files. It's enough to add a MT-32 reset message at the start of the file, and/or insert any requisite SYX dump's messages.

If you play MIDI files which are not detected as MT-32 with MUNT selected as the driver, it will initialize MUNT in the 16 channel extended mode, and pre-upload a General MIDI emulation instrument set. I designed this specifically for supporting a retro feel with normal MIDI files, as well as also providing a GM mode which requires a minimal amount of download and disk space.

So, for future reference, any MT-32 MIDI files you wish to play with foo_midi should have the bare minimum of an MT-32 reset message at the start, and you won't need to select MUNT as the MIDI synthesizer for it to be able to play them.

EDIT: I have added a notice about this to the components information page for foo_midi.

foo_midi and MUNT issue

Reply #2 –
Quote from: kode54 link=msg=0 date=
foo_midi will automatically use MUNT in basic 9 channel 32 polyphony mode if a file has midi_type = "MT-32", regardless of whatever MIDI output mode you have set in preferences. So you don't need to select MUNT specifically if you're playing any MT-32 files. It's enough to add a MT-32 reset message at the start of the file, and/or insert any requisite SYX dump's messages.

Thanks, it wasn't obvious.

As I've got it the problem was that those midi files were written especially for MT-32, though in GM format  . Only your version of MUNT played it differently so it was confusing.

Now I'll get a bunch of proper MT-32 midis to test.

foo_midi and MUNT issue

Reply #3 –
You can easily fix those MIDI files. All you need to do is use a MIDI sequence editor to insert a MT-32 reset message. For simplicity, I suggest using mf2t to convert them to text files, then insert the reset command into the first track, then convert back to MIDI. Well, at least that step won't require a complete MIDI sequencer, and it won't mess with the files in any other way than changes you make to the text files.

I have since renamed the MUNT mode in preferences, and added a notice that regular MT-32 emulation will be used automatically on detected files.

EDIT: If you have downloaded mf2tsrc.zip before now, I suggest redownloading it. I have fixed some serious errors in the original code that prevented it from compiling on modern systems, and also broke reading variable length events, such as meta and System Exclusive messages.

Anyway, outlining the process of fixing that file:

1) Convert <file.mid> to text:
Code: [Select]
mf2t file.mid > file.mid.txt


2) Open file.mid.txt in your preferred text editor.

3) Insert an LA Reset message with timestamp 0 after the first MTrk line, maybe after the Tempo command:
Code: [Select]
0 Sysex f0 41 10 16 12 7f 00 00 00 01 f7


4) Save the result.

5) Convert it back over the original MIDI file:
Code: [Select]
t2mf file.mid.txt > file.mid


And you're done.

foo_midi and MUNT issue

Reply #4 –
Thanks for clarification, made myself a sticky with your answer  Will try to convert those bastards to real MT-32.

foo_midi and MUNT issue

Reply #5 –
It would also help for a real MT-32, since then your player won't need to know to reset the device between files. Adding any SYX dumps to the individual files also helps, although if you're going to play them on an actual device, you'll need to bump up the delay before the song starts and add a small delay between each part of the dump. There is no such requirement for MUNT.

foo_midi and MUNT issue

Reply #6 –
Tried many times but still can't compile mf2t (I'm definitely not skilled in this). Downloaded mf2tXP, which works but the midi it produces (with sysex chunk) can't be opened. Could you provide a compiled binary?

foo_midi and MUNT issue

Reply #7 –
Here you go.

The syntax supports output file names as well:

mf2t in.mid out.txt
t2mf in.txt out.mid
 

foo_midi and MUNT issue

Reply #8 –
Thanks, now everything works like it should!