Bitwig

dirtboy · Post by **dirtboy** » Wed Apr 02, 2014 8:31 pm

Definitely some wild CPU usage here as well. Just the program open with nothing loaded increases my MBP temps drastically. I've let it sit hoping it was a background indexing process going on but no dice. Optimization needed here as well.

iONikbeats · Post by **iONikbeats** » Wed Apr 02, 2014 10:23 pm

Been pretty solid for me. Running 3.5gHz i7 on a Hackintosh.

Just out of curiosity, what is the audio engine written in? What about the UI?

AstralExistence · Post by **AstralExistence** » Thu Apr 03, 2014 12:28 am

EvilDragon wrote:OK seems after restarting CPU usage is better. Still not better than Reaper.

8 Divas at Divine setting running the same one-bar loop with chords going all the time:

Bitwig - 50-60% CPU
Reaper - 35-45% CPU

At least it's 0% running idle now. i5-2380p at 3.4 GHz, 16 GB RAM.

well what do you expect lol reaper has the best cpu use of any daw. nobody in daw history has ever been able to do what cockos did/does with reaper. nobody probably ever will. its a shame reaper is so stale development wise. reaper is crying for tool icons that simply work without all that customization that needs to be done before hand. reaper needs some serious work.

machinesworking · Post by **machinesworking** » Thu Apr 03, 2014 3:25 am

^^^ Actually on a Mac Digital Performer far outperforms Reaper CPU wise, Reaper for whatever reason is a pig on the Mac.

After an initial crap output from Live 32 bit, Bitiwig by far performs the worst CPU wise on a Mac. The Reaper VS numbers are almost exactly the same on OSX with DP VS Bitwig.
I'll post the numbers when I get to the studio but it's something like DP on top, Live 75% performance of DP and Bitwig 50% performance of DP.

Honestly this is the single biggest disappointment to me about Bitwig, I expected it to at least be more CPU efficient than Live, but it's less. I suppose though if I was using Cubase it wouldn't be as apparent, but Logic and DP both trounce Live CPU wise, and now Live is trouncing Bitwig.

qtheerearranger · Post by **qtheerearranger** » Thu Apr 03, 2014 3:29 am

iONikbeats wrote:Been pretty solid for me. Running 3.5gHz i7 on a Hackintosh.

Just out of curiosity, what is the audio engine written in? What about the UI?

Im not a programmer, but I've read somewhere else that it may have been programed in Max MSP.

glokraw · Post by **glokraw** » Thu Apr 03, 2014 3:29 am

Reaper proved a talented small team can succeed against a
team thaqt became bloated/mediocre/complacent etc
as in the old long-estabshed boxed products.
So the Bitwig team knew it was possible from the start.
I doubt that Bitwig would have happened in the way we see it,
if Reaper had failed. Other small teams, probably even individuals,
have/are coding great DAWs, for 'love of the game', in some cases,
without a budget to support them.

AtomOfScent · Post by **AtomOfScent** » Thu Apr 03, 2014 4:11 am

AstralExistence wrote: ...its a shame reaper is so stale development wise.

Do you know how foolish saying that makes you sound?

http://landoleet.org/whatsnew4.txt

