Open grayxr opened 2 months ago
Hey @grayxr ,
Yes it makes total sense, i will review your PR and get back asap. Thanks for the development work on your side!
Are you running this multi shuffle schema on your sequencer? any videos for me to take a look?
Hey @midilab - yes here is a demo video (sorry for the rotated video)
By applying the step microtiming on steps, the hi-hat track gets its own shuffle template. I made it also so that it merges in any shuffle from the pattern shuffle template as well, but only to steps which are not overridden with their own microtiming offsets.
This looks nice, 1 have a 2 track classic arpeggiator that would be good to add some variation to. Are there any examples of basic shuffle operation?
Cheers, Paul
This does indeed sound very cool. I'm going to have to do some serious thinking about how to restructure my project in order to take advantage of this :D
Hey all, good to see this development going on! I'll try to test the Add track-based callback with shuffle per track PR over the next weekend.
I was just working on adding grooves to my clocking device. I have a switch that toggles between quarter notes (4, 8 ,16) and triplet (3, 6, 12) speeds. Adding shuffle with the onStepCallback works fine for the quarter note speeds, but is harder to work with when manipulating triplets.
It would be great to have a version of the onStepCallback based on 24 steps instead of 16. This way we can easily manipulate triplets. What do you think?
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.