Sorry, I have no apples and can't therefore maintain an OS X build 🙁
But I think you may work around without Munt GUI (btw, I don't remember the way to mute MIDI channels there, NYI 😁) if you just record the MIDI in question and then use your favourite MIDI editor to make it sound the way you like.

Offtop:
Maybe someone can help with maintaining the OS X build? I put a word about in times of 1.0.0 release but nobody seems interested... 🙁

I could try to maintain the OS X version, if that mainly includes compiling and testing. Where should I start?

Oh, great. Basically, I'd like to add a .dmg package to the main SourceForge download page. Not sure whether we still need to support PPC arch, but probably still need 32-bit binaries. The starting point should of course be compiling and testing 😉

Ok. I'll free up some hard disk space 😉, set up needed libraries and compile it. Might be weekend before I have time to focus on that.

I don't think PPC is needed anymore. I have access to my MacBook Pro running Mountain Lion on i5 and also an older white MacBook running Snow Leopard. I think that targeting Snow Leopard as an oldest operating system supported would be a good move, at least for pre build binaries.

Let's continue this with PMs or create a new thread. I might have some questions after I start... Although I have compiled the Qt version successfully at least once, I recall.

Edit: And if it makes any difference I have a MT-32 as well as a LAPC-I card, too.

Sure, MT-32 Development is a good place for that. If you prefer, we can go on in #munt channel @ FreeNode (though, it became too silent recently 🙁 ).

IIRC, pre-built Qt worked just fine, so we may need not to build it (perhaps, for statically linking only). CMake is also provides ready to use binaries. GLib is a bit problem to get but maybe considered obsolete as well as smf2wav itself (the only thing that needs GLib actually). I suppose, Mac users tend to avoid terminal anyway 😁

I'll happily volunteer as tester 😉
Just don't want to mess with qt or I'd have volunteered as maintainer 😉
But please post a how-to anyway to follow up on how you make the binary..,

Hi, Dominus. Still love Qt? Hmm... Things change, maybe it is better than you expect. 😀

Anyway, it was easy to make the binaries for me when I tried CoreMIDI, making a useful dmg is rather a question. Actually, CMake provides their CPack packaging tool but it looks really weird to me on non-Windows systems just because it relies on NSIS and not on ugly shell scripts. So, I'd want something better. Same for Linux/POSIXes, btw.

As to compile, there is nothing special required. Assuming XCode is working, only those dependencies I listed above are needed. If you don't want smf2wav and GLib, you just remove the references to it in the main CMakeLists.txt file. Then, usual cmake ${path_to_sources} && make && sudo make install should succeed. No idea whether it is still compilable though as I changed many things since v.1.2.0.

he he, I just don't dare touch QT... 😀
I don't doubt I could make it to run on my system, it's just that I'm not sure how well I could do a shareable binary/dmg 😀

Anyway, if you just test the munt package for compatibility with OS X from time to time, I'll surely have a better sleep 😁

I did so preliminary tests. I first downloaded Qt version 5.1.1. Couldn't compile with it, complains about wrong version (probably simple CMake issue, didn't look into it yet), so I downloaded Qt 4.8 version as well.

Now I get a bit further. Unfortunately, I still can't compile Qt project:

1[ 35%] Generating ui_MidiConverterDialog.h
2[ 37%] Generating ui_MidiPlayerDialog.h
3Scanning dependencies of target mt32emu-qt
4[ 38%] Building CXX object CMakeFiles/mt32emu-qt.dir/src/moc_AudioFileWriter.cxx.o
5In file included from /Users/janischulze/Documents/Projects/oss/munt/munt/mt32emu_qt/src/moc_AudioFileWriter.cxx:9:
6In file included from /Users/janischulze/Documents/Projects/oss/munt/munt/mt32emu_qt/src/AudioFileWriter.h:8:
7/Users/janischulze/Documents/Projects/oss/munt/munt/mt32emu_qt/src/QSynth.h:27:11: error: no type named 'MIDIDelayMode' in
8      namespace 'MT32Emu'
9        MT32Emu::MIDIDelayMode midiDelayMode;
10        ~~~~~~~~~^
11/Users/janischulze/Documents/Projects/oss/munt/munt/mt32emu_qt/src/QSynth.h:121:33: error: no type named 'MIDIDelayMode' in
12      namespace 'MT32Emu'
13        void setMIDIDelayMode(MT32Emu::MIDIDelayMode midiDelayMode);
14                              ~~~~~~~~~^
152 errors generated.
16make[2]: *** [CMakeFiles/mt32emu-qt.dir/src/moc_AudioFileWriter.cxx.o] Error 1
17make[1]: *** [CMakeFiles/mt32emu-qt.dir/all] Error 2
18make: *** [all] Error 2
19

