Hey KingGuppy...
Any news on when Munt 0.1.3 will be coming down the road? Not that I want to pester, but I am really looking forward to the emulation of the extra CM-32L/LAPC-1 SFX.
I'm sure most of us hear would be anxious to hear.
I'm planning to release 0.1.3 this weekend. No guarantees, though.
wrote:I'm planning to release 0.1.3 this weekend. No guarantees, though.
Sure has been quiet lately. Any news on the release date of 0.1.3?
@ KingGuppy
I've seen that you have made some updates to ScummVM CVS 3 days ago.
So I knew you're on the way for Munt 0.1.3 😀
As moturimi just mentioned, I've made some changed to the MT-32 emulation in ScummVM. It's now in sync with Munt's CVS, so it's the latest and greatest. I'm waiting to see whether anyone using the ScummVM daily builds reports any problems; if not, expect a new Munt release soon. I won't give another time estimate, that's always a bad idea 😀
There are still major problems with percussion similar to the symptoms I described in this bug report:
http://sourceforge.net/tracker/index.php?func … 616&atid=697157
Testing the MT-32 emulator on latest ScummVM CVS with MI1 or MI2, the percussive track / part 9 is almost entirely missing. As you mentioned in response to my bug report, it probably has to do with how Munt handles partial allocation for the rest of the parts. Anyway just thought I'd let you know it seems even 'worse' than with the previous builds. Otherwise things seem to be progressing very nicely 😁
In case you're not monitoring the tracker, I've added a comment to that bug report.
KG, is the Munt CVS public? I see that you don't use the CVS repository on Sourceforge under your Munt project page. I came here because I monitor the ScummVM (and DOSBox) CVS logs 😀
The Munt CVS is public, and is hosted by SourceForge. Their stats are screwed, which is why it says "0 commits, 0 adds" in the overview. I assume that's why you think we don't use it.
Ah, that's what I get for being lazy and trusting their stats - thanks. Unfortunately I use MingW instead of MSVC++ (and I'm not enough of a Win32 developer to want to try to port it) so I'll have to wait along with everyone else for a new Win32 driver binary release...
hmm a proper project should have a makefile based make.
Making a makefile isn't that hard you know.
you can't expect your users to have a crappy compiler installed.
just kidding, although dosbox has certain code pieces in to make sure msvc makes good code.... Better said we had bugs that we caused by msvc making bad code. We fixed those as some of our devs use msvc as well. but we had to reorder our code flow....
To prevent errors like this we build releases with mingw.
Water flows down the stream
How to ask questions the smart way!
Qbix: The mt32emu library is buildable using the GNU toolchain (it uses the autotools and gcc). The Win32-specific driver requires MSVC++.
I'd love to have the Win32 driver building with MinGW, but there just isn't much incentive for me personally to get that working. Note that it uses ATL, which I think is one of the sticking points. Of course it could be changed to do COM by hand if necessary.
wrote:In case you're not monitoring the tracker, I've added a comment to that bug report.
I've responded to your comment.
