Request for native Linux Support

[ThomasHelzle]

While I'm not sure how much commercial sense it would make at this moment in time, it would be amazing to have the u-he range available on Linux!

Cheers,

Tom

[abique]

that's actually exactly the problem with Linux. with Mac or Windows, they have different events systems, but at least they have *ONE* event system and *ONE* way of doing things that's guaranteed to be supported on any system. with Linux you're forced to either support multiple (GTK and Qt/KDE, maybe something more exotic), or shut yourself out of one of the markets. granted, software works in different environments, and audio plugins probably have less problems with feeling native on the OS since UI's are completely custom in the first place and the rest is provided by the DAWs, but still there's two popular UI toolkits and desktop environments (and quite a bunch of not-so-popular ones), there's a few DSP plugin formats (VST, LADSPA, LV2), and, most importantly, lots of distributions that are slightly (or substantially) incompatible with each other for no apparent reason, with different versions of desktop environment, or different versions of libabc and libxyz (or worse, libabc compiled with different compilation flags), and the kernel and the sound drivers, and with or without JACK or realtime kernel support, or this, or that. in other words, while i would love to see some great quality Linux plugins, truth is that for a developer, unless your target market is other developers, Linux is a nightmare.

For the event system, I totally disagree. Win32 events system is old school. You really don't want to use it. Everybody knows that it is an anti-pattern, and modern applications should use signal/slot mechanism for GUI.

For the portability issue, you're running into it for sure when using OS specific stuff... Qt taking care of those.

For the UI consistency, I use openbox, I have both qt and gtk application, they're styles which makes qt and gtk looks the same, anyway, u-he plugins use custom drawn UI, except for the license prompt, which you use only once.

For the plugin format VST just works and we do not need more than that.

For the third parties, you can bundle them, link statically, etc... If you choose to use libs which the author does not understand what is binary compatibility or soname, then you'll run into issue for sure. But you can't say that standard/system/critical libraries are subject to these issues nowadays.

Some people succeed in distributing binary VST, or even more complicated: DAW. And they distribute a single archive.

More over #lad@freenode or the mailing list is a place to find help if you run into issues.

[abique]

While I'm not sure how much commercial sense it would make at this moment in time, it would be amazing to have the u-he range available on Linux!

I would bet that if you bring Linux support, you'll sell more than 20 licenses pretty quickly.

[ThomasHelzle]

While I'm not sure how much commercial sense it would make at this moment in time, it would be amazing to have the u-he range available on Linux!

I would bet that if you bring Linux support, you'll sell more than 20 licenses pretty quickly.

[abique]

While I'm not sure how much commercial sense it would make at this moment in time, it would be amazing to have the u-he range available on Linux!

I would bet that if you bring Linux support, you'll sell more than 20 licenses pretty quickly.

Well, I think that 20 licenses covers the development costs, and helps a lot Linux to become an audio production system. It is very worth in my opinion

[Burillo]

For the event system, I totally disagree. Win32 events system is old school. You really don't want to use it. Everybody knows that it is an anti-pattern, and modern applications should use signal/slot mechanism for GUI.

i meant the "event system" in a general sense, not referring to win32 events.

For the portability issue, you're running into it for sure when using OS specific stuff... Qt taking care of those.

...so all those who run a GTK-based distro will have to install Qt first, and vice versa. good luck figuring out what's wrong and why the plugin isn't loading if you haven't. i will, you will, average Joe musician? come on.

For the UI consistency, I use openbox, I have both qt and gtk application, they're styles which makes qt and gtk looks the same, anyway, u-he plugins use custom drawn UI, except for the license prompt, which you use only once.

UI is not the only thing that's handled by GTK/Qt. there's file access, network access, config paths and whatnot.

For the plugin format VST just works and we do not need more than that.

there's a lot of background processes to a VST plugin that's any more complex than OnePingOnly.

For the third parties, you can bundle them, link statically, etc...

...so that each plugin takes up 50 megs of space or more, each of them has its own libraries that are loaded into memory and aren't shared between processes (i.e. memory use skyrockets with more plugins in use)... yeah, right, that'll work.

