Right now, a single callback for getting shuffle-enabled 16th steps is handled via onStepCallback. This is well and good. However, when using uClock in a multi-track system, you may want to disengage a track from being shuffled so that it's played on the straight beat instead.

Also, for doing microtiming adjustments on 16th steps for each individual track, one option could be to just not use the onStepCallback and instead process everything in the 96ppqn callback function, and track the 16th steps inside there. But I think this would be more intense on the CPU having to do more work inside the 96ppqn callback, which also might make the clock a bit less tight.

So, what if instead we could generate/register multiple 16th step handlers, for any number of tracks? And each handler could have its own shuffle settings. This way, you could have the main clock processing freed up from having to do all of this extra stuff, and you could have separate track-style instances of 16th step handlers, each with their own shuffle settings to allow for microtiming adjustments.

Seems like if you also want to enable live pattern recording (tapping in steps live while a pattern is playing) then that would best be handled in the 96ppqn callback so you could determine where the nearest step is (plus/minus any microtiming adjustment) with
some quantization algorithm.

Let me know if this makes sense.