Breaking into the DAW and production market isn’t easy to do. Bitwig Studio has been criticized by some – including this author, in a couple of instances – for not differentiating itself in particular from rival Ableton Live. But in the latest beta video, we start to see something genuinely new in how VST plug-ins load in the host.

Previous betas of Bitwig Studio lacked VST support, and it’s been a bit too early to really evaluate them. In this new build, though, we not only get the ability to load VSTs, but a way of treating them that isn’t quite like other hosts. There are features you’d expect – side-by-side loading of 32-bit and 64-bit plug-ins these days is a must-have, and unlimited parameter automation is nice.

The video reveals some new ideas, though. VST plug-in hosting is the last feature you’d expect to be sexy, but this looks promising:

  • Parameters in easy reach: The default interface for plug-ins shows all their parameters in a list, and you can find them quickly as you type. (Most other hosts have a hidden screen with a mess of faders and require you to sort through them.)
  • Quick automation: When you select a parameter in a plug-in – such as a fader or knob – that parameter is automatically selected for automation in the track view. (Note: this is a feature straight out of Ableton Live, which will be more useful with the introduction of curves and better automation recording in Live 9.)
  • Faster loading: Folder monitoring is automatic, so the program doesn’t have to rescan your plug-ins with each launch – reducing load time
  • Crash protection: Plug-ins are protected from crashes by instantiating each as a separate process.

It’ll be especially interesting to test crash protection. I was chided by a plug-in developer recently for accepting marketing speak about crash protection or sandboxing. In a typical host, when a plug-in is loaded, it has access to the same memory space as the host; that’s why a plug-in crash can bring down the host. Propellerhead has pitched “sandboxing” in their Rack Extension scheme, but some users (and CDM readers) have complained that resource consumption is beyond what they’re finding using VST versions of the same effects and instruments. We’re awaiting an explanation of what’s going on there.

As for Bitwig, I similarly wonder how resource consumption will scale as you use a lot of plug-ins. But the best way will be to test that and talk to Bitwig’s engineers about the feature. (I just had a reader complain that I’m doing too much speculation on public announcements – uh, sorry, I’ll get on it. Bitwig is here in Berlin, so I expect we’ll meet soon.)

The feature that’s driving some Ableton users batty, as seen in Bitwig Studio. Image courtesy Bitwig.

While we wait on real-world testing of crash protection, I will say that seeing the way Bitwig handles plug-ins really does look more productive, especially for advanced users. I hope we keep seeing this kind of new thinking in the beta videos. We’ll be watching. Ableton users did, for their part, find there were features still wanting in Live 9 – most infamously, side-by-side arrangement and clip views, multiple monitor support, and native Linux compatibility, as found in Bitwig. So I don’t expect that the discussion of these two apps, or the interest in Bitwig Studio, will wane any time soon. Stay tuned.

  • http://raaphorst.info/ Marco Raaphorst

    Nice to see that it will be available on Linux as well!

    • http://pkirn.com/ Peter Kirn

      Yeah, I assume that means Windows VST support? Will ask. Even though native Linux plug-in support would be theoretically better, for now Windows VST seems it brings the most plugs.

    • marc

      Yeah, I think linux is a smart move long term. What I think will happen is that as the desktop computer itself starts to disappear the only supported os for it will be Linux…

  • Mark Luszniak

    I’m no expert, but as I understand it, Reaper has offered VST hosting with each running as a separate process for several years. I’ve witnessed VST crashes several times, but Reaper itself has continued to run just fine.

  • PaulDavisTheFirst

    Instantiating a plugin in a separate THREAD does not provide crash protection. It might provide crash recovery possibilities, but that still isn’t robust in the face of all possible plugin misbehaviour. It also adds a thread context switch (which is admittedly cheap – no address space change) and thread synchronization to the cost of running every single plugin. This could be an acceptable tradeoff for some people.

    BUT … what is shown above is NOT running plugins in a separate thread. The OS X activity monitor shows processes, not threads. It does not allow you to kill a single thread, only a process. So what Bitwig is doing is running the plugin in a separate process, which adds the cost of an address space change (translation lookaside buffer flush for the technically minded) to the cost of running the plugin. As I’ve described separately, this does not scale well for workflows with lots of plugins, especially if some of them touch large amounts of memory every time they process some audio.

    “We’re awaiting an explanation of what’s going on there.” – hopefully this will suffice, but I am happy to get into even more detail if someone wants me to.

    There is an inevitable tradeoff between this type of crash protection and plugin scalability. With today’s machines, it may be that the cost of running each plugin as its own process is low enough that most people really won’t care too much. But if that is true, you have to wonder why its worth even developing for a plugin API that is designed around the idea of in-process execution when there are models like JACK or ReWire that are explicit about the separation of processes. Hint: that is mostly a rhetorical question :)

    In addition, most of the approach to plugin parameters and automation has existed in Ardour for roughly 8 years, though the part about touching a parameter in the plugin editor/GUI causing the parameter’s automation lane to show up is an interesting idea. I question the utility of type-ahead on parameter names, given that most people probably don’t actually know the names of most of their plugin’s parameters. But we’ll see, I am sure …

    • http://pkirn.com/ Peter Kirn

      Sorry, I wrote ‘process’ rather than ‘thread.’

      I’d like to know if there’s native ReWire or JACK support coming.

    • PaulDavisTheFirst

      It would be suprising if Bitwig showed up on Linux without JACK support, but also entirely possible. You don’t need ReWire on any platform if you’ve got JACK installed :)

    • angstrom

      On the BitWig FAQ they say this :

      There is no ReWire support planned, but if you want to route
      audio and MIDI between different applications, you might want to
      take a look at the JACK Audio
      Connection Kit, which is available for OSX, Win and Linux.

      http://www.bitwig.com/faqs.php

    • porpoisemaker

      That’s not exactly true though is it? JACK is very cool and all (and I do use it occasionally for the odd routing task) but it’s not a replacement for Rewire. Rewire is more than sync and note data, it presents instrument parameters from Reason to Live Clip Envelopes which is fantastically useful. It’s also built-in and proven technology that works across other DAWs.

      JACK is useful and all but it’s not a replacement for Rewire and as such I’ll be giving Bitwig a miss until they deem it useful enough to implement. I’m not faffing with JACK just to get Reason 6 playing alongside it like I can with very little effort in Live, which is a shame because they look like they’ve done some sterling work there.

    • PaulDavisTheFirst

      I’m not privvy to the ReWire API (for reasons that have been presented here before). I wasn’t aware that ReWire had a sub-API for doing that sort of thing. I’d be interested to know if they are actually doing more than using MIDI CC or something similar between the master+slave. But yes, you’re right that there are parts of ReWire that JACK does not address (and vice versa, actually).

    • http://www.facebook.com/profile.php?id=1543525531 Paul Rose

      “the part about touching a parameter in the plugin editor/GUI causing the parameter’s automation lane to show up is an interesting idea” and existing in Live since, err, ever?

    • http://pkirn.com/ Peter Kirn

      Right, exactly, that’s a Live feature. The parameter interface for the device is novel, however.

  • squirrel squirrel squirrel

    This is just like Logic Pro 9 in 64-bit mode. It uses a 32-bit AU bridge for 32-bit plugins. If that bridge crashes, it doesn’t affect the 64-bit plugins.

    • http://pkirn.com/ Peter Kirn

      My understanding from their video explanation is that the plug-ins are each independent, not just one bridge.

  • dew shbog

    dual monitor support ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh want

  • http://twitter.com/goofrider Jeffrey Chan

    That’s interesting about memory consumption in sandboxed audio plugins. Audio plugins process streams, as opposed to regular applications, which allocates memory mostly from stack. Theoretically audio plugins should be much easier to sandbox and should require much less memory (compare to, say, sandboxing Flash plugin in the browser), unless the plugin does some complex DSP modeling.

  • http://www.facebook.com/profile.php?id=3213089 Taylor Holliday

    So they aren’t just running the entire audio engine in a separate process? That would seem to be the right way to do it — offers both crash protection and performance.

  • remz

    a- ha. “…. thank you for watching and see you in the NEXT BETA VIDEO…”
    i guess that means wating for 3 – 4 months to get the next bone.
    do i have to say that their marketing/promo- moves arent the best?!

  • metrosonus

    I’m very disappointed in Live 9. With Ableton, you’re essentially paying for the clip view and midi control and they seem to make that the laurels they are resting on.

    I’m glad they implemented automation cures, but I’m upset that the clip (which is a sampler) has no sampler controllers in it. I’d PAY for the ability to be able to record into a clip, crossfade, loop, one shot ect right from the clip and hit play without having to use simpler and draw 8 -10 bar whole notes.

    That’s just the biggest “I don’t get it” I have about Live. Fl studio is easier to use than Live in that regard.

    The included material and instruments are also lame and Live is more expensive than other DAWs that offer way more content.

    As a company, I’m just not sure anymore what they are trying to achieve.

    • http://www.facebook.com/leon.tricker Leon Tricker

      Metrosonus – totally agree. Especially re. clip-level sample controls.

  • http://dinside.no Øivind Idsø

    Looks good, actually, but Bitwig’s really made a mockery of the term “coming soon”, haven’t they?

  • Bosco

    Actually, can we all please stop saying “Actually” all the time? It doesn’t actually mean much. Thanks

  • http://www.facebook.com/people/Jim-Jones/1779461945 Jim Jones

    What really goes on at Ableton Headquarters:
    http://www.youtube.com/watch?v=0phA3t9qHNw&feature=fvwrel

  • http://www.facebook.com/jossmolders Jos Smolders

    uhmmm, hello? This VST handling is standard operation in Reaper for at least a couple of years already and, come to think of it, Audiomulch as well…. Crash protection ditto.