Bitwig

ThomasHelzle · Post by **ThomasHelzle** » Tue Aug 26, 2014 7:26 pm

Yeah, I'm sure such an option will come, but we still have a performance discrepancy I personally can't reproduce.

- Bad graphics cards may be one part of it.
- CPU throttling was a problem in some cases.
- Any other ideas?

The clearer we can nail it down, the more probable it can be fixed.

Cheers,

Tom

askewd · Post by **askewd** » Wed Aug 27, 2014 7:36 am

Thinking about it... My noted improvement with bitwig latest version does also coincide with me replacing my graphics card recently (it started to have issues) so maybe the graphics card is playing a bigger part in this than I ever realised.

Like another user mentioned, its worse when there are moving screen elements. If I zoom in and out on main arrangement while a heavy track is playing the clicks get bad. If I leave my mouse alone it's fine.

Graphics card or not, this never happened in logic... So I would hope that this is something fixable by BW.

Regarding plugins bypassed but not totally deactivated... I'm quite fond of this approach right now. At least I always know that the cpu usage is what it is. No nasty surprises when I reactivate a plugin. Plus automating the bypass is perfectly in time. I'm thinking, if it's deactivated why's it in project at all? Isn't removing the plugin just the same as deactivating it? Saves clutter... Just wondering what the main reasons are really.

Cheers
Dale

lehtiniemi · Post by **lehtiniemi** » Wed Aug 27, 2014 10:27 am

askewd wrote:I'm thinking, if it's deactivated why's it in project at all? Isn't removing the plugin just the same as deactivating it? Saves clutter... Just wondering what the main reasons are really.

For me the deactivating and saving CPU has two important scenarios:

1) Mixing a project, simultaneously finding the sound for certain instruments: you can bypass plugins/effects that you're quite not sure about. Even instruments that you don't know if they will end up in the final mix. You don't want those eating your CPU when they're muted but you don't want to ditch them yet either - you might still need them.

2) If you aim to perform live instruments on stage, especially in a rig where you have many instruments - you NEED to be able to deactivate the others while using one. The way a normal stage piano works - you load one preset at the time. As an extreme example, I'm playing as a musician in an improvisation theatre and my Ableton Live rig consumes 9 GB of RAM while the set is loaded. I switch the instruments with TouchOSC from my iPad and Live frees the CPU from the deactivated instruments. This rig wouldn't run otherwise. I have probably 40+ production quality VST instruments loaded with some Altiverb and Speakerphone 2 instances in addition, but they're never on simultaneously.

askewd · Post by **askewd** » Wed Aug 27, 2014 10:42 am

Fair points, Lehtiniemi. Especially in live performances as you described, i see the value. Cheers

dom@bitwig · Post by **dom@bitwig** » Wed Aug 27, 2014 1:37 pm

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.

Regarding the graphics cards: We're pretty sure the performance problems are mainly due to gfx chips that share memory with the cpu. We hope to be able to improve even that, but so far we strongly suggest gfx cards with their own RAM.

Cheers!

lehtiniemi · Post by **lehtiniemi** » Wed Aug 27, 2014 1:48 pm

dom@bitwig wrote: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.

EPIC!!!!

dom@bitwig wrote:Regarding the graphics cards: We're pretty sure the performance problems are mainly due to gfx chips that share memory with the cpu. We hope to be able to improve even that, but so far we strongly suggest gfx cards with their own RAM.

I have Mac Mini so it's one of those shared memory computers. But you can't really upgrade the GFX unless you go to Mac Pro which is thousands of euros more. Hopefully this gets better (or the GFX in the next Mac Mini will be better alternatively!)

pdxindy · Post by **pdxindy** » Wed Aug 27, 2014 1:54 pm

askewd wrote:Regarding plugins bypassed but not totally deactivated... I'm quite fond of this approach right now. At least I always know that the cpu usage is what it is. No nasty surprises when I reactivate a plugin. Plus automating the bypass is perfectly in time. I'm thinking, if it's deactivated why's it in project at all? Isn't removing the plugin just the same as deactivating it? Saves clutter... Just wondering what the main reasons are really.

Cheers
Dale

It is deactivated but still in the project because I am exploring and creating and changing stuff... So suppose I need to free up some cpu, so I bounce a track to audio and then I want to be able to disable the plugin(s) on that track so as to save the cpu while keeping the track, plugins and associated automation available for later edits.

Lesha · Post by **Lesha** » Wed Aug 27, 2014 2:13 pm

dom@bitwig wrote:Regarding the graphics cards: We're pretty sure the performance problems are mainly due to gfx chips that share memory with the cpu. We hope to be able to improve even that, but so far we strongly suggest gfx cards with their own RAM.

What do you mean?
I have a dedicated graphic card with 1GB of its own memory and also have the same problems.

spinlud · Post by **spinlud** » Wed Aug 27, 2014 2:14 pm

dom@bitwig wrote: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.

Regarding the graphics cards: We're pretty sure the performance problems are mainly due to gfx chips that share memory with the cpu. We hope to be able to improve even that, but so far we strongly suggest gfx cards with their own RAM.

Cheers!

Very good news Dom! Can't wait to try the 1.1! When do you expect to release?

dom@bitwig · Post by **dom@bitwig** » Wed Aug 27, 2014 2:17 pm

pdxindy wrote:
askewd wrote:Regarding plugins bypassed but not totally deactivated... I'm quite fond of this approach right now. At least I always know that the cpu usage is what it is. No nasty surprises when I reactivate a plugin. Plus automating the bypass is perfectly in time. I'm thinking, if it's deactivated why's it in project at all? Isn't removing the plugin just the same as deactivating it? Saves clutter... Just wondering what the main reasons are really.

Cheers
Dale
It is deactivated but still in the project because I am exploring and creating and changing stuff... So suppose I need to free up some cpu, so I bounce a track to audio and then I want to be able to disable the plugin(s) on that track so as to save the cpu while keeping the track, plugins and associated automation available for later edits.

For now i just keep the original versions of those bounced tracks in a second document tab and just throw them in an out as i need to tweak them or not. Works pretty good as a workaround for not being able to turn off plugins or freeze until 1.1 contains the "hard" deactivate.

dom@bitwig · Post by **dom@bitwig** » Wed Aug 27, 2014 2:26 pm

lesha wrote:
dom@bitwig wrote:Regarding the graphics cards: We're pretty sure the performance problems are mainly due to gfx chips that share memory with the cpu. We hope to be able to improve even that, but so far we strongly suggest gfx cards with their own RAM.
What do you mean?
I have a dedicated graphic card with 1GB of its own memory and also have the same problems.

Then i don't think you have the same problem and should contact support with as many information as possible on how to recreate your issue. Performance problems can have millions of reasons, down to local issues only present on single machines. Therefore i absolutely believe you have a performance problem, if you state that but just not the one I was referring to. The one i was talking about is about bad performance on just any machine with shared graphics due to RAM bandwith.

Cheers!

Lesha · Post by **Lesha** » Wed Aug 27, 2014 2:38 pm

dom@bitwig wrote: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.

dom@bitwig · Post by **dom@bitwig** » Wed Aug 27, 2014 2:57 pm

lesha wrote:
dom@bitwig wrote: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.

throst · Post by **throst** » Wed Aug 27, 2014 4:35 pm

a work around for this would be to make use of your library, dragging clips over and saving before bouncing, then revisiting em to add changes, repeating the process with the updated clip.

Raffi · Post by **Raffi** » Thu Aug 28, 2014 11:50 am

@Dom great news, can we then macro/automate the deactivate switches as well?

Bitwig

KVR Audio

CPU usage is ridiculous