Dorico on Linux?

All of the above in some cases. The binary thing is solved by my mentioned snaps, flatpaks or appimages. They’re “universal” binaries.

“Linux” is any operating system based on the Linux kernel. (A kernel is the very core of every operating system.)
There are hundreds of different distributions, that is, different collections of libraries, support software and desktop environments built on top of the Linux kernel.

KDE Plasma/GNOME are two widely used desktop environments. The desktop environment provides a GUI to some parts of the OS and various additional software. (Interestingly, the KDE framework is built on top of Qt.)

Unfortunately, all of this can be quite a mess: If you want your software to run on any given distro you need to make sure it has the libraries you’re linking against in the right version.

There may be various reasons. There’s often quite a substantial number of contributors. With smaller projects the number of dependencies is likely rather small. The big distros usually have a great assortment of prebuilt software available as packages. In other cases the compilation step may be part of the installation and you just don’t notice it: They ship the source code and link/build it with the compiler on your machine. But much as I’d love to take a peek, Steinberg can’t really distribute their source code, can they? :slight_smile:

I guess it wouldn’t be impossible to maintain a Dorico build for Debian/Ubuntu based distros – if it was worth the effort for Steinberg, that is. One can hope…

Oh that’s so early 2000s. These days it’s all about systemd vs init.d :laughing:

The basic reason is that in open source applications with “no budget”, having bugs (and not fixing them for years) doesn’t cost anything either.

If a software app is “free”, and your main interest as a Linux hobbyist is actually getting it to run at all rather than using it to do work, you don’t really mind how buggy it is or how many hoops you have to jump through.

If you pay a few hundred dollars for some software in order to earn money by using it for 40 hours a week, your expectations are different.

Yes. Also, don’t forget that most open-source software wouldn’t exist if the creators couldn’t make a living from programming elsewhere. It makes sense to pay specialists for creating systems that “just work” if you are using computers to actually do stuff!

An extreme example of that is the Gnu compiler collection.

That isn’t really an open source project at all. The main contributors work for big companies that sell proprietary versions of Unix and the hardware to run it (e.g. IBM, Cray Research, etc) and the development is paid for by those companies for their own use. Releasing an open source version is just a bit of philanthropy.

Of course this has the downside that “user requests” that don’t align with the needs of the authors’ employers tend to get ignored, but life’s never perfect.

Another general feature of Linux Distros is that what they contain can be literally years out of date, so if you want to use an application for “real work”, you still have to find the latest version and install it yourself (and then figure out why it doesn’t work, if it depends on other components of the distro which are out of date…)

Fwiw Martin, I tend to agree that with flatpaks, snaps, or appimages, putting out a half-decent distro-agnostic version of Dorico is not at all insurmountable. In fact, I’m honestly of the opinion that Dorico probably runs in WINE as it is already. The problem (well, the first of several) is that the licensing software definitely doesn’t. WINE doesn’t support dongles, and I’ve only once seen a random user on a random forum from many years pre-Dorico claim to have gotten Steinberg’s e-licenser to work with WINE, sans dongle of course.

So, if we wanted a version of Dorico for Linux, yes, it would be another version to maintain and support, but it would also require Steinberg to create a licensing method for Linux, and given how long it’s been since we were promised a new licensing solution for their already supported versions, coupled with the fact that there’s a fairly common, albeit entirely unfair, perception of Linux as being just for hackers and pirates and thus inherently not secure for protecting paid software, I just could never really see that as being in the cards. Mayhaps the new licensing system will accidentally work on Linux, but don’t hold your breath.


The easiest and most boiled down way that I’ve ever found to explain all the different flavors of Linux to non-linux folks is by saying there are basically two main parts to any linux distro. There’s your desktop environment and there’s your package management/repositories (obviously, it’s much more complicated than this, but we’re boiling things waayyy down here).

The desktop environment essentially is a collection of software pieces that determine the look and feel of your desktop and how you interact with your machine; it provides you with sound, display management, window management, wallpaper, taskbar, context menus, etc… As others have mentioned, KDE and GNOME are just two different desktop environments among plenty of other popular choices like MATE, LXQt, Xfce, Budgie, etc. Oh, and on top of all that, most desktop environments are pretty durn customizable, so you could actually get a lot of them to look and feel pretty similar, or wildly different and idiosyncratic, whatever suits your fancy (and how much RAM you’d like to spare, lol).

Your package management system and your system’s repository list determine how software is installed and how up-to-date that software will be; one of the main considerations here, with regard to all the different distros you might choose, being stability vs. up-to-date-ness (some other considerations being openness vs. proprietaryness and the like). Software is installed on Linux differently, much more like the Google Play Store or the iOS Appstore. You just tell your package manager which software you’d like to install and it installs it. Imagine if with an Android phone though, you could choose between two different versions of the Google Play Store, one where the software is bleeding edge but not always stable and one where software is suuuper stable but maybe a little bit old sometimes. That’s the main distinction between two of the more popular distro families of Linux, Debian (which includes Ubuntu, Linux Mint, and several other popular variations) which is very stable and Arch (which includes Manjaro and others) which is super bleeding edge.

So it’s a lot like a car. You’ve got your internals (your brakes, engine, etc.) and you’ve got your cosmetics (your body, paint job, radio, steering wheel, etc.). If we continue with the analogy, some people might be running the internals of a drag racer with the body of a ’94 Honda Accord or vice versa. Then you’ve got your pure Arch users who literally have just an engine, some wheels, and a seat, and somehow feel that’s a better way to live life. No judgement. But yeah, your desktop environment is your cosmetics, and your package management system is what’s under the hood. Like I said, significantly simplified, but it’s a decent way to wrap your head around it if you haven’t been able to do so before, more or less…

