macOS SDK version for M1

[Zaphod (giancarlo)]

For example we have arm code compiled in xcode 12 and Intel code compiled in xcode 3 and xcode 10

Xcode 3??? That's from 2007. Is there really still a market for PPC plugins? Is it really worth limiting yourself to an ancient version of C++ / Objective-C just to support these machines? Or do you have different branches of your codebase for each Xcode version?

I'm happy building everything with Xcode 12.2 and the latest SDK. I can support back to 10.10 (and hopefully 10.9 if I can figure out the signing issue). Do people who don't update their OS for 6 years even buy new software?

Yes for better compatibility with older os. You don't need to sign there. The right engine is installed directly by our download manager
There are no branches, just different preprocessor directives.
Our code is still compiling on Borland c builder!!! It is a bit of pain to have code which compiles on llvm, or Microsoft compilers, Borland or GCC at the same time, but it is a good exercise.
All the times we need something specific we have a dispatcher in our framework (ie specific code compiled for avx512, or silicon)

[mystran]

Nearly all VST3 plugins (as well as the oney which have been wrapped to AU) use it. Steinberg's VST 3.7 SDK still uses it. Juce ueses it.

Do you have any source for this? I'm almost certain JUCE uses Core Graphics on macOS and OpenGL is only an option that - as far as I know - very few plugins use.

Core Graphics is so slow it's not really a realistic option if you're doing any kind of non-trivial animation (eg. for visualisation or whatever). Even if you're software rendering, it's way faster to just upload a texture and draw a quad. So realistically the only other option is Metal.

[FigBug]

FYI: productsign on Big Sur is broken and not adding SHA1 hashes (only SHA256) so your pkg won't install on anything older than 11.12. Don't upgrade your build machines yet.

[Markus Krause]

FYI: productsign on Big Sur is broken and not adding SHA1 hashes (only SHA256) so your pkg won't install on anything older than 11.12. Don't upgrade your build machines yet.

Thanks a lot for this important info. I think you mean 'older than 10.12' (typo).
Sounds like another 'planned obsolescence' from Apple's side. Customers are necessitated to buy new machines to be able use the new software

As a result in practise we would have to drop support for anything below 10.12 if we support Silicon

Another point:
Does it affect only signing the .pkg or also the code-signing?
I am not sure if code-signing and package-signing on two different machines works to pass the Notarisation.

And another one:
Are customers below 10.11 still able to install the software signed with Big Sur with "high-click +Open"?

[discoDSP]

Edit. Didn't read using lipo to join 10.9 SDK x86 and 10.15 SDK ARM binaries suggestion. Probably best thing to do.

[lkjb]

Nearly all VST3 plugins (as well as the oney which have been wrapped to AU) use it. Steinberg's VST 3.7 SDK still uses it. Juce ueses it.

Do you have any source for this? I'm almost certain JUCE uses Core Graphics on macOS and OpenGL is only an option that - as far as I know - very few plugins use.

Core Graphics is so slow it's not really a realistic option if you're doing any kind of non-trivial animation (eg. for visualisation or whatever). Even if you're software rendering, it's way faster to just upload a texture and draw a quad. So realistically the only other option is Metal.

While I thought JUCE uses Core Graphics looking at the latest code it seems to be rather a software renderer. Maybe it was changed or maybe I got that wrong. My main point was that JUCE doesn't seem to use OpenGL for rendering by default, though. "gl.h" is only included within the juce_opengl module which isn't a dependency for graphics in JUCE. Again, I might be wrong in thinking that OpenGL is only available with "gl.h" being included. That's why I asked for sources about the statement (paraphrased) "JUCE as well as VST3 use OpenGL often" in the first place.

[audiothing]

Nearly all VST3 plugins (as well as the oney which have been wrapped to AU) use it. Steinberg's VST 3.7 SDK still uses it. Juce ueses it.

All our current versions of our plugins (24 so far) don't use OpenGL, and yes, we use JUCE. Even when there are a few animations, if they are optimized properly, we didn't have any need to use OpenGL.
However, we had just 2 complaints recently from mac users (with older CPUs) for our latest plugin which uses heavier animations. So, we'll probably implement OpenGL in such cases and move to Metal asap when the JUCE team adds it (hopefully before Apple completely removes OpenGL).

FYI: productsign on Big Sur is broken and not adding SHA1 hashes (only SHA256) so your pkg won't install on anything older than 11.12. Don't upgrade your build machines yet.

As a result in practise we would have to drop support for anything below 10.12 if we support Silicon

Let's hope it's a temporary thing. We were planning on making two separate installers to cover up to 10.7. If that's the case, it won't be a big problem.
Otherwise, we might need to check that lipo command. But I'm not sure if it works on installers and plugins. Any idea anyone?

[mystran]

Nearly all VST3 plugins (as well as the oney which have been wrapped to AU) use it. Steinberg's VST 3.7 SDK still uses it. Juce ueses it.

All our current versions of our plugins (24 so far) don't use OpenGL, and yes, we use JUCE. Even when there are a few animations, if they are optimized properly, we didn't have any need to use OpenGL.
However, we had just 2 complaints recently from mac users (with older CPUs) for our latest plugin which uses heavier animations. So, we'll probably implement OpenGL in such cases and move to Metal asap when the JUCE team adds it (hopefully before Apple completely removes OpenGL).

Make sure to profile whether you're spending too much time rendering or too much time sending the final image to the window. If it's the latter (yes, it can very much become the bottleneck) then OpenGL (or Metal) could speed things up even if you're still rendering in software, simply because uploading a texture and drawing a quad is usually quite a bit faster than going through CoreGraphics.

[FigBug]

