OSX Catalina vs OpenGL vs ProTools 10

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Yeah, I used to send non-stripped plug-ins to people with odd crash errors. It would be handy to be able to search them without copying to a text file first.

Post

quikquak wrote: Sun Sep 15, 2019 6:18 pm Crash logs? Don't you 'strip' your code? Or does Apple not allow that any more. :P
They come with address offsets rather than symbol names. We keep the symbol files and use a script to put the symbols back in.

------------

Quick search for "Mac" vs "Win" throughout our support emails shows a slight lead of Mac after correlating with preferences of our user base. So maybe there are indeed more problems, but even if, not worth dropping the platform.

-------------

We couldn't make Catalina break our stuff - yet. Doesn't seem to be half as bad as some people think (some hosts don't work though, so there's that...)

Post

Great info, thanks Urs.

Post

Ju2999 wrote: Thu Sep 12, 2019 12:49 pm I think opengl will be dropped as soon as the first arm based Mac will appear. Maybe interesting detail: ios at least supports open gl es (and already runs in arm). Maybe they will at least provide open gl es also for Mac OS at least? But better don't count on Apple, they will even stamp over your dead body.
Please forgive my ignorance on this subject. But has the audio industry considered switching to the MoltenVK/Vulkan which is both open source and cross platform?
Orion Platinum, Muzys 2

Post

v1o wrote: Mon Sep 16, 2019 8:53 am
Ju2999 wrote: Thu Sep 12, 2019 12:49 pm I think opengl will be dropped as soon as the first arm based Mac will appear. Maybe interesting detail: ios at least supports open gl es (and already runs in arm). Maybe they will at least provide open gl es also for Mac OS at least? But better don't count on Apple, they will even stamp over your dead body.
Please forgive my ignorance on this subject. But has the audio industry considered switching to the MoltenVK/Vulkan which is both open source and cross platform?
These are only interfaces for existing libraries and you cannot build your software if you don't know if OpenGL or Metal will be supported.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

v1o wrote: Mon Sep 16, 2019 8:53 am
Ju2999 wrote: Thu Sep 12, 2019 12:49 pm I think opengl will be dropped as soon as the first arm based Mac will appear. Maybe interesting detail: ios at least supports open gl es (and already runs in arm). Maybe they will at least provide open gl es also for Mac OS at least? But better don't count on Apple, they will even stamp over your dead body.
Please forgive my ignorance on this subject. But has the audio industry considered switching to the MoltenVK/Vulkan which is both open source and cross platform?
That's our first choice should we have to. But always keep in mind, we're doing plug-ins. We have fewer choices as to what we can use, and sometimes there are conflicts if multiple pieces of software (hosts, plug-ins) use the same technologies/libs/drivers/sub systems in the same process (e.g. namespace problems in ObjC are very common when to symbols have the same name).

Post

Btw. Urs, how about the "SpriteKit"? Afaik it's supported from 10.9, may do the trick, I didn't check it much, but it would probably use OpenGL / Metal depending on what is supported. Not that I'd like to reimplement the graphics, again...
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

v1o wrote: Mon Sep 16, 2019 8:53 amPlease forgive my ignorance on this subject. But has the audio industry considered switching to the MoltenVK/Vulkan which is both open source and cross platform?
Hardware support.

The first Vulkan release was in February 2016, and, while many of the GPUs that existed at the time are supported well, support for GPUs older than that gets sketchy and quick. Particularly take a look at the Intel support – on Windows, the oldest supported GPU generation is Skylake from 2015, so that leaves a lot of people in the dark. NVidia and AMD discrete GPUs have support back to 2012 and then absolutely no fallback for anything older.

That said, I am certainly going to move to Vulkan in the future (either with MoltenVK or the gfx-rs portability implementation) – the question is when. I'd like to have at least 5 years of device compatibility, and that's just not possible right now. I was hoping to start working on this in mid-2020, and I would very much like it if Apple doesn't force my hand into doing it sooner.
owner/operator LHI Audio

Post

mgw38 wrote: Fri Sep 13, 2019 10:46 pm
MeldaProduction wrote: Fri Sep 13, 2019 5:51 pm - I honestly hate Apple and their attitude towards developers.
Whenever there is a discussion about the merit of different operating systems, things have a tendency to get off into very weird directions. A simple mention of a preference can derail any discussion completely. This was not my intention.

My point was actually a very simple one. You asked what the best strategy would be given that Catalina seems to force you into forking the MacOS version of your product into a post- and a pre Catalina variant. That is a perfectly legitimate question that you decided to formulate by adding a number of completely unnecessary emotional attributes which admittedly annoyed me quite a bit.

