Bitwig Release 26.03.2014

[linuxdsp]

@stanlea: You're right, so far I haven't found any "best" plugin format, and as I mentioned linux presents some uniquely horrible problems for plugins with custom GUIs (and I know there are some who think these unnecessary, but, for a variety of reasons I think they are essential, and I'm not just refering to photo-realistic virtual hardware - though I think there's a place for "art" in these designs) - but other more "scientific" GUIs are equally valid.
What do I expect as improvements..? That's very much dependent upon individual point of view, but (certainly as a commercial developer) what I wish linux audio had, is a better set of better defined common standards and APIs across distros and toolkits etc - for example:

We are soon to have X11, Wayland, Mir, XMir, XWayland, or whatever else gets invented as graphical servers / subsystems, where we used to have just X11 (not ideal but one of the few things you could guarantee was in every linux distro) and on top of that sits either GTK, GTK2, GTK3, Qt, Qt4, Qt5, SDL, FLTK, JUCE or (as in our case some proprietary widget toolkit) and that's just a few examples (and any host can choose to use any of them), but almost all of them will not host another toolkit natively so a plugin written in GTK won't easily (without some X11 based LV2 magic) operate in a Qt host and vice-versa, and that's without adding in GL and all the versions and potentially incompatible driver issues. And that's just the graphical display...

We have JACK1, for audio which is great, and still the 'go to' standard - but, we have JACK2 (which is ok, but has some bugs) and is the default in some (but not all) distros, and is not entirely compatible with JACK1 or perhaps a generic "JACK" client application - whatever the definition of that really is. From a user point of view they don't 'overtly' know which JACK they have because they are both called 'jackd' - and compatibility issues will likely manifest as perceived problems with the client app (e.g. failure to export ardour sessions or some such).

So the audio stack is not as confusing - but not optimal. However, either JACK cannot really function without a good session manager, and that's where things get even more mixed up, because we have several incompatible session formats - and managers - some of which work only with JACK1 (or JACK2) some of which require DBUS (not ideal if you have for example a headless audio 'engine') and all of which seem to support different goals with varying success.

