Bitwig

abique · Post by **abique** » Sat Apr 19, 2014 2:23 pm

phantom-one wrote: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.

OK. This is a very very very welcome news

I had no more energy to develop vst-bridge, been stuck with wine xembed. The code has been wrote like a proof of concept rather than engineering.

Good luck bro !

psycha0s · Post by **psycha0s** » Sat Apr 19, 2014 4:07 pm

abique wrote:OK. This is a very very very welcome news I had no more energy to develop vst-bridge, been stuck with wine xembed. The code has been wrote like a proof of concept rather than engineering.

Good luck bro !

Sadly, wine xembed drives me crazy. I've got wine window embedded in Bitwig window successfully, but some VST plugins (reFX Vanguard for example) try to get mouse position in absolute coordinates. When window is embedded in another window, reported global coordinates are always relative to embedder's origin, not screen origin. Also it seems, that not all events are translated to client window from embedder. As result VST GUI partly unusable in embedded mode.

abique · Post by **abique** » Sat Apr 19, 2014 4:12 pm

phantom-one wrote:Sadly, wine xembed drives me crazy. I've got wine window embedded in Bitwig window successfully, but some VST plugins (reFX Vanguard for example) try to get mouse position in absolute coordinates. When window is embedded in another window, reported global coordinates are always relative to embedder's origin, not screen origin. Also it seems, that not all events are translated to client window from embedder. As result VST GUI partly unusable in embedded mode.

There is one guy on IRC called slackner. You'll find him on freenode, in #winehackers. He might be able to solve your issues. Also I'm idling in #bitwig if you want to come by

Sometimes the issues with mouse comes from wine. I remember u-he synth to misbehave with left click (started by reaper so without any bridge).

Lesha · Post by **Lesha** » Sun Apr 20, 2014 11:16 pm

CPU consumption is THE biggest problem in Bitwig for me, this is completely unacceptable.
I hope they will improve this if they want to be taken seriously, this should have the highest priority!!!

crazyfiltertweaker · Post by **crazyfiltertweaker** » Mon Apr 28, 2014 4:44 pm

here too....

Since I started using 32-bit plug-ins, the CPU display moving in a high range. I turned off one by one all of my internal and third party plugins by process of elimination, but even if all plugins are turned off, the CPU remains display tagged (see 2 screenshots).

I don't know what the cause is, but I would have following suggestions to counter this:
(a) an adjustable CPU threshold, the not a single plugin may come across and if you tappin' a message on what plugin is it and whether you want to disable it.
(b) a list that displays the CPU usage of each individual plug-ins and the latency.

LYTZ · Post by **LYTZ** » Mon Apr 28, 2014 5:31 pm

Looks like Bitwig has "Soft-bypass".

Means, when you bypass plugins, they are not "hard-bypassed", meaning you still have the hit on CPU.

Thats also true when you bypass high latency plugins.

You still have the PDC latency even if they are bypassed, which might cause trouble when you want to add/record stuff late in the session when you already have some high PDC stuff going on.

(Because your only chance then is to delete the plugs to get some acceptable latency...
might be good to keep that in mind.)

'L.

Lesha · Post by **Lesha** » Mon Apr 28, 2014 5:55 pm

CPU usage is still a lot worse than other DAWs. I am interested what is the reason behind this.
As you can see from my previous posts Bitwig runs 18 instances of SlickEQ without crackles, compared to Ableton's 30. You do the math.

Could anyone from Bitwig comment on this?

Cyoon · Post by **Cyoon** » Mon Apr 28, 2014 6:12 pm

are you guys indivudal processing the plugins or global?

Lesha · Post by **Lesha** » Mon Apr 28, 2014 7:48 pm

Suloo wrote:are you guys indivudal processing the plugins or global?

It's the same result with both.

I have conducted another test, putting a loop (with no stretching) with a Slick EQ on each track.
I have managed to run 63 in Bitwig, and 103 tracks in Ableton without noticeable crackles!

Bitwig guys, do you have an explanation for this?
Is it because of JAVA, or is it something else?

I would really like to know.

abique · Post by **abique** » Mon Apr 28, 2014 7:58 pm

I think that the audio engine is in C++, only the UI is in Java, so the issue does not come from the GUI.

I'm not an expert on this area, but I would bet that this issue comes from cache miss in the CPU.
So there are a few things to check:
- take care of running the same plugins on the same cpu core id to avoid cache issues
- this includes running the an instance A on the same cpu as much as possible
- regroup plugins of the same type on the same cpu, so the plugin's code is hot cache.
- run cachegrind, callgrind, and all the profiling tools available

Good luck!

Chris Rimby · Post by **Chris Rimby** » Tue Apr 29, 2014 4:56 pm

The #1 thing I have issues with when using Ableton Live is cpu inefficiency. To switch over to Bitwig I would need it to be MORE efficient that AL9, so this thread is a little disconcerting.

_leras · Post by **_leras** » Tue Apr 29, 2014 6:18 pm

I think the reason - which I think I saw Bitwig state somewhere - is that this is primarily a live performance tool. For the Bitwig team, always having everything available and knowing that 100% when you switch your e.g. delay effect on, or drop in a busy synth line - that the part and/or effects will come in without causing glitches or any other problems is a top priority.

The tradeoff is cpu performance vs rock solid live performance.

Which is more important to you? Personally I agree with their approach.

It wouldn't surprise me that they will be able to improve cpu usage in the future. Running each plug in a failsafe wrapper must have some impact, but it's probably worth the cpu hit imo.

A completely different question then arises. If Bitwig is primarily focused on rock solid live performance, can it maintain this and also become a 'complete' DAW for recording as well as live performance? We'll have to wait and see. Again, personally, I'm in agreement for their live performance first approach.

abique · Post by **abique** » Tue Apr 29, 2014 6:21 pm

If this is the issue, then we may see a "live/studio" switch button?

Fjorko · Post by **Fjorko** » Tue Apr 29, 2014 6:21 pm

Live ? Really ?

I heard the contrary in that it was aimed more at the studio producer with an emphasis towards sound design, and workflow improvement etc...

Sure, it can be used live as well i guess, but that's not what I heard....

Lesha · Post by **Lesha** » Tue Apr 29, 2014 6:28 pm

_leras wrote:Running each plug in a failsafe wrapper must have some impact, but it's probably worth the cpu hit imo.

CPU usage is the same no matter if you run the plugins independently or not.

Bitwig

KVR Audio

CPU usage is ridiculous