not trying to be flippant, but here is the code:
the crone program can be used effectively on non-norns systems. (including macOS, if you don’t mind installing JACK.) it is a Jack and OSC client. i’ll leave MSP/PD/SC ports to others.
we could have a longer discussion about this, but in a nutshell the biggest issue (IMHO) with such a system is correctly resampling when writing to the buffer. (resampling while reading is more straightforward.) this is the same problem faced by @Rodrigo, @RABID/@CrackaAttacka/@rajatheresidentalien, and pierre tremblay (dunno if he’s on lll) in the karma~ external (and by a younger, stupider version of myself in the poki~ external.)
finally in the incredible year of 2018 i’ve boiled down my own boneheaded solution to a simple c++ class: https://github.com/monome/norns/blob/dev/crone/src/softcut/Resampler.h
of course many other programs face the same issue of realtime resampling. (e.g., w/ and any number of fancy digital FX units.)
anyways, beyond that rather arbitrary (though central) technical detail, the softcut module also has these properties (good and bad):
-
each voice reads all its parameters once per audio block. this means (among other things) that position cuts have jitter on the order of ~4ms. [*] also, voices can only synchronize position once per block. we could synchronize every sample for a significant performance hit. maybe this will be a norns option in future.
-
filters input using a state variable filter. in the default configuration, this is modulated by the phasor rate, and the lowpassed output is written to the buffer. this helps typical applications where phasor rate is modulated to <1.0, and especially when phasor modulation is “through-zero” (- consider that setting rate = 0 while writing is also effectively reducing samplerate to zero and aliasing every frequency.) i used a full SVF because it’s hardly any extra computation (compared to an LPF that can be efficiently modulated at audio rate) and because it gives you the option to, like, deliberately emphasize some tuned sample-rate reduction (in the form of reducing phasor rate.) (like, this seems like a popular um “effect” these days for "edgy’’ soundtrack work. i digress of course)
-
applies some fairly transparent softclipping before buffer write. i think this is important when, as here, there are basically arbitrary signals being mixed to each voice input, possibly in a feedback configuration. (softclip algorithm is a simple quadratic with a linear breakpoint. there are more musical clipping options but will consider these later.)
also considering other options for per-voice processing (playback filter, bitcrush), but as it is i think the functionality needs to be put through its paces before we add stuff.
([*] BTW: asking someone to care about 4ms jitter is approximately like asking a drummer to play 16th notes at 3750 BPM. </controversial_opinion>)