Anyone who reads the changelog can see Reaper's development is far from "stale" and it's still being developed faster than every DAW, and faster than many combined. Unfortunately, they might not always code according to your priorities (they certainly don't mine), but that's reality with any DAW.

Btw, they've also just added the main person behind the SWS extension to the development team, so there's a good chance of seeing a lot of what is now extension functionality integrated into the main code-base.

Ogopogo · Post by **Ogopogo** » Thu Apr 03, 2014 4:16 am

AtomOfScent wrote:Btw, they've also just added the main person behind the SWS extension to the development team, so there's a good chance of seeing a lot of what is now extension functionality integrated into the main code-base.

That's really interesting. I'm coming from Reaper and I had about given up hope that they would fix the stuff that bothers me anytime soon. Maybe they'll be able to make some big changes.

machinesworking · Post by **machinesworking** » Thu Apr 03, 2014 6:58 am

OK breakdown on a 2009 Mac Pro 8 core 2.66 Xeon with 24GB RAM.
Initially the 32 bit version of Live 8 gave an abysmal performance, after installing Live 8 64 bit, it seams whatever was wrong with the 32 bit instal got fixed, only explanation I can give?

All done with NI Massive 1992 preset Ultra setting, 256 sample buffer and an RME Fireface interface. Automap is installed and running here. 8 bar single quarter note, and a simple audio loop accompaniment.

Bitwig -------- 44 instances of Massive
[at best, the new 1.0.5 build currently is not handling 38 without crackling]

Live 8 32bit - 55 instances
[Before installing the 64 bit version of Live 8, it could only handle 15, have no idea why?]

Live 9 64bit - 58

DP 8 64bit-----76

So Bitwig is currently at 50% the CPU power of DP and 65% the CPU of Live 9.

Sadly I thought that not having massive dependencies on old code and an internal modular system instead of Max For Live etc. would improve the performance. I hope this is something they plan on working on, a 50% cut is CPU power is about as bad as it gets.

MonsieurF · Post by **MonsieurF** » Thu Apr 03, 2014 8:44 am

Hello bitwig devs,

I saw on my Linux instance that from time to time, the CPU of the app (the Engine part, IIRC) remains superior than 100% of one core usage for a large amount of time (it seems until I shut it down), even without anything playing or any plugin started. Would it help if I send you some java thread dumps when it happens?
Maybe it will give you a clue of what can possibly go locked in the app.

AstralExistence · Post by **AstralExistence** » Thu Apr 03, 2014 1:07 pm

AtomOfScent wrote:
AstralExistence wrote: ...its a shame reaper is so stale development wise.

Do you know how foolish saying that makes you sound?

http://landoleet.org/whatsnew4.txt

Anyone who reads the changelog can see Reaper's development is far from "stale" and it's still being developed faster than every DAW, and faster than many combined. Unfortunately, they might not always code according to your priorities (they certainly don't mine), but that's reality with any DAW.

Btw, they've also just added the main person behind the SWS extension to the development team, so there's a good chance of seeing a lot of what is now extension functionality integrated into the main code-base.

i know what im saying. i know thats, correct what you said about reaper being the most fastest developing daw. this is completely true. i will not argue, cant argue with that. but reaper needs needs interface, usable preconfigured tool icons, and tons of things that will make it user/ergonomically friendly. they just keep tacking stuff onto it without addressing the underlining issues.

thats needs to change. the default theme is ugly. i always hated white ties work. sorry but i do. now that guy lamda, juston needs to hire him. or silent if he was still around.

Simulant · Post by **Simulant** » Thu Apr 03, 2014 1:23 pm

AstralExistence wrote:
AtomOfScent wrote:
AstralExistence wrote: ...its a shame reaper is so stale development wise.

Do you know how foolish saying that makes you sound?

http://landoleet.org/whatsnew4.txt

Anyone who reads the changelog can see Reaper's development is far from "stale" and it's still being developed faster than every DAW, and faster than many combined. Unfortunately, they might not always code according to your priorities (they certainly don't mine), but that's reality with any DAW.

Btw, they've also just added the main person behind the SWS extension to the development team, so there's a good chance of seeing a lot of what is now extension functionality integrated into the main code-base.
i know what im saying. i know thats, correct what you said about reaper being the most fastest developing daw. this is completely true. i will not argue, cant argue with that. but reaper needs needs interface, usable preconfigured tool icons, and tons of things that will make it user/ergonomically friendly. they just keep tacking stuff onto it without addressing the underlining issues.

thats needs to change. the default theme is ugly. i always hated white ties work. sorry but i do. now that guy lamda, juston needs to hire him. or silent if he was still around.

I agree, I never liked Reaper at all. Some people love it, just not me! Bitwig is light years ahead imo.

Reaper just seems like an ugly mess of a DAW. And each update seems to address a ton of stuff that nobody cares about. Whereas the Bitwig team seem to be listening and improving their product.

ThomasHelzle · Post by **ThomasHelzle** » Thu Apr 03, 2014 2:12 pm

machinesworking wrote:OK breakdown on a 2009 Mac Pro 8 core 2.66 Xeon with 24GB RAM.
Initially the 32 bit version of Live 8 gave an abysmal performance, after installing Live 8 64 bit, it seams whatever was wrong with the 32 bit instal got fixed, only explanation I can give?

All done with NI Massive 1992 preset Ultra setting, 256 sample buffer and an RME Fireface interface. Automap is installed and running here. 8 bar single quarter note, and a simple audio loop accompaniment.

Bitwig -------- 44 instances of Massive
[at best, the new 1.0.5 build currently is not handling 38 without crackling]

Live 8 32bit - 55 instances
[Before installing the 64 bit version of Live 8, it could only handle 15, have no idea why?]

Live 9 64bit - 58

DP 8 64bit-----76

So Bitwig is currently at 50% the CPU power of DP and 65% the CPU of Live 9.

Sadly I thought that not having massive dependencies on old code and an internal modular system instead of Max For Live etc. would improve the performance. I hope this is something they plan on working on, a 50% cut is CPU power is about as bad as it gets.

Hm - interesting. Is it the same with a current machine?
I was rather impressed when I got my 6 core i7 running at 4.1 Ghz last year that while it is only about twice as fast as my 2008 Mac Pro 2.8 Ghz 8 core Xeon with most software, that for instance Diva performed like 10-20 time better.
On the old MacPro I could only play 1-2 Notes at a time while now I can hardly saturate it at all.

Would be interesting if Bitwig also uses some of the optimizations for current CPUs.

Cheers,

Tom

garyboozy · Post by **garyboozy** » Thu Apr 03, 2014 3:28 pm

this doesn't worry me because i don't run that much stuff at once,
but out of interest i just tested quickly here to see what happens...

Live 9.1.1 (64-bit)
interface set to 512 samples
1x Aalto instance with 2-voice sequence running per track
duplicated = 24 tracks before audio breakup occurs

Bitwig 1.0.5 (64-bit)
interface set to 512 samples
1x Aalto instance with 2-voice sequence running per track
duplicated = 17 tracks before audio breakup occurs

quite a difference

Echoes in the Attic · Post by **Echoes in the Attic** » Thu Apr 03, 2014 4:29 pm

Yeah it looks Bitwig is consistently performing up to about 75% of the CPU threshold of Live by many of our tests.

I am very surprised by this given that it's a fresh re-write. I always thought Live was inefficient. I wonder if it's due to the JAVA programming or what. It's not exactly a bloated program right now.

Not only the CPU performance, but I can't get anywhere near as low of audio buffer without crackles. Lowest I can go with built-in card is 256 in Bitwig! (My fireface is packed up due to moving/renovations). With Live I can play at 64 samples.

Bitwig

KVR Audio

CPU usage is ridiculous