Bitwig

Enrize · Post by **Enrize** » Thu Jun 14, 2018 5:08 am

For the last few months i've been reading and watching a lot of how people reacts to Bitwig Studio (using hashtags, keywords, search queries etc on different social platforms).

I must admit that a lot of people very like Bitwig Studio but most of them switching back to their previous DAWs after some time because of the bad performance (GUI slowdown, CPU spikes etc). Probably it starts to happen when their projects become bigger.

So i know everyone is already aware of the problem. I just want to point out that this is probably the biggest reason why people switch back and this issues should be addressed with highest priority.

Cheers everyone!

SLiC · Post by **SLiC** » Thu Jun 14, 2018 5:52 am

Wasn’t this issue just with Macs? (Linked to an OS issue, I have head the same thing with some plugins like Avenger).

I can only say that on a PC with a decent graphics card I have never experienced any slowdown or CPU spike issues with the latest version.

JHernandez · Post by **JHernandez** » Thu Jun 14, 2018 6:03 am

If the graphics are currently rendered entirely by the CPU what does your graphics card have to do with it, or Macs for that matter?

Zexila · Post by **Zexila** » Thu Jun 14, 2018 7:44 am

Can confirm spikes with few track projects on Windows, guess with more tracks is more annoying, It's shame they need new shinnie features to collect subscription, intsead focusing everything on optimizing this thing once and for all.

ozinga · Post by **ozinga** » Thu Jun 14, 2018 9:51 am

After finishing a fairly crowded song in BWS I went back to S1 due to slow response and cpu problems of the current version on mac. Instead of new featıres, devices I am hoping for a performance optinization focused update.
Oz

connmach · Post by **connmach** » Thu Jun 14, 2018 10:49 am

I'm with SLiC on this one. Decent (not top notch) PC. Lots of 3rd party VST(i)'s, Lots of tracks.
Never experienced any slowdowns or CPU spike issues ever, not now (2.3.4) not when I started with Bitwig (1.3.14)

But I'm not superfluous dpi horny.

SLiC · Post by **SLiC** » Thu Jun 14, 2018 11:04 am

JHernandez wrote:If the graphics are currently rendered entirely by the CPU what does your graphics card have to do with it, or Macs for that matter?

I dont know how how the graphics are rendered, the post seemed to insinuate there was an endemic probem, I am not sure that is the case, I (and others) dont have any issues at all and I am on an i7 PC and a i5 MS Surface Tablet.

Obviulsy some people are having problems some of the time, but it is helpful for the developers to identify what systems give issues, this can help narow it down/reproduce it so it can be fixed for those people.

Bathrobe · Post by **Bathrobe** » Thu Jun 14, 2018 11:25 am

Ohhh

For a moment there i had high hopes when i missread the topic

Quick heads up from Bitwig developers.

instead of

Quick heads up for Bitwig developers.

antic604 · Post by **antic604** » Thu Jun 14, 2018 1:27 pm

It was confirmed several times in other threads that the issue (low performance in "big" projects) is directly related to rendering of the GUI being done by the CPU, using Cairo libraries which are best implemented in Linux, pretty well implemented in Windows and really poorly implemented for OSX.

So yeah, most of those complaints come from Mac users

And the devs said they're committed to fixing this by offloading (at least the most intensive parts of) GUI to GPU, which obviously takes time for a very small dev team working on 3 platforms.

JHernandez · Post by **JHernandez** » Thu Jun 14, 2018 2:38 pm

Thanks antic.

fwsuperhero · Post by **fwsuperhero** » Thu Jun 14, 2018 2:58 pm

Ive got two laptops, one is much better than the second one, but bitwig has glitchy gui on it (maybe because it has touch hd screen?). so i can understand why some people left bitwig. But it seems, cpu hungry is not the problem...

connmach · Post by **connmach** » Thu Jun 14, 2018 3:26 pm

antic604 wrote: So yeah, most of those complaints come from Mac users

True, but in all those (self repeating) threads there was also a consensus that it was due to the HiRez monitors. I thought every 40000000000k screen (specifically made for word processing, music composing and Youtube) had a sluggish response due to Cairo libraries and only using the CPU.

Mac users complain much faster and louder because of the mother lode of cash involved in those cases.

But I can be wrong.

antic604 · Post by **antic604** » Thu Jun 14, 2018 4:17 pm

connmach wrote:
antic604 wrote: So yeah, most of those complaints come from Mac users
True, but in all those (self repeating) threads there was also a consensus that it was due to the HiRez monitors. I thought every 40000000000k screen (specifically made for word processing, music composing and Youtube) had a sluggish response due to Cairo libraries and only using the CPU.

Mac users complain much faster and louder because of the mother lode of cash involved in those cases.

But I can be wrong.

What do you want me to say?
- yes, the higher the res, the more burden is put on the CPU (taking it away from audio processing),
- the worse the implementation of Cairo, the sooner those problems rear their ugly head,
- the more you've spent on your machine, the louder you'll complain.

I'd love some iMac Pro user to post a screenshot of how Bitwig looks in full 5K res and in so-called 'low resolution' mode, because I'm pretty sure the latter still holds much better than the pixelated mess Reason is on high-DPI monitors... But maybe Cairo implementation on OSX is so bad, that even dropping down to low res mode doesn't help once the projects get bigger? I don't know, never owned Mac. And also size of the project differs by person - for me big project is 25-30 tracks (full of native instruments & effects, few VSTs, lots of automation, ideally all still in MIDI), for others they have 100+ tracks template with huge sample libraries, channel strips on every track, ozone plugins on every group, etc. before they even put a single note in.

JHernandez · Post by **JHernandez** » Thu Jun 14, 2018 6:20 pm

FWIW

1080 Asus MX279 monitor, 2010 Mac Pro with dual 6 core processors (12 core), 16 gig ram, on El Capitan. Mechanical drives, if that matters. Also, I'm not using my Apogee in this test, the audio output is set to the Asus monitor via Mini DisplayPort to HDMI.

Using Bitwig's "Sample Magic Demo by Hedflux" I duplicated all tracks and I stopped at 256 tracks.

At the very least I learned that CPU efficient (native BWS) devices/plugins and bouncing heavier plugins to audio are my friends. As long as I do that, I can run all the tracks I personally need, which is a lot less than 256 in my case. As you can see below I can get away with quite a bit more. Unless I'm overlooking something crucial?

Screen Shot 2018-06-14 at 1.57.36 PM.png

I did notice that when I switched to the mixer it took a second or two. I'm guessing it's because it had to draw all the channels while under the load, but the audio was consistant. Scrolling up and down is obviously not as smooth as a blank slate but it's not bothersome enough to slow me down either.

How do you fair in the same scenario on your set up? (Mac people) I get most of you likely have up to date machines, I'm just curious. Maybe there's something to be learned?

pekbro · Post by **pekbro** » Thu Jun 14, 2018 6:48 pm

I imagine its not about platform specific implementations, but more about platform
display resolutions. Its just a graphics library...