The first thing that comes to mind is whether it is a 32bit vs 64bit thing. Is Munt in 64bit?

Dominus wrote on 2020-04-08, 08:24:

The first thing that comes to mind is whether it is a 32bit vs 64bit thing. Is Munt in 64bit?

I checked in the terminal and Munt is a 64-bit only app. I can see the 0.74-3-1 is a fat binary with x64,i386 and ppc.

I looked in the Activity Monitor, and it is running in 64-bit when launched.

I performed the same tests with a November 2019 SVN build of SDL2 and a February 2020 SVN build of SDL1 (the ones you formerly linked to - I have not been compiling my own). All these builds work fine with Munt, the problem is only with 0.74-3-1. downloaded from the DOSBox website.

Thanks, I'll take a look at what is going wrong there.

tested a bit and it seems that also 0.74-2 doesn't work and 0.74-3 also doesn't work for me - are you sure that works for you?
The Coremidi code slightly changed from the release branch to SVN and I suspect that this is what is making it not work correctly. It might be something got deprecated in Mojave that now no longer works.
I'll investigate further, but can you confirm whether 0.74-2 and 0.74-3 work for you?

Changing the version number changes the config file used.

It's not that, I made sure of that.

Problem found:
There is no way you could have successfully run it with any 0.74 version. The ability to use a named midi port has only been available in SVN and that only since May 2017 https://sourceforge.net/p/dosbox/code-0/4016/
I do have to redo the 0.74-3-1 release anyway, so I'll ask Qbix if he wants to add that feature to this version. but since it is named experimental and it is available on SVN... probably not.

jmarsh wrote on 2020-04-08, 10:14:

Changing the version number changes the config file used.

Ahh, you are right. I have been testing so many builds that I got confused. This is what works or does not for me:

0.74-2: NO
0.74-3: NO
0.74-3-1: NO
Any SVN build (SDL 1 or 2) as far back as mid 2019: YES

I also made sure to create a fresh config file for each version to make sure nothing was going wrong with the settings. My settings are definitely fine. I also downloaded and re-installed Munt.

Dominus wrote on 2020-04-08, 10:44:

Problem found:
There is no way you could have successfully run it with any 0.74 version. The ability to use a named midi port has only been available in SVN and that only since May 2017 https://sourceforge.net/p/dosbox/code-0/4016/
I do have to redo the 0.74-3-1 release anyway, so I'll ask Qbix if he wants to add that feature to this version. but since it is named experimental and it is available on SVN... probably not.

OK, I appreciate you asking. Thanks.

If it helps.. I have found the feature to be rock solid on my iMac under High Sierra and Mojave. It works great for Munt and also real MIDI devices.

Btw. the reason I need to redo the release is that in macOS 10.14 and 10.15 surface was not working anymore correctly but the SDL devs finally fixed that. So I need to rebuild 😉

More elaborate:
If you built Dosbox and SDL on macOS 10.13 (or older) surface works in 10.14+.
BUT OpenGl would crash on Macs with Intel or Nvidia graphic chips on macOS 10.14+. That means it had to be built against the 10.14 SDK -> surface not working...
Apple hell 😉

almeath wrote on 2020-04-08, 10:49:

If it helps.. I have found the feature to be rock solid on my iMac under High Sierra and Mojave. It works great for Munt and also real MIDI devices.

Thanks, it does help 😉

Dominus wrote on 2020-04-08, 10:52:

Btw. the reason I need to redo the release is that in macOS 10.14 and 10.15 surface was not working anymore correctly but the SD […]
Show full quote

Btw. the reason I need to redo the release is that in macOS 10.14 and 10.15 surface was not working anymore correctly but the SDL devs finally fixed that. So I need to rebuild 😉

More elaborate:
If you built Dosbox and SDL on macOS 10.13 (or older) surface works in 10.14+.
BUT OpenGl would crash on Macs with Intel or Nvidia graphic chips on macOS 10.14+. That means it had to be built against the 10.14 SDK -> surface not working...
Apple hell 😉

Oh, that is very interesting. I did have some issues when moving from my 2013 iMac to my 2019 one, across High Sierra and Mojave and from Nvidia to AMD, but I do not know if that was the root cause. There was all sorts of crashing until I started using later SVN builds. Thanks for that insight.

Apple does create problems with all the changes they make between OS versions for under-the-hood frameworks, which are not well documented (or even mentioned at all). I guess it will all happen again once they decide to strip out OpenGL support and force everything onto Metal. Knowing them it will be sooner rather than later.

Yes, I applaud and damn Apple for deprecating stuff.
The OpenGl drivers for Nvidia and Intel have not been up to date for years and something broke when Apple deprecated OpenGl in 10.14.
The crashes were pretty severe, taking out the whole graphics system which meant it crashed back to the login screen ;(

Dominus wrote on 2020-04-08, 11:34:

Yes, I applaud and damn Apple for deprecating stuff.
The OpenGl drivers for Nvidia and Intel have not been up to date for years and something broke when Apple deprecated OpenGl in 10.14.
The crashes were pretty severe, taking out the whole graphics system which meant it crashed back to the login screen ;(

That is exactly the behavior I saw on my Nvidia 2013 iMac. Everything went black and then eventually crashed back to the login screen. Fortunately, everything has been good on the 2019 model with Mojave. At this point I am too scared to even contemplate upgrading to Catalina. 😒

Catalina is mostly ok, but loosing all 32bit support bit me at least once, but I have another machine that now runs at 10.13. this one I use for building the snapshots.

Dominus wrote on 2020-04-08, 11:43:

Catalina is mostly ok, but loosing all 32bit support bit me at least once, but I have another machine that now runs at 10.13. this one I use for building the snapshots.

That is good to know, thanks. I will make sure I load it onto an external drive first, and do some thorough testing with my DOSBox wrappers before proceeding. I did try an early beta release and it seemed OK at the time. I think more drastic changes will be the OpenGL and (gasp) potential shift to ARM if the rumors are true. I will keep those thoughts out of my mind for now. 😀

Yes, as soon as OpenGl is gone, Dosbox will NEED to upgrade to SDL2. No way will SDL 1 ever get Metal...

Dominus wrote on 2020-04-08, 11:51:

Yes, as soon as OpenGl is gone, Dosbox will NEED to upgrade to SDL2. No way will SDL 1 ever get Metal...

I know this thread went off-topic, but while we are on the subject of SDL2 supporting the Metal renderer, I notice that the only way to get high-performance pixel-perfect scaling is to set output to openglnb, as follows:

output=openglnb
renderer=metal

Does that mean that the patched SDL2 build of SVN is still dependent on OpenGL and there will have to be more extensive work done for this version to run in a future release of macOS that is stripped of OpenGL frameworks?