Any chance of adding slew_time options for the post filter cutoff/Q params? This would be really handy for a new norns app I’m working on. I’m considering trying to manually pseudo-slew it with a background metro but I doubt I’ll be able to get it to sound as good/gradual as it would if it were written into the engine itself.
@zebra - do you take outside contributions to softcut-lib? I’d be happy to take a stab at this myself, but then I imagine there would be some steps to take between that and getting it into the next norns version.
filter parameter envelopes are already in the next version (on dev branch. sorry this has taken so long to get together. it works great but needs another optimization pass for norns hardware. also have been trying to get the “ducking” feature to work better but should just leave it and move on.)
adding them is/was a trickier problem than it might appear:
there is a serious performance issue. filter coefficients are relatively costly to recalculate, and can’t feasibly be update per-sample on the norns. so (1) the envelopes for them are effectively downsampled, (2) i’ve rewritten parts of the filter to memoize certain calcuations and use LUTs for others.
the new envelopes allow other shapes besides logarithmic slew. among other things, this alows filter cutoff sweeps to be perceptually linear in both directions
My nmQuadroDubber script is constantly playing back looping buffer regions, yet also sometimes recording external audio to those regions. So the playhead and recordhead are synced. When overdubbing then, it seems as if I sometimes hear fragments of what’s being recorded, which I assume is due to some jitter between the playhead and recordhead. I.e. sometimes the playhead might slip a tiny tiny bit behind the recordhead and I hear what’s being recorded.
Would that be an accurate assessment? And if so (or if not), what would be a good way to turn this into a feature, so that, while recording, I always hear what’s being recorded.
I’ve tried to set softcut.rec_offset to 0.0001, so it records slightly before the playhead. This works, but when the buffer region loops, it produces a slight click, as the playhead is probably playing outside the region for 0.0001 seconds.
no, there is no jitter between the play head and record head. off top of my head i’m not sure what you are experiencing.
if you are modulating record offset, weird things can happen. by default it’s chosen to be just large enough for the interpolation windows of play head and record head to not overlap. (a small negative number.)
probably not the answer you’re looking for, but: as it stands, this seems a bit out of scope for the softcut module. what does it give you that you can’t get with the monitor or engine levels?
(the answer i can think of is that you want to route input directly through the (post-)filter stages of each softcut voice while bypassing the buffer. seems a bit niche and would require some pretty significant alterations.)
btw, there is a new version of softcut in the works. i’m afraid my progress on it has been exceedingly slow since the pandemic but it will get merged eventually. i mention it mostly because any bugs related to sub-head positioning are likely to be addressed there already (it’s a substantial rewrite) but also because i’d wait for that to make any big routing changs (new architecture makes that a little cleaner anyway.)
i’m still thinking about your issue but i don’t think i can reproduce it.
Thank you very much for the thorough reply! I’m using the monitoring feature already to blend the external audio with softcut’s audio, but my record heads (voices) are panned, so it would be cool if the currently recording audio would also be panned accordingly, while the monitoring sits in the middle. Not sure if I explained that well enough But you’re right, it’s very niche and not important at all for my script.
I was just wondering why I hear fragments of the external audio through still when overdubbing. Maybe it’s to do with my DIY Shield and the powerbank and cable, plus wifi, etc. which is already quite noisy when Norns is idle. I’ll investigate this with different power and settings.
Thanks again for the help! Softcut is so well put together for a newcomer like me. No hard coding challenges, so I can focus on creative ideas with sampling
I’ve been using the rec ahead approach as part of a real time chorus/tapey thing (w/monitor = chorus; wet only = tapey). It works, but difficult to maintain a short enough gap over time so the timing impact is imperceptible while also getting the desired effect and avoiding run-play overruns. This is making me think to revisit it.
Hi everyone, I’m working on a little sample slicer and was building off some work done in sam, which is based on softcut. There was this comment by @zebra:
I think that buffer_write_mono has been updated since then, and no longer takes start and end, but start and duration. I was wondering if the same approach of adding the fade time and some ms works. I am still getting some pronounced clicks at the end of each slice after adding some time to the duration of the sample. Logically, that makes complete sense as it is just now extending the duration of the loop that is written to the file.
I’ve been through the docs and can’t really find a solution to this. Is there a way to write the buffer to the file with the fade-outs?
The API did not change, has always taken duration as second arg.
My notation quoted describes a time interval, not Lua code.
No, sorry, there’s no facility to apply fades in an exported file. (But crossfades are applied to record heads, so if softcut records something the fade will be in the buffer if it’s set up that way )
Id recommend using sox for arbitrary post processing. Can’t remember if it’s included in the base norns image.
Ah! Thanks so much for clarifying — that’s what I get for not understanding notations haha!
That actually makes tons of sense (at least to me) given softcut’s purpose!
Thanks also for the pointer to sox! I’ll have a look to see if it can do what I need it to do and how to get it to work on norns.
Really appreciative that you took the time to answer in what must be a hectic time for you (and congratulations are in order as well, I gather from another post!)
Yep! Sorry for not reporting back! Got it working quite a while ago and incorporated it into my script! It was exactly what I needed. Thanks for that and for checking back in
I was just thinking of modifying mlr to have more tracks, I think I have it working in the (mlr) interface but softcut is only still working on 6 tracks. Maybe it would be better to test on a fork of softcut?
we tuned the voice count to the cpu capabilities of the norns. if you were to attempt a fork you’d need to put some limitations on additional voices if added (ie, disable recording on most of them).
like brian says above, the voice count is deliberately limited to what a single core is capable of processing when all voices are simultaneously reading and writing at a high rate.
if you want to try changing this, bearing the limitations in mind:
on the audio side it is determined by a single enum value:
and it should probably match this voice count value in the lua API:
and unless i’m forgetting something, that should be it.
anyways: you don’t have to fork the softcut library, it doesn’t impose a voice count. these changes are just in crone (the norns audio program that uses softcut-lib) and the lua layer, both part of the norns repo.
i don’t think we would be totally opposed to increasing this basic voice count (to 8 or something.) but it would have to come with a big caveat because it would put the onus on script authors to limit what they are doing.
rec and play commands. these are hard flags which enable/disable write and read heads respectively. (use e.g. rec_level instead for realtime modulation.) writes cost much more than reads (something like 2x, 3x.)
being aware of rate limits for heads that are record-enabled. (if rate=4, then the write head must upsample by a 4x factor when storing to the buffer.)
But you’re right, it’s very niche and not important at all for my script.
and for checking back in