Speaking as a customer and not as a developer it is important for me that I get the best support I can get for the products I buy. If you feel so strongly about the MacOS ecosystem as you indicate, I can no longer be sure that you are properly supporting your products on that system at all. Your products suddenly lost a lot of their original appeal for me. If you are a developer who hates the system you are developing for, the software you will produce will very likely not live up to its fullest potential.
Interesting points, but I think subtly leaving out and ignoring some things. Your stance seems to be predicated on "As a customer I want X and if I cant get X from you I will go get X somewhere else" - quite reasonable, but entirely ignoring the possibility that X is not available anywhere else. Sure thats not the current case with nearly all Audio software - but it may be the case at some point in the future, and that future may be nearer than you think.

Making OS purchase and usage decisions do have consequences, on the eco-systems of those OSes. I think its clear from this thread that Apple dont respect or help their development community - especially the smaller (often most innovate) members. Sure you may continue to use MacOS for your audio needs and never feel the consequences of Apples behavior - but maybe not if we all decide to stop supporting MacOS. Alternatively we may decide to reflect the costs of developing on MacOS in the price of the software we make available.

So as a buyer I think its only sensible for me to realise that my OS purchase decisions DO have an influence on what else I can purchase and at what price too...in the future, especially when I know the OS developer is non-too-friendly or cooperative with their development community.

Is Apple's approach sensible or silly? Only time will tell.

Also you say: "If you are a developer who hates the system you are developing for, the software you will produce will very likely not live up to its fullest potential." - which seems to entirely place the burden of "potential" at the door of the developer - and I think there are several post here which point out that for a cross-platform code-base the MacOS throws up more problems than its competitors. So again - your(and my) OS choices have an impact on products that are outside the control of the developer of said product, and I think it (again) would be wise to realise this when we make OS purchasing choices.
VST/AU Developer for Hire

Post

Lind0n wrote: Mon Sep 16, 2019 12:52 pm
mgw38 wrote: Fri Sep 13, 2019 10:46 pm
MeldaProduction wrote: Fri Sep 13, 2019 5:51 pm - I honestly hate Apple and their attitude towards developers.
Whenever there is a discussion about the merit of different operating systems, things have a tendency to get off into very weird directions. A simple mention of a preference can derail any discussion completely. This was not my intention.

My point was actually a very simple one. You asked what the best strategy would be given that Catalina seems to force you into forking the MacOS version of your product into a post- and a pre Catalina variant. That is a perfectly legitimate question that you decided to formulate by adding a number of completely unnecessary emotional attributes which admittedly annoyed me quite a bit.

Speaking as a customer and not as a developer it is important for me that I get the best support I can get for the products I buy. If you feel so strongly about the MacOS ecosystem as you indicate, I can no longer be sure that you are properly supporting your products on that system at all. Your products suddenly lost a lot of their original appeal for me. If you are a developer who hates the system you are developing for, the software you will produce will very likely not live up to its fullest potential.
Interesting points, but I think subtly leaving out and ignoring some things. Your stance seems to be predicated on "As a customer I want X and if I cant get X from you I will go get X somewhere else" - quite reasonable, but entirely ignoring the possibility that X is not available anywhere else. Sure thats not the current case with nearly all Audio software - but it may be the case at some point in the future, and that future may be nearer than you think.

Making OS purchase and usage decisions do have consequences, on the eco-systems of those OSes. I think its clear from this thread that Apple dont respect or help their development community - especially the smaller (often most innovate) members. Sure you may continue to use MacOS for your audio needs and never feel the consequences of Apples behavior - but maybe not if we all decide to stop supporting MacOS. Alternatively we may decide to reflect the costs of developing on MacOS in the price of the software we make available.

So as a buyer I think its only sensible for me to realise that my OS purchase decisions DO have an influence on what else I can purchase and at what price too...in the future, especially when I know the OS developer is non-too-friendly or cooperative with their development community.

Is Apple's approach sensible or silly? Only time will tell.

Also you say: "If you are a developer who hates the system you are developing for, the software you will produce will very likely not live up to its fullest potential." - which seems to entirely place the burden of "potential" at the door of the developer - and I think there are several post here which point out that for a cross-platform code-base the MacOS throws up more problems than its competitors. So again - your(and my) OS choices have an impact on products that are outside the control of the developer of said product, and I think it (again) would be wise to realise this when we make OS purchasing choices.
:clap:
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

