ChrisD

A few years ago I took Andrew Benson's overdub loop example and made it into stereo. I also used the phaser to synch this master loop with other loops so that I could do live overdubbing /multi-tracking / multi-looping. I never got around to actually using it. I dusted it off this week and started to play with it and build out fairly intensive patch but have run into a problem.

The reason I am posting the heart of it , is that I get some intermittent noise or harshness or distortion once and a while. The recorded signal comes through but is very thin sounding with a buzzing distortion. I don't know if these are artifacts from the index object or what but it makes it unusable for performance because it is not reliable. Clearing the buffer and starting over doesn't always remove it. It's odd because the next day it can be fine and then a day later the problem returns. I first thought it was a buffer initialization problem but I no longer think that and am at a loss.

Intermittent problems can be tough to solve so I am hoping some of the more senior guys in the forum like Tim and Raja and Stefan or maybe even Andrew could take a look and let me know what they think could be causing this or suggest a better way of doing this. I seem to remember quite a bit of discussion on sample accurate looping so maybe a newer/improved solution exists.

Here is the main loop patch. The unused outputs are used to synch other loops based on the same fundamental patch design . All loops are synched to this main loops phasor. All loops are are of a shorter duration/smaller buffer size.

The reason I am posting the heart of it , is that I get some intermittent noise or harshness or distortion once and a while. The recorded signal comes through but is very thin sounding with a buzzing distortion.  I don't know if these are artifacts from the index object or what but it makes it unusable for performance because it is not reliable. Clearing the buffer and starting over doesn't always remove it. It's odd because the next day it can be fine and then a day later the problem returns. I first thought it was a buffer initialization problem but I no longer think that and am at a loss.

Here is the main loop patch.  The unused outputs are used to synch other loops based on the same fundamental patch design . All loops are synched to this main loops phasor. All loops are are of a shorter duration/smaller buffer size.

overdub-looping-with-poke-index-phasor-multiple-loops

"senior" guy? me?! ha. you flatter me. now i feel obliged to answer:

i don't get any distortion after playing with it for 20 mins or so.... and it looks fine to me... maybe the distortion happens when you link it up to other things?

i do notice, though, right before trunc~, in [p mainphasor], you have [+~ 0.5] with its right-inlet connected to the phasor~-frequency input. I think this is supposed to remain as a static [+~ 0.5](with constant offset of 0.5, nothing connected to the right-inlet of +~), because it is a rounding function(round up by adding 0.5 and truncating to integer)... other than that, depending on how long your loop length is, you might not even need [+~ 0.5] -> [trunc~](i have good results leaving it in and making sure +~ is at a constant offset of 0.5), either way, that's probably the problem area.

also, in [p L/R_index_poke], you could add a feedback level control(between index~ and poke~) and then you'd be able to temper any overload distortion occuring that way(i sometimes get distortion that way, then by adding a volume control for the feedback, the distortion calms down again after awhile by feeding it levels below 1). those are my best guesses...

like this, see the difference in [p mainphasor] and the 2 index_poke subpatches:

hope that makes sense and helps. best of luck.

i do notice, though, right before trunc~, in [p mainphasor], you have [+~ 0.5] with its right-inlet connected to the phasor~-frequency input. I think this is supposed to remain as a static [+~ 0.5](with constant offset of 0.5, nothing connected to the right-inlet of +~), because it is a rounding function(round up by adding 0.5 and truncating to integer)... other than that, depending on how long your loop length is, you might not even need [+~ 0.5] -> [trunc~](i have good results leaving it in and making sure +~ is at a constant offset of 0.5), either way, that's probably the problem area.
also, in [p L/R_index_poke], you could add a feedback level control(between index~ and poke~) and then you'd be able to temper any overload distortion occuring that way(i sometimes get distortion that way, then by adding a volume control for the feedback, the distortion calms down again after awhile by feeding it levels below 1). those are my best guesses...

hope that makes sense and helps. best of luck.


How long are your loops? I see two potential issues:

1 - For long loops you might run into floating point accuracy limitations (but that would need to be in the region of a few minutes probably).

2 - The other possibility is phasor~ slippage after a long period of time so that you are no longer reading out a sample at a time (maybe skipping one, or reading one twice in a row) - as you are not interpolating that will sound pretty horrible.

1 - use the hr objects by jkc (I think they are on the share page). That will increase the length of time this system will be viable for.

2 - Use count~ rather than phasor~ (you won't need the rounding then). Personally I think count~ is a better solution to use with index~ (or better still hr.count~ and hr.index~). If you need to sync smaller loops off of that you could use a %~ calculation or something like that. count~ is counting samples, so it won't slip.

2 - Use count~ rather than phasor~ (you won't need the rounding then).  Personally I think count~ is a better solution to use with index~ (or better still hr.count~ and hr.index~). If you need to sync smaller loops off of that you could use a %~ calculation or something like that. count~ is counting samples, so it won't slip.

I'm not sure I have anything to add to what Raja and Alex have said! I would also recommend [count~], if not because [phasor~] is causing issues as Alex has suggested, then just because it's slightly more efficient. The hr.~ objects are brilliant, but you only need to use them if you want to play longish loops at 44.1kHz, or if you want to run the patch at a higher sample rate (reduces the time you have before running into fp accuracy issues), or if you want to play back via [play~] with some kind of varispeed.

I'm also flattered, I still feel pretty nooby at this programming game :)

I'm not sure I have anything to add to what Raja and Alex have said!  I would also recommend [count~], if not because [phasor~] is causing issues as Alex has suggested, then just because it's slightly more efficient.  The hr.~ objects are brilliant, but you only need to use them if you want to play longish loops at 44.1kHz, or if you want to run the patch at a higher sample rate (reduces the time you have before running into fp accuracy issues), or if you want to play back via [play~] with some kind of varispeed.

I'm also flattered, I still feel pretty nooby at this programming game :)


Thank you all for your replies , I appreciate it. I have cleaned up the patch so that there is a static value of 0.5 before the trunc and so far so good. Thanks for the example Raja.

The patch I'm working on would let me record up to 4 random sized loops of live instrument input or live sampling and right now I'm using the first loop as the longest time value and syncing them all with range~ and phasor~, eventually I may try to make that dynamic.

I like both Alex and Tim's suggestion of using count and I found a count example Tim posted that is more or less Andrews patch but using count~ and I see what I would need to do to modify my patch,

While I wouldn't mind using count~ and having that be the "master" , without something like the use of range~ with phasor~ to sync the loops I'm at a loss in trying to use count~. I have been thinking about Alex's suggestion that something like modulo might work but I haven't been able to come with something that works. If anyone has and example of how this might be done please post it.

For now I am testing my phasor approach and so far my intermittent issue hasn't showed up.

Thank you all for your replies , I appreciate it. I have cleaned up the patch so that there is a static value of 0.5 before the trunc and so far so good.  Thanks for the example Raja.

The patch I'm working on would let me record up to 4 random sized loops of live instrument input or live sampling and right now I'm using the first loop as the longest time value and syncing them all with range~ and phasor~,  eventually I may try to make that dynamic.

While I wouldn't mind using count~ and having that be the "master" , without something like the use of range~  with phasor~  to sync the loops I'm at a loss in trying to use count~. I have been thinking about Alex's suggestion that something like modulo might work but I haven't been able to come with something that works. If anyone has and example of how this might be done please post it.

Overdub Looping With Poke, Index, Phasor & Multiple Loops