OSX Catalina vs OpenGL vs ProTools 10

[Markus Krause]

We are a small company. That's why i have to deal with Apple's stuff for myself and can't hire a guy who does it for me.

I have been running into bugs within Apple's notarisation tools twice.

1) The notarisation tool did not accept my password although it was correct. Tryed again and then again. Then received an error message 'This Apple Account as been banned because of security problems'.
Contacted them on the phone, however they were not able to solve it. There was also no ban on my account.
Then i found out that their commandline tool has problems with hyphens when a password is used. Generated a new one-time password and used it without hyphens and it worked.
Notarisation is really slow (several hours) and a pain if you need to upload large files with a slower internet connection.

2) The code signing certificate 'was not found' although it was present on my system in the correct place. Deleted it from the keychain and generated a new one. Added to the keychain. Then it worked.

Further bugs:

3) Since the last two MacOS updates the auval tool is buggy. It does affect not only our software. Audiounits do not get detected. So far it was not fixed. You need to reboot the mac or add a shell script to your installer which forces a restart on auval to make it work.

[Urs]

But the compatibilty is top notch there.

Unless, of course, your software needs write permissions to save presets and stuff, but it is a plug-in and you don't want your users to have to explore hidden directories. Every upgrade of Windows, and sometimes those pesky little updates, has broken things for us.

Could you share the link to the notarization tutorial?

viewtopic.php?f=33&t=531663

[Markus Krause]

During the last 15 years none of the Windows updates except Windows Vista has broken compatibility with my software. The Vista problem was very easy to fix.

You can set the write permissions in innosetup with [Dirs].

[EvilDragon]

Write permissions are not a problem on Windows, folders exist for that (Documents or Roaming). Program Files is not supposed to be writeable by apps (and it's Steinberg's fuckup that they chose Program Files/Steinberg/VstPlugins as default folder for VST2 plugins - not Microsoft's). This goes way back since XP or so, but it started to be enforced more by MSFT since Vista onwards.

The main problem with u-he installers on Windows was that it defaulted to having their .data folder right next to the plugin (which of course would raise issues in Vista or above, if the user used the default VST2 plugin folder...)

But u-he have this sorted out now. It was just a case of bad defaults coupled with Steinberg not following MSFT guidelines. Any plugin that uses Documents folder (which is NOT a hidden folder) to save presets in absolutely doesn't have any write permission issues. Were this used for u-he plugins since the start, you never would've had those issues, since literally the Documents folder was write-safe for any program since XP or even before - and AFAIK no update of Windows ever broke this.

[Wallander]

To Apple's defense, they don't actually remove functionality as often as they deprecate it. Ok, so they left parts of Carbon out from their 64-bit OS SDK, but that's not the same as actively removing stuff for political reasons.

As for OpenGL, I would be very surprised if they point-blank killed support for OpenGL-based applications, for no good reason. Going by how they usually operate, they'll probably leave OpenGL in, and let it die from a lack of driver support, inferior performance, or something. Or not providing an SDK for it, when they deprecate Swift for another language.

Even if Apple killed direct hardware access for OpenGL drivers at some point, I would be extremely surprised if they removed Apple's own software renderer for OpenGL. Because it maintains baseline compatibility with most OpenGL apps, at no significant penalty for Apple, shifting the blame for inferior performance on the app developer who doesn't support Metal.

So if a Metal port was out-of-reach, I would ensure that any OpenGL-based plugins render fine with Apple's fallback software renderer, by relying only on the subset of OpenGL supported by it. Frame rate is lower than a hardware driver, but for being a software renderer it's pretty great.

[omiroad]

They stopped updating OpenGL support to newer versions right? It's forceful behavior.

[Markus Krause]

We don't use openGL. But i have read in some development threads that parts of it do not work as expected in the latest versions.
Apple itself tagged it as 'deprecated'. Sooner or later they will drop support for it. There is nothing known when this will happen. As a consequence all plugins that use openGL (that's nearly all that offer a scalable GUI) will stop to work

[MeldaProduction]

We are using OpenGL and it is pretty clear that something bad started happening in Mojave already. Just the fact they cannot write a simple layer emulating OpenGL using Metal is just sad. But it's classic Apple... Forcing developers do their dirty work...

As for permissions on Windows, there have been changes in Win 7/Vista or something, and it was a bit bothering at some point, but nothing too problematic. Just move everything to user data. Same thing happened on OSX, so...

[Christian Schüler]

We've found 10.14+ XCode SDK's have various problems with OpenGL (bugs, worsened performance),
so we stick with 10.13 for now.

Oh that high? For my VST I still use 10.6 as deployment target; for my game I use 10.9.

[quikquak]

They stopped updating OpenGL support to newer versions right? It's forceful behavior.

I've seen reported from someone on the Juce forum that they actively made the 'swap buffer' very slow on a recent SDK.
A 'bug' of course....