It confidently works under Snow-64 but it's still lacking those "official" txt files...

Ok. 😊 I'll add the txt files to bundle.

Here is a link to an updated dmg-package. https://dl.dropboxusercontent.com/u/30899371/ … ttu/MT32Emu.dmg It now includes DOCS folder with AUTHORS.txt, COPYING.txt, NEWS.txt and README.txt text files. Hopefully that is what was requested. Things still to do:
1) Visual stuff. Proper icon and maybe a folder background image. Anyone?
2) Signing of the package. Maybe dominus can help?
3) Distribution. Should this be distributed on sourceforge?

Ah, yes. I can help with signing. I return hom on tuesday and can then sign the app(will have to re-image the dmg, though).

I ran into some problems signing...
The framework for the QT stuff seems to need its info.plist file as per http://stackoverflow.com/questions/9476465/ho … 143296#18143296 or signing will always fail.

Pity to hear about the signing problem. I'll study the link you posted later today. My previous experience with signing Mac builds has been that I have signed both the libraries and the actual executable separately with no issues, but this case seems a bit different. Need to look into it...

Hmm, I'll see about signing each binary individually.

Edit: I wonder, did you already sign it? I cannot trigger a negative gatekeeper response to the downloaded file. This is with OS X Maverick, so maybe things changed a bit...

I didn't sign it. Maybe Qt binaries have signing on them by Qt folks.

You are right, on a new 10.8.5 installation in a VM Gatekeeper rejects the app. So after signing everything individually, you can get it from https://dl.dropboxusercontent.com/u/7737184/D … mu-qt-1.1.0.dmg (edited to point at the later discussed version).
- moved the qt_menu.nib from the QTGui resources to the main resources folder of the App (as per some obscure hint somewhere on the web)
- gave the dmg the name "MT32Emu 1.3.0"
- the dmg got slightly smaller (mostly because it doesn't have the folders .fseventsd, .DocumentRevisions-V100, .TemporaryItems and no .DS_Store file)

So, Sergm, I think you can put that up on the official dl page 😀

Great news, guys!
As for publishing: naming you use is a bit confusing. AFAICT, the image contains the build of mt32emu_qt solely, no library framework files. The damn DOCS folder also contains mt32emu_qt specific files only. So, I'd rename it to something like mt32emu-qt-1.1.0.dmg instead. How does it sound?

You can also consider adding to the package a proper (for OS X directory layout) Framework to allow static linking to the library out of the box. In this case all the above said becomes a bit inconsistent though 😉

I'd say mt32emu-qt-1.3.0.dmg 😉
If you want I can change the finder displayed title of the dmg as well to that (only takes a minute and a bit to do and upload)
I can see why you'd want the framework there as well, but IMO the framework should be a seperate package. For an OS X end user the QT package is the only one he/she needs. Adding the framework to that will only confuse 😉

OK, agree about end users 😉

But the version numbers of the package and mt32emu-qt thing are different in fact, so I am not mistaken.

He he, oops 😉
I'll make a new dmg

Yes, please.
Though, that per-project versioning confuses me myself. And keeping separate projects in one repo isn't any better. Hmm, it's heritage we have.

ok, here it is https://dl.dropboxusercontent.com/u/7737184/D … mu-qt-1.1.0.dmg with the dmg title "MT32Emu-Qt 1.1.0"

Cool, uploading...

sergm wrote:

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

Back to the "problem" of port in coremidi. I couldn't find any way to control this in DOSBox so that it favors Munt-qt over USB. Only when you disconnect the USB-Midi device can you control via midiconfig=Mt32EmuPort which port of the MT32Emu it should use. So if I add a new Midi port in MT32Emu I can switch between those MT32Emu ports by using midiconfig=Mt32EmuPort or midiconfig=Mt32EmuPort1 etc...
So definitely keep this in mind for OS X that the software CoreMidi driver will only work after real hardware is disconnected.

Bah, that is really disappointing...

midiconfig for coremidi wants a number, not a name

Interesting, so when I entered mt32emuport and mt32emuport1 it thought of it as 0 and 1?