CPU usage is ridiculous

[Lesha]

Therefore i absolutely believe you have a performance problem, if you state that but just not the one I was referring to.

I have no problem at all using Ableton Live, only BWS gives me high CPU consumption.

Absolutely possible.
I can only quote myself: Millions of reasons can be the cause, get in touch with support with as much information as possible in order to recreate and find your issue.

Ok, I will wait for a new graphic card to arrive first and see if there are any changes.

[codec17]

[quote="dom@bitwig"]Quick one: deactivating tracks (and even hiding those then) as well as deactivating devices and vst plugins to save cpu will be included in 1.1 as an additional function to the current "on/off" button of devices, which acts like a mute, as you know.

What?? even HIDING tracks????? YES! OOOOH MAN cant wait for 1.1!!
This is some really good news! thnx!

[askewd]

ok thought i'd do a new test with the latest version.

I've decided to do a 'real life' kinda test - rather than using one plugin i used a few different ones (all 3rd party) and also rather than using an audio track to test i've used a synth (Zebra) with a basic patch playing one note on every beat constantly.

Each track consisted of: 1) Zebra 2) VallallahRoom Reverb 3) Waves One-Knob Wetter 4) Kramer Pie 5) Voxengio Voxformer. I then duplicated the track over and over. Of course i ensured the settings were identical in both DAWS.

I have Logic pro X and BitWig on IMac (10.9.4) 2.8ghz Intel Core i7 16GB ram

Results....

Logic could play 35 tracks before coming to a complete standstill (audio overload error pop up)
Bitwig could play 32 tracks before crackling and popping.

I think that is pretty respectable.

Some other observations / thoughts...

Logic didn't crackle ... was fine, then just stopped.

Bitwig cracked and popped at 27 tracks when i was zooming and doing graphical stuff. So this is the 'safe' limit for live performances (if using this particular set up). not quite so good.

Logic's GUI remained responsive even when CPUs maxing out. Where as Bitwig itself slowwwwwwed right down as the track count mounted. It became very slug like.

Interesting!
best
DALE

[PolaroidThePenguin]

So as far as CPU, what is better, independent or global plug in processing? Confused. Independent would free up some RAM usage, but at the cost of CPU, correct?

[ThomasHelzle]

I always use independent processing since that is just such a great feature to have.
Try it yourself on your own machine if it makes a difference for you with the same realworld project. I guess I should repeat my tests with global processing as well...

I would think that overall global should use a bit less juice, both with RAM and CPU, but will need to do some tests to verify it.

Cheers,

Tom

[ThomasHelzle]

Just tried it with the Slick-EQs-on-one-track project: Made absolutely no difference on my machine. I restarted after switching to make sure it reloads it correctly. In both cases, if I loaded one more EQ, it started crackling. So on a good machine it should basically make no difference.
I'll continue using independent processing - it's just too nice to miss

Cheers,

Tom

[askewd]

i forgot to mention in my post the buffer was set to 512. Also it was global processing. I only use Nebula as individual process as that's the one that crashes the most. Infact i'd say that in my experience, bitwig is incredibly stable.
cheers

[ThomasHelzle]

I'm running buffers at 128.
I don't see much crashes either (don't use Nebula) but find individual processing just a nice fallback in case something happens. (I'm testing a lot).

I just recently used another Host and a plugin went - the Host of course went with it... Almost forgot already that that used to happen and how regularly in some cases...
That feature alone is worth it for me.

Cheers,

Tom

[Lesha]

Just want to add that the situation is still the same in v1.1
Ableton Live = 32 instances of SlickEQ, BWS = 18 instances until I hear clicks.

[ThomasHelzle]

Just want to add that the situation is still the same for me in v1.1
Ableton Live = 32 instances of SlickEQ, BWS = 18 instances until I hear clicks.

Fixed that for you

Cheers,

Tom

[pdxindy]

Just want to add that the situation is still the same on my machine in v1.1
Ableton Live = 32 instances of SlickEQ, BWS = 18 instances until I hear clicks.

Fixed that for you

Cheers,

Tom

Fixed it better...

[kurasu]

Just want to add that the situation is still the same in v1.1
Ableton Live = 32 instances of SlickEQ, BWS = 18 instances until I hear clicks.

I assume you're adding the plug-ins in series on one track and use a dual-core CPU?

In that situation you are seeing a fundamental difference how Live and Bitwig Studio works. In Live, each plug-in adds the latency of one audio I/O buffer for each plug-in in the chain. That would be roughly 5ms if you're running you at 41.kHz with a buffer size of 256 samples. This means that if you have 32 plug-in instances on a track, you will also get 160 ms of latency contributed by the plug-ins (assuming that the plug-ins doesn't add any latency on their own). By adding this latency, the audio engine doesn't need to take the audio output of the effect prior to it in the chain as it's input, but can use the audio output that was calculated last buffer as its input. That means that there is no dependency between the different plug-ins, when calculating "this" buffer, so they can all be processed in parallel.

