Voxengo Premium Membership - All Voxengo Plugins For a Fixed One-Time Fee
Winter Holidays 2017-2018 Discount
Forums     Plugins     Voxformer High CPU drain when GUI open


Please try AudioUnit as well.

Ok, tested a few more things:

- AU Voxformer 2.10 in Live seems to exhibit same CPU load

- VST GlissEQ 3.8 shows up to 65% CPU load

- AU Voxformer in Logic 10.2.1 shows up to 60% CPU load

- AU GlissEQ 3.8 in Logic settles at around 10%


Thanks for testing!  I'll investigate this issue after installing OSX 10.11 soon.

Cannot reproduce this issue with OSX 10.11.3 and Live 9.6 and Voxformer 2.9.  No idea what's wrong.  Please try switching preset - maybe its the default preset which causes the overload.

Hmm, ok, I'll update to OSX10.11.3 to see if it can be recreated

Definitely not default preset issue - every preset has same CPU drain

For information- after closely monitoring the CPU when using the VF interface, I notice these

- CPU before VF inserted, 5-6%

- CPU after VF inserted - 55% - no functions enabled

- CPU after enabling COMP1 - 66%

- CPU after enabling COMP2 - 71%

**disable COMPs**

Test with EQ nodes

- CPU after 2 EQ node increased +6db while moving the node, at rest, CPU drops back to 55%

Perhaps this data can help eliminate what isn't causing the problem.


After upgrading to 10.11.3 no change in GUI performance.  Same as previous post.

OSX 10.11.3

Live 9.6

VF 2.10


Ah, this is a real shame - I'm testing GlissEQ 3.8 and I'm getting even worse CPU drain than VF - up 80% with 1 EQ node altered.

Please remember this is only a problem when using the 64bit version of Live.

32bit version does not exhibit the same CPU drain.

I really don't want to but I'm going to have to start looking at other channel strip solutions if there isn't a clear fix for these GUI issues.  I'm also surprised there aren't more customers who are experiencing this - I can't believe my combination of equipment is particularly unique.


Sorry, but this is definitely an isolated issue which has something to do with your Mac setup.  I have not received similar reports and I cannot reproduce this issue on my MacBook Pro.  On the other hand, we are planning to rework graphics engine we use to render the UI, but this won't happen soon and I do not know if that will help or not to fix the issue.

I'm hesitant to agree with you, but I just tested on my old MBpro and the CPU increase sits very low at around 10%.  It must be something to do with the graphics code and my graphics platform.  Still, I'm going to have to look at an alternative channel plugin which is going to be tough since I've used your products for around a decade.

Hi Aleksey - I wonder if an OSX report log might give you an idea of where, or how, this high CPU problem in 64bit Live persists.  The first couple of lines read like this (which is what made me thing it _might_ be useful to you):

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

0 com.voxengo.audio-plugins.VST2.GlissEQ 0x0000000161495f45 vox::CUIEventBridge::handleEvent(int) + 165

1 com.voxengo.audio-plugins.VST2.GlissEQ 0x0000000161530f75 -[CWindowCocoaEventBridge_d29nmv00 postedVoxEvent:] + 69

If the rest of the log is of any use to you in this respect, I can forward the whole report.  Sorry for bringing this up again, but if you can help me identify where the problem is, I may be able to affect it, and possibly improve it, from here.

Many thanks, Matthew

This topic was last updated 180 days ago, and thus it was archived.  Replying is disabled for this topic.