Sergm, how are the growl notifications/baloons generated?
If that is being done via apple script, it shouldn't be the app itself being called but the bundle identifier com.growl.growlhelperapp

Using QSystemTrayIcon->showMessage() 😁
I don't know how Qt does this. But I know how to disable them. 😜

"On Mac OS X, the Growl notification system must be installed for this function to display messages."
^ That's all Qt docs says...

Ah, k. Probably due to the older qt framework. Not sure against which version ufo compiled now

I'd think it's 4.8.5

Yep. It is compiled with Qt 4.8.5.

Quick research shows it's indeed a QT framework problem. Not sure if it is even fixed yet in 5.x frameworks 😉

So, tested with a USB2Midi device and real MT32 hooked up. CoreMidi prefers the USB device, Munt doesn't receive anything. Not a problem but good to know when people start complaining nothing works 😀

I wonder what would need to be changed in the programs (scummvm, dosbox, exult, ...) to be able to select a port for coremidi

Can't the port be made "default" using MIDI studio (Audio MIDI setup / whatever)? Having the user without such a choice is in fact a Vista+ feature 🤣

As far as I could google, it's not that simple, especially as the "Audio Midi Setup" is only for real midi hardware not software midi. I can't even disable the USB Midi device...

Well, at least, DOSBox should be excluded from your list. I remember midiconfig changed the port it connects to.

Hmm, CPack actually has more advanced generators. It is weird it produces so ugly installs by default. 😒

EDIT: It would be better if it had not 😈

Any news on building 1.3.0 for OS X?

Side note: not 100% sure since I looked at the .dmg using 7-zip but I didn't find those *.txt files people usually caring about much 😉

Oh, sorry. I have been busy, haven't been checking this forum.

I take a look on building 1.3.0 on weekend.

Well, the weekend went by without me doing anything on Munt. Now, today, I have some time and I'll try to make the build for Mac users. My first problem seems to be CMake not playing nice with new XCode 5 😕 . Stay tuned..

the first thing that comes to mind with Xcode5 is that there is only clang now. If Cmake has an hardcoded different compiler (gcc-4.2, llvm-gcc, ...) somewhere that will fail. /usr/bin/gcc still works as a link to clang.

Here's the Mac OSX build from the current github master:
https://dl.dropboxusercontent.com/u/30899371/ … 013/MT32Emu.dmg

Just basic compile with XCode 5, Release settings, all dependencies should be included in the app bundle. I just remembered that I didn't check the deployment target, so this might be for Mountain Lion (and Mavericks) only. I will give it a spin on the Snow Leopard and re-compile if needed later today.

Please test and comment.

Regarding the CMake / XCode issue I mentioned earlier, it was solved by itself. First the CMake check for C-compiler script failed because of the white space in the path to compiling binaries. The path to XCode was like Volumes/Macintosh HD/Applications/XCode.app and so on, which was correct, but the compiling failed with the error: "Volumes/Macintosh no such file or folder". Anyway, I googled answers, found similar problems, but not obvious solutions, somehow the problem went away and I was able to make a build. I did update the cmake from Macports though, maybe that did it.

Great! Thanks a lot for this!

Dominus: You're welcome. Thanks to sergm for making all this.

Here is an updated build that should work on OSX 10.6 and later. https://dl.dropboxusercontent.com/u/30899371/ … 0.6/MT32Emu.dmg

Cannot verify Snow Leopard neither Lion myself at the moment, briefly tested on Mountain Lion though.