If you choose to use libs which the author does not understand what is binary compatibility or soname, then you'll run into issue for sure. But you can't say that standard/system/critical libraries are subject to these issues nowadays.

that's the thing - there are no "standard" libraries. each distro decides on what is standard. while i agree there's certain consistency and backwards compatibility to system libraries, the problem still stands.

Some people succeed in distributing binary VST, or even more complicated: DAW. And they distribute a single archive.

kudos to them, but i'd say it's not scalable. it's one thing to require that for a DAW. it's another to require it for every plugin.

[abique]

For the event system, I totally disagree. Win32 events system is old school. You really don't want to use it. Everybody knows that it is an anti-pattern, and modern applications should use signal/slot mechanism for GUI.

i meant the "event system" in a general sense, not referring to win32 events.

For the portability issue, you're running into it for sure when using OS specific stuff... Qt taking care of those.

...so all those who run a GTK-based distro will have to install Qt first, and vice versa. good luck figuring out what's wrong and why the plugin isn't loading if you haven't. i will, you will, average Joe musician? come on.

For the UI consistency, I use openbox, I have both qt and gtk application, they're styles which makes qt and gtk looks the same, anyway, u-he plugins use custom drawn UI, except for the license prompt, which you use only once.

UI is not the only thing that's handled by GTK/Qt. there's file access, network access, config paths and whatnot.

For the plugin format VST just works and we do not need more than that.

there's a lot of background processes to a VST plugin that's any more complex than OnePingOnly.

For the third parties, you can bundle them, link statically, etc...

...so that each plugin takes up 50 megs of space or more, each of them has its own libraries that are loaded into memory and aren't shared between processes (i.e. memory use skyrockets with more plugins in use)... yeah, right, that'll work.

Does Juce answer all these points? Juce is not available by default on Windows or Mac, and I don't that TAL or D16 Groups have issues to distribute their plugins.

If you choose to use libs which the author does not understand what is binary compatibility or soname, then you'll run into issue for sure. But you can't say that standard/system/critical libraries are subject to these issues nowadays.

that's the thing - there are no "standard" libraries. each distro decides on what is standard. while i agree there's certain consistency and backwards compatibility to system libraries, the problem still stands.

Most users use common distro (ubuntu, fedora, suse) which are compatible enough with each other. If you're using something else then you'll probably be able to solve a missing dependancies like Qt.
Bitwig chose to support ubuntu and only distribute a .deb. Everyone is fine with it and able to use it, adapt the package (which solves the deps issue).

OK maybe it requires a bit more reflexion to distribute for Linux, but you just have to do it once. You can also copy those who succeed in doing it.

[UncleAge]

While I'm not sure how much commercial sense it would make at this moment in time, it would be amazing to have the u-he range available on Linux!

I'm not on Linux. But before I would consider it as a platform u-he and quite a few other devs would have to support it.

I am increasingly unhappy with the direction Apple and Microsoft are heading with their OS'es. It would be awesome to have a Linux solution that worked well.

[chk071]

While I'm not sure how much commercial sense it would make at this moment in time, it would be amazing to have the u-he range available on Linux!

I would bet that if you bring Linux support, you'll sell more than 20 licenses pretty quickly.

Well, I think that 20 licenses covers the development costs, and helps a lot Linux to become an audio production system. It is very worth in my opinion

Apart from that i doubt that it will cover develpoment costs (the costs for developments are only half the truth, you have to give support too, which, in the case of a Linux version, could become a big PITA), i also think that u-he first of all is a company making audio software, not a foundation with the aim of advancing Linux as a OS. So, the thought of a Linux version, which could cost more than you can gain with it, is quite illusionary IMO. It'd probably also mean that you have to hire additional people who are familiar with the OS, and the native plugin formats.

[danboid]

I would like to refer Burillo and the U-he devs to the Loomer plug-ins. I think they use JUCE so that certainly simplifies porting to Linux but they only have to create / distribute two 4MB (in the case of Aspect) tarballs - one for 32bit Linux and one for 64bit. Aspect has worked perfectly under every Linux distro and DAW I've tried it under - just copy the .so into your VST dir and go. Absolutely no more difficult than installing and using a plugin under Windows or OSX.

