Tim Lloyd

Has anyone successfully used index~ or elasticindex~ for looping playback from a buffer?

I realize its not the most sensible way of looping, but I want to make a live looping system that takes advantage of the ability of elasticindex~ to "freeze" playback on a particular sample, or read through the buffer incredibly slowly to create granular-ish sound-scapes.

I have tried everything I can think of to loop playback of a buffer with index and elasticindex~ but it always retriggers late and out of time.

I preferably want it all signal rate as well, which is why I'm not sure that a combination of elasticx~ for normal playback and elasticindex~ for frozen/slow playback will work well enough. Is there a way to trigger playback of groove/elasticx~ with a signal?

Also, is there a way to read through a buffer in reverse or at varying speeds using count~?

I tried using phasor~ multiplied by the length of the sample to drive index, but this doesn't work properly - seems to create sort of a wavetable-ish playback.

Am I barking up the wrong tree thinking I can make a sample-accurate looping patch using elasticindex~? I could just use groove as I have done already, but I want to avoid using control-rate messages to start/stop recording and to start/stop playback, because of timing and the whole right-left ordering thing.

If anyone can be bothered to wade through that question and make some suggestions, that would be great!

I've attached the 3 little patches that I've been messing with. If anyone has elasticindex~ I would really appreciate some advice on using it!

I have tried everything I can think of to loop playback of a buffer with index and elasticindex~ but it always retriggers late and out of time.  

I preferably want it all signal rate as well, which is why I'm not sure that a combination of elasticx~ for normal playback and elasticindex~ for frozen/slow playback will work well enough.  Is there a way to trigger playback of groove/elasticx~ with a signal?

Am I barking up the wrong tree thinking I can make a sample-accurate looping patch using elasticindex~?  I could just use groove as I have done already, but I want to avoid using control-rate messages to start/stop recording and to start/stop playback, because of timing and the whole right-left ordering thing.

I've attached the 3 little patches that I've been messing with.  If anyone has elasticindex~ I would really appreciate some advice on using it!

index-for-sample-accurate-looping

Thanks, that works really well, no need to set up change~ edge~ etc to loop either.

Using index this works great, and elasticindex~ is designed to work in exactly the same way, just with a few added features, but I'm getting artifacts when playing back at normal speed.

It sounds like aliasing, or as if the phasor isn't driving index quite fast enough.

I'll post on the elastic forum regarding this, but its not a very busy forum, so I'm still hoping someone on here can help.

Heres your patch with the elasticindex mods:

I am using elasticindex~, and after using that latest patch of yours, I don't really experience those fluttery artifacts you mentioned.

apart from that, as you said, elasticindex~ is supposed to work the same way as index~, being sample accurate. if you achieved that with your latest patch, any artifacts would be due to the internal workings of elasticindex rather than you doing anything wrong with your patch.

to summarize: No, you are not barking up the wrong tree. Within the pure MSP world, wave~ would be another option. But that's just a detail.

could you record your output when playing back @normal playback speed with elastic switched on ?

I am using elasticindex~, and after using that latest patch of yours, I don't really experience those fluttery artifacts you mentioned. 

I've been experimenting with using that patch inside a poly~ and have had no issues with the "aliasing" sound that happened with elastic mode off. Not sure what was causing that.

But I still think that with the algorithm on, there are artifacts at normal playback speed.

Heres a patch to try and show what I mean:

Another question - when using poly~ how do I give each instance of the patch its own signal outlet? The patch has only one elasticindex~ and one signal out, but I want to be able to load multiple instances each with their own signal outlet.

I've been experimenting with using that patch inside a poly~ and have had no issues with the "aliasing" sound that happened with elastic mode off.  Not sure what was causing that.

Another question - when using poly~ how do I give each instance of the patch its own signal outlet?  The patch has only one elasticindex~ and one signal out, but I want to be able to load multiple instances each with their own signal outlet.


the signal outputs in a poly~ object are a mix of the outputs of all instances of the patchers's outputs which correspond to that number.

regarding elasticindex~, I can't confirm your findings. In fact, cancelling the signals out by inverting the phase doesn't work for me, regardless of whether elastic has been switched on or not. I also don't really hear any differences when switching elastic on/off.

On the other hand, replacing the elasticindex~ objects on the left side with index~ works as expected (cancelling out).

So altogether, there seems to be an issue with audio jitter within elasticindex.

Thats really strange that my elasticindex seems to have issues, I'll post on the elastic forum about it.

Regarding poly~, I can't work out how to have a patch with one outlet loaded into poly~ multiply times, and give each instance its own audio outlet. I may be misunderstanding the purpose of using it, but heres the patch if you have any suggestions.

Also, is there a better way of doing the start/stop/freeze/slow control, preferably triggering as fast as possible, sometimes the freeze button seems to not take effect immediately.

Btw, since you don't seem to have any issues with playing back at normal speed with elastic on, the way I have it set up turning it on and off won't be needed for you, but its why I have to use all the trigger objects - probably what is slowing down the messages.

Also, I'm aware that the way I have it set up right now, using multiple instances of el.index won't be sample-accurate as they are using separate phasor~ objects, but I'll sort that out once I know how to use poly~ correctly.

Regarding poly~, I can't work out how to have a patch with one outlet loaded into poly~ multiply times, and give each instance its own audio outlet.  I may be misunderstanding the purpose of using it, but heres the patch if you have any suggestions.

just quickly, as I am at work without access to Max.

I don't get your point about the individual audio outlets for a poly~ patcher. As I said before, the signals coming out of the patcher instances are merged. So if you have an internal patch with a "out~ 1" outlet (although it is not a normal outlet), the signals passing through that object (for all the instances) are merged at the poly~ outlet.

I myself haven't worked too much with poly~ but the documentation seems to be pretty exhaustive. If you need independent signal processing per patcher instance, you would have to include it into the poly patcher itself. Once it leaves that patcher, it gets merged, and I don't think there is a way around it.

I don't get your point about the individual audio outlets for a poly~ patcher. As I said before, the signals coming out of the patcher instances are merged. So if you have an internal patch with a "out~ 1" outlet (although it is not a normal outlet), the signals passing through that object (for all the instances) are merged at the poly~ outlet. 

Ok, thanks for the reply, it seems I'm misunderstanding the uses of poly~. I'll go back over the tutorials and rethink the patch.

Ok, thanks for the reply, it seems I'm misunderstanding the uses of poly~.  I'll go back over the tutorials and rethink the patch.

index~ for sample-accurate looping??