My plug-in recalculates coefficients of a FIR filter every time when the user moves any control. The recalculation takes more than 10 mS – quite enough to interrupt the sound if the calculation is done inside the signal processing thread.
I want to use VSTGUI and I don’t need any accurate synchronization with audio. Is it possible to remove the IparamValue Queue from the signal processing thread? What
is the recommended method to do it?
I’ve already added my algorithms to AgainSimple and everything works. However, I hear a crackle sound every time when I move a slider. The reason lies in the fact that the calculation of new FIR-filter coefficients overloads the signal processing thread.
The resource of the signal processing thread is limited and we should not abuse it. Musicians use long chains of plug-ins and we must leave enough resources for other plug-ins. I believe that processing of the GUI events in the signal processing thread should be abandoned with rare exceptions. Is there an example of a VST3 plug-in which is able to process the GUI events outside the signal processing thread?
You can either split the calculations over several blocks, if that’s possible,
or compute the FIR coefficients in a separate thread then swap the new with the old ones when ready.
Splitting the calculations over several blocks is theoretically possible, but using the signal processing thread for such calculations looks like an unacceptable waste of a very limited resource. More than that, I believe that the presence of the command queue in the signal processing thread is also not acceptable with the exception of rare cases when sample-accurate actions are really necessary. We must reduce the number of CPU cycles in the signal processing thread to its theoretical minimum because we must respect musicians who may want to use our plug-in in a single chain with other CPU-hungry plug-ins.
If the signal processing thread is the wrong place for the command queue, the queue should be implemented somewhere in the GUI thread. Right? If so, we don’t need making a third thread to calculate the necessary coefficients because we have more than enough CPU time in the GUI thread.
I understand that the AGain example is a very simple one which is not intended to be used as an example for standard plug-ins. My use case is a pretty common one, but I cannot find a ready example in the SDK. Did I overlook something?
Hi Konstantin,
it is not always easy to decide if sample accurate parameter changes are more important than low-cpu consumption or the other way around.
To make this decision a little bit easier, there’s a way to declare a parameter as “LowLatencyMode” see ivstparameterfunctionname.h.
If you have declared such parameter it will be used in Cubase whenever the user engages the Constrain Delay Compensation mode.
When this mode is active, the sample accurate parameter changes are less important than CPU consumption.
So you have a way to make a better guess on what is needed.
In your case I would use this information and do either calculate the coefficients in one go or split the calculations over several blocks.
I hope this helps,
Arne
Hi Arne,
I use GUI controls for opening Help files, opening and saving audio samples, drawing curves by means of the mouse and performing heavy calculations. The results of the calculations should be transmitted to the DSP thread through a pointer.
Including the calculations to the DSP thread and splitting the calculations over multiple blocks either causes “crackles” or takes too much time (e.g. 5…10 seconds) to perform the calculation because I must leave some CPU time to other VST3 plug-ins in the same thread.
It looks like I am enforced to implement my own command queue in another thread. I expected that there is a ready solution. In any case thank you for your advice and your explanation.