a proper looper block

[jamesholdenmusic]

softcut-like flexible reading and writing rates would be really fun with the polyphonic part of this

look at ipoke?

old notes: looper: either use softcut or ape it - multiple heads on one buffer, crossfading, smooth, varispeed writes

• a voice is a head, can read or write or both
  • inputs: signal to write, position modulation
  • outputs: read signal, position
  • parameters: write mix, loop start/end, head rate, slew on mix/pos, gap between read and write?
• position: can this somehow be handled in a smart way? relating to slices in the buffer, imposing slices and a length if the buffer is empty?
• it should be able to work on a wave you've loaded in, but if there isn't one it should make a blank one of a set length? might need to update the wave remapping routines at load to take into account the idea that it might want to be mapped to an empty slot.

[jamesholdenmusic]

parameters:

• select a wave
• rate
• loop start, end, enable
• record: doesn't have a mode switch, it's always recording. rec level sliders controls it whether anything gets written / retained in the buffer
• • record / preserve level sliders
• crossfade time

[jamesholdenmusic]

midi trigger input should start playing from the nth slice i think undo isn't possible in this architecture (it's one loop in the buffer, not many iterations of the loop across it)

the patch should handle making a new wave if you select a blank one (it should wait a second or something? to avoid creating loads if you move the slider?) or just scan that param infrequently..

• slicing: is more complicated, should be written in parallel
• • could maintain a list of slice points (overwriting when you loop over a section) - maybe an option param for how often? (eg 8ths, beats, etc)
• • can also maintain a list of detected pitches? intensity levels? there were externals with a few metrics like these in i remember. this overlaps with finishing the waves section etc

a midi looper is a separate but very similar project - it needs to store a timed list of events, but store a note's vel at its off so you can play it backwards too.

[jamesholdenmusic]

needs to be able to reliably link voices with an offset (eg one is playing 2 beats behind the record one, etc)

• i think just being able to follow a 'target' input should do it? is offset a slider? this would be a way to enable quantised offsets

[jamesholdenmusic]

there are two challenging parts to the playback/record engine - variable speed and xfades record and play both do both of these, as the heads are together.

a xfade happens when you jump (inc looping) during a xfade there are two play heads, two record heads. rather than calculating position of the second one using speed etc it'd be simpler to take a snapshot of the offset between them at the moment of jumping and then use that to calculate the 2nd head's position.

ok xfades not too hard then.

varispeed: if speed <1 then you end up writing lots of samples into one buffer sample. i think you do an average? that way if preserved level is up you end up replacing it with the same amount? AH only write the buffer once the head has moved forward, otherwise just keep accumulating (otherwise the 2nd sample you write into a buffer sample then reads back a bit of the 1st sample as it's 'preserved' value) if speed >1 then each sample you receive is going to write multiple samples in the buffer. the start and end may not align with buffer-sample boundaries, so those ones are kind of like the <1 case. if speed ==1 then you don't know you're aligned with buffer-sample boundaries anyway so you kind of do it like the <1 case

[jamesholdenmusic]

normal varispeed playback - you'd interpolate, taking a single reading per output sample i think there's no benefit to reading all the samples? (and lowpassing, resampling downwards) as what's there is likely upsampled anyway

writing, if speed <1 then that's downsampling the input, and an optional AA filter here would help. the nyquist is nyq*speed? so if you're at 0.25 speed, running at 48k, nyquist would be 6khz.

recording is expensive, disable it if fader at zero.

read head is one whole sample ahead of the write head in the buffer, so the two never interfere

[jamesholdenmusic]

actually that doesn't work if you change direction. so they have to be the same sample. it's only written when the head moves off that sample so..

[jamesholdenmusic]

have a proof of concept working and pushed. in2 - rate mod or position mod (ie you set rate to 0)

need to fix waves page drawing need a way for this block to clear the draw-wave accrued peaks? or flag some of it for redrawing at least?

[jamesholdenmusic]

upsampling covers a multitude of sins lol, i'll enable it at the end (it's easier to tune it with upsampling off)

[jamesholdenmusic]

ui: a buffer viewer, playhead indicator buttons for common rates, a reverse button?

[jamesholdenmusic]

working - with linear interp on buffer fill and on read. to do: jumping (midi triggers), xfades, implement loop as a xfade jump instead, metadata writing, waves page fixes, ui

add a parameter to enable aa filter add a parameter to follow global tempo variations (like my old looper used to)

this does such a good BBD i'm tempted to wrap it up as an m4l device

• you could make it more BBD-y by adding a little cut between buckets, which would introduce 'clock noise bleed'..

[jamesholdenmusic]

xfades: ideally you want to do all the work at the moment a jump is triggered so - the main playhead jumps, volume starts at 0 and ramps up the secondary one has its offset set so that it goes where the main one would've. volume starts at 1 and ramps down. so there are two variables - fade_offset and fade_level, if fade_level>0 that head gets processed. and the xfade parameter is converted into the coefficient of the linear fade - ie the gradient that gets subtracted every sample. ignore jump requests during a fade? wouldn't be impossible or expensive to queue up one to start straight after fade but..

[jamesholdenmusic]

so xfades for looping is done, it can only do it on read - if you xfaded the tail of the write it would stack up in weird ways?

[jamesholdenmusic]

xfade jumping done, there's a trigger in, a jump in (midi mapped accross the length of the sample, kind of useless). need to do slice jump (looks up in slices list) metadata writing - it could add beats to the slices list? aa filter global tempo variation following

a UI - buttons for common rates, and to set loop length to preset beat interval (at the current rate), or to set rate so that loop is a preset beat interval (at current loop length), reverse button. probably draw the buffer too? how do you handle multiple voices for all the ui stuff?

[jamesholdenmusic]

real BBDs have a lowpass working as a 'reconstruction filter' at the playback end of things. i think that's what my linear interpolation is doing too though?

read and write and all the xfading stuff done now. but i think some bugs remain with looping:

• if looplen < xfade rate 3 then they collide
• i think something about fade glitches when it's looping near the end of the buffer?
• if it escapes (eg load block with rate negative and it just wraps to the end irrespective of where loop is)
• i'm not sure the xfades happen at the right moment in reverse?

ui can have wipe button?

[jamesholdenmusic]

initialisation! it should start at the loop start point, otherwise it could take 15 minutes to get there!

[jamesholdenmusic]

it's totally possible to keep track of where writing is probably going to occur and have all the read heads duck if they're going to cross that, to remove the last source of clicks here. sounds quite long but doable. thanks tehn :(

[jamesholdenmusic]

ok there's a buffer called intervoice. there are 8 positions per voice. if a voice is writing, it should write where it will be writing (+ a crossfade length) in the next vector if a voice is reading, it should check a list once per vector, the list of points in intervoice to look at is made by the max bit of the patch and stored in gen data