simple_looper1.2.pd

Hi,

I am trying to construct a looper. My goals seem simple but I am having some issues.

I want to record an initial loop into an array, and once that's recorded I don't want the array size to change.
I want to be able to playback my loop at different speeds, plus backwards.

I think all this is working fine in what I have, which I uploaded with this post. I record audio input, and the array is resized to reflect the length of my loop.

When I try and overdub additional audio I am running into issues where the original loop seems to skip around in time. I can't figure this out.

Ultimately I want to be able to playback the loop at various speeds and overdub onto that as well, which is giving my issues too, but I think if I resolve the first issue noted above it might help me resolve this goal as well.

If anyone can take a look at this patch and offer suggestions I would appreciate it.

Thank you.
Nick

@nicnut simple2.pd
Note that I removed the array to reduce the upload size..... so you must recreate it.
I still have no headphones so no testing..... just some ideas.
The [20000( message resets the [phasor~] read speed to match the 820000 table size.... otherwise playback is still wrapping at the previous timer length when you make a new original recording..... and will echo if there is feedback outside of Pd.
I am pretty sure that was the skipping issue.... it probably worked ok on first opening of the patch.
The [0( alongside just stops the [phasor~]. Similar effect except that you will no longer hear the first loop as you lay it down.
It's one or the other.... [20000( to [*~] or [0( to the left inlet of [phasor~].
I cannot see how the overdub button could affect the original directly as it just opens a record.
Messages to auto delete last original.
Needs tidying.
David.

@whale-av

Thanks a lot for taking a look at this. I think I have a better way of articulating the issue. When I do an overdub, if I don't stop it exactly at the end of the loop, the loop sounds like it will play the overdubbed part and then start at the beginning and play the loop, get to the end and the play the overdubbed part again. And it might omit some parts too. It does seem like the array size is staying consistent though so that's good.

Since the array size is not changing, and the phasor~ should be going from beginning to end of the loop maybe it's something in the logic of how I am overdubbing. Shouldn't tabread4~ just be reading the array? When I press "stop" in the overdubbing section why would that mess up where tabread4 is reading from?

@whale-av

Now that I think of it, because i am recording new material into the array, the actual contents of the array are changing, so even if the array size stays the same, what is inside the array is changing.

Maybe i need two different arrays, the same size as the initial recording, and moving at the same speed and same direction. When I overdub it will be into a second array. and if I overdub again it will go back to the first array. I don't know, but it's one idea.

@nicnut I was not really paying attention, so yes..... you found the problem yourself.....
The array is only written between a [start( and [stop( message.
The feedback control does nothing unless a new [start( message arrives, and if you don't press the overdub at exactly the start of the loop then the original recording loses the bit before you pressed it because it starts writing again from the first index of the array.
Same goes for the [stop( message..... but the bit after you stop is lost.
So I have tried to automate the start and stop of a single overdub. The toggle starts overdubbing at the start of the next loop, and stops at the end of a loop after you deselect it......... simple3.pd
Array removed as before.

Here is what I use live........ loop.zip
It's a bit simpler in reality to use a delay..... as you can feed in an overdub any time you like.
I use it for a specific piece.
The feedback is 100% for the piece, and it's score and tempo are determined...... except the length.
The number of patterns is set to exceed any possibility that the musician will get carried away.
The musician gives me a sign when he wants to end the piece and I hit the "cue seen" button. The patch then changes its click sound as it reaches the last bar, and auto-mutes the audio as the bar ends.
It doesn't use an array.... just a delay....
The OSC..... for my remote control from my phone...... needs updating for Vanilla as it uses MrPeach.
Levels are set during rehearsal.
I use it with ASIO in windows and a good soundcard.... otherwise latency upsets the artist.
I am sure that the final loop could be written to a file or an array afterwards if that is required.
David.

@whale-av

The simple3 looper works perfect. Your solution was super simple and works perfect, way better than messing around with 2 arrays.

I couldn't try the loop.zip patch yet, because there are limiter~ objects from the zexy library that I don't have. I used Dekken and installed the library, but only the help file for limiter~ and z~ are there. I tried to join the github group for zexy to post a bug about that, but waiting for approval.

There is only one other issue with this looper that is tricky. When I try to overdub to a loop at a speed other than 1 or -1 things get out of whack. If I over dub onto a loop that is at speed greater than 1, the speed seems to double on playback after the overdub. If I overdub onto a loop at a speed less than 1 it seems to go twice as slow on playback. Note, this is not a scientific observation, but something I am determining by listening to what's happening.

I tried to implement this expr to resolve this: [expr if($f1 < 1, 2, if($f1 > 1, 0.5, 1))]

which multiplies a value less than 1 by 2 and a value greater than 1 by .5.
Here's the patch that I tried it out in: simple3.11.pd minus the array called loop that you need.

Anyway, it didn't resolve the problem, in fact when I try it out it sort of creates a moment of silence in the loop, so something is off.
If you have any ideas how to resolve this please let me know. Thank you for all your help!

@nicnut I am away working for a few days.... so I will look at it on Sunday on the flight home.... as straight away I cannot see why.
David.

@whale-av
Hey David, I just want to thank you for you input on this patch once again.
I had an idea. I think I need to implement a version of the same idea you had with the overdubbing to various speeds with over dubbing.

So if I overdub a speed = 2, the overdub should occur during one full time through the loop as you have it, but at the exact end of that loop the speed should immediately jump to 1. I can try and make a spigot type solution, like what you did.

I don't know if that explains it well, but I think it is something to try. I will assemble it and post a result.

thanks, Nick

Hey @whale-av and anyone else interested in this issue.

I'm still trying to wrap my head around this.
So this looper works if you loop one pass and play it. It works with overdubbing at speed = 1 or -1.. The problem is if you overdub at any speed other than 1 or -1.

I am going to explain the issue as I see it, although I may be mistaken. It is set up so the buffer length will not change after the first recording, so when overdubbing the buffer size doesn't change. If you doing playback at a speed other than 1 or -1 the speed of the phasor~ reading the array with the loop will change to that new speed. When you are done overdubbing, it would seem that the phasor~ should be at the same speed it was during the overdub, but if this is the case things get out of whack. At least that was my observation in the "simple3.pd" patch a few posts up.

I added an [expr] object to try and accomodate for what I was hearing. But now what is happening is it seems that the loop is getting shorter if it is less than 1 and it's too long if it's greater than 1.

I must be missing something obvious here.

I haven't tried this yet, but maybe I should add another phasor~ that is lined up to start with the first phasor~ playing the array, but when I alter playback speed this 2nd phasor will change as well and i can use that to start and stop the overdub process. What I am hearing is the overdub, when playing at speed = 2, will double in speed , then double in speed again during a recording. and the opposite is true for half speed. I think maybe a 2nd phasor can modulate to the new speed when an overdub is activated then take over reading the array when an overdub is finished. It's just an idea I had.

Anyway, any suggestions into this would be much appreciated.
Here is what I have now. simple6.pd

Thank you.

@nicnut I haven't been following this discussion very carefully but I could have sworn that @whale-av suggested ipoke~ and you determined it wasn't necessary. From your last problem description, it sounds like ipoke~ is exactly what you need. If you are looping a fixed-length buffer at some speed other than -1 or 1, then the time to play each loop iteration will be different than the time it took to record it. But if that's the case then you are no longer recording at the normal sample rate. ipoke~ let's you record into a buffer at a variable rate by either interpolating the samples when the record speed is fast, or averaging the samples when the record speed is slow. It's like tabwrite4~ except with linear interpolation. Does this sound like what you need?

Edit: hmm, ipoke~ is a general solution but I think there might be a way to do this with 2 buffers, Suppose you are overdubbing a previous loop recording that you are playing at 1/2 speed. What should happen if you punch in sometime in the middle and punch out before the end? What should happen if you punch in towards the end and the playback loop wraps around to the beginning?

Hi @jameslo,

thank you for your input. I think maybe I should look at ipoke~ again. For some reason, after looking at the ipoke~ help file it seemed like it was good for playback but not recording/ overdubbing, but maybe I need to look at it again as I am having this issue.

When I try and overdub in the middle of the loop I run into some issues. I think the loop starts to play at different speed within the new loop, which isn't what I wanted. I want it to be one speed, whatever that might be, You can alter that speed and then overdub into it at different speeds. The method @whale-av came up with, of locking the overdubbing to the beginning and end of the loop is actually really cool. If you are consistently playing at one speed it's pretty cool and you can endlessly overdub layers into it. I thought 2 buffers might be necessary too, but now I think I just need to figure out when/how to change the speed of the phasor~ when overdubbing.

I think it might get more complicated if I do speeds other than 2 or 1/2, but to keep it simple I'm trying to figure out that math first.

I'll go back into ipoke~ tonight and see how that works out.

@nicnut OK, but if you punch in and out in the middle of the original loop, you still want the original loop to play out in full with your new overdub in the middle and at the speed it was playing at when you punched out, right?

@jameslo

Yes, I want to be able to punch in and out in the middle of a loop. I think enabling recording with using the [edge~] object to detect the top of the loop was a good idea. Only thing is, if I am playing a super slowed down loop I might have to wait a long time to get to the top of a loop.

I found out about the loop~ object, which looks similar to the ipoke~ object. ipoke~ is a little annoying for me because it doesn't load everytime I launch pd.

I think I'm going to try and go back to my initial looping patch, just record at normal speed, use loop~ and record into a 2nd buffer. Maybe bounce back and forth between two buffers and use loop~ to stretch and repitch the loops. I will try and construct a basic version of this and post here.

@nicnut I got something working that uses 2 buffers and I'm wondering if it does what you want. It was much harder than I thought it would be--you can see all the mind-numbing state handling I had to do inside of the record subpatch--maybe I overcomplicated things.
varispeed overdub looper.pd

There are lots of untested edge cases like trying to make a loop that's longer than the buffers or changing playback speed while overdubbing, I would not be shocked if terrible things happen when you choose a 0 playback speed for too long. But I think I was successful in handling the case where you start overdubbing in the middle of one loop but stop in some following loop.

Edit: you can change playback speed while overdubbing.

Hey @jameslo

This is pretty amazing patch. I think one of the best things about it is that there is no click when it loops, it's very clean.
I can't figure out all of the functionality, but even without knowing how to use the patch it's pretty good. I manually altered the speed with the slider and overdubbed a few times. The speed changes seemed to be recorded into the loop, I like the swap buffer method too. I was thinking I would just have two sets of controls, but your method is very clean. I will try and tweak this for my needs. Thanks so much!

@nicnut Great! I just thought of another issue with this patch: it doesn't gate the overdub signal from [adc~] according to when you press [record( and [stop(. It records everything you play during loops while you are in the record state--maybe that's a good thing for your application, I dunno. Anyway, I'd be happy to explain how things work as long as you ask while I still remember

@whale-av, am I right to say that ipoke~ is the general solution to this problem, and if so, does this 2 buffer solution do a similar thing (from the user's perspective) WRT looping? In other words, how does this patch differ from your ipoke~ tape delay?

Edit: I added the input gate and cleaned up some of the state handling:
varispeed overdub looper.pd

Edit2: oh wait, I think I know the answer to the question I asked about David's tape echo: if you change the speed of the tape, you are recording at a variable speed. My thing can't do that.

Hi @jameslo and @whale-av

I wanted to let you know I incorporated some of the ideas both of you presented and combined them into one bigger looper.

I used the overdub concept, from the earlier posts, using [edge~] to line up the overdubs with the beginning/end of the original loop. And I am using the 2 tables concept presented later, but I am separating the tables so I can bounce one table into another.

I made a video using my midi controller to demonstrate it. I also added delay and pitch shifting.

I still have a few general questions.

1. When you record into these tables like this, and don't save the audio ( in the properties of the array) Is this eating up any storage on my computer? or just recording and erasing when I open the patch?

2. @jameslo I saw the way you did cross fading in your patch, but I really don't understand what you did. Can you explain it a bit? Since I have the length of the arrays is there an easy way to just do a quick fade out and fade in at the end points?

Thank you both again for all the information and help

EDIT: here's a simplified version of my patch. It has a lot of controls for my midi controller, but those can be ignored.
3simple_edit.pd

@nicnut
[1] Calculate the distance of the current playback point from the beginning and end of the loop, measured in # of samples.
[2] Take whichever is smaller
[3] Divide by 4000 and limit the result to the range 0 to 0.25. This gives you a upward ramp over the first 1000 samples, a downward ramp over the last 1000 samples, and a 0.25 flat line inbetween.
[4] Shift that ramp to go from -0.25 to 0
[5] Compute the cosine of that ramp (which goes from 0 to 1)
[6] Multiply the looped signal by the reshaped and rescaled ramp

@jameslo thank you for the info. I am still a noob at a lot of this kind of signal math stuff. I see how you achieved calculating the current playback point in your patch, but I don't understand it. I might just try and copy it and put it into my patch. Thank you for the info.

@nicnut You're using tabplay4~. The input to that object is the playback point.

@jameslo ok awesome. thanks I'll keep working on this.