Ah! Exactly what I was thinking. Not sure if its super exciting, but maybe a good exercise for myself to get a little familiar with the language etc. Cool
Been having lots of fun with the softcut studiesand exploring the various parameters tonight.
Does anyone have a link to a (very) simple example of using a button to start recording into a softcut buffer, then pressing again to mark the end/loop. Much like a ‘traditional’ looper would behave.
I’ve been poring over the cranes script, as this achieves the functionality (amongst all the extra cool stuff) - but it’s a bit too advanced for me, at my current basic-brain level of understanding anyway!
Maybe have a look at Sam? It’s super simple and the…
thing happens between lines 159 and 171.
Thanks! Yes, this looks manageable
top post edited with section 6, which uses inter-voice routing to make this lovely sounding loop disintegration:
basically a linear play head with a jumping record head which is overdubbing what’s coming off the first playhead… all with partial feedback so the process is a sort of scatter-blur that is different each iteration
Oh god. So beautiful
That example is lovely, @tehn!
Is anyone else having a hard time getting the new
routing study to work? Loaded it up last night, and while it plays the sample, nothing seems to be happen afterwards. Feeding it live audio doesn’t seem to do anything either. Must be missing something obvious…
any errors in maiden?
Nothing in maiden, actually, either at startup or when pressing keys 2/3. Didn’t have time to take a close look at the code, but will later.
I got it to work by running the other study scripts first. So it’s probably something in the init() but I couldn’t spot exacting what
oops— forgot some commits. re-pull the update
final section completed. any feedback would be appreciated!
I seem to be having issues loading a stereo file. I have stereo and mono versions of a 48k file; loading the mono file with the following:
softcut.buffer_read_mono("/home/we/dust/audio/tape_hiss_m.wav", 0, 100, -1, 1, 1)
This stereo load results in the following error:
softcut.buffer_read_stereo("/home/we/dust/audio/tape_hiss_s.wav", 0, 100, -1)
liblo error: lo_send, lo_message_add, or lo_message_add_varargs called with mismatching types and data at…/matron/src/oracle.c:622, exiting.
Works as expected loading the mono file into one or both buffers simultaneously. If I replace the mono file loads with the stereo code, I get the error. Suggestions?
Bug, will fix
Great patches, thank you.
One slightly obsessive question: why the ‘convention’ of reading the start of the sound file into position 1 (as opposed to 0) in the buffer ?
. . . and then having to keep track of that when calculating positions (eg pos-1).
. . . is there an advantage to this ?
Maybe I am missing something here !
I’m struggling to understand the behavior of
softcut.rec. I figured it would just enable/disable the
voice “tape head” abstraction from writing to the buffer or not, but would otherwise not change its behavior. However, I’m seeing that it seems to change the timing of the recording in mysterious ways.
A minimal reproduction example: take study 4, and swap line
softcut.rec(1,rec). Then, with
1.0 use K2 to “punch in” short segments. You’ll quickly see that the segments when looped are not where they originally were recorded. E.g., record pitch 1 for one second, then immediately turn recording off. When the loop comes back around, immediately when pitch 1 is complete, toggle record on and record pitch 2 for one second, then toggle recording back off. Then repeat again for pitch 3. Instead of pitch 1 and pitch 2 and pitch 3 being back to back, pitch 2 or 3 or both are now at a seemingly random time, often significantly overlapping with pitch 1. (sorry that’s probably hard to follow, but I couldn’t think of a simpler way to explain it).
Is there something I’m misunderstanding about
rec, and how it offsets the record head? I’ve even tried using
softcut.rec_offset(1, 0) (which I’d think would sync the play head and record head) but that didn’t seem to help either.
sounds like this bug:
since the development-branch rewrite, i haven’t run into this.
rec flag dynamically is not ideal anyways;
rec_level is better.
Am I reading this correctly to mean “in a yet-unreleased version of norns, we believe the problem is fixed”?
The reason I’m trying to use
rec instead of
rec_level is I still want
pre to apply (e.g., with
0.5, the loop slowly decays in volume, even when
rec is off)
EDIT: in my use case, as I’m just using the ADC inputs, I can use
level_input_cut to achieve what I was trying to do
unless i’ve lost my mind,
pre_level function independently in just this way
output = (output * prelevel) + (input + reclevel)
the only reason to toggle
rec off completely is to save CPU. it’s not even useful in the present version because you can’t have more than 6 voices regardless. thinking of making a larger number of voices available but only allowing N simultaneous writers. (writing is several times more expensive than reading.)