Hi Dave and all,
It's working muuch better: chuck --loop and adding/removing rapidly with a heavily loaded system (doomed to horrible death before), not an xrun to be found.
That's great to hear! Thank you for checking this out, and of course for suggesting to implement the callback functionality in the first place.
There is still that mutex being locked in RtApiJack::callbackEvent which will cause problems (mostly with many jack clients running) Is it even necessary? I can't see any immediately obvious reason why it needs to be there, but admittedly I havn't looked very thoroughly.
I believe it is necessary currently, though we will look into it more with Gary's help to figure out the conditions under which it may be blocking.
Pedanticness aside - nice work. I can't seem to actually find your callback anywhere though - it looks like you're passing a NULL callback (via the default param value) to all the initialisation functions to me (it's a bit twisty to navigate). Where's the actual chuck DSP callback live?
under callback mode: in Digitalio::cb2( ... ) in digiio_rtaudio.cpp: vm_ref->run( buffer_size ); this calls an overload Chuck_VM::run( t_CKINT ) in chuck_vm.cpp that takes the number of samples to be computed. The samples are computed here: m_shreduler->advance(); Thanks again! Best, Ge!