I know this isn’t helpful, but I’ve spent a few days now porting my OpenGL API to Metal in Obj-C++, and it wasn’t as bad as I thought.

Shaders and stuff freaked me out initially. But once I had a triangle on screen, the rest went smoothly.

I suggest starting with this video, and the hello triangle example projects:

https://developer.apple.com/videos/play/wwdc2018/604/

Obviously it’s necessary with a code design where you can decide between Metal or OpenGL at runtime, for backwards compatibility.
Arne @ noteperformer.com

Post

Wallander wrote: Tue Sep 17, 2019 12:54 pm I know this isn’t helpful, but I’ve spent a few days now porting my OpenGL API to Metal in Obj-C++, and it wasn’t as bad as I thought.
Do you switch between Metal and OpenGL at runtime or compile time? Or do you just ship on Mac so you can go all-in on Metal?

Metal could be a fine API, but that it's single-platform makes it a complete non-starter. I would like to avoid (at all costs) having to roll my own 3D API abstraction layer, which is why MoltenVK, gfx-rs, or bgfx are in the first conversation that needs to happen. Unless we're talking about shipping for only a single platform, of course.
owner/operator LHI Audio

Post

wrl wrote: Tue Sep 17, 2019 9:40 pm
Wallander wrote: Tue Sep 17, 2019 12:54 pm I know this isn’t helpful, but I’ve spent a few days now porting my OpenGL API to Metal in Obj-C++, and it wasn’t as bad as I thought.
Do you switch between Metal and OpenGL at runtime or compile time? Or do you just ship on Mac so you can go all-in on Metal?

Metal could be a fine API, but that it's single-platform makes it a complete non-starter. I would like to avoid (at all costs) having to roll my own 3D API abstraction layer, which is why MoltenVK, gfx-rs, or bgfx are in the first conversation that needs to happen. Unless we're talking about shipping for only a single platform, of course.
Runtime.

I’ve always had an OO code structure where I can choose between different graphics frameworks at runtime (at startup). It’s very convenient.

On PC, users could choose between a DirectX, an OpenGL and a GDI+ ”driver” for compatibility reasons (this was in 2007).

On Mac, I have a Carbon OpenGL driver for 32-bit and a Cocoa OpenGL driver for 64-bit. And now, a Metal driver. And I also have an OpenGL ES driver for iOS.

My plan is to simply detect the macOS version and pick the Metal driver for 10.13 and up. In 64-bit mode only, then, because Metal is 64-bit only.

I only do 2D. Everything from fonts to antialiased lines is done with textures. I realise rolling your own isn’t fun at first, but it makes porting a whole lot easier. It’s only a matter of time before Metal is deprecated as well.

If anything, I would make sure your OpenGL plugin is compatible with Apple’s software rendering mode for OpenGL. I wouldn’t be surprised if Apple kept their software driver, as a fallback solution, or strategy.
Arne @ noteperformer.com

Post

The silly thing here is that even if you're software rendering, you're STILL kinda stuck solving these 3D API problems simply because macOS doesn't really seem to have the equivalent of GDI BitBLT in any form that could compete with the performance of uploading a texture and drawing a single triangle. In this case writing the relevant blit-routines against whatever API is mostly an minor annoyance and the main problem is that you simply can't have a single piece of code that works everywhere, but rather have to either pick an API at runtime, drop support for old systems (which is obviously what Apple would prefer) or accept poor performance everywhere.

Post

mystran wrote: Thu Sep 19, 2019 12:33 am The silly thing here is that even if you're software rendering, you're STILL kinda stuck solving these 3D API problems simply because macOS doesn't really seem to have the equivalent of GDI BitBLT in any form that could compete with the performance of uploading a texture and drawing a single triangle. In this case writing the relevant blit-routines against whatever API is mostly an minor annoyance and the main problem is that you simply can't have a single piece of code that works everywhere, but rather have to either pick an API at runtime, drop support for old systems (which is obviously what Apple would prefer) or accept poor performance everywhere.
Agreed, but also BitBlt only gets you so far. If you want to do lines and fonts, you want transformations, alpha transparency and color blending all at the same time. And I couldn’t be without a clip rectangle, e.g. glScissor.

OpenGL is also the worst offender in terms of being completely unmanaged, and poor consistency in compatibility and stability over different video cards. Direct3D is better in this regard, and Metal also abstracts the GPU.
Arne @ noteperformer.com

Post Reply

Return to “DSP and Plugin Development”