Too many other music software programs, virtual instruments, and plugins do not run on Linux, except maybe using emulation (although I wouldn’t necessarily feel comfortable going that route). Almost every semi-pro or pro musician working with computer music is stuck using Mac or Windows because then you can run basically any major DAWs or samplers or other plugins that you want. Especially if you are doing commercial music and the computer rendition is the end product, you can’t just say “yeah, sorry, that sound isn’t very good, but the best library/sampler for this is only available on Windows or Mac, so I can’t run it because I use Linux”.

It becomes a circular issue - developers find it hard to justify releasing and supporting Linux versions for music software programs since so few musicians use Linux currently, and this in turn discourages musicians from adopting Linux, etc.

That certainly explains why buggy open source software can be programmed for many OSs, it doesn’t explain however why good open source software gets programmed for many OSs, why commercial software gets ported to Linux and why there’s also buggy commercial software for either platform :man_shrugging:t2:.

:bulb:

What do hackers and pirates have to do with serious musical composers? Dorico for Linux is not Linux, it’s Dorico. The perception of Dorico is independent of its platform and is attracts the people that are actually gonna use it. Were it not the case, that proprietary software is not secure under Linux, there wouldn’t be any commercial software available for it. Hackers and pirates exist in Windows as well. Specially hackers are probably in a totally different field. Maybe you can elaborate your point more. I really don’t see the connection to Dorico.

A licensing system is a software as well that probably uses encryption. I would be surprised that something like that, for a system that has actually a very strong security and knows about encryption, is not possible to do for Linux. If anything, I’m inclined to think that a fairly insecure OS like Windows systems are more the target of hackers (since it’s probably less difficult to hack… And indeed, Windows systems get more often hacked).

How much engraving quality does a commercial musician need anyways? I’d find it surprising that Dorico is indeed popular among commercial music makers. If you’re not making scores for people to play, but you need to do pop music with VSTs, I fail to see how these musicians could use Dorico at all. Ironically, the commercial part of music software for Linux that has most expanded in these years are DAWs, mainly used for pop music. Go figure.

My point is just that some companies are reticent to develop software for Linux because they worry that people will use their software without paying for it and that Linux will somehow magically help facilitate this in some way, shape, or form. Like I said, this perception in entirely unfair, but it certainly exists. Whether or not Steinberg feels this way, I couldn’t say.

In any case, I’m on your side. The only thing that keeps me on Windows is Dorico, and I’d love for that to change; I just don’t see it happening any time soon.

…and if it does ever happen, with 99.99% certainty, it’ll be because somebody got it to run in WINE, not because Steinberg saw fit to give us a native Linux version.

Question to those of you who know about this stuff (because I really really don’t):
Dorico is built on Qt. Cubase isn’t. Dorico’s audio engine borrows from the Cubase audio engine. Would Dorico’s audio engine have to be rebuilt for Linux?

Have you ever met a “serious” music student who doesn’t know somebody who uses hacked software, even if they don’t admit to using it themselves?

By commercial musicians using Dorico, I wasn’t really thinking about pop, but rather film music, for instance. Many film composers would prefer working in a hybrid environment that emphasizes notation, since notation is still (at least I feel) the clearest way of giving you the vertical view of your harmony and orchestration, compared to separate piano rolls which overemphasize the linear aspects. I would certainly prefer doing film composition in Dorico if I could do CC shaping, velocity adjustments etc with the same ease as in Cubase.

Qt is all about the user interface. The audio engine itself doesn’t have a user interface. It doesn’t display any graphical windows of its own, on either MacOS or Windows.

The VST instruments that the audio engine runs for you do have user interfaces, but they aren’t necessarily written by Steinberg, and they don’t necessarily use Qt. For example Native Instruments (Kontakt, etc) doesn’t support Linux, period.

Steinberg released its VST3 development kit for Linux, so I guess in principle the audio engine could run natively on Linux, and VST instruments could be ported to run as well. There are a few (e.g. Pianoteq) which run on Linux already.

One basic weakness of the design of Linux is support for new types of hardware, so you may have a limited choice if you want to use an audio interface, hardware control surface, etc, unless you can get the low level software interface included in the Linux kernel - and that decision is pretty much entirely under the personal control of Linus Torvalds, who doesn’t have a reputation for suffering fools (or people he thinks are fools) gladly when they come along with new ideas!

Thanks, Rob.

On the bright side, there’s a whole lot of stuff that’s “not supported” on Linux but works just fine. Focusrite audio interfaces supposedly work decently, since they’re class compliant, for instance, despite not being supported. And perusing the Native Instruments forum seems to indicate that their stuff works generally fine as well. The situation is not so dour such that the only recourse for poor Linux users is to petition The Dear Leader Torvalds to support their hardware; probably usually easier to just ask the hardware manufacturers themselves to make drivers. As is the case with any OS or piece of hardware or software, one should always do at least a little bit of research to make sure a thing will work with their system. And yes Linux can definitely be inadequate for certain sorts of specialists who need a whole ecosystem of software and hardware to work together properly, e.g. musicians, but depending on your needs, it can also be perfectly adequate (you know, just like Dorico only a few years ago). I know you know all this Rob, so really I’m directing this comment to the general curious forum user :wink:

Cheers!