I will take a closer look soon...

Eek, looks like mt32emu_qt desynced with mt32emu library %
That enum MIDIDelayMode was added quite recently. If you have the library of older version installed in your system, it can probably cause interference.

Thanks. I deleted old version and compiled and installed a new version of the mt32emu. That almost did the trick of getting Qt version to compile.

I got following errors after that:
1) Protected member error

1[ 58%] Building CXX object CMakeFiles/mt32emu-qt.dir/src/mididrv/TestDriver.cpp.o
2/Users/janischulze/Documents/Projects/oss/munt/munt/mt32emu_qt/src/mididrv/TestDriver.cpp:36:14: error: 
3      'waitForProcessingThread' is a protected member of 'MidiDriver'
4        MidiDriver::waitForProcessingThread(this, TEST1_EVENT_INTERVAL_NANOS);
5                    ^
6/Users/janischulze/Documents/Projects/oss/munt/munt/mt32emu_qt/src/mididrv/MidiDriver.h:18:14: note: declared protected here
7        static void waitForProcessingThread(QThread *thread, MasterClockNanos timeout);
8                    ^
91 error generated.
10make[2]: *** [CMakeFiles/mt32emu-qt.dir/src/mididrv/TestDriver.cpp.o] Error 1
11make[1]: *** [CMakeFiles/mt32emu-qt.dir/all] Error 2
12make: *** [all] Error 2

Solved that by making waitForProcessingThread public, which is a hack and probably not the right solution. Any comments?

2) Linker error

1Linking CXX executable mt32emu-qt
2Undefined symbols for architecture x86_64:
3  "_CFStringCreateWithCString", referenced from:
4      CoreMidiDriver::midiNotifyProc(MIDINotification const*, void*) in CoreMidiDriver.cpp.o
5      CoreMidiDriver::createDestination(MidiSession*, QString) in CoreMidiDriver.cpp.o
6  "___CFConstantStringClassReference", referenced from:
7      CFString in CoreMidiDriver.cpp.o

Solved that by adding Foundation framework to linker parameters along with existing CoreMidi framework for OSX, might be a correct solution.

After that I got the emulator running, now I next need to build a beatiful bundle out of it 😉

ufoufo512 wrote:

Thanks. I deleted old version and compiled and installed a new version of the mt32emu.

In case you aren't aware, the preferred way to build things in POSIX world is using clean chroot environment. The package gets no extra dependencies this way, as well as it ensures better compatibility (I mean no undeclared dependencies in the package).

1) Protected member error

Ah, yep. MSVC & GCC don't throw even a warning, heh. 🤣 Btw, a similar thing happened with QtAudioDriver mt32emu-Qt cross-platform UI-enabled application development, so I just disabled it under Darwin. The righter way seems to be moving this protected call to TestMidiDriver::stop(). I'll fix, thanks.

Solved that by making waitForProcessingThread public, which is a hack and probably not the right solution. Any comments?

This reminds me how FreeBSD porters work all their life 😀 They constantly produce patches for Linux software in order to get it compile under BSD 🤣 It seems OS X inherited this way of porting software...

Solved that by adding Foundation framework to linker parameters along with existing CoreMidi framework for OSX, might be a correct solution.

Cool. This framework was not needed / added implicitly / whatever before. Thanks again.

Thanks for the tip for clean chroot environment, I will definitely look into it. Good thing that it helps just even to compile the project on Mac OSX. I won't hack too much 😊 , it just sometimes the urge to get something to compile is just too great 😈

Now that I got the Qt project running, I am facing another problem. There is only AudioFileWriter available as Device in Audio Output section. When the program is started there will be a text "Scanning audio devices..." but nothing seems to be found and a file chooser is displayed instead as for selecting where to create the file for audio file writing. The recording itself goes very well this way. Don't have any special sound device setup, just normal Macbook Pro stuff. I will debug this more deeply later.

BTW. I created a new thread. Let's continue relevant discussion there. Munt Mac OSX version discussion

Bah. PortAudio should work and provide the access to your audio devices... QtAudioDriver is disabled as I mentioned above but it didn't produce any sound either when I tried it.

You're right. Similar issue, old stuff conflicting. Got it to work, going forward... 😀 Damn it sounds good, great job. I also like the new more square UI.

more square UI

Heh, I suppose this is about Window 8, no less 🤣