LinuxMusicians

alex stone wrote:Michael, is it possible to add Non Session Management support to the standalone version of Dragonfly?

If somebody updates Distrho Plugin Framework such that it supports NSM, then yes. Currently I don't think I can commit to doing the required work.

Right, I didn't know you were using DISTRHO.

EDIT: I've just added a feature request for NSM support in DISTRHO github.

Alex.

Just was testing the new Dragonfly Reverb and again the older Dragonflly Hall. With both VSTs in Reaper I get extremely high DSP loads.



Just the two reverbs makes Carla CPU load going from 5 to ~4o%. I never observed such a high CPU load. On channel 4 there is DF Reverb and on Channel 5 DF Room. It doesn't seem to depend on the settings.

edit: Strange, it doesn't seem to be reproducible.

lilith wrote:Just was testing the new Dragonfly Reverb and again the older Dragonflly Hall. With both VSTs in Reaper I get extremely high DSP loads.



Just the two reverbs makes Carla CPU load going from 5 to ~4o%. I never observed such a high CPU load. On channel 4 there is DF Reverb and on Channel 5 DF Room.

That's trouble for sure. Do you get the same results if you quit Reaper and then reload it without showing the user interface for either reverb plugin? Also, please test each plugin individually to determine if only one is at fault. I would be surprised if Dragonfly Hall reverb is causing this, because many people have reported that it is light on CPU usage.

Buffer size 528? Why is that? My understanding is that it is better for buffer size to be a power of 2, like 128, 256, 512, etc., but still it doesn't seem like this should impact the CPU usage of the reverb.

Using the Linux VST version in Reaper of either plugin, I get around 5% CPU. RT CPU is around 2%.

(This is when I set my CPU governor to "performance" so it's at max operating frequency, just so I'm not getting a skewed number which might mean "40% of whatever frequency the CPU is currently operating at". It's truly that percentage of what my CPU can handle.)

Compared to Dragonfly (Hall) 1.1.4, that's several times the CPU and a couple times the RT CPU. I normally get around 0.7-0.8% CPU for Dragonfly 1.1.4. I tested doing a back to back comparison just to be sure.

I also notice the frequency graph takes longer to draw, and the CPU spikes more/longer when it draws. With 1.1.4 the graph drew within a second. With the latest versions of both Dragonfly it takes 2-3 seconds and I can hear my CPU fan speed up.

JamesPeters wrote:Using the Linux VST version in Reaper of either plugin, I get around 5% CPU. RT CPU is around 2%.

(This is when I set my CPU governor to "performance" so it's at max operating frequency, just so I'm not getting a skewed number which might mean "40% of whatever frequency the CPU is currently operating at". It's truly that percentage of what my CPU can handle.)

Compared to Dragonfly (Hall) 1.1.4, that's several times the CPU and a couple times the RT CPU. I normally get around 0.7-0.8% CPU for Dragonfly 1.1.4. I tested doing a back to back comparison just to be sure.

I also notice the frequency graph takes longer to draw, and the CPU spikes more/longer when it draws. With 1.1.4 the graph drew within a second. With the latest versions of both Dragonfly it takes 2-3 seconds and I can hear my CPU fan speed up.

Does it mean you see the same high DSP load with the latest version?

When I saw the high CPU usage I was specifically referring to the latest versions of both plugins. (I assumed you were, too.)

Version 1.1.4 is the previous version of Dragonfly (Hall) prior to the disambiguation of Dragonfly by adding "Hall" to its name (and the addition of the Dragonfly Room plugin).

JamesPeters wrote:When I saw the high CPU usage I was specifically referring to the latest versions of both plugins. (I assumed you were, too.)

Version 1.1.4 is the previous version of Dragonfly (Hall) prior to the disambiguation of Dragonfly by adding "Hall" to its name (and the addition of the Dragonfly Room plugin).

Yup, I just downloaded the latest version from https://github.com/michaelwillis/dragon ... 1.9.0-beta

@Michael: Maybe it's possible to change the colors of the two plugins to better distinguish them. I like purple for instance

JamesPeters wrote:Using the Linux VST version in Reaper of either plugin, I get around 5% CPU. RT CPU is around 2%.

Compared to Dragonfly (Hall) 1.1.4, that's several times the CPU and a couple times the RT CPU. I normally get around 0.7-0.8% CPU for Dragonfly 1.1.4. I tested doing a back to back comparison just to be sure.

That's really weird, since Dragonfly Hall is mostly unchanged. I did update to the latest version of DPF, but I don't want to blame that unless I have proof that it is the problem. I'll try building 1.9.x against the older version of the framework.

I compiled it from git today. Works ok. Spectrum display is indeed slower (but nut unusable slow) and seems to affect the speed of another instance of the old version (if that's possible).

Qtractor project with 2 VST instances of the old version: 60% CPU in the chorus
Qtractor project with 2 LV2 instances of the new Hall version: 69% CPU in the chorus

So CPU hungriness increased a bit.

The new version suffers from the "sometimes the spectrum display is plain white" bug as well.

Michael Willis wrote:

lilith wrote:Just was testing the new Dragonfly Reverb and again the older Dragonflly Hall. With both VSTs in Reaper I get extremely high DSP loads.



Just the two reverbs makes Carla CPU load going from 5 to ~4o%. I never observed such a high CPU load. On channel 4 there is DF Reverb and on Channel 5 DF Room.

That's trouble for sure. Do you get the same results if you quit Reaper and then reload it without showing the user interface for either reverb plugin? Also, please test each plugin individually to determine if only one is at fault. I would be surprised if Dragonfly Hall reverb is causing this, because many people have reported that it is light on CPU usage.

Buffer size 528? Why is that? My understanding is that it is better for buffer size to be a power of 2, like 128, 256, 512, etc., but still it doesn't seem like this should impact the CPU usage of the reverb.

Ups.. I missed your post. Will look into it.

I tried it in Renoise:

with Dragonfly Reverb the DSP load oscillates between 11% (normal) and 20% and with Dragonfly Room between 11% (normal) and 30%.
But only if the GUI is open. With GUI close it's at ~11% constant.

If signal is routed to the plugin the DSP is high independent of the GUI state (i.e open or close).

Just in case you're wondering, Michael, the tests I did in Reaper (Linux and Windows): the CPU measurements were done with signal and without (the readings were approximately the same, a tiny bit higher with signal going through them).

Beta release 1.9.1 is now available.

I switched back to the prior version of DPF to see if it might be the cause of the increased CPU usage. My preliminary testing seems to indicate that the switch improved CPU usage while the GUI is active, but makes no difference when the GUI is inactive. Please note that some hosts only hide the GUI rather than killing it when you close the window rather than killing it; I had to restart the host session to make sure I was testing without the GUI.

I also adjusted the minimums and/or maximums of some of the parameters, and adjusted all of the room presets to have a much smaller sound, based on feedback I got that the reverb was still too big even with the decay time bottomed out. For more specifics, look at the changes here. Even if you don't write code, it should be clear, you just need to understand that the red marks are deletions and the green marks are additions.

CPU usage in the Linux VST (in Reaper) is improved compared to the previous 1.9.0 beta, but still around 2.5x what it was for (hall) version 1.1.4. I sent a PM with more details.