Yes, I've been quite happy with it on my laptop. I should probably also install it on my desktop for the games that sound better on CM-32L than on MT-32.

Anyway, our hardware won't last forever. *sigh* I've already burned one unit. I can still get digital output from it though 😀

I guess digital output is the only thing you are interested in so broken analog is no loss.

I thought it was only KingGuppy who was able to get digital output from his cm-32l. Was that all moved to your place now? And what other units have you got?

sergm wrote:

Anyway, our hardware won't last forever. *sigh* I've already burned one unit. I can still get digital output from it though 😀

What devices do you currently have for testing?

I've got CM-64 and poor RA-50. Unfortunately, RA-50 has the same reverb ROM as the CM units and its LCD is completely different from the MT-32. So, it isn't too precious to me (probably that's why I've burn it in fact 😁 ). But exactly RA-50 was used to analyze the reverb, so it was sacrificed to the science. 😉

@ robertmo

It appears not so horribly complicated to get DAC digital output from the LA unit. Using a basic logic analyzer makes this a piece of cake. But I had no one at home so I just soldered an ATA cable and attached it to my old PIII. As the DAC frequency is low, IDE in the basic PIO mode is enough to grab all the 16 DAC pins. In Windows 98 we had full access to PC resources which is handy to get the DAC output in real time. Though, the time of the capture is limited by the amount of RAM (I have 384 Mb) but it's more than enough for analysis or capturing a single tune.

Getting the reverb RAM addresses is another matter. RAM frequency is high and the IDE sucks in PIO mode. Unfortunately, I had no success in convincing the IDE controller to work in DMA/UDMA modes, the transfer just didn't start regardless of what signals I send to the control pins. Looks like the IDE device is required to strictly perform according the DMA timing diagram with my controller. So, I was stick with PIO and I had to lower the clock frequency. This proves the IDE is the cheapest logic analyzer ever. 😁
But the setup was a bit rushed and poor RA-50 got 😵

On the other hand, the nice features of a logic analyzer are the ease of tapping chip pins and the ability to grab much more pins. Though, such a logic analyzer costs at least as two MT-32. But if you happen to have an access to it, it's not a big problem. balrog has a costly one. Lord_Nightmare attached it to his old MT-32 and dumped all the reverb-related pins. So, we are close now to complete understanding how the Boss chip works.

So, with luck, KingGuppy isn't the only guy in the world who is able to do this. 😜

sergm wrote:

Besides, those guys hanging around on #munt channel @ FreeNode (actually they greatly helped me with the LA32 internals) are targeted not exactly at the MT-32 emulation. 😀

So what is their target?

Various things, like reverberators, guitar synths, etc.

robertmo wrote:

the strange thing is that my mt-32 displays instrment names when playing tfx.mid
though i think they are just the default ones (not reprogrammed ones)

That's because the editor used to create TFX's music does not set instrument names, it simply re-maps the ones in the editor to 1, 2, 3, 4 etc to make it easier for the composer to switch between them. To note, the editor is a tracker and I have an old video of it here. I've also ripped a MIDI file of that track here.

I wonder why tfx midi songs load in Cakewalks (even the latest SONAR X2 Producer) with tempo 100 instead of 120 like in gsplay (mfplay).

Anyway I guess I should be happy it plays mt32 midis at all unlike other sequencer that either play them from: slightly not properly, through completely not properly, silently, crushing whole program, to even crushing whole OS 😉

I think 100 BPM is the default tempo for Cakewalks. All the other MIDI players I've seen have 120 BPM instead (including gsplay and that nasty WMP). When you save a SMF from Cakewalk it adds a tempo metaevent, so it won't trouble you further.

sergm wrote:

I think 100 BPM is the default tempo for Cakewalks. All the other MIDI players I've seen have 120 BPM instead (including gsplay and that nasty WMP).

I think that is not true.
For example when i load dune 2 midi songs it sets tempo 120 in all cakewalks (pro 3, pro audio 9 and sonar).
When I load policequest3 or colonelsbequest mids in gsplay (and mfplay) they are set to 100.
When I load stalker mid (for Sound Canvas) it has tempo 114 in cakewalks and gs/mfplay.

But I still think it is 😀
It seems Dune 2 MIDIs have the tempo metaevent. Look at the Munt's console for reference if you don't like searching for the HEX string. 😉
E.g. when playing "Ambient 01.mid" I can see:
MidiParser: Meta-event: Set tempo: 500000

ok, so SONAR X2 Producer is the only sequencer i know that plays mt32 midis correctly 😀

When testing that tempo i found something:
the xeen_la.mid from here
Re: Xeen and Roland synths
has too long sysex for munt. Why?

Because this may appear a bug. I set the limit of 266 bytes for the sysex size in the MIDI player after have read http://www.queststudios.com/utilities/MT-32Manual.pdf , p.38 DT1 messages where Roland claims the data being sent can't exceed 256 bytes. This particular MIDI file (only I've ever seen) contains sysexes with one junk byte at the end (i.e. 257 bytes overall sysex data length).

I agree that if we made munt looking only in docs, it'd never be so good, so, I'll check whether this is true.

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

Nice catch, Skatoony 😀

I noticed that munt complains about missing f0 and f7 when sending sysex with
Bome's SendSX (1.30 build 182)
short messages goes no problem though

I suspect this is because Munt doesn't support fragmented SysEx messages by now. This means every single SysEx message must be send to Munt by a single function call in order to parse the SysEx message properly. When an application attempts to send fragmented message or several messages at a time, this fails.

There is a vague plan to add a function to fully parse MIDI input byte-by-byte. But I suspect there is no much use of that. Usually special MIDI processing programs allows us to configure SysEx buffer size and the delay between SysEx messages (e.g. MIDI-Ox does) and programs which offer no such configuration options just perform well (with a few exceptions) sending SysExes one-by-one. See if SendSX also allows to configure buffer size (should be > 256 bytes) and ensure there is a (for example 1 ms) delay between SysExes.

I have no issue with Munt and SendSX. Make sure the option "Split Long Sysex Messages" is disabled and the MIDI speed is limited to 1 kB/s.