Bitwig 3.0 Questions??? Can't find basic stuff...

[jonljacobi]

IIRC the Mac issue had to do with drivers from Apple, that BW can't fix alone. Or something like that was mentioned once.

The issue is that Bitwig is using an ancient library called Cairo for their UI drawing. It needs to be accelerated via OpenGL to get good performance. On the Mac OpenGL is getting pushed out by Apple in favor of Metal. Personally I have no idea why Bitwig went with Cairo in the first place as it's pretty old but now they are in a conundrum on the Mac platform where they are stuck with this old lib and Apple has no desire to support OpenGL on their platform anymore. Cairo has a software backend that uses the CPU to render, that's what Bitwig is using on the Mac.

So either Bitwig is working on their own lib (likely), working on a metal backend to Cairo (doubtful) or they will never fix the issue.

I've been looking for a knowledgeable answer to that issue for a while. Thanks!! Note that you can skirt some of the issues by limiting the drawing taking place.

Remember the PortAudio fiasco?

And Apple is great for dumping older tech that lots of people still use. I had to redo about a hundred VPNs when they decided to dump pptp.

[ejgallego]

Good list, please send to support. Indeed BitWig is more of a live/sound design DAW and mixing has a long way to improve. It also features a more interactive display with lots of animations, which together with the software being still quite young and done by a small team means performance suffers.

From which DAW are you coming? I am not aware of any DAW that is able to do your point 6. But of course you can attach whatever automation to your clip and either send it to a separate fx or activate/bypass whatever fx in your chain...

Magix Samplitude for example can do that and way more advanced stuff. In fact Samplitude + BitWig is a combination I like, it ain't cheap tho.

I wonder why BitWig people didn't take more inspiration from Magix DAWs, they have so cool features.

[apoclypse]

IIRC the Mac issue had to do with drivers from Apple, that BW can't fix alone. Or something like that was mentioned once.

The issue is that Bitwig is using an ancient library called Cairo for their UI drawing. It needs to be accelerated via OpenGL to get good performance. On the Mac OpenGL is getting pushed out by Apple in favor of Metal. Personally I have no idea why Bitwig went with Cairo in the first place as it's pretty old but now they are in a conundrum on the Mac platform where they are stuck with this old lib and Apple has no desire to support OpenGL on their platform anymore. Cairo has a software backend that uses the CPU to render, that's what Bitwig is using on the Mac.

So either Bitwig is working on their own lib (likely), working on a metal backend to Cairo (doubtful) or they will never fix the issue.

I've been looking for a knowledgeable answer to that issue for a while. Thanks!! Note that you can skirt some of the issues by limiting the drawing taking place.

Remember the PortAudio fiasco?

And Apple is great for dumping older tech that lots of people still use. I had to redo about a hundred VPNs when they decided to dump pptp.

Yeah. The issue with Cairo is that it's not designed for modern GPUs. It uses trapezoids for tessellation which is not really how GPUs work. The last major piece of software that uses or used Cairo is GTK. Even the devs of that project are moving away from it because Cairo in general is inefficient and slow especially when its CPU accelerated. The same issues we are having with Bitwig now literally were happening in 2004 or so when GTK+ first started adding Cairo to the toolkit. There was no GPU accelerated backends then.

Considering that Cairo really isn't maintained anymore and that almost all the major projects that used it have moved away or are moving away, I'm kind of let scratching my head as to why Bitwig went that route.

I get it Cairo has a lot of nice primitives and drawing functionality which probably helps with the bouncy UI animations etc, but there were other ways to do the same thing without dealing with such a complex, inefficient, no longer maintained api imo.

I mean why not Skia which is used by Chrome, Firefox among others and it's also BSD licensed so open to everyone to use. Anyway this is a music forum and this is way OT.

[antic604]

Downloaded the demo based on the positive hype for version 3. I'm scratching my head wondering why I can't do or find very basic stuff found in other DAW's...

That's a pretty good list. Some stuff is missing right now, for some there are workaround that perhaps take extra time, but there are other things you can't or are very difficult to do in other DAWs, so it might balance out depending on how you're using a DAW (everyone has a different needs and workflow).

And like others have said - approach new DAW with a mindset of what it can do, not what it cannot. If I went to Cubase or Reason forcing them to be like Bitwig then I'd be really frustrated, because lots of things aren't there or are "convoluted" or require "work arounds".

So, coming back to your list:

1) I'm afraid there isn't one. Vertical zooming and in general track height options are lacking in Bitwig indeed. Wish it was more like in Studio One.

