What exactly is involved in cross-platform development these days?

[jonljacobi]

I haven't really paid attention to programming tools and environments in a couple of decades, but I'm assuming some make it easier than others to support x86/ARM, Windows/macOS/Linux.

I'd love to hear from anyone in the know about the options out there, their strengths and weaknesses, etc. Also, which DAWs are based on which.

I've heard of Juce and PortAudio, but that's about it. I just wonder why devs like Tracktion and Bitwig guys, Reaper, Ardour, seem to have little trouble supporting all platforms, while others are limited to Windows/macOS, and still others Windows-only or Mac-only or Linux-only. DAWs such as Logic where it's a deliberate marketing decision aside, of course.

It seems to me that most of the vendors would support all the platforms if it were easy, so I'm figuring it has to be the tools.

[syntonica]

You don't have just cross-platform, but different paradigms on how to handle graphics, user events, etc. However, anyone performing cross-platform dev is going to be using something on the backend that abstracts away the differences so that there is only a single codebase for the actual task at hand.

For plugins, there's Juce and IPlug2, among others. While they'll do applications as well, there's other libraries as well that will handle the graphics, keyboard and mouse, processor differences (SSE vs Neon, e.g.) that can be used together. SDL, Skia, SMFL, Allegro are common libraries for graphics and user events. SIMD support is usually just a simple header of macros

There's also the matter of which language you want to use. If you're doing plugins, you're very much tied to C++. It's very tricky to break out and use a different programming language, although there's frameworks for D, Pascal and probably some others I'm unaware of.

If you wish to use something other than C++, then you need to verify the cross-platform libraries you wish to use are supported--either with wrappers or ports.

Basically, you need to figure out what your end goal is and work backwards from there. Your goal will help to inform your choices of language and backend.

As to applications that are Mac-or Windows-only, that is purely the dev's choice. They've started on their platform and never desired to expand to other platforms, they've developed inhouse tools that only support their platform of choice, or, particularly on the Mac side, they've used tools only available for that platform.

As to which DAWs use which language and tools: FLS is a mixture of at least Delphi and assembly. Since they've added Apple Silicon support, this may now be slightly different. I assume Logic is a mixture off C++ from the original Emagic versions and Obj-C/Swift for newer development. Reaper is C++ and use mostly (all?) in-house tools. Tracktion is Juce-based. Pretty much everything else is C++, although I don't know their tooling. I'm sure other can fill in my blanks.

I hope my shotgun approach helps...

[jonljacobi]

Well, I'm a lot more knowledgeable than I was before... I now have stuff to research. So yes, it helped. I had a program that ran on the Atari ST, Amiga, and finally Windows (C and assembly). The C stuff was no issue at all, the OS conventions were a slight issue, but easy. The switch from 6800 to x86 was harder, but there was so little code involved, it was more the learning process than the actual recoding that took time.

However, it was nowhere near as complex as a DAW. I would think it would be the MIDI/audio engine that would be the major issue. Depending on what that's written in of course.

BTW, I stuck with C because the C++ compilers of the time were extremely inefficient and they increased executable size quite a bit. Plus, I was already so modular and structure driven in my methods that the objects portion really didn't appeal to me. After almost three decades I imagine compilers have improved...

[syntonica]

Modern C/C++ compilers (gnuCC, Clang, MSVC) are awesome! I no longer have to perform stupid coding tricks to fool the compiler into creating faster code. Now, it just knows when it optimizes and I can code clean. C++ has become a big, bloaty mess, but it's helpful to use when you need classes. (Dear C: why can't I stick a method in your struct? Is that so wrong?? Throw us a bone. Namespaces?!?) I just stick to C++11/C99 and the basic libraries.

IIRC, the 68K/PPC chips were both big endian, but now, Intel and ARM are both little endian, so there's no worries about byte swapping. (Well, not until you get to loading old WAV/AIFF files...)

[BertKoor]

[...] assembly [...]
After almost three decades I imagine compilers have improved...

You're right. At that time a fast processor ran at 60 MHz, now any basic processor runs at 2 or 3 GHz.
I hardly see good reasons for inline assembly anymore. The performance gain is not really needed (well, you really don't know until you go profiling your code) and there's far less need to outsmart today's compilers. And if cross-platform code is your goal, then parts in assembly will make that harder.

Regarding the size of executables: most people stopped caring when their primary disk got larger than 100 GB and internet bandwidth was sufficient for 4k video streaming.

[mystran]

[...] assembly [...]
After almost three decades I imagine compilers have improved...

You're right. At that time a fast processor ran at 60 MHz, now any basic processor runs at 2 or 3 GHz.
I hardly see good reasons for inline assembly anymore. The performance gain is not really needed (well, you really don't know until you go profiling your code) and there's far less need to outsmart today's compilers.

I would argue that unless you plan on spending a completely insane amount of time writing and fine tuning that assembly code, there's a pretty good chance that the code any modern compiler will produce out of nice, clean, straight-forward C++ code is going to be faster anyway. You're better spending your time on high-level stuff (eg. better algorithms, better cache layouts) 'cos these will usually give you a much better payoff.

[Tj Shredder]

The most used library for cross platform based development of musical apps is Juce with a huge margin. It was developed to create the Tracktion DAW. For other apps Linux gave us two libraries for that purpose GTK and QT. QT was the first, but wasn’t GPL’d in the beginning which forked the two main Linux GUIs between Gnome (GTK) and KDE (QT). Both libraries are used for many non-musical applications. I think QT wins overall and is the oldest anyway and GPLd since a long time. Juce and QT are dual licensed as GPL would not allow to use it for closed source commercial applications. Juce 6 made it easier for independent developers with little revenue to also use it for close sourced development as a free starting point. The license fee is based on the revenue of the company which is a fair solution… Juce switched ownership several times in its history, currently owned by Pace (iLok) the copy protection company. Nothing to worry about for open source programmers, because if its once open sourced it will be forever…

[jonljacobi]

I have no intention of programming ever again. Completely burnt on the idea. I simply want to get an idea of why only a few DAWs make it to Linux.

As to assembly, that’s what I started with (dip switches actually...) and what I always found the most satisfying, however, I’d never use it now. Far too time consuming as software has become more complex. No need either as computers are so much more powerful.

Thanks for all the info.

[Tj Shredder]

As long the better ones make it to Linux, all is good. Less choice can be a relief…
Anything coded with Juce should be easy to compile for Linux, I guess most fear to test it there… Also copy protection might be an issue as often that isn’t made in house and the big names don’t support it. Maybe this will change with Pace as they own now Juce…

[audiojunkie]

I have no intention of programming ever again. Completely burnt on the idea. I simply want to get an idea of why only a few DAWs make it to Linux.

If you're willing to put in the work of deep, detailed reading, I will point you to a thread that will explain in exacting detail precisely why commercial/closed-source software development is so difficult in Linux. The situation is getting better, and there are development best practices that help. But seriously, this thread is exactly what you are wanting to know:

https://forum.cockos.com/showthread.php?t=259967

Best

[TVbene]

What about iOS? I only know of Roland Zenbeats that‘s cross platform including iOS — projects don‘t need to be imported like with cubase/cubasis. Is there some added difficulty? Performance issues on older/cheaper iPads would be a problem I guess. Something touch oriented like Bitwig would be nice on an iPad Pro, though.

[jonljacobi]

Thnx audiojunkie.

[audiojunkie]

Thnx audiojunkie.

You’re welcome! I only barely learned about this stuff myself, and I found it very enlightening! It gives me a whole new view on how the state of Linux is, and I feel like I now have a much bigger picture of what is going on.