Loomer have proved to me that most if not all of Burillos concerns are invalid but I suppose a lot of this (chances of Zebra and friends getting ported to Linux) boils down to what toolkit U-he chose for their GUIs. If it doesn't support Linux then we're prob out of luck.

[Burillo]

Does Juce answer all these points? Juce is not available by default on Windows or Mac, and I don't that TAL or D16 Groups have issues to distribute their plugins.

i'm not familiar with JUCE enough to answer that question. but JUCE ain't Qt, it's much smaller in size and the task it sets out to achieve is much more limited. also, unlike Qt, JUCE is dual licensed with GPL/commercial (Qt and GTK are LGPL, which means they can be freely used by closed-source software, as long as you don't make modifications to the libraries themselves), so you have to either open-source your plugin, or obtain a license. Qt, on the other hand, offers free development environment and more liberal licensing, but is a bit of a moving target (especially since recently when all the development has shifted to Qt 5 but the majority of software out there still targets Qt 4).

Most users use common distro (ubuntu, fedora, suse) which are compatible enough with each other. If you're using something else then you'll probably be able to solve a missing dependancies like Qt.
Bitwig chose to support ubuntu and only distribute a .deb. Everyone is fine with it and able to use it, adapt the package (which solves the deps issue).

fair enough, but that kinda kills the purpose of switching to Linux - you're now beholden to Ubuntu instead of Windows or OS X. arguably Ubuntu is heading in the wrong direction as well (last few years especially - lots of fun to be had with looming switch to Mir), so there isn't much point in picking one over another.

OK maybe it requires a bit more reflexion to distribute for Linux, but you just have to do it once. You can also copy those who succeed in doing it.

Linux landscape actually changes much more rapidly than Windows or OS X (okay, perhaps not OS X, but you get the point). so if anything, actually *shipping* something for Linux is not a one-off process. even with Ubuntu you'll have to ship a new package every six months (unless you're targetting only LTS, which majority of people don't use), same with other distros. it may be less so for one thing than it is for other (arguably for plugins it's less of a concern because they aren't full-blown applications and hence may render most of my criticisms invalid - i don't have experience developing plugins, only bigger pieces of software) but it's still something to be considered.

[Urs]

I suppose a lot of this (chances of Zebra and friends getting ported to Linux) boils down to what toolkit U-he chose for their GUIs. If it doesn't support Linux then we're prob out of luck.

We have our own toolkit that interfaces to CoreGraphics on Mac, and draws into a bitmap on PC. Latter could probably be adapted to whatever windowing device exists on Linux (well, that's the actual problem, isn't it? How many windowing systems would we need to support?). We would also need to write a window class to deal with events/signals and we would need to abstract the file system. Then we'd need a solution for installers, an automated build system on a whole lot of things that I can't even imagine right now.

It might not be very complicated, but it might take well over a month, probably more than two. We would need to make a six-digit revenue from this to justify two months of work

[abique]

I suppose a lot of this (chances of Zebra and friends getting ported to Linux) boils down to what toolkit U-he chose for their GUIs. If it doesn't support Linux then we're prob out of luck.

We have our own toolkit that interfaces to CoreGraphics on Mac, and draws into a bitmap on PC. Latter could probably be adapted to whatever windowing device exists on Linux (well, that's the actual problem, isn't it? How many windowing systems would we need to support?). We would also need to write a window class to deal with events/signals and we would need to abstract the file system. Then we'd need a solution for installers, an automated build system on a whole lot of things that I can't even imagine right now.

It might not be very complicated, but it might take well over a month, probably more than two. We would need to make a six-digit revenue from this to justify two months of work

It seems that you made your life complicated. Even for the installer, if you provide the same installer that discoDSP does, it is fine for me.

[Urs]

It seems that you made your life complicated.

Yes we did. But we have scalable user interfaces and a galore of funky stuff that common toolkits don't offer.

The installer is pretty much my least concern

[abique]

Yes we did. But we have scalable user interfaces and a galore of funky stuff that common toolkits don't offer.

Maybe you could use SDL? If you have an abstraction layer, I can help you.