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

Plug-in hosts and other software applications discussion
jonljacobi
KVRAF
1776 posts since 16 Jan, 2013 from USA

Post Wed Dec 08, 2021 10:13 am

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.

User avatar
syntonica
KVRian
1257 posts since 25 Sep, 2014 from Specific Northwest

Post Wed Dec 08, 2021 12:35 pm

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... :lol:

jonljacobi
KVRAF

Topic Starter

1776 posts since 16 Jan, 2013 from USA

Post Wed Dec 08, 2021 12:57 pm

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... ;-)

User avatar
syntonica
KVRian
1257 posts since 25 Sep, 2014 from Specific Northwest

Post Wed Dec 08, 2021 7:20 pm

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...)

User avatar
BertKoor
KVRAF
13337 posts since 8 Mar, 2005 from Utrecht, Holland

Post Wed Dec 08, 2021 11:25 pm

jonljacobi wrote:
Wed Dec 08, 2021 12:57 pm
[...] 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.
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

mystran
KVRAF
6748 posts since 12 Feb, 2006 from Helsinki, Finland

Post Wed Dec 08, 2021 11:46 pm

BertKoor wrote:
Wed Dec 08, 2021 11:25 pm
jonljacobi wrote:
Wed Dec 08, 2021 12:57 pm
[...] 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.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
Tj Shredder
KVRAF
6555 posts since 6 Jan, 2017 from Outer Space

Post Thu Dec 09, 2021 6:05 am

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
KVRAF

Topic Starter

1776 posts since 16 Jan, 2013 from USA

Post Thu Dec 09, 2021 9:56 am

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.

User avatar
Tj Shredder
KVRAF
6555 posts since 6 Jan, 2017 from Outer Space

Post Thu Dec 09, 2021 11:48 pm

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…

User avatar
audiojunkie
KVRAF
3181 posts since 19 Apr, 2002 from Utah

Post Fri Dec 10, 2021 9:09 am

jonljacobi wrote:
Thu Dec 09, 2021 9:56 am
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
C/R, dongles & other intrusive copy protection equals less-control & more-hassle for consumers. Company gone-can’t authorize. Limit to # of auths. Instability-ie PACE. Forced internet auths. THE HONEST ARE HASSLED, NOT THE PIRATES.

TVbene
KVRist
75 posts since 6 Nov, 2017

Post Fri Dec 10, 2021 10:10 am

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
KVRAF

Topic Starter

1776 posts since 16 Jan, 2013 from USA

Post Tue Dec 14, 2021 3:05 pm

Thnx audiojunkie.

User avatar
audiojunkie
KVRAF
3181 posts since 19 Apr, 2002 from Utah

Post Wed Dec 15, 2021 11:27 am

jonljacobi wrote:
Tue Dec 14, 2021 3:05 pm
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. 🙂
C/R, dongles & other intrusive copy protection equals less-control & more-hassle for consumers. Company gone-can’t authorize. Limit to # of auths. Instability-ie PACE. Forced internet auths. THE HONEST ARE HASSLED, NOT THE PIRATES.

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”