2) You can't do it from clip level, only via Inspector panel (as you noticed). If you Ctrl+click on a fader (or actually any thing in Bitwig) you can input exact value, though.

3) No, you can't resize mixer faders for now.

4) There's Dual Pan device that you simply stick to your FX chain.

5) There isn't one. But try this - while on the track, hit Ctrl+G (to put it in a group), then hit 2 and (on the Group track!) select time covering the area you want to freeze, right-click and select Bounce In Place. Then just disable the source track (hit Alt+A while having it selected) and "fold" the Group track - you're left with single track, but within it you have your MIDI / audio source will all the FX, automations, etc. BTW - this works on any track - you can bounce in place an FX track, your Master track and always the audio ON the track has priority over what's routed to that track.

6) There's no such option specifically, but obviously you can automate FX on/off switch or automate send amount to get the same result. Other solution is to add the FX on the (whole) track, select the clip (or time, like in point above) you want affected, right-click and Bounce In Place, then disable the FX.

[antic604]

Considering that Cairo really isn't maintained anymore and that almost all the major projects that used it have moved away or are moving away, I'm kind of let scratching my head as to why Bitwig went that route.

It's all easy to criticise in retrospective, but Bitwig - being released in 2014 - started development probably 3-4 years earlier and they had 3 OSs to work on from a very small team of devs (AFAIK 4 people now, so perhaps 2-3 max then?), so I suppose availability of the platform on all 3 OSes and probably familiarity of the devs with the environment played a role.

Also, Live only got GPU acceleration in v10 (and read the beta forums - many people complain about their fans sounding like jet engines on OSX there too), Reason doesn't have it at all (and struggles on Macs as well), I'm not sure about Cubase but if it's there it's fairly recent too.

Furthermore, Bitwig was the 1st DAW that fully supported high-DPI / 4K screens from the get go, unlike Live (again, only since v10), Reason (no support whatsoever) or Cubase (laughable "support" and only since 9.5 or 10 too)

All I'm trying to say Bitwig isn't alone struggling in this area and most old, well-established DAWs that have huge development teams (by comparison) had and continue to have problems in this regard.

[apoclypse]

Considering that Cairo really isn't maintained anymore and that almost all the major projects that used it have moved away or are moving away, I'm kind of let scratching my head as to why Bitwig went that route.

It's all easy to criticise in retrospective, but Bitwig - being released in 2014 - started development probably 3-4 years earlier and they had 3 OSs to work on from a very small team of devs (AFAIK 4 people now, so perhaps 2-3 max then?), so I suppose availability of the platform on all 3 OSes and probably familiarity of the devs with the environment played a role.

Also, Live only got GPU acceleration in v10 (and read the beta forums - many people complain about their fans sounding like jet engines on OSX there too), Reason doesn't have it at all (and struggles on Macs as well), I'm not sure about Cubase but if it's there it's fairly recent too.

Furthermore, Bitwig was the 1st DAW that fully supported high-DPI / 4K screens from the get go, unlike Live (again, only since v10), Reason (no support whatsoever) or Cubase (laughable "support" and only since 9.5 or 10 too)

All I'm trying to say Bitwig isn't alone struggling in this area and most old, well-established DAWs that have huge development teams (by comparison) had and continue to have problems in this regard.

Live has had DPI scaling since at least version 9. What it didn't have was plugin scaling (on Windows) on Macs it already supported plugin scaling since that's built into the OS. What they added to Live 10 on Macs is gpu acceleration, but you have to consider that Live (before 10) doesn't have the same issues as Bitwig in-terms of cpu based 2d performance.

Sure there are other companies having issues but these companies should have higher technical debt than Bitwig which is relatively new in comparison. Making changes in old code is harder in general. It doesn't matter how big the team is.

I completely understand that Bitwig was working with what they had at the time. However now they are in a bind on the Mac platform. As a user I don't really care why it performs the way it does, I care that it doesn't perform well. I just wanted to give people an explanation as to why this may be happening and why we may not see a solution anytime soon.

[Puddi]

Regarding #2 there are no gain handles straight on the clips. Both Bitwig and Ableton are kind of clunky in this aspect, although the latter is far worse. I'd love to see it get implemented since it makes small volume adjustments much quicker.

[BobDog]

Considering that Cairo really isn't maintained anymore and that almost all the major projects that used it have moved away or are moving away, I'm kind of let scratching my head as to why Bitwig went that route.

It's all easy to criticise in retrospective, but Bitwig - being released in 2014 - started development probably 3-4 years earlier and they had 3 OSs to work on from a very small team of devs (AFAIK 4 people now, so perhaps 2-3 max then?), so I suppose availability of the platform on all 3 OSes and probably familiarity of the devs with the environment played a role.

