Well CrunchBang is actually a Debian derivate, so I'm not sure if that would actually be compatible with Ubuntu and derivates ^^;

launchpad.net is supposed to have some "recipe" system that can automatically pull source and build deb packages from it, and then post it on a custom PPA that you can use with apt-get in Ubuntu and derivatives. However, I couldn't make heads nor tails of it when I looked at it. I guess you have to already know a lot about deb packaging for it to make any sense.

Oh, I got another suggestion! It's from another project I follow (PPSSPP)
You could contact Orphis team to see if they accept your offer to make your automated builds =3
Since Munt doesn't get a lot of revisions (since it's already awesome =D ) I don't think they'll have problems accepting your offer ^^

Yes, it is. But the way his ppa looks is very confusing. It says only the library is build (I suspect for his DOSBox build) and the build has version number 1.1.1, though the sources look fresh.

@marooned_on_mars
I already have binaries for Windows 😀 And to get compatible with Android I need to move to Qt 5.
Actually, I can just put Linux binaries in that frustrating .tgz to be installed / dependency resolved manually.

EDIT: I wonder if anyone seriously use slackware packages these days. Only if it is accompanied with a sane shell script maybe...

EDIT2: I also think Linux users have better ability to compile stuff than Windows users, so having Windows only binaries doesn't seem too wrong 😁

sergm wrote:

I already have binaries for Windows 😀 And to get compatible with Android I need to move to Qt 5.

I'm not sure how compiling on Android would come to much use since DosBox is already quite intensive on most devices ^^;
But I also think maybe they/he can set the system to compile to other platforms?
Don't know much about his project but you could always ask if you want to =)

EDIT: Forgot to specify the new version of the driver works faster and is more "stable" than the previous ones. Kudos to everyone involved 😁

sergm wrote:

Yes, it is. But the way his ppa looks is very confusing. It says only the library is build (I suspect for his DOSBox build) and the build has version number 1.1.1, though the sources look fresh.

Yes, this is a daily build. And yes, only library is built. And yet it is a bit messy regarding docs 😀

I haven't been able to verify 100%, but I think Munt 1.3.0 may be kicking DOSBox out of fullscreen mode whenever the following log occurs - even when balloons/consoles/etc. are all hidden/disabled:

AudioStream: Estimated play position is way off: -7778 -> resetting...

Hmm, that would be weird 😒 But that message is likely caused by switching fullscreen mode on Windows. Also when a window minimised/restored. This stops the rendering thread for ~200 millis regardless of thread/process priority.

Hi, i'm the guy from the ppa. i just wanted to tell you (sergm) that your dosbox dosbox-0.74-mt32-patch.diff no longer applies cleanly to dosbox svn - i know it's not supposed to, but i was nesting it for the dosbox ppa builds and i noticed once they started failing. I've now copied it over to the packaging repo, fixed it so it applies (it's just the src/midi.cpp file which changed slightly).

Another thing, your github page has a pull request from me for some gcc compile errors which were preventing the mt32emu from being built.

Thanks, SCO!

A question: is there any difference if mt32emu is configurated with either a CM32L or MT32 roms or does the library not care? Also, the current patches (including the dosbox patch i picked up from you) do not seem to care overmuch about mismatched CONTROL and PCM roms, is this something that will work?
+ if (!controlROMFile.open("/usr/share/mt32-rom-data/MT32_CONTROL.ROM")) {
+ if (!controlROMFile.open("/usr/share/mt32-rom-data/CM32L_CONTROL.ROM")) {
+ return 1;
+ }
+ }
+ if (!pcmROMFile.open("/usr/share/mt32-rom-data/MT32_PCM.ROM")) {
+ if (!pcmROMFile.open("/usr/share/mt32-rom-data/CM32L_PCM.ROM")) {
+ return 1;
+ }
+ }

exult sounds pretty bad with the mt32emu driver compared to the recordings, probably things are wonky there in sysex land on their end.

Yes, munt for quite a long time supports additional sounds from CM-32L PCM ROM. Also, a bit of info is extracted from control ROM and used. In particular, the expected size of PCM ROM. So, munt should complain if PCM ROM you provide doesn't correspond to the control ROM.
The code above should work. But in the patch for DOSBox which resides in the munt repo, CM-32L ROMs are tried first, and hardcoded path for ROMs avoided. In fact, CM-32L is the best choice for munt for now but we're in the process of adding configurable emulation of quirks and features of other units (coming soon) 😉
Yep, it well may be a sysex issue. Windows driver is not quite durable for acquiring fragmented or coupled sysexes (they are ignored). The expected behaviour is sending complete sysexes one per message. It doesn't matter when you send sysexes to a real unit of course (except the timing issue with the old MT-32 units). As I noted above, this doesn't seem to be a big issue. DOSBox and a couple of MIDI players I checked work just fine. Sysex senders should have a configurable option to add a delay between messages which effectively decouples multi-sysex packages. Fragmented sysexes are to be prevented by increasing sysex buffer size above 256 (as claimed by Roland, though, I observed even 267-byte sysexes).
KingGuppy had an idea once to add MIDI byte-stream parser to the lib (which would allow to get rid of this sysex issues) but currently this isn't a top priority. Of course, if there is a valuable app which has no such options configurable (that makes me doubt it is valuable honestly), I'll consider to make a quick update...

Don't bother comparing with Exult, it has known issues regarding sysex or whatever when played with a real mt32. Compared to playing the original u7 intro through dosbox it is obvious 😉

I'm using only CM-32L roms nowadays and works wonderfully with the latest MUNT.

I'm almost at the brink of selling off my last LAPC-I because of how good the MUNT emulation has evolved to be. 😁

Malik wrote:

I'm using only CM-32L roms nowadays and works wonderfully with the latest MUNT.

I'm almost at the brink of selling off my last LAPC-I because of how good the MUNT emulation has evolved to be. 😁

I wish it was a CM-32L that you were selling. I can't find those anywhere these days.

I have an MT-32 connected to my desktop, but I use MUNT on my laptop.

HunterZ wrote:

Malik wrote:

I'm using only CM-32L roms nowadays and works wonderfully with the latest MUNT.

I'm almost at the brink of selling off my last LAPC-I because of how good the MUNT emulation has evolved to be. 😁

I wish it was a CM-32L that you were selling. I can't find those anywhere these days.

I have an MT-32 connected to my desktop, but I use MUNT on my laptop.

I looked into selling some of my units, but overseas postage makes it unreasonable. We are talking over $100 just for the shipping 😒

So I keep them for retirement 😁

I've been noticing a quirk in the MUNT version 1.2.1 and up until now, wherever "IceRain" is played, it has an obnoxious pop preceding it. Sample:

I'll also try to get hold of an older MUNT, and test out from when exactly this behaviour started.

http://sourceforge.net/projects/munt/files/munt/ official releases there

I know where the binaries are, but thanks.