Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Solution for 3nd party plugins gui slugishness
#11
(03-19-2016, 10:20 AM)Ian Ballard Wrote: I'm just throwing this out there. I'm not a programmer but I know enough to be dangerous. The way in which a host deals with parsing out the code for graphics can determine how well it performs with certain plugins. Different plugin brands have different ways in which they tell the host to deal with the GUI, so whatever the DDMF metaplugin is doing with the graphics code, is more efficient than what Ardour is doing natively. If the folks at Harrison were able to find what aspect of the graphics parsing is causing a bottleneck, they might be able to fix it properly, so you won't need a middle man between the native host and the plugin. This issue is pretty serious, in my opinion. Lots of people use Soundtoys, including myself. I also use the Softube Console 1 and it is virtually unusable on a decent sized session. I can't make any udjustments to the channel strip, unless playback is off, which defeats the purpose. Surely, this isn't an insurmountable issue. Otherwise, Mixbus is absolutely brilliant!

I agree 100% Ian.
Windows 10, Harrison Mixbus 10 Pro, UAD 2 octo, http://www.youtube.com/user/NikosPitloglou/videos
Reply
#12
I still think that having to use a plugin host to make those plugins work properly within Mixbus is unacceptable.
Don't get me wrong, I support MB since the first release, and I'm always try to work with it as much as I can, but as of now, it's a no go for me.
I hope the team gets this right soon.
Reply
#13
(03-19-2016, 10:20 AM)Ian Ballard Wrote: I'm just throwing this out there. I'm not a programmer but I know enough to be dangerous. The way in which a host deals with parsing out the code for graphics can determine how well it performs with certain plugins. Different plugin brands have different ways in which they tell the host to deal with the GUI, so whatever the DDMF metaplugin is doing with the graphics code, is more efficient than what Ardour is doing natively. If the folks at Harrison were able to find what aspect of the graphics parsing is causing a bottleneck, they might be able to fix it properly, so you won't need a middle man between the native host and the plugin. This issue is pretty serious, in my opinion. Lots of people use Soundtoys, including myself. I also use the Softube Console 1 and it is virtually unusable on a decent sized session. I can't make any udjustments to the channel strip, unless playback is off, which defeats the purpose. Surely, this isn't an insurmountable issue. Otherwise, Mixbus is absolutely brilliant!

This is similar to what I thought -- the graphics for AD2 are just being handled poorly.

And it is not just big GUI plugins like AD2 (which is almost like a DAW engine itself)... one of my favorite EQ plugins is also from DDMF -- the 6144 (a Neve eq clone), and when I try to use the AU version just dropped in as an insert ion a track, the adjustments of knobs are VERY slow and erratic.

But if I use the DDMF Metaplugin, with the 6144 eq loaded in it, the performance of the 6144 is just fine.

I suspect _many_ plugins are exhibiting this type of behavior... at least AU on OSX.

What say ye, Mr. Loftis?

(03-19-2016, 04:05 PM)Jera Cravo Wrote: I still think that having to use a plugin host to make those plugins work properly within Mixbus is unacceptable.
Don't get me wrong, I support MB since the first release, and I'm always try to work with it as much as I can, but as of now, it's a no go for me.
I hope the team gets this right soon.

I agree. This is a sad situation, and deserves serious attention.
Reply
#14
Well, I'm working on a mix right now, that has no plugins other than the SSL Bus compressor (1 instance), Valhalla Vintage Verb (2 instances) and Airwindows Gate (5 instances).
Since I put the first plugin in, things were getting sluggish. So I must say something is wrong with Mixbus.
Now at final stages, things are sluggish, but not to the point I can't work, but I really don't think it's enjoyable.

I'm running an i7 3.5ghz, with 16Gb RAM, Mac OS 10.5.5. Video card is a GT 640 1Gb.

I spoke with Ben a loooooong time ago about the GUI being very slow on a heavy mix (back in 2012 I guess) but I had a very weak video card in that time (8400), and after v2, I didn't have this problem anymore. Now I have a slightly better video card but v3 doesn't work well again...
Reply
#15
Mixbus only limits the framerate of plugin GUIs to about 25fps and does not process separate the plugin GUI.
AD2 in particular can be bad: The animation can be nearly a full HD video, more so on recent Retina screens.
It was worse before we limited it to 25fps - AD was able to completely freeze the host's UI.
Reply
#16
I'm sure some plugs are worse than others, but I have several that can really slow things down. Slate VMR seems to be getting better. Metric halo's plugs, mostly while using their foo analyzer within them, and also redline eq while using the analyzer, seems to be my biggest culprits. My newly acquired x42 eq with analyzer seems to be much better. Smile but I concur that there is something a bit amiss. I've never noticed these issues in other daws.

And fwiw I'm using a dual quad-core 2009 Mac Pro. With 48GB of ram and a r9 280x video card. So horsepower shouldn't be an issue. At least imho.
Reply
#17
(03-23-2016, 11:34 AM)x42 Wrote: Mixbus only limits the framerate of plugin GUIs to about 25fps and does not process separate the plugin GUI.
AD2 in particular can be bad: The animation can be nearly a full HD video, more so on recent Retina screens.
It was worse before we limited it to 25fps - AD was able to completely freeze the host's UI.

So, why does the AD2 AU plugin work fine, when placed in/ran from the DDMF Metaplugin (wrapper)?

Could the developers figure out how to make Mixbus handle AU plugins the same way DDMF did?

(03-23-2016, 01:01 PM)Matt Wrote: And fwiw I'm using a dual quad-core 2009 Mac Pro. With 48GB of ram and a r9 280x video card. So horsepower shouldn't be an issue. At least imho.

What he said.
Reply
#18
(03-23-2016, 02:24 PM)brucerothwell Wrote: Could the developers figure out how to make Mixbus handle AU plugins the same way DDMF did?

I think that's a valid point and a relevant inquire.
MacMini M1 16gb RAM - MacOS 13.6.6 - Apollo silver +  Apollo 16 silver w/Thunderbolt & Satellite OCTO Thunderbolt - SSL UF8/UC1 - Softube Console 1/Fader - UAD v11.2 - Mixbus 10 Pro ARM
Reply
#19
Huh I was in touch with Mixbus support about a month ago and they said they were working on this problem. Since then, nothing. I checked out the DDMF wrapper but it costs a lot more money than I want to spend, especially for something that should work without it. Does anyone know where one can download earlier versions of Mixbus 3? I have 3.1.66 but it has the same bug as well. Earlier versions than that were fine, but unfortunately I deleted them.
Reply
#20
(04-14-2016, 10:48 PM)rieuwert Wrote: Does anyone know where one can download earlier versions of Mixbus 3?

http://mixbus.harrisonconsoles.com/forum/forum-9.html
Macmini 8,1 | OS X 13.6.3 | 3 GHz i5 32G | Scarlett 18i20 | Mixbus 10 | PT_2024.3.1 .....  Macmini 9,1 | OS X 14.4.1 | M1 2020 | Mixbus 10 | Resolve 18.6.5
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)