acousmod.
ZynewaveZynewaveConcerning the new plugin automation recording:
The approach I chose was to make it as easy as possible to record automation. Arm the record button on the track with the plugin, start recording/playback and drag away in the plugin editor. I find it convenient to be able to record automation without worrying about automation read/write mode and selection of parameters that you want to automate. This approach however has some disadvantages with certain plugins. Some synths output all parameters upon a program recall. Recall a preset in e.g. the SonicSynth2 demo, and whooosh… you have close to 100 tracks with parameter automation. To avoid this you need to stop playback or disable recording on the plugin track before loading a new program. I observed another undesired behaviour with Z3ta+, where simply hovering the mouse over a slider would automate the parameter.
If this becomes a problem, I will have to think of some way for the user to disable or prevent automation recording. Please report if you find any plugins that is causing difficulties.
duncanparsonsone thing you could do is compare each setparameterautomated value passed, and compare it to the current host value for that parameter, and only record the change. I realise that this could be hugely CPU intensive, and so could be an option for plugs that display this kind of behaviour.
?
DSP
Zynewaveone thing you could do is compare each setparameterautomated value passed, and compare it to the current host value for that parameter, and only record the change. I realise that this could be hugely CPU intensive, and so could be an option for plugs that display this kind of behaviour.
That would probably help with the Z3ta+ problem, and it would not be CPU intensive at all. It would not help with plugins that output all parameters on a program recall. Rather it would then only record curves for parameters that have changed compared to previous program, which also is undesirable. Currently Podium does not maintain its own copies of the plugin parameters, so I do not have the previous value to compare an automated value with. I’ll be looking into this when I start on the generic editor for GUIless plugins.
super_crunchy@Zynewave wrote:
- Fix: Increased rate of plugin editor idle notifications. For many plugins this provides smoother graphics and a steadier CPU usage.
Wow! This is much better now Fritz, running very smoothly here, whereas the previous version was very sluggish to respond when turning knobs etc
acousmodThis is much better now Fritz, running very smoothly here, whereas the previous version was very sluggish to respond when turning knobs etc
indeed…
but I’ve noticed that now Podium takes a fix percentage of ressources for the plugins that doesn’t depend of the activity of the plugin.
The result is that the ressources usage is more constant BUT also that it takes a lot of CPU even if there is no need for.
It is the case with Synthedit made plugins which have an automatic “idle” mode for each component…
My question : do you think that it would be possible, as it has already been suggested, that the user could switch of the refresh rate that you have introduce in 1.20 version ?
For me, the behaviour of 1.19 was better…
Thanks,
Zynewave@acousmod wrote:
It is the case with Synthedit made plugins which have an automatic “idle” mode for each component…
🙁
No doubt that SynthEdit has contributed heavily to the popularity of the VST plugin format. That being said, the SynthEdit VST implementation has been very troublesome in my work with VST support in Podium. I think I have to download SynthEdit some day and try it out, to see what on earth is going on in there. Is it not possible to do something about the extent of idle message processing in SynthEdit?
Btw. Jean-Marc, have you tried out the new SynthMaker tool: http://www.synthmaker.com ? There is a downloadable beta. I tried it and was very impressed with the UI. The example VSTi plugin seemed to work ok in Podium.
My question : do you think that it would be possible, as it has already been suggested, that the user could switch of the refresh rate that you have introduce in 1.20 version ?
For me, the behaviour of 1.19 was better…
As I wrote in the release note of 1.20, with 1.19 you could experience that the plugin UI would become completely inresponsive, when the CPU usage reached a certain percentage (depending on PC system). I also noticed this UI freeze with your plugins. With the slow idle update introduced in 1.20 I also managed to crash the SpatPod plugin at high CPU load. So to ensure usability/stability regardless of CPU usage, the new high rate of idle messages has to be used. It is unfortunate that it comes at a cost of higher CPU usage for some SynthEdit plugins, but I think stability is to be preferred.
acousmodIt is unfortunate that it comes at a cost of higher CPU usage for some SynthEdit plugins, but I think stability is to be preferred.
Yes, I agree…
Is it not possible to do something about the extent of idle message processing in SynthEdit?
I don’t know… will see with others on the forums.
Synthedit is not an ideal tool and I know that its plugins are not optimized, but it is better than nothing for me, as I am not able to write codes 🙁
have you tried out the new SynthMaker tool
Yes, I had tried the old version a time ago and this new one is very promising !
I hope that the developpment will continue this time and if the VST are more stable and faster, sure that I will try to rewrite some of them inside SynthMaker.
Thanks a lot for your support.