CPU usage is ridiculous

[Echoes in the Attic]

!

Generalisation is inappropriate.
Everyone has to test on his own machine.
Even a software driver can make the difference for instance.

Don't trust me, test yourself.

Here the first simple comparison I do on my machine I do on mine :
- Have 1 effect track, put valhalla reverb's default preset (room)
- Have 1 one audio track, set a stereo input, leave the output to master, send 50% to the effect track, activate monitoring.

On my machine, on my current project, Live 9 takes 17 % whereas BwS takes 7 %.
It's a stable situation when a stable sound is sent from a kb.

B.

Sorry but it's not really a very accurate test to measure cpu % (and what percentage reading is that anyways?). It doesn't necessarily reflect real world processing availability. The only real test is to duplicate a process until failure across tracks, as many people have already tested and are consistently getting the similar results.

[AtomOfScent]

...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.

Yes, different issues entirely. I've never used the default theme and considering how many there are, and the fact that Reaper is themable to an extent no other DAW is, I think it's another non-issue. I use a Cubase style theme called Alter Ego, and there are countless, just find one you like.

I agree with features seemingly being tacked on, which over time leads to a less desirable user experience. Hopefully they work to address this, but it's easier when there is only one way to do something in a program, but as Reaper aims to give completely freedom for people to customize it exactly how they want, until a person does that, it will be more cumbersome than a DAW that picks a single way to do everything and just forces people to "get used to it". Sometimes, I think the latter would be desirable, but on the whole, I'm happy for the customization ability.

Sometimes this leads to a bit of an identity crisis, as my Reaper can be using a Cubase theme with all Cubase shortcuts, where someone else's has a Pro Tools theme with Logic shortcuts. We would be lost in each others setup. Thankfully it takes seconds to change it, or run our own copies on a USB stick, but I do think not having a single coherent identity can be daunting for new/casual users.

Bitwig doesn't even allow altering shortcuts. Compare that with Reapers fully assignable shortcuts, custom action/macro chaining, and python scripting. Again the key is to have things set up the way you want before hand, not try to struggle with it during the music making process.

[bulusglo]

!

Generalisation is inappropriate.
Everyone has to test on his own machine.
Even a software driver can make the difference for instance.

Don't trust me, test yourself.

Here the first simple comparison I do on my machine I do on mine :
- Have 1 effect track, put valhalla reverb's default preset (room)
- Have 1 one audio track, set a stereo input, leave the output to master, send 50% to the effect track, activate monitoring.

On my machine, on my current project, Live 9 takes 17 % whereas BwS takes 7 %.
It's a stable situation when a stable sound is sent from a kb.

B.

Sorry but it's not really a very accurate test to measure cpu % (and what percentage reading is that anyways?). It doesn't necessarily reflect real world processing availability. The only real test is to duplicate a process until failure across tracks, as many people have already tested and are consistently getting the similar results.

You missed the point :
I haven't anything concrete in this topic.
At least a common project definition to start with,
and, ok, push that same project until "failure across tracks".

[vientemusic]

CPU usage is dissapointing. I've made a test. 8 instances of Spire in Bitwig against 14 in REAPER without crackings (same MIDI, same preset, same settings)...that's not much I hope it can be improved in the future.

[Echoes in the Attic]

You missed the point :
I haven't anything concrete in this topic.

How could I miss a point that you never made. There have been lots of users reporting almost the same relative performance between bitwig and other DAWs, regardless of whether you've heard about it.

At least a common project definition to start with,
and, ok, push that same project until "failure across tracks".

No need for common project. We are not evaluating Bitwig performance with respect to different setups and computers. We are comparing relative to other DAWs on the same system. You need only make sure that you are using the same test in both DAWs. The relative performance is what's important, not absolute track count.

There's nothing wrong with how users have tested so far, which is why results are consistent. I'd suggest trying the same to get an accurate picture of performance.

[Lesha]

This is my post from another thread which is related to CPU usage, I think you might find it interesting. Ableton Live is 50-60% more efficient than BWS.

http://www.kvraudio.com/forum/viewtopic ... 4#p5704494

[shadiradio]

Ableton Live is 50-60% more efficient than BWS.

It's easier to be more efficient when you aren't concerned with calculating things properly. I kid, I kid.

But seriously, last night we were well underway on our first "real" track produced fully in Bitwig, and the DSP meter is super high with very few tracks (compared to our previous songs). It was pretty disappointing, I just hope it's not a fundamental thing that is not improvable. In fact judging by the intermittent crackling, I think it would actually be impossible for us to have produced our previous tracks in Bitwig, they were much more demanding (without a ton of bouncing left and right).

I'm not sure what to think about that, I'm trying to mentally prepare for acknowledging that this is the reality here, but I hope not!

Sidenote that has me hopeful that this is actually a bug: Native Instruments Guitar Rig (FX) seems to pretty easily cause Bitwig to crackle/struggle with some presets. I'm used to using it liberally on several tracks, but I get nervous adding it to just a couple tracks in Bitwig.

[Echoes in the Attic]

Yes hopefully the cpu efficiency can be improved. But I'd also like to hear from Bitwig if there is a good reason for it, perhaps something they are doing that is CPU costly that other DAWs aren't.

On a related note - I just tried using lower buffers and it is working fine for me now all the way down to 32 sample buffer! I couldn't go below 256 before. So one of the recent updates must have improved something there.

[abique]

I also think that there is an issue in the CPU usage.

I'm at 60% CPU usage, the playback is stopped. And while stracing the engine, I can see a lot of futex stuff. Maybe there is an issue in their concurrency/producer/consumer design but it may be harmless when bitwig is loaded.

On the other hand, I made a track with only bitwig synths and effects, and they take almost no CPU. So I'm not complaining on bitwig performances.

Also I use bitwig on linux and ALSA as audio backend.

[psycha0s]

I noticed that bitwig uses about 10 threads for requesting audio data from *SINGLE* VST plugin (I mean calls to processReplacing() are made from 8-10 different threads). Maybe I misunderstood something and Bitwig just uses 10 audio processing threads for all VST plugins.

[abique]

How did you record that?

[Lesha]

I noticed that bitwig uses about 10 threads for requesting audio data from *SINGLE* VST plugin (I mean calls to processReplacing() are made from 8-10 different threads). Maybe I misunderstood something and Bitwig just uses 10 audio processing threads for all VST plugins.

Interesting. What is the usual number of threads?

[psycha0s]

How did you record that?

Currently I am writing wine VST bridge for using windows VST under Linux. I took your code as example but I use shared memory instead of domain sockets. When debugging my code I log thread id inside of each call to my proxy plugin. And according to my logs, processReplacing() gets called from many different threads.

[psycha0s]

Interesting. What is the usual number of threads?

Usually only one thread to handle GUI events, and one for audio processing. But each VST host has its own threading scheme, so there may be different options.

[Hez]

I'm hoping it's just related to the current bugginess of external VST support, which can hopefully be refined a lot over time. Given how efficient Bitwig seems to be when just using internal instruments and effects that seems to be the case. Maybe the plugin sandboxing is extremely CPU intensive, in which case it would be nice to have two 'modes' - live mode where plugins are very carefully sandboxed, and studio mode where we can eke out a bit more CPU use at the cost of plugin crashes being a bigger deal. I realise this is currently covered to some extent with the independent plugin processing but I haven't actually noticed a huge CPU saving switching to either.