In Bitwig Studio there is no buffering tricks used and no latency added to the plug-in processing other than what the plug-in itself requires, which means that if you put all the plug-ins on one track, they are all dependent on each other and can't be processed in parallel. However once you start distributing these plug-ins on multiple tracks they will be processed in parallel, and in actual documents there will be enough tracks to have enough work to distribute among the CPU cores.

So your test doesn't really test much more than what happens if you put 32/18 plug-ins on a single track, it doesn't test how it well would work in a real-world document where you have many tracks. It also doesn't take into account that Bitwig will play have much lower latency for the same buffer size, allowing you to use much bigger buffer sizes for a comparable latency.

[Eta Carinae]

Just want to add that the situation is still the same in v1.1
Ableton Live = 32 instances of SlickEQ, BWS = 18 instances until I hear clicks.

I assume you're adding the plug-ins in series on one track and use a dual-core CPU?

In that situation you are seeing a fundamental difference how Live and Bitwig Studio works. In Live, each plug-in adds the latency of one audio I/O buffer for each plug-in in the chain. That would be roughly 5ms if you're running you at 41.kHz with a buffer size of 256 samples. This means that if you have 32 plug-in instances on a track, you will also get 160 ms of latency contributed by the plug-ins (assuming that the plug-ins doesn't add any latency on their own). By adding this latency, the audio engine doesn't need to take the audio output of the effect prior to it in the chain as it's input, but can use the audio output that was calculated last buffer as its input. That means that there is no dependency between the different plug-ins, when calculating "this" buffer, so they can all be processed in parallel.

In Bitwig Studio there is no buffering tricks used and no latency added to the plug-in processing other than what the plug-in itself requires, which means that if you put all the plug-ins on one track, they are all dependent on each other and can't be processed in parallel. However once you start distributing these plug-ins on multiple tracks they will be processed in parallel, and in actual documents there will be enough tracks to have enough work to distribute among the CPU cores.

So your test doesn't really test much more than what happens if you put 32/18 plug-ins on a single track, it doesn't test how it well would work in a real-world document where you have many tracks. It also doesn't take into account that Bitwig will play have much lower latency for the same buffer size, allowing you to use much bigger buffer sizes for a comparable latency.

Thanks for the explanation, that was an interesting read.

[billcarroll]

...
Bitwig cracked and popped at 27 tracks when i was zooming and doing graphical stuff.
...

It's good to hear this from someone else re: cracks and pops when zooming and scrolling. I am not alone. Still have some CPU left, but audio breaks up.

Are you on Windows or Mac? I'm on a Mac running 10.10.1 Yosemite.

[Lesha]

Just want to add that the situation is still the same in v1.1
Ableton Live = 32 instances of SlickEQ, BWS = 18 instances until I hear clicks.

I assume you're adding the plug-ins in series on one track and use a dual-core CPU?

In that situation you are seeing a fundamental difference how Live and Bitwig Studio works. In Live, each plug-in adds the latency of one audio I/O buffer for each plug-in in the chain. That would be roughly 5ms if you're running you at 41.kHz with a buffer size of 256 samples. This means that if you have 32 plug-in instances on a track, you will also get 160 ms of latency contributed by the plug-ins (assuming that the plug-ins doesn't add any latency on their own). By adding this latency, the audio engine doesn't need to take the audio output of the effect prior to it in the chain as it's input, but can use the audio output that was calculated last buffer as its input. That means that there is no dependency between the different plug-ins, when calculating "this" buffer, so they can all be processed in parallel.

In Bitwig Studio there is no buffering tricks used and no latency added to the plug-in processing other than what the plug-in itself requires, which means that if you put all the plug-ins on one track, they are all dependent on each other and can't be processed in parallel. However once you start distributing these plug-ins on multiple tracks they will be processed in parallel, and in actual documents there will be enough tracks to have enough work to distribute among the CPU cores.

So your test doesn't really test much more than what happens if you put 32/18 plug-ins on a single track, it doesn't test how it well would work in a real-world document where you have many tracks. It also doesn't take into account that Bitwig will play have much lower latency for the same buffer size, allowing you to use much bigger buffer sizes for a comparable latency.

Well, I have already tried that, and the result was even worse!
Take a look:
http://www.kvraudio.com/forum/viewtopic ... 0#p5855490

I have a 6 core CPU.