i can fix the inconstistency of the klang- and noise- type algos upstream. (mapping the mod range, and mixdown before the application of pan.) but these are not crashing the main process.
(as an aside, the ‘klang’ algos also produce more noticeable artifacts when attack time = 0. this is because they do not engage a lowpass filter after the amplitude envelope, like most others do; instead the spectral range is limited explicitly in the additive synthesis spec.)
as far as your script performance, it is hard to ask us to review 4k lines in one file with few comments. (wheras the engine code i provided is only a couple hundred LOC and i made it as clear as i could, so i hope it can be understood well enough to allow you to modify it yourself.)
re: memory leaks: in general, memory leaks are not likely from the lua layer, which is garbage-collected. however, excessive allocation means the GC can’t keep up and this is the biggest cause of performance hits in lua; in extreme cases it can crash with an allocation failure.
at a glance i can see quite a few ways your script could be refactored to do less work on the main clock tick, but i don’t think this is a show stopping issue based on the core usage reported by top. (instead, i am seeing high usage not just in the DSP on scsynth process, but in sclang process which is marshalling the large amount of OSC traffic generated by the script. [we are also being rather rude by asking it to dynamically recompile a synth graph specification on every note; this would be an obvious place for optimizing the engine but would also limit / complexify the kinds of decisions that can be made at note creation time.] when usage for these processes creeps above 50-60%, one is likely to encounter audible artfiacts and possibly strange behavior like dropped events.)
specifically, i’d strongly recommend putting all screen drawing calls in one function and making sure this is called at a sustainable pace and ultimately all from the redraw function, which is specially managed by the system.
memory leaks in the C layer are of course a possibility. i regularly stress-test the system with valgrind/massif and timing-heavy scripts, and the C layer is not really that complicated, but the platform can do many things so it is always possible.
i should say that the most common cause of “mysterious” crashes i have seen, is running out of battery with the screen dimmed. in performance contexts we always recommend booting norns without the wifi peripheral: saving power, reducing CPU load and reducing noise. (i have found that heavy scripts, especially with lots of screen activity [or driving hungry peripherals] can induce some constant drain on the battery even when connected to wall power.)
in the situation shown by @sademik, the supercollider processes are still running and are not the problem. either the UI is in an unresponsive state for whatever reason (the structure of the drawing calls is a likely culprit), or the matron process has crashed.
if holding down K1+K2+K3 for >10s induces a soft-reset, then matron is not crashed and the problem is that the UI is just stuck. if the combo doesn’t work then it is likely a crash.
