On Thu, 19 Mar 2009, B. Bogart wrote:
Mathieu Bouchard wrote:
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
Does this mean that rendering/audio in PD will be interrupted during this time of global locking?
Well, in the same way that when a [delay] or a [metro] outputs a bang it "interrupts" the rendering. But those events are never nested nor overlapping in real time, so a block always finishes computation before something else happens, and a message sent from [delay] always gets "fully processed" before something else happens, and so on. It wouldn't be much different from what you'd get if you turned the 2nd thread into a separate server that you'd communicate with using [netsend], really.
The only thing is that sometimes, pd runs in the 2nd thread, but that doesn't make so much of a difference, as pd is then not running in the 1st thread at the same time. The question is not which thread is in use, but how many of them at a time.
Replacing the lock by a message queue could have had some advantages, but it's more work.
Ah! I would only need to lock while before I do the PD calls right? sys_lock(); outlet_symbol(); sys_unlock(); ?
Exactly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec