Come on Native Instruments! Think Linux!

One doesn't mean the other and unfortunately, this is really not on our radar at all. It's hard enough to maintain Win and Mac, I don't see our teams addings Linux support anytime soon.

 

Although disappointing at least that's a clear answer ;-) too bad though :-(

 

A real shame honestly Matt.
I've been a DJ for 10+ years and while I own a mac for Traktor, that's literally the line. I don't have a choice and neither does anybody else (not using windows again, experience was poor.)
I actually use a Linux-Based Desktop OS for literally everything else on my PC: Gaming (Yes real gaming with Steam), Consuming entertainment/browsing, Work/General Productivity. If the option to run Traktor 3, (which is a Qt based application by the way and could be cross compiled) I know personally what i'd be doing. I can't speak for everyone else, but I doubt i'm alone here.

Hell i even use Linux on my Live Setup, the live streaming rig runs Ubuntu Studio which has a real-time kernel and JackD Audio baked in so i can do real-time DSP with low latency etc for streaming audio/video on a weekly basis.

It's a shame the S4 Mk3 is HID only and (STILL) Lacks Midi support, because I actually got traktor partially working in Wine with midi control from the Denon Prim 4 I have here. (sidenote that's also an embedded linux device) I just wouldn't want to use that in a live/production setting at this time.

The biggest shameof it all really is the lack of MIDI for the flagship product, the S4 Mk3.. a beast of a mixer basically now a 700 buck paperweight because of the lackluster driver support and absent midi implimentation. Hell if NI released even a basic HID Driver or something for the device on Linux, the community at large would do the rest and probably get it running in software like Mixxx and other surfacing offerings out there.. i could probably even further my efforts with the wine support and put up a reliable bottle config on Lutris or something that ensured traktor worked properly.

 

Qt is only handling the front end, not the back end. So it being cross-compilable doesn't really fully help in running it on Linux.

 

Right, but it does take care of one of the common hurdles presented if say it was instead using WinAPI or Cocoa/Metal instead. the rest is just recompiling the 'back end' which at a guess is likely to be one of the C languages which is already platform agnostic anyway. the rest is down to the more platform specific caveats such as sound interface support, HID and MIDI implementation etc. I very much doubt it's impossible

 

I never said it is impossible!

Also, C/C++ itself might be platform-agnostic, but the libraries used might not be...


At any rate, Matt's reply is where things stand.

 

Just logging on to voice my support, and help put it on your radar. I'm currently running Macs in my studio, but would very much like to switch over to Ubuntu Studio and REAPER. NI support would be all I need at this rate...

 

+1 for Linux support.
Now with Pipewire as a new multimedia framework for audio/video, I don't need to use JACK anymore for low-latency audio.
I'd love to see some alpha/beta NI software coming to Linux, even without official support. The community could at least test the software on Linux and try to solve the problems on their own (as they already do nowadays).

 

Nope.

There aren't enough Linux users in the market to justify this, and it would be a support catastrophe as most people are not running on anything even approximating a standard configuration on those platforms - if we can even say such a thing exists, practically speaking. Part of what makes Windows and macOS easy to support is the fact that a lot of assumptions can be made in development. Things we take for granted on Windows and macOS suddenly become issues on Linux...

Are they running Ubuntu? SUSE? Fedora? Slackware? What packages do they have installed? What versions of those packages? What Window Mangers? What Kernel version? What version of GCC and GLIBC? Are they using Nvidia/AMD/Intel's drivers are proprietary drivers?

This has gotten better on Linux over the past couple of decades, but it's still pretty terrible from a consumer software standpoint.

This is fine with self/community-supported F/OSS. It is not fine with software a commercial developer has to support. There are too many moving variables. It's a nightmare.

When Linux was "newer" back in the 1999-2001+ timeframe, lots of companies tried porting their software over from it. 95% of them pulled back for this very reason. The only way to ensure compatibility and be able to support it properly, for some, was to basically roll their own Linux distros (Corel did this, for example).

That's the unfortunate issue with Linux. Unless you support only a handful of enterprise/LTS distros (which users don't like to run, as they tend to be very conservative in terms of package versions and updates), it becomes a support nightmare.

You have 20M users. 500k of them are Linux users. But 85% of your support and maintenance is going to the 500k while the other 19.5M users pay the price for it.

 

If NI was a company with a big dev pool like MS, Google or Amazon it could make sense to think about Linux.
Regrettably and obviously they have no big dev pool but a huge Maschine universe to maintain. Otherwise we wouldn't have to wait month and years for certain bugfixes or updated features.
Everyone can experience how long they struggle with OS updates for Win and Mac platforms.

 

The system configuration the developers test against to certify a product on Linux can be WILDLY dissimilar to what the users reporting problems are running. There can be dozens of moving targets. Windows and macOS are more standardized as platforms. You don't have people running 10 different Kernel Revisions and 5 different revisions of the Window Manager, among other things.

This makes them, from a developer's standpoint, more reliable targets - and from a business standpoint, cheaper targets. Support is not free, and people need to be paid for the time they spend investigating, troubleshooting, and fixing problems. If a product costs more to support, it often ends up costing more to purchase.

The F/OSS market thrives on Linux largely because it shirks this requirement and puts that onus on the users themselves. In the Enterprise space, Linux is monetized largely via support contracts, and the machines that run web servers are not managed in the same way a home studio PC is or would be.

I also agree with EvilDragon - people here seem to have an incredibly surface-level view of what it takes to move complex software across platforms.