FYI: productsign on Big Sur is broken and not adding SHA1 hashes (only SHA256) so your pkg won't install on anything older than 11.12. Don't upgrade your build machines yet.

Another point:
Does it affect only signing the .pkg or also the code-signing?
I am not sure if code-signing and package-signing on two different machines works to pass the Notarisation.

And another one:
Are customers below 10.11 still able to install the software signed with Big Sur with "high-click +Open"?

It's only productsign that is broken, not codesign. So I can still sign plugins, but not pkg. So my solution for now is to build on Big Sur, copy the pkg to a Catalina VM, sign pkg & notarize. As Xcode 12.2 runs on Catalina, I'd stay on Catalina for now.

And no users can't right click install.

[Markus Krause]

Yes. Catalina currently seems to be the best compromise as a development platform.
I am a bit scared to upgrade my Mojave to Catalina. Currently everything works

[audiothing]

Make sure to profile whether you're spending too much time rendering or too much time sending the final image to the window. If it's the latter (yes, it can very much become the bottleneck) then OpenGL (or Metal) could speed things up even if you're still rendering in software, simply because uploading a texture and drawing a quad is usually quite a bit faster than going through CoreGraphics.

Yes, OpenGL is definitely faster. But for a simpler UI, with just a small animation, it's not really making a huge difference here.

Yes. Catalina currently seems to be the best compromise as a development platform.
I am a bit scared to upgrade my Mojave to Catalina. Currently everything works

Just install Catalina on an external drive and boot from there. I'm also still using Mojave to build everything, but I test the builds on Catalina with an external drive (even with a 2012 MacBook Pro).
If you still are afraid, grab SuperDuper and make a bootable copy of your current Mojave setup.
We do this regularly just to be safe as I don't fully trust Time Machine, and it's just one click.
Make sure to format the drive with the same filesystem as your current setup.

[Markus Krause]

Thanks. The external drive with Catalina is a good idea

[mystran]

Make sure to profile whether you're spending too much time rendering or too much time sending the final image to the window. If it's the latter (yes, it can very much become the bottleneck) then OpenGL (or Metal) could speed things up even if you're still rendering in software, simply because uploading a texture and drawing a quad is usually quite a bit faster than going through CoreGraphics.

Yes, OpenGL is definitely faster. But for a simpler UI, with just a small animation, it's not really making a huge difference here.

Well, sure. It's more of an issue when you need to update a large area on every frame, such as with a spectrum analyzer or some such.

[syntonica]

Just install Catalina on an external drive and boot from there. I'm also still using Mojave to build everything, but I test the builds on Catalina with an external drive (even with a 2012 MacBook Pro).
If you still are afraid, grab SuperDuper and make a bootable copy of your current Mojave setup.
We do this regularly just to be safe as I don't fully trust Time Machine, and it's just one click.
Make sure to format the drive with the same filesystem as your current setup.

I whole-heartedly second the recommendation for SuperDuper (or Carbon Copy Cloner). It saved my bacon when Apple decided to brick my music machine when it tried to install an iTunes update to support the new iOS. I am frozen on Mojave and I really suspect that update might have been Catalina.

I keep TimeMachine off as I have no need of incremental backups and it doesn't work as a bootable backup solution. Sometimes, I need to boot from an external drive to work on the internal drive without interference--move/delete files, run diagnostics and repair, etc., all the things Apple doesn't want me doing.

You definitely want a dedicated SSD of similar size to your boot partition and to partition/format it the same. My current solution is a mechanical 500gb drive and it's so painfully slow (even though it's still probably the fastest mechanical hard drive I've ever used!)

Regarding Open GL, I had a working solution based on nanoVG and vector graphics for both Mac and PC, which worked very well. Scaling the plugin window just meant changing a single variable before sending it off to the GPU. The result was surprising crisp, although not as good as the Cocoa version. No comment on the Windows version as that physical display is awful to begin with.

I abandoned the Open GL version because right after I finished it, Apple deprecated it in favor of Metal, which meant that with the next macOS release, OpenGL would get no love and slowly start breaking, just like Carbon did after OS 10.9.

Regarding OpenGL speed, there really was no CPU usage difference for the basic form of my GUI. However, if the expanded size was used, CPU usage with OpenGL remained the same, but for Cocoa, usage went up proportionally. I use a number of animations for dynamic waveforms and knobs turning automatically.

One thing to note, however, is that in the OpenGL case, the GUI was redrawn in full for each of 60fps, while the Cocoa version is heavily optimized to only redraw widgets that need to be updated. If I applied the same optimizations, then the OpenGL version would hardly use any CPU at all.

I still far prefer the look of the Cocoa version, however, despite how CPU-hungry it can get. In the end, projecting 2d graphics onto a 3d space made of triangles is just a hack.

[audiothing]

It's only productsign that is broken, not codesign. So I can still sign plugins, but not pkg.

I think I found an issue with codesign as well. I managed to fully automate our builds on Big Sur silicon. To fix the issue with productsign, you can use xar (MacPorts version), follow these steps: https://forum.juce.com/t/upgraded-to-bi ... r/42812/10

Codesigned plugins on Big Sur seem to work fine on 10.9, but fail to load on 10.10, which doesn't make much sense. Runinng auvaltool on 10.10, I get this error:

Code: Select all

code signature invalid for '/Library/Audio/Plug-Ins/Components/Wires.component/Contents/MacOS/Wires'
FATAL ERROR: OpenAComponent: result: -50,0xFFFFFFCE

However, the same exact version of auvaltool on 10.9 (!) returns AU VALIDATION SUCCEEDED.

Replacing the signature with codesign on Mojave, fixes the issue.

So I'm back at splitting the build process between two macs. Anyone else with the same issue?