Hello,
I saw the following two lines in many member functions in Engine like Engine::bypassModule or Engine::randomizeModule. Am I assuming correctly that these member functions are supposed to be called from app-thread and they are for syncronization with the engine thread?
This leads me to another question: When changing anything from Widget (e.g. in onHoverKey) in Module should I synchronize threads? My guess is the answer will be “it depends what you are doing”. How should I do it? Is there a module that implements it to have a look?
After thinking about it for a while I conclude that the safe path is to use an additional parameter for “sending messages” from the app-world into the dsp-world. At least for non-atomic operations.
Hi Ben! I necro-summon this thread from the graaaaaaaave to see what you concluded about this and to humbly request your help (or anyone else’s).
I have a naive implementation of programmatic cable adding (unstable API, I know!) that calls APP->scene->rack->addCable from Module. Most of the time, it works, but occasionally the lock (in the code lines you have above) is taken and never released (I think I’m putting that right) and the engine thread freezes. The vipLock constructor hits count 1 and returns; it’s the lock() call that does it.
C++ concurrency is far from my strong suit. I gather that Rack must be calling addCable from a context where the lock will always release, and that’s not true if it’s called from Module.
I’m looking at your T7 code to see how you handle this there. My intuition is that this is one of the things you’re doing with the T7Event system?
Many thanks in advance for any insights into this, and I’ll keep poking at it in the meantime!
You can’t call this method from a dsp thread, it must be from the GUI thread. I’m not sure at the moment how I implemented it in the T7 modules but I guess I used dsp::RingBuffer as a queue and the GUI thread as a kind of worker-thread for the queue.
