tehn
commented
5 years ago thank you for the excellent assessment (with rad graphix)
i think option #3 is very sensible. particularly with the conditional muting of rows in the matrix mixer with play_enable.
agreed re: softclip. seems very easy to digitally overload inputs with all of the potential mix inputs... and it'd be nice to have that sound nice
re: sync for stereo vs. mono. curious what you propose for syntax. some sort of fixed channel arrangement? ie sync 1-2, 3-4, etc.
re: play head ducking. this is a very attractive feature. i understand the cpu ramifications of multiple rec heads on.
aside #1: would it makes sense to simply limit the number of rec heads that can be enabled at once? ie, others would have to be disabled before additional could be enabled. there's something annoying about this, of course.
aside #2: it occurred to me that perhaps 8x rate is overkill and adds a more substantial worse-case CPU to all scenarios? there are workarounds if extreme-pitch-shifting is desired ie rec at 0.25x then play at 4x or course.
it seems difficult/impossible to design maximal flexibility without introducing constraints such as above or trusting the user script (and educating about over-cpu cases.) theoretically matron could monitor specifically crone's cpu usage as a guide?
you instinct to remove post-resample LPF and add post-playback SVF seem very good.
if you were to add mix matrix muting (which seems like biggest cpu savings?) how many voices would you propose having?
thank you again for the awesome work on this.
ranch-verdin
catfact
discussion so far has produced this task list. kinda putting in order of complexity (low->high).
(checking these as they are added to open PRs. doesn't mean they are fully tested.)
(current tracking PR: #705)
this issue is for discussion of proposed feature additions / structural changes to the
softcuteffect client, in particular regarding their performance impact.first, a high-level overview of the dsp graph for a single softcut voice looks something like this:
profiling
i used
profto sample the entirecroneprocess with 4 voices. each voice was setup in a simple echo configuration and running at a high speed (rate = 8.0). this is important because it essentially means that every process between theresampleblock and the actual buffer write is running at 8x the audio sample rate.the flame chart for the crone process looks like this:
and a more detailed view of the call stack for the softcut client looks like this:
some notable results:
(all percentages are all given in terms of the total
croneprocess).simply mixing all the busses in
croneis pretty expensive: ~27% just on softcut inputs. this might seem weird, but it makes sense; there is a full NxN matrix with audio-rate level smoothing between all softcut I/O points. the inner loop is fairly well optimized; further optimizations would involve keeping a lot more state (buffers of amplitude level envelopes.) we could also totally disable processing of mix points that are zeroed, but this doesn't help the worst case.the SVF is quite cheap: ~2%. there would be no problem at all adding a second SVF stage to each voice output. (why an audio-rate LPF needed at the input is a longish story; basically it has to be there and has to have the ability to modulate according to the write-phasor rate; otherwise you are essentially downsampling recorded material to SR=0 when sweeping the phasor speed through zero.)
the "brickwall" lowpass, on the other hand, is quite expensive: ~12%! it is not a particularly expensive algo (basic fixed 5th-order butterworth at half-nyquist or so); this high usage is because it is applied after effectively upsampling the input.
the soft clipper is also fairly heavy: ~8%. this is actually a fairly lightweight process: something like ~10 intructions / sample; but again it is effectively running with 8x oversampling.
so, i would eliminate the fixed lowpass. it's intention is to help with possible resampling artifacts; but, the resampler is using a hermite interpolator and is pretty clean; i don't think the additional stage makes much difference.
i would like to keep the soft clipper; i think it is important to gracefully limit signal level right before it hits the buffer, and exposing its gain/knee parameters could make for interesting musical effects.
input resampling before write: ~18%, making this the single largest computation - as expected. (the total load for the "poke" function is ~40%, but this includes the LPF and sofclip described above.)
"peek" function: ~4.5%. the actual hermite interpolation has a tiny footprint of ~0.5%; the rest is lookup and indexing. (could probably be improved a bit.)
crossfade mixing: ~2.5%.
playback versus record
as shown, computing the record head is massively more expensive than computing the play head - at least in this "worst case" scenario where the phasor speed is high. (cost for recording varies ~linearly with speed; cost for playback is ~fixed.) in this test (including the stupid LPF) the difference is a factor of 10x
so, there are a few related proposals for leveraging this fact to increase total voice count: 1) make some voices that cannot be used for recording 2) totally decouple record heads from play heads, with some mechanisms for locking them in sync 3) just have lots of voices, with the understanding that not all can be enabled for recording simultaneously. any voice can have record and/or playback disabled at any time. (there is already a record flag; adding a play flag would be simple.)
its important to keep in mind the cost of more points in the softcut matrix mixer, which is not inconsiderable.
solution (1) is probably the simplest. if there are N play+record voices, and M playback-only voices, then the matrix mixer can be reconstructed for N inputs and M+N outputs.
solution (2) is attractive, but involves a bigger refactor and the sync mechanism isn't totally clear in my mind. (but see below.)
for solution (3) we would also want to make the matrix mixer able to disable given rows/columns when corresponding record/play function is toggled. but that shouldn't be too big a deal.
stereo versus mono
a common request is for applications like
mlrto operate on stereo files/signals. the way i would implement this is to have a subclass of softcut head that performs all read/write/mix as usual, but doesn't compute any of it's own position; instead it is always sync'd to another head and just points at a different buffer (or position in buffer, potentially) and uses a different I/O bus.the relevant takeway w/r/t performance for this kind of feature, is that the positional logic is actually a pretty insignificant part of the computation cost.
solution (2) above would dovetail nicely with this feature since i think it could use a similar or identical sync mechanism.
in fact now that i think of it, solution (3) plus the sync feature would maybe cover all the use cases: any combination of mono/stereo voices, and any combination of record/play heads, within CPU constraints.
play head ducking
i'd like to add a feature whereby each play head "ducks" its level whenever its position approaches that of any record head. this works to eliminate a class of glitches (well, replacing them with smooth dropouts, but other approaches quickly become very complex.) however, the cost of computing this increases exponentially with the count of (active?) record heads. i'll need to try an implementation here to get a baseline performance hit, but it's something to bear in mind.
ok, phew.. please feel free to leave feedback here. in the meantime i will probably disable the post-resampling LPF and add a post-playback SVF, for a net savings of 16% or so on CPU load.