3 ms·

I’m considering massively successful as two companies that have literally been selling versions of the same software for Mac and PC software for over 35 years

I’m considering massively successful as two companies that have literally been selling versions of the same software for Mac and PC software for over 35 years. Another poster cited this as far as how much “native” code is in PhotoShop > But Russell still has MacApp to contend with — it most recently flared up during the Mac Cocoa conversion. Millions of lines of code had to be changed, and for a time the entire team was engaged on the project. And let’s talk about ProTools. It is even in a worse position than Adobe with respect to being able to use cross platform frameworks. The backend leverages Mac and Windows specific APIs https://www.pro-tools-expert.com/production-expert-1/is-there-any-difference-between-mac-and-pc-for-pro-audio-in-2022 https://www.pro-tools-expert.com/production-expert-1/is-ther... It specifically leverages Core Audio on the Mac.

PaulDavisThe1st 4y ago
> same software for Mac and PC software for over 35 years You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so. CoreAudio is not a "front-end" toolkit/framework/library. You cannot do audio or MIDI I/O on any platform without ultimately talking to the platform APIs for that (not totally dissimilar to how all GUI toolkits ultimately having to talk to some low level drawing/event API). The backend of every DAW, audio editor, audio player etc. uses platform-specific APIs, either directly via their own platform-specific code, or via a wrapper such as JUCE, or RtAudio (JUCE is extremely popular these days, though it is also a large cross-platform GUI toolkit that is increasingly dominated startup audio software development). None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.
- mroche 4y ago
  > None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about. This was the basis for my comment. It's not possible escape native APIs, but what differs will be how you consume them. You can either choose to use them directly (true native) or you can use a toolkit that abstracts the various backends. This provides you a single development layer across all platforms while the toolkit itself is what handles the access to the underlying platform native APIs. So it's not on you the vendor to keep up with what's changing at the OS layer, but the toolkit. Obviously there are trade offs with all methods, and they can be mixed and matched as needed. For example, Qt is not a GUI toolkit like GTK, but a platform toolkit providing APIs for a whole host of functionality beyond visual representation. Does that mean you need to use Qt's multimedia package to handle video or such? Absolutely not, but for the features it provides that are shared across platforms it can make things easier to develop (this is purely for example purposes, I've never authored anything with Qt Multimedia).
- scarface74 4y ago
  > CoreAudio is not a "front-end" toolkit/framework/library What difference does it make? You still can’t have a “write once run anywhere”. You still have to have a dedicated team to develop each app.
  - mroche 4y ago
    Do web developers generally create their own audio subsystems or use platform native APIs directly? No, those aspects are handled by the browser which does the heavy lifting for them, allowing for a write-once-run-anywhere{-that's-supported} experience. The cross-platform toolkits (like Qt, JUCE, etc) do the same thing; they talk to the platform APIs on your behalf. What kind of expertise or team structure you require to build your application for various platforms really depends on what level of the stack you want to author against.

PaulDavisThe1st 4y ago

> same software for Mac and PC software for over 35 years You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so. CoreAudio is not a "front-end" toolkit/framework/library. You cannot do audio or MIDI I/O on any platform without ultimately talking to the platform APIs for that (not totally dissimilar to how all GUI toolkits ultimately having to talk to some low level drawing/event API). The backend of every DAW, audio editor, audio player etc. uses platform-specific APIs, either directly via their own platform-specific code, or via a wrapper such as JUCE, or RtAudio (JUCE is extremely popular these days, though it is also a large cross-platform GUI toolkit that is increasingly dominated startup audio software development). None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.

mroche 4y ago
> None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about. This was the basis for my comment. It's not possible escape native APIs, but what differs will be how you consume them. You can either choose to use them directly (true native) or you can use a toolkit that abstracts the various backends. This provides you a single development layer across all platforms while the toolkit itself is what handles the access to the underlying platform native APIs. So it's not on you the vendor to keep up with what's changing at the OS layer, but the toolkit. Obviously there are trade offs with all methods, and they can be mixed and matched as needed. For example, Qt is not a GUI toolkit like GTK, but a platform toolkit providing APIs for a whole host of functionality beyond visual representation. Does that mean you need to use Qt's multimedia package to handle video or such? Absolutely not, but for the features it provides that are shared across platforms it can make things easier to develop (this is purely for example purposes, I've never authored anything with Qt Multimedia).
scarface74 4y ago
> CoreAudio is not a "front-end" toolkit/framework/library What difference does it make? You still can’t have a “write once run anywhere”. You still have to have a dedicated team to develop each app.
- mroche 4y ago
  Do web developers generally create their own audio subsystems or use platform native APIs directly? No, those aspects are handled by the browser which does the heavy lifting for them, allowing for a write-once-run-anywhere{-that's-supported} experience. The cross-platform toolkits (like Qt, JUCE, etc) do the same thing; they talk to the platform APIs on your behalf. What kind of expertise or team structure you require to build your application for various platforms really depends on what level of the stack you want to author against.