Then we get to plugin formats, and LV2 attempts (valiantly) to solve the compatibility issues (especially the UI) by permitting extensions to be "required" by the plugin and "provided" by the host, so somewhere amongst "LV2 compatible" there has to be an agreement that plugin X which requires extensions A,B and C to be present in host Y will find that host Y (and hopefully host Z or host QtZ) will provide all of A,B and C (or a subset thereof) for it to function as intended (or to fail over - if possible - to some limited version of itself if not). The user will not necessarily know (or care) what combination is required or supported by his host app (but the plugin developer - or his company - will get the support call when it doesn't work)

There is in theory a standard host LV2 library, but, I know of at least one instance where two different hosts ship with their own bundled versions of this, which don't support all of the expected functionality - for a commercial developer this is a compatibility nightmare..

By contrast, (and I'm not saying VST is better - just here's something different)

VST (on a particular OS) defines that the plugin will provide its UI to a Parent "host window" on linux this is an XWindow, on Windows this is an HWND, on Mac its a Carbon Window (32bit) or Cocoa View (64Bit) - it clearly defines what you will need to use, and by virtue of the host providing the parent window, you can safely build your plugin against the required libraries because you know they must be present for the host to work.
Its basically telling the plugin "here's the thing you need to render your UI to" and the host sorts out all the detail of getting that displayed, its deceptively simple (and elegant) way to standardise things (from a plugin point of view) and yet still provide maximum flexibility (for UI design, host compatibility etc etc). On linux this could be e.g. an ARGB surface leaving the host to manage displaying that surface in whatever way its chosen toolkit / graphical server requires.

So its not impossible to make things more standard or "predictable" but at the moment, the biggest problem is that as a developer (especiallly a commercial developer) there are so many incompatible ways of doing the same thing on different distros / applications etc that its impossible to make robust guarantees about functionality (which is why we provide demos - and we also factor in the cost of supporting the issues and trying to help improve the user experience if things don't work).

(I haven't mentioned all the incompatible installer / package formats either, but that's a whole other problem to do with actually deploying a - commercial - application too - and the unavoidable fact is that, for an application to be successful - or worth supporting - we need to target as many distros / host apps as possible, because its such a niche, that to focus on one target combination would rapidly reduce the market to single figures..)

[Qualitymix]

Does this mean then that linuxvst is easier to work with than LV2?
Also another thought... Could something (like Carla) exist as a host space with all potentially required resources accessible for any type of plugin? Kind of an uber plugin wrapper?
Something like this would allow devs to focus on the dsp, not the toolkit.

[ssj71]

sounds to me more like VST is easier to support, not necessarily work with (in the development phase). LV2 is fairly simple if you are doing fairly simple things. It also allows you to use theoretically to use whatever toolkit you are comfortable/familiar with. Haven't tried VST development personally.

[vehka]

Hi, first time poster here, and a newcomer to Linux audio, but a long-time Linux user (since around 1995).

I was fascinated to notice the relative lack of enthusiasm regarding Bitwig Studio coming to Linux. There is a myth among commercial software developers that Linux users are not willing to pay for software, and I thought that this thread is sort of perpetuating that myth. I guess we Linux users are ruined for super high quality and free (in both meanings of the word) applications. No offense meant here, just an observation!

I think there's a huge potential for commercial software in Linux. But I guess we'll see how well software like Lightworks and Bitwig Studio will fare. I've understood that Steam is already doing pretty well under Linux, in terms of games sold.

Personally, I'm super excited about Bitwig Studio, and can't wait to try the demo version. I don't think there's anything like it available for Linux at the moment. If the included synths and effects are of a decent quality, I think 300 euros is not a bad price. Moreover, the potential wider effect of Bitwig Studio on Linux audio software is interesting. I'm hoping that it will make the audio devs of the Win/OSX world finally cross-compile their VST plugins made with JUCE, and release them to the Linux audio world...

[linuxdsp]

@vehka: As a commercial developer, I can say that, in my experience linux users are prepared to pay for good quality software - some may not wish to for personal / political reasons, and that's their choice to do so, but for those who just prefer linux as an OS, the option to use commercial software is there. Its just a smaller market of course, as linux is still in a minority compared to Windows, (it could even be said that there is actually far more "free" software for Windows - as in no cost - but that's a different topic entirely). One of the significant problem areas for audio software on linux is lack of compatible interfaces / drivers coupled with a reluctance by some hardware developers to adopt agreed standards where they exist. (I always recommend that if anyone can't get drivers for an audio interface they would like for linux, to politely write and tell the manufacturer that they bought another manufacturer's product in preference, so they know they lost a sale and why).

[aprzekaz]

I was fascinated to notice the relative lack of enthusiasm regarding Bitwig Studio coming to Linux. There is a myth among commercial software developers that Linux users are not willing to pay for software, and I thought that this thread is sort of perpetuating that myth. I guess we Linux users are ruined for super high quality and free (in both meanings of the word) applications. No offense meant here, just an observation!

I am actually very excited about it as well and will probably pay the price for it if it really is as great a product as it is expected to be. I am also excited to see Tracktion 5 coming to linux. It's just odd to me that there is such a price discrepancy between these products. I watched a video from NAMM with the guy from Bitwig saying that honestly any song can be made on any major daw these days and so the focus is on the workflow to set Bitwig apart. But is the worlflow going to be 6 times better? Maybe you can't really quantify things like this. It's true that if it sells, then it's worth it to those who buy it. I might be one of those who buy it.

[ssj71]

But is the worlflow going to be 6 times better?

Generally more expensive hardware really just makes it easier/faster to make your productions. You can make quality productions on cheap stuff, you just have to be more careful. For example, I mix on $30 headphones and I have to double check everything on several systems, for lack of decent monitoring. It takes quite a while (and usually I settle for sub-par mixes rather than pay the price to get it right). With some $300 monitors, I could probably do it with much less double checking. With some high quality $3000 monitors, I wouldn't really need any other reference. So are the nice monitors 100x better? Probably not, but the curve is also exponential (the price doubles for a small increase in quality).

I'd venture software can be perceived much the same. Especially if you are trying to produce professionally, saving hours is saving dollars. The 10% gain in workflow might well be worth a few hundred more. I think its a fair price for a professional product.

(p.s. quality monitors is on the top of my shopping list, but it will be a while longer. All the more reason I won't be buying bitwig, but I really hope lots of others do)

[linuxdsp]

@ssj71: good quality monitors (and if you're fortunate enough, a good quality room - doesn't have to be huge, but properly set up) is essential - far more than any other piece of (modern) equiplment in your signal chain. That said (and I know, I'm biased, however...) good quality audio processing software (free / open source or commercial) is more important than a lot of people realise too - that said, don't be taken in by nebulous claims without actual measured evidence or some reliable technical information to back it up, the audio software industry sadly has appropriated some of the "gold plated power cable" marketing philosophy especially when promoting some "big name" plugins / audio processors etc.

[ssj71]

I know. Perhaps I should clarify a bit that I'm not buying ANYTHING until I get monitors (including bitwig).

I think the concept still stands true for processing software. You can get good results with budget software, you just have to be a lot more careful and spend more time making sure your automations aren't causing zipper effects in the plugin etc. Bitwig won't have these sort of issues.

[Garmonbozia]

You makes some great observations that I as a non-developer would never realize.

For me, I can only exist in the Linux environment for so long before I need to use my Windows applications. Maschine and other software are essential to how I work. I've tried to use ardour, but it just doesn't cut it for me. I'm a Renoise user but it's not enough. It isn't long before I realize I need to start using plugin-X (insert whatever plugin here). Once I do, I have to stop to relog back into Windows just to complete my work. At this point Linux doesn't have enough for me to sustain for long enough periods to get any work done. If Bitwig works for me, this could change things. Not permanently mind you, I'm still going to want to use Maschine and my Komplete instruments (sorry they're just better than any free plugin available). But, all of this depends on how good the Soft Synths in Bitwig are. The great thing about this, if Bitwig works well and I enjoy it, that means that I can sustain use inside of Linux for longer periods. This also means that more of my work is interchangeable between windows and Linux. If I'm working on a piece in Windows where I need Maschine, I can just render everything to Audio and take my files into Linux and finish my work there. That's a really inspiring thing for me! Renoise is not my only DAW, so this isn't possible at this point. I do all of my final mixing inside of Studio One, and this is where I do the majority of my audio work. Renoise alone is never enough. I need a host!! And a serious one at that. Ardour is cool, but it just doesn't stand to a major DAW like Studio One or Pro Tools for me.

What gives me so much hope about Bitwig, is that it's target audience, the DJ and electronic music crowd, will bring a huge influx of casual users. You're not going to see audio engineers until something like Pro Tools moves that way. But, it's the casual users, like Gamers and DJ's that are the bigger market, not Audio Engineers. Audio Engineers are a much smaller group of people than DJ's. If casual users start to believe that Linux is a viable platform for playing around with their favorite audio app and doing reasonable gaming, than that's when things will change. Slowly more things will move that way as the market shifts. NI will start developing for it if they see that there is a bigger Market there than before. The engineer tools will be the last to move. Now all of that is a lot of hopeful thinking. It's just as likely that Bitwig will flop, or no one will be using it on Linux and they'll discontinue support for it if it seems like a waste of development time. It's hard to say. I just would love to use Linux as my primary environment, but at this point it's just impossible. I can only maintain my existence there for a short time before I'm rebooting into Windows. I hope someday that won't be the case and I will have more options in terms of which OS I can use.

[bluebell]

@stanlea: You're right, so far I haven't found any "best" plugin format, and as I mentioned linux presents some uniquely horrible problems for plugins with custom GUIs (and I know there are some who think these unnecessary, but, for a variety of reasons I think they are essential, and I'm not just refering to photo-realistic virtual hardware - though I think there's a place for "art" in these designs) - but other more "scientific" GUIs are equally valid

GUIs are important, indeed. But not to have fancy logos and vintage-knobs. LADSPA fails in simple but important things:

- File open dialog, e.g. for impulse responses
- Graphical display, very helpful e.g. to find a starting threshold when using a compressor

I wonder why no-one created a standard for having external GUIs for plugins, similar to the GUIs for linuxsampler. A standalone GUI could use any toolkit and could even crash without crashing the plugin's host.