Also, Live only got GPU acceleration in v10 (and read the beta forums - many people complain about their fans sounding like jet engines on OSX there too), Reason doesn't have it at all (and struggles on Macs as well), I'm not sure about Cubase but if it's there it's fairly recent too.

Furthermore, Bitwig was the 1st DAW that fully supported high-DPI / 4K screens from the get go, unlike Live (again, only since v10), Reason (no support whatsoever) or Cubase (laughable "support" and only since 9.5 or 10 too)

All I'm trying to say Bitwig isn't alone struggling in this area and most old, well-established DAWs that have huge development teams (by comparison) had and continue to have problems in this regard.

Performance problems with Cairo were well known well over 10 years a go, just have a google search.

[antic604]

Live has had DPI scaling since at least version 9.

Live had GUI scaling in 9 (probably before), but it simply was useless because if you've not forced it to run in compatibility mode then majority of VSTs were tiny and unusable on e.g. Surface Pro. In compatibility mode it was blurry and fuzzy.

That's what I meant by no high-DPI until v10, where they finally made it usable.

[apoclypse]

Live has had DPI scaling since at least version 9.

Live had GUI scaling in 9 (probably before), but it simply was useless because if you've not forced it to run in compatibility mode then majority of VSTs were tiny and unusable on e.g. Surface Pro. In compatibility mode it was blurry and fuzzy.

That's what I meant by no high-DPI until v10, where they finally made it usable.

Right, but that's for Windows only like I said. So far we've been talking specifically about macOS. Live wasn't the only app that has had issues with DPI scaling on Windows, in-fact that's an issue with Windows in general. However this being a conversation about Bitwig on macOS and Cairo, I'm not sure why Live getting HI-DPI support for plugins on Windows is relevant.

[kurt008]

Oh, I know. Switching tools always lets you experience some brick walls. You definitely should send your list also to support, I think one of the most interesting feedbacks for enhancing workflows is the impression of the first moment. But also workflows you learned in one tool might be not the best and the new approach could be way faster...
From which DAW are you coming? I am not aware of any DAW that is able to do your point 6. But of course you can attach whatever automation to your clip and either send it to a separate fx or activate/bypass whatever fx in your chain...

Try to do a project from start to finish and try not to insist on your known workflow. I finally recorded a classical session I would usually do in ProTools. It was not (yet) as smooth I wished, but I could achieve the same result in almost the same time. The most missing feature was vertical zoom for audio editing of very soft signals btw... I had the same problem in Ardour, it does not have a vertical zoom, but had something way better, an exponential waveform view. I requested that for Bitwig as well, it would eliminate the need for a vertical zoom feature...

Well, you asked for a DAW with per Clip FX... that feature is offered (at least) by Reaper (made by Cockos) since a longer time now. It needs to be enabled in the settings, but works fine. But - of course - I don't know, which DAW perhaps comes with similar functionality...

[wavedigit]

I'm not sure what the per-clip FX is in other DAWs, but if you want to have a specific FX applied only to a specific clip, you can just insert an FX Selector device and then select an FX chain in that clip's automation.

[apoclypse]

I'm not sure what the per-clip FX is in other DAWs, but if you want to have a specific FX applied only to a specific clip, you can just insert an FX Selector device and then select an FX chain in that clip's automation.

Studio One and a few other DAWs (Logic has something similar I think since version 10.4?) have effects that you can kick off per clip as opposed to per track. If What you wrote here effectively does the same thing that's pretty cool then.

[pdxindy]

I'm not sure what the per-clip FX is in other DAWs, but if you want to have a specific FX applied only to a specific clip, you can just insert an FX Selector device and then select an FX chain in that clip's automation.

Studio One and a few other DAWs (Logic has something similar I think since version 10.4?) have effects that you can kick off per clip as opposed to per track. If What you wrote here effectively does the same thing that's pretty cool then.

the nice thing about this way is if you want to apply it to some other clips in the track, that is easy to do without additional FX

[syncr]

Hey, regarding this iMac fan noise problem. I'm research Bitwig and trying out the demo. Did some google searching but I didn't come up with any threads to guide me toward a spec or model of iMac that is susceptible to this GPU/Cairo/Fan Noise issue. I'm currently running the Irrupt Mind demo song on the fifth straight play-through and I'm not hearing any fan noise. Is there a benchmark, demo track, or super hungry feature I should test out?

FWIW, Running Bitwig v3.01 with Mojave on a 2012 iMac 27" i7 3.4ghz with 24gb of RAM and Nvidia GTX 680mx 2gb.