if you want sample accurate kickcdrums in SC, there are two options:
-
schedule them in SC
-
send timestamped OSC from lua. (with latency.)
as you are surely aware from using PD extensively, sample accurate timing is simply not necessary for many musical applications. even 1ms is often fine. the norns event loop is far more accurate than the message loop in PD/max, and probably at least as accurate as the sample clock.
you’re right, callbacks in the user script can block the event loop. i don’t see a simple solution to this given that lua is single-threaded. i have some specific suggestions about how to improve the event queue, but they are not simple (e.g. there shouldn’t be any locks or memory allocations:) https://github.com/monome/norns/issues/144. i would certainly welcome more specific suggestions or any contributions towards implementing improvements.
but from what i’ve seen so far, implementing things like multi-threaded lua, and/or a lockfree and allocation-free event queue, are perfect examples of premature optimization: complex and error-prone engineering tasks that set out to solve a problem that is currently totally hypothetical. so the real first step would be showing me some quantified results of system usage where stalls in the event queue have perceivable timing effects in a real application.
user scripts simply shouldn’t do heavy processing on callbacks in “realtime.” if common sense is applied, then e.g. firing events in lua from midi clock, through the event loop, is totally fine - execution time for each callback should be under a microsecond or something. (the UDP layer is a far more serious source of timing indeterminacy than the event loop, which is why we should consider timestamping everything, or having a runtime option for “timestamped” versus “immediate” on a given engine command - this has been discussed on GH and you can see some stuff in the code too. it is the old “jitter v latency” tradeoff for which there is no actual right answer.)
i think what @artfwo means is that it doesn’t seem reasonable to try to build a system out of executing lua code (with a shared, singlethreaded VM) in response to events on the audio clock. as you have also pointed out.
rant
i think you are casting this as a simple question when it isn’t. musical time in computers doesn’t have a single standard of perfection. its not sample accuracy - you can’t “really” play 127bpm music at a sample rate of 48khz. we did not set about to make a perfect system from whole cloth. we made a scripting layer on supercollider that has some UI glue.
it is also convenient for many applications to use the scripting layer for timing and sequencing logic, and i can make strong claims that it’s also entirely functional and pragmatic. we added a timing and events system that is definitely not perfect but has the enormous benefit of being easy to understand.
going deeper for specialized purposes (like subsample timing on an audio output - which SC supports) should be handled on the SC or ugen development level.
none of this means we should not have simple mechanisms for selecting “control-rate” clock sources in norns scripts.
TL / DR:
if “tight” means “computed on the audio thread using the sample clock” - obviously not. you want to do everything with UGens in that case. compose an engine that will suit your needs and accept appropriate commands. maybe wrap SuperDirt if it meets your criteria.
[mod: moved to development]
