Ableton has audio crackles/glitches ONLY while I am VIEWING the UI of an audio plug-in. I can use the plug-in (not any specific plug-in) just fine, but when I open the plug-in to view it, then I get audio glitches. In this particular case I'm using this little Hornet plug-in that displays the tempo of my live midi keyboard playing so I NEED to have the UI showing. But when I show this plug-in's UI, only THEN do I have audio crackles/glitches.
Does the plug-in UI really take that much processing power? Is there a way to minimize the CPU of a given plug-in, specifically the plug-in's graphical UI?
thanks much!
Audio Glitches while VIEWING Plug-in
-
florian_bl
- Posts: 85
- Joined: Wed Oct 12, 2011 3:53 pm
- Location: Austria
Re: Audio Glitches while VIEWING Plug-in
Certain parts of a plugin‘s graphical user interface can need a lot of processing power if they are not implemented in an ideal way. A good example would be a goniometer to show the stereo width. It needs to be drawn in realtime and there are efficient but also very CPU demanding ways to do this, depending on what values you want to show as numbers overlay at the same time or the update rate of the graphics.
I have the same problem as you with certain plugins. Most of them don’t feature obviously complicated graphical user interface elements that need to be drawn in realtime. So another reason for this problem might be level metering visualization.
Metering in plugins can be displayed by using two images. One with no level (e.g. grey), one with full level (e.g. fully filled with color). If a developer puts the colored image on top of the grey one but only shows the lower part, it looks as if audio signal is present.
Another way to display metering information is to use many different images of the metering bar and constantly load the one that corresponds to the momentary level of this one audio sample. Here we enter the world of higher demand to the computer because of the constant loading of images.
The worst way that I‘m aware of is to include the metering visualization in the background image of the plugin. This means that there need to exist a lot of background images, all with a different level displayed on them. In the worst case your computer would load the full background image for every audio sample and this would lead to worse performance while the plugin window is open.
I hope that nobody implements metering like this nowadays but for most plugins I don’t know how to look inside and see if this is the reason for the bad performance.
Since I work as a product manager and not as a developer, my knowledge about any details of this problem is limited. Maybe there are developers here who can provide more details on plugin architecture and how we as users can avoid the problem of high CPU load while the plugin window is open.
I have the same problem as you with certain plugins. Most of them don’t feature obviously complicated graphical user interface elements that need to be drawn in realtime. So another reason for this problem might be level metering visualization.
Metering in plugins can be displayed by using two images. One with no level (e.g. grey), one with full level (e.g. fully filled with color). If a developer puts the colored image on top of the grey one but only shows the lower part, it looks as if audio signal is present.
Another way to display metering information is to use many different images of the metering bar and constantly load the one that corresponds to the momentary level of this one audio sample. Here we enter the world of higher demand to the computer because of the constant loading of images.
The worst way that I‘m aware of is to include the metering visualization in the background image of the plugin. This means that there need to exist a lot of background images, all with a different level displayed on them. In the worst case your computer would load the full background image for every audio sample and this would lead to worse performance while the plugin window is open.
I hope that nobody implements metering like this nowadays but for most plugins I don’t know how to look inside and see if this is the reason for the bad performance.
Since I work as a product manager and not as a developer, my knowledge about any details of this problem is limited. Maybe there are developers here who can provide more details on plugin architecture and how we as users can avoid the problem of high CPU load while the plugin window is open.