Use tryLock in audio threads for VST/ZynAddSubFX

[PhysSong]

Prevent loading VST or toggling ZynAddSubFX GUI from blocking entire audio processing. It still blocks audio output from specific VeSTige/ZynAddSubFX but not whole playback.
Address #1825.

[DomClark]

Won't this cause the plugin settings not to be loaded if the mutex can't be locked? I think this code runs on the main thread anyway so it shouldn't affect audio processing if it has to wait for the mutex.

[PhysSong]

You're right here, probably a mistake.

[PhysSong]

Fixed in e79aeb7.

[PhysSong]

Merge?

[falkTX]

won't this produce lag noise when the lock is on (GUI doing stuff) because we are not clearing the buffer?
the last buffer values will remain there unchanged.

[PhysSong]

PlayHandle::doProcessing clears the buffer before processing, so I believe it doesn't matter.

[falkTX]

If that is the case then all is good :)
Now I wonder if carla plugin is doing the same... I think not..

[PhysSong]

Now I wonder if carla plugin is doing the same... I think not..

I guess the mutex can be dropped with a proper workaround for race conditions(maybe Mixer::requestChangeInModel stuff?). However, the mutex is less likely to cause severe blocking than the VST/ZynAddSubFX case...

[PhysSong]

I guess this patch might break rendering. Should I restrict this fix to playback only?

[PhysSong]

I found that this is insufficient because RemotePlugin::process() calls lock(). I think #5074 (comment) might be the ultimate solution.