francois.
ZynewaveThe Podium demo has been updated to this version and can be accessed on the download page. You may have to refresh the page in your browser to see the latest download link.
acousmodHi Frits,
I have made some tests with the new version and :
Fix: The graphics update in some VST plugin editors could slow down or stop at high CPU load. This fix should also improve overall speed of the plugin graphics update response to parameter automation.
For me it is the contrary : my plugs automations are now jerky and eat a lot of CPU !!!
I’ve reinstall the 1.19 and movements are smooth…
Do you undertand what does it means ?
Thanks
ZynewaveHi Jean-Marc,
I have just tested version 1.19 against 1.20. I used the Surround.pod demo project which is using two of your plugins, and added a couple of parameter automation tracks for the two plugins. What I found was that when automating VST parameters, SynthEdit plugs are very sensitive to the rate at which they receive idle notifications from the host.
The problem with 1.19 and older versions was that Podium notified plugins with idle messages at the same rate that the Podium UI entered idle state. That meant that if the CPU load was low or playback was stopped, the idle messages would be very frequent. But once playback was started and the CPU load was high, then Podium never entered idle state because the remaining CPU time was used to update the animated playback graphics. In this case plugins never received idle messages, which for many plugins (including your plugins) meant that they did not update their UI. I even managed to crash the SpatPod plugin by doing some parameter automation during high CPU load. If I were to make a wild guess on what is causing this crash, then it appears that SynthEdit buffers up parameter automation events and does some processing for these in the idle calls. If an idle call is not received at a regular rate, then a buffer overrun probably occurs inside the SynthEdit code.
In 1.20 the idle messages to the plugins are controlled by a timer. Thus the plugins should receive a more steady rate of idle messages independent of the CPU load. I have set the timer to fire with 200 ms intervals (5 times per second), which I agree is too slow to make parameter automation appear smoothly in the plugin editors. I have now reduced this to 50 ms (20 times per second) which gives a more steady CPU reading and smoother graphics.
Fix will be available in 1.21. Thanks for pointing out this problem.
stefancrsSince updating of guis actually has quite an impact on cpu load, could there be some kind of advanced config to set these things up? You set the default, advanced users can tweak it on their own.
Is it a good idea? On slow computers a 50hz gui updater might be really unconvinient but on a fast computer a gui update synced to monitor refresh rate might be swell. Or something.
Nothing necessary, might just be useful for a few I guess!
cheers!
acousmodI have now reduced this to 50 ms (20 times per second) which gives a more steady CPU reading and smoother graphics.
Seems to be good…
Since updating of guis actually has quite an impact on cpu load, could there be some kind of advanced config to set these things up? You set the default, advanced users can tweak it on their own.
… and perhaps the idea of stefancrs will be efficient ?
ZynewaveSince updating of guis actually has quite an impact on cpu load, could there be some kind of advanced config to set these things up?
I don’t think that will be necessary. The increased plugin UI update rate will consume more CPU time, but it is taken out of the CPU time remaining after the audio processing. The audio thread is running at high priority so it will always be first in queue for CPU time. If anything suffers from the higher plugin update rate, it is the Podium UI, but I doubt it will be a problem.
If the audio processing is taking a massive amount of the CPU, the idle processing calls will occur less frequently. Note that the Podium CPU will indicate 100% or overload at something like 95% of the ‘real’ available CPU time and then start gradually to skip plugin processing etc. to drop down below overload indication. If Podium were to allow the audio thread to use close to 100% of the real CPU time, there is a risk that the PC will freeze completely because the UI thread will never get a sufficient slice of the CPU time. This is what you could experience with at least older versions of Cubase.
super_crunchy@Zynewave wrote:
If the audio processing is taking a massive amount of the CPU, the idle processing calls will occur less frequently. Note that the Podium CPU will indicate 100% or overload at something like 95% of the ‘real’ available CPU time and then start gradually to skip plugin processing etc. to drop down below overload indication. If Podium were to allow the audio thread to use close to 100% of the real CPU time, there is a risk that the PC will freeze completely because the UI thread will never get a sufficient slice of the CPU time. This is what you could experience with at least older versions of Cubase.
And that’s why it hasn’t crashed on me yet… even when I’ve been experiencing 100% CPU spikes with a new plugin I have. Smart coding there
francoisOh Yeah! this is why i abandoned my VST32…Cool Podium! š