Looper & Buffer Size Issue
Hello! Lately I used a stacking looper patch (from Andrew Robinson's video) to add an extension to it. Techically I want the loop's buffer size to be calculated via note values and tempo and I've pretty much created an algorithm that works pretty well. The only problem remaining is that the buffer size will reset every time the counter sends an output, therefore the recording that follows after the latest output will be the only thing saved as the buffer's content. Is there a way to send the counter's final message result after the recording? Or should I use a different object than counter? My thoughts so far would be that I need to stop the counter from sending a message while the recording is on, and then when the recording goes off then the counter's final message will then be sent and calculated for the final buffer size. It'd be very helpful to open the patch since everything is pretty complicated! Thank you!
remove that clocker in first place.
if you use counter to calculate multiplication of the length - that note value,
then you have length update every counter output.
record off should execute quantised to beat / counter output.
then use message like
duplicate loop, crop $1.
by the way why crop at all or change buffers ?
all that can be done using single buffer ...
unless you want to listen to previous loop while recording new one.
Thanks, although I experimented with it a bit on my patch and it doesn't seem two work. Two problems that I inspected are 1. the gswitch object goes back to toggle value of 1 even though i set it to 0, and 2. no data comes out of t 0 b object. I understand the mechanism on your patch i just can't figure out why it doesn't work on mine. Also why should i remove clocker? Is it because metro does the job for it? Then maybe this means I should connect it a bit differently, but that's ok.
Also i use crop message because for example if i record for 4 whole notes then buffer length will be 8 seconds. If i stop recording at let's say 7.2 seconds then the remaining 0.8 will be cropped out. This creates a perfect loop. And lastly, yes, i want to listen to multiple loops while recording a new one, therefore i need the duplicate message.
as I mentioned,
using clocker in parallel to metro-counter-multiply
is not necessary.
Same as that complicated tempo - notelength etc construct.
if you want to use translate, transport & Co then all it needs is this
or then make your own calc without transport.
if you want precise time, then use multiplied length.
here one simplest example.
play buffer gets croped, not record buffer.
And now to that "perfect" loop.
as first you should at least use fade in/out when recording
otherwise pops and clicks could happen.
In really good looper one would crossfade
10- 50 ms when loop ends recording for smooth loop.
if you listen and record ( sort of overdub) - you need a bit of
latency compensation, I mean in case you play precisely.
and so on and so on.
Well the notelentgth - tempo construct is pretty complicated because I'm on begginer level and it obviously takes practice to learn more efficient ways to create/do stuff. I've fried my mind today trying to understand some stuff, but your answers are pretty helpful and insightful nontheless, so thank you! I'll post more questions around the topic if I happen to stumble upon more difficulties, but for now I'll take a break and let the new information settle in!
Thank you for your time!!
Feel free to post questions.
Best approach is to post some infos about the concept,
then it is easier to look at it.
Like " I want 4 loop tracks to be recorded in the length of initial recording,
(or set time, like your 4 1n notes in tempo 130 ...)
mute or re-record into them individually etc"
cropping buffers might be memory saver,
but it is not really needed, because one can perfectly
set recording and playback time for longer buffers.
Only exporting loops to disk needs cropping.
To make the concept a bit more clear, I want to create a looper which functions are based on Tc Electronic's Ditto Looper. Technically this looper can record for as many times as you want with each loop being on top of each other. There is no length limit for the first loop though and this patch is meant for musicians, therefore I had to make an algorithm which would help a musician set the buffer size via musical terms (such as notevalues and tempo) and this would also lead to the first loop lasting for as long as the musician wants. Then from the second loop and so on all of their lentgths should be limited to the first loop's length.
So yeah, setting note values and tempo to your own preference is the way to calculate the buffer's size, the only problem is the whole buffer refresh issue. I think a gate connected to the metro output and recording/stop recording toggle would solve the issue since it will let the total metro output be multiplied at once, once the toggle is off.
Also there should be a pause/resume palyback function and another one that resets the contents of the buffer, but I'm just mentioning these just so you can have a clearer view of the objective here.
I am sure the logic with control assignment to individual
loop instances, monitoring of their states, etc will be the most challenging
part for you.
You can also consider using only 1 recorder instance
and set it to buffers that need to get recorded.
So after init recording to buffer~ rec
you send message set buffer~ play-1 to record~ object
Much morer interesting then just same length for all loops
is bar or beat synced recording.
you record one loop, the others can record any number of init lengths.
I see, I'll work on it to see if I get some efficient results and get back here for any possible updates, thank you!