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.
4 Likes
Thanks! Yes, this looks manageable 
1 Like
almost done!
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
softcut!!! @zebra
34 Likes
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
3 Likes
final section completed. any feedback would be appreciated!
2 Likes
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?
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 ?
softcut.buffer_read_mono(file,0,1,-1,1,1)
. . . 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 56 from softcut.rec_level(1,rec) to softcut.rec(1,rec). Then, with pre at 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.
but using 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 pre at 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 
yep
unless iāve lost my mind, rec_level and pre_level function independently in just this way
each frame:
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.)
1 Like