user482601

edit: removed, I didn't explain myself properly in original OP as to what I was going for and confused myself and later posters a bit I think. Alienz posts some great solutions here, thank you!

I found rez~ recently, but unfortunately the way it's designed doesn't work for my sampler instrument. I need the playhead phase to adjust with the loop size, and unfortunately in rez~ it does not. 

Groove~ does do this, but I need a crossfade on the loop and *ideally* also a crossfade when moving start and end positions. 

I know this is a tall order, but in previous threads people kind of dismissively just suggest using two instances of groove and crossfading them playing alternating loops. I've done some research and have tried to blueprint out some ideas but this is a bit more complex than I thought it would be.

I would like to be able to use waveform~ with the mouse in 'loop mode' to control the loop points with as little clicking/popping as possible, but I can't figure out how to add the crossfading time. I'm thinking that the solution would just be to add the crossfade time to the loop, so there's an invisible ramp time before the loop point on waveform~. 

So perhaps waveform~ loopstart > subtract crossover time > groove~ > amp envelope with crossfade ramp > offset and trigger based on fade time? This is where I get in over my head, with then offsetting the loops and alternating them. I need to figure out how to alternate them every phase, but then also offset both groove~ loops by the crossfade time as well so that they trigger a crossfade's length before the actual loop start.

Any help or suggestions for externals or examples to check out would be greatly appreciated!!

edit: removed, I didn't explain myself properly in original OP as to what I was going for and confused myself and later posters a bit I...

variable-loop-sampler-w-crossover-many-people-mention-using-2-groove~s-as-a-solution-but-weeks-of-searching-yielded-zero-examples

thanks for checking out rez~.. i stopped developing it for now(i want to redo it in C++ and also Cycling74 has released new objects which make groove~ a more sample-accurate looping solution that's easier to use so i'm waiting to see what people come up with there, we might not even need 3rd party looper solutions anymore)...

here's a patch that uses some of the new objects like phasegroove~, ramp~, updown~, etc... these objects seem to be designed to make this type of thing easier to come up with... but in your description, i don't really see why you need a crossfade at all, so here i've created an example with just one voice, to show that if you use something like line~ or ramp~ and only register changes when they are complete, you might not need as much declicking and crossfading... but if you feel this isn't what you want, then it can at least get you started and you can use it to comment/describe-better how you would like the crossfade to work:

(particularly, the part where you write, "add the crossfade time to the loop, so there's an invisible ramp time" is a bit confusing: it's not clear why there's any need for a sense of accurate timing if just using the mouse to change a loop in a waveform~ view - it's an innaccurate way of determing loop-lengths to begin with(?)... on the other hand, maybe there's a rhythmic aspect to this which you haven't described yet((?)...is there a clock or something else that you're trying to sync certain things happening to?)... you could also create two versions of what i've created above, and then have a set crossfade(say of anywhere between 10-20ms) between the two voices anytime you change the waveform~ selection with your mouse(but sometimes that might mean two rhythmically differing passages might play layered/crossfading together?))

anyways, hope it helps give some ideas on what to try; there's new stuff in Max8.3 that should help with this type of thing, so i'm just thinking we should give those a go before going back to 3rd party externals(oh! but if you haven't: also try karma~(download it from the package manager) ..it's probably more friendly with waveform~ control; rez~ attempts to be too sample-accurate, karma~ is more flexible)

thanks for checking out rez~.. i stopped developing it for now(i want to redo it in C++ and also Cycling74 has released new objects which make groove~ a more sample-accurate looping solution that's easier to use so i'm waiting to see what people come up with there, we might not even need 3rd party looper solutions anymore)...
here's a patch that uses some of the new objects like phasegroove~, ramp~, updown~, etc... these objects seem to be designed to make this type of thing easier to come up with... but in your description, i don't really see why you need a crossfade at all, so here i've created an example with just one voice, to show that if you use something like line~ or ramp~ and only register changes when they are complete, you might not need as much declicking and crossfading... but if you feel this isn't what you want, then it can at least get you started and you can use it to comment/describe-better how you would like the crossfade to work:

This is an interesting patch, thanks for sharing!

this is just my basic guesswork as to one way to use the newer objects introduced in 8.3 for loopers, there are likely to be so many more advanced ways...

here's a more developed version, where the subpatcher is properly embedded into poly~, and then further options allow for the driving metro to run at a faster rate than the window(so that we can trigger more voices to play all-at-once and this way test out the sound of many voices crossfading into each other). i think this version is more like what the OP might want, but i'm still not sure since there's always a slight reaction time to deal with between selection of loop and actual playback... but i added the 'twist~' object here, too, so that the windowing can be even smoother(one thing people could try if it's still not smooth enough is erase the '@shapemode' attribute from 'twist~' altogether so it sticks with the default), but i think it's working pretty well anyways:

XFadedPolyPlaya.zip

P.S. try running the poly~ with these settings, too:

Screen Shot 2022-06-01 at 11.49.37 PM.png

my pleasure @Jean-Francois Charles :) 
this is just my basic guesswork as to one way to use the newer objects introduced in 8.3 for loopers, there are likely to be so many more advanced ways...
here's a more developed version, where the subpatcher is properly embedded into poly~, and then further options allow for the driving metro to run at a faster rate than the window(so that we can trigger more voices to play all-at-once and this way test out the sound of many voices crossfading into each other). i think this version is more like what the OP might want, but i'm still not sure since there's always a slight reaction time to deal with between selection of loop and actual playback... but i added the 'twist~' object here, too, so that the windowing can be even smoother(one thing people could try if it's still not smooth enough is erase the '@shapemode' attribute from 'twist~' altogether so it sticks with the default), but i think it's working pretty well anyways:

Wow Raja, thank you so much for posting these! You did absolutely phenomenal work on rez~ I'm really excited to take a stab at this type of approach.

If I can get anywhere near rez~'s lack of pops and clicks I will be immensely happy! I really appreciate these examples, I'm going back to the drawing board with these in mind. Huge ups!

Wow Raja, thank you so much for posting these! You did absolutely phenomenal work on rez~ I'm really excited to take a stab at this type of approach.

If I can get anywhere near rez~'s lack of pops and clicks I will be immensely happy! I really appreciate these examples, I'm going back to the drawing board with these in mind. Huge ups!

The part about the invisible ramp was hard for me to describe because as far as I understand it (I could be way off base here) for proper dynamic blurring at least one of the fades needs to include audio from OUTSIDE the loop. If you have access to a copy of Cubase 11, check out the included sampler's loop fading functionality - it works exactly how I was thinking this would/should. In Cubase's sampler, fade in/out ramps include data that is 'not within the loop' so to speak: the ramp down includes audio from after the previous loop end point, and/or the ramp up data has audio from before the next loop start point, hence the 'blurring' effect. I think the trick there would be timing when to do those calculations. E.g., right before the fade in calculate the next 'virtual loop' start position (one that includes the pre-loop ramp up audio). So one possible setup could be 2 groove~s doing this, alternating, and overlapping.

The kicker is that the audio playing during the fade-in is audio from outside the loop. I'm sure there is a way to do it on both the fade in and fade out equally but I can't quite wrap my head around that type of crossfade in this scenario.

To your point, that would indeed mean that at certain times you'd have two different chunks of audio in each of the loops if you were going the 2 groove~ method, but I think that's the only way one could effectively blur changing the loop positions in real-time, as you'd need the fade out of one chunk to fade into a completely separate chunk of audio since the next loop is in a totally different place. I think 2 groove~s would for sure be necessary for this type of blurring, but I'm in way over my head at that point.

In any case, I think approaching this using your first example above is going to be 100x easier than what I was originally envisioning. I wasn't really after a super long 'blur' effect as much as I'm just trying to get rid of pops and clicks while moving loop positions, so I don't think I will need the two groove~ method after all if I can get rid of pops and clicks this way instead. Seriously can't thank you enough for your insight here, this is extremely helpful! 

If anyone does come up with a workable solution for a proper crossfaded 'blur' when moving loop points, that would be amazing - the onboard sampler in Cubase 11 does this, and it is incredible the sounds you can get from it scanning the loop heads in real-time. 

I'm going to keep stabbing at it but it's definitely a tall order indeed. For now I'm just super excited to get smoother position changes!

@Raja

The part about the invisible ramp was hard for me to describe because as far as I understand it (I could be way off base here) for proper dynamic blurring at least one of the fades needs to include audio from OUTSIDE the loop.  If you have access to a copy of Cubase 11, check out the included sampler's loop fading functionality - it works exactly how I was thinking this would/should. In Cubase's sampler, fade in/out ramps include data that is 'not within the loop' so to speak: the ramp down includes audio from after the previous loop end point, and/or the ramp up data has audio from before the next loop start point, hence the 'blurring' effect. I think the trick there would be timing when to do those calculations. E.g., right before the fade in calculate the next 'virtual loop' start position (one that includes the pre-loop ramp up audio). So one possible setup could be 2 groove~s doing this, alternating, and overlapping (using fade-in for this example): 

/ xfade | loop start   loop 1 xfade  \ | loop end     
                                                             / xfade | loop start  loop 2  xfade  \ | loop end                                                                                                                          
                                                                                                                         / xfade | loop start ---
                  |---------------loop 1---------|  
|----------------virtual loop 1---------|                                                                          
                                                                             |--------------loop 2 -----------|                                                               
                                                             |--------------virtual loop 2 -----------|                                                                                                                                                  
                                                                                                                                          |------loop 1---                                                                                                                                
                                                                                                                           |--------virtual loop 1-- 
repeating

The kicker is that the audio playing during the fade-in is audio from outside the loop. I'm sure there is a way to do it on both the fade in and fade out equally but I can't quite wrap my head around that type of crossfade in this scenario.

To your point, that would indeed mean that at certain times you'd have two different chunks of audio in each of the loops if you were going the 2 groove~ method, but I think that's the only way one could effectively blur changing the loop positions in real-time, as you'd need the fade out of one chunk to fade into a completely separate chunk of audio since the next loop is in a totally different place. I think 2 groove~s would for sure be necessary for this type of blurring, but I'm in way over my head at that point.

In any case, I think approaching this using your first example above is going to be 100x easier than what I was originally envisioning. I wasn't really after a super long 'blur' effect as much as I'm just trying to get rid of pops and clicks while moving loop positions, so I don't think I will need the two groove~ method after all if I can get rid of pops and clicks this way instead.  Seriously can't thank you enough for your insight here, this is extremely helpful! 

If anyone does come up with a workable solution for a proper crossfaded 'blur' when moving loop points, that would be amazing - the onboard sampler in Cubase 11 does this, and it is incredible the sounds you can get from it scanning the loop heads in real-time. 

I'm going to keep stabbing at it but it's definitely a tall order indeed. For now I'm just super excited to get smoother position changes!



ya, this is how rez~ does it too(and you don't need "to do it on both the fade in and fade out equally" because if you had a perfectly 'correlated' signal(where the crossfaded-out signal is exactly the same as the crossfaded-in signal - which is never the case in any real-life situation, but this is how people test accuracy of crossfade algorithms), then the part being faded-in, will sum with the part being faded-out, to reconstitute the same signal as though it was never interrupted, especially if you're using an 'equal power' crossfade-curvature too... therefore, it doesn't matter where the center of the crossfade would be if a good equal-power crossfade is implemented... (i don't think i even used an 'equal power' crossfade in rez~, it was just a 'raised cosine' window which works similar but is softer, therefore applies to more varied material for my taste))... 

but, you might not even need to think about this amount of detail, or if you really want that detail and the sound-quality of the cubase sampler, then it's easier to do this all in gen~(using 'codebox') where you can be sample-accurate, and also think about implementing the exact math for the crossfade curvature they use, etc.(this level of detail would be hard to find on forums tbh)... 

...also, one small detail to think about before anything else: if you're scrolling a selection with the mouse, any crossfade/fade is constantly reset the longer you hold down and drag out a scroll, which adds a point of complexity to the interface(or i might not even have understood how you're using the mouse to begin with, because i've been using it in 'select' mode, and now reading back, i realize you mentioned 'loop' mode... i might've been way off in what i'm thinking you needed(?))... so it might be necessary to simplify that first: maybe use 'speedlim' object to limit the speed at which changes can occur, then use that minimum as a reference for your crossfade time; you need both fade-in and fade-out to be able to happen within that minimum, otherwise, you'll get an additional source of clicks/pops/bumps; and then once you do that you have an interface that might make it clearer to others in what further direction you need to go. 

once you have these small kinks in the interface worked out how you'd like it, you could post back a patch here with how you might guess it would work(if it's not complete just add comments where you think something could happen differently, etc.), and people can help with more detail from there.

the ramp down includes audio from after the previous loop end point

ya, this is how rez~ does it too(and you don't need "to do it on both the fade in and fade out equally" because if you had a perfectly 'correlated' signal(where the crossfaded-out signal is exactly the same as the crossfaded-in signal - which is never the case in any real-life situation, but this is how people test accuracy of crossfade algorithms), then the part being faded-in, will sum with the part being faded-out, to reconstitute the same signal as though it was never interrupted, especially if you're using an 'equal power' crossfade-curvature too... therefore, it doesn't matter where the center of the crossfade would be if a good equal-power crossfade is implemented... (i don't think i even used an 'equal power' crossfade in rez~, it was just a 'raised cosine' window which works similar but is softer, therefore applies to more varied material for my taste))... 
but, you might not even need to think about this amount of detail, or if you really want that detail and the sound-quality of the cubase sampler, then it's easier to do this all in gen~(using 'codebox') where you can be sample-accurate, and also think about implementing the exact math for the crossfade curvature they use, etc.(this level of detail would be hard to find on forums tbh)... 
...also, one small detail to think about before anything else: if you're scrolling a selection with the mouse, any crossfade/fade is constantly reset the longer you hold down and drag out a scroll, which adds a point of complexity to the interface(or i might not even have understood how you're using the mouse to begin with, because i've been using it in 'select' mode, and now reading back, i realize you mentioned 'loop' mode... i might've been way off in what i'm thinking you needed(?))... so it might be necessary to simplify that first: maybe use 'speedlim' object to limit the speed at which changes can occur, then use that minimum as a reference for your crossfade time; you need both fade-in and fade-out to be able to happen within that minimum, otherwise, you'll get an additional source of clicks/pops/bumps; and then once you do that you have an interface that might make it clearer to others in what further direction you need to go. 
once you have these small kinks in the interface worked out how you'd like it, you could post back a patch here with how you might guess it would work(if it's not complete just add comments where you think something could happen differently, etc.), and people can help with more detail from there.

glad to help get ya started 🍻

Ah, I have seen other people mention gen~ in this context, I'm thinking that may be my best bet. 

Thank you so much for all the insight above Raja! It helps a lot to get the perspective from someone who has experience with this type of thing specifically. Huge ups again on rez~ it's an amazing tool (I just have a niche use-case here where I need the playhead phase to shorten/lengthen along with the loop size, otherwise I'd probably just use rez~)

it's easier to do this all in gen~(using 'codebox') where you can be sample-accurate, and also think about implementing the exact math for the crossfade curvature they use, etc

Ah, I have seen other people mention gen~ in this context, I'm thinking that may be my best bet. 

Thank you so much for all the insight above Raja! It helps a lot to get the perspective from someone who has experience with this type of thing specifically. Huge ups again on rez~ it's an amazing tool (I just have a niche use-case here where I need the playhead phase to shorten/lengthen along with the loop size, otherwise I'd probably just use rez~)

Realize this is an older thread but I've been playing with "

" (wicked cool) and it does almost everything I would like, except some of the audio transformations that are typical such as speed, timestretch, etc.

I noticed that in the subpatch there's groove~ that can do these things; however, I'm new to Max and despite trying to hack it out, reading / watching tutorials, etc. I can't seem to figure out how to get that functionality to work. I'd be happy with just speed, for example. : ) 

If anyone can share some pointers that would be really appreciated, thanks! 

I finally got this working. The trick is to use one groove~ object as a master that doesn't actually play the sample, and use two slave groove~ objects to do the playing and crossfading. This way you can keep them off loop mode but use the loop points on the master groove~ to control when to trigger startloop on each of the slaves.

I hope this may help someone later on that's looking for a solution to this. 

I finally went back to this project and figured it out. The trick is to use one master groove~ connected to a waveform~ to control the loop then use two groove~ objects that aren't in loop mode as slaves to that master to actually play (using startloop message) and crossfade. The other trick is just timing the start and fade properly to eliminate any clicking, but that part is easy by comparison. HTH anybody looking for a solution to this later. 

Also afaict, the best way to detect the end of the loop is still

I finally figured it out, apparently I'm the only one as I haven't seen anybody else with a successfully click-free looper in groove.

Since I apparently have proprietary shit now I don't want to give it away, but I will say the solution is not two grooves~ but actually 3. 

ha, was worried this might be a slightly weird interface(i was experimenting with some objects that had been new to me, like phasegroove~)...

...this is the basic idea, see how i added a 'target 0, $1 $2' message near bottom-right("target 0" targets all voices of the poly~, and the comma separator just separates messages, so that after we've set all voices to be targeted, they then all receive the '$1 $2' list in that second inlet), and inside the poly~ voice where i address ramp~ duration separately using 'in2'... this is just one way to do it, if you think of any more concise way to interface it, definitely go with your instincts:

^in the early version of the patch, the same list that got the duration from the selected waveform was sent to both 'ramp~' and 'groove~' in the same way.

you just need to apply those durations differently in order to work 'speed of playback ramp', separate from 'duration of selection'(ramp~ controls the speed with which the duration is read through - you can also do it the other way, where you keep ramp duration steady and change duration of selection, but ramp~ also controls the de-clicking envelope.... so you won't be lining up the durations as well).

edit - i upload the newer patch here, because i forgot to put in a 't b f' object that can make changes instantly audible:

I resurrected the thread initially, I just wanted to pass along that I figured this out finally myself, but I deleted my replies because it wasn't quite working 100%, but later that day I got the bugs ironed out and it's now working great! I edited the OP as resolved.

I'm sure there are many different ways to accomplish this, but for my limited skill set in max I had to just figure it out on paper logically then implement it the best I could. It ended up being a billion times more simple than people make it sound on this forum, to be honest. In my case the trick to get it working with no clicks was just to use THREE groove~ objects, rather than two: one as a master receiving from waveform~ and two as slaves. I don't know what finally gave me that idea, but when it hit me how simple it was on paper, implementing in max was just time consuming, but not overly complicated.

 At first I thought the triggering would be tricky, but actually triggering the fades at the exact same time as the 'startloop' message to the slave groove~ that is next works 100%. The only thing I'm still not sure of is if there's a more efficient way to get a bang from 'end of loop' outside of using delta~ into abs~ into > 0.5 into edge~, so if anyone knows of a better method please let me know! Using the delta~ method seems to work just fine for me though fwiw.

I only regret being so intimidated I stepped away from this for 2 years, when I came back I had it figured out in one day! It's my fault for making my problem sound more complicated than it was, then convincing myself it was because I couldn't find the answer here anywhere, so for anyone who searches in the future HUGE 

I feel like people are offering up solutions that didn't apply to my problem specifically so If anybody runs into this in the future and needs help feel free to email me tekeldnb at gmail I'll be happy to help.

Thank you all for the pointers! I'm new to Max but will try to decipher and figure out what you all are describing. : ) 

(@Tekel DNB if you have time it'd be great to see an example or even just a screenshot showing how things are connected, I've recently learned how to use groove~ so not sure how 3 of them would work together – much less how they would all connect to buffer, waveform, etc – but no worries if you haven't got the time or unable to!)

Edit: if you need help from Raja (Alienz) on his interface he linked above (the xfadedpolyplaya), a new thread may be in order, as that is not related to what I was working on. That's why I posted that last line with my email so people can hmu if needed if anyone ends up on that path (which most people won't, so no worries at all).

Thanks @Teknel DNB – my browser didn't load your earlier post about contacting you directly, my intent is actually your original post and I was trying to understand how to approach it via what Raja had shared. But I stumbled on your post via Google because I was trying to solve the same thing : ) I'll hit you up at your email.

No worries! Cool I'll look for that email.

apologies, i only initially answered the thread because of mention of rez~

i feel that groove~ is a 'beginner-level codependence' that cycling74 created to solve some simpler looping sample-playback needs.

eventually, the crossfade detail sought for in this thread is best found, as with any other detailed algorithm, in a more discretely coded environment(in my humble opinion)...

but! this thread has a very descriptive title which people might find ongoing when they search, so if i can come up with a nice codebox in gen~ that can be embedded in poly~(that performs the crossfade as the OP mentioned where there is an outside-of-loop crossfade area to work with in order to keep looping start/end points in sync while crossfading) for this, then i'll post back here with it... otherwise, others should feel free to post more relevant examples to this thread than i have.

(i did not mean to hijack with that one shitty patch, plus, i need to add a second-crossfaded voice to that patch anyways, sorry, i see that now: but it wasn't occurring to me how to lock it in nicely with phasegroove~ control yet).

threads should be for everyone and anyone to contribute their suggestions/ideas to 🤗

That's all fair, but in my OP I was asking specifically for a solution that used groove~, I'm not sure how that's my bad exactly. My replies here are in an effort to convince the next person with this problem that it's not as complicated as people make it seem.  I'm not sure how my OP is deceptive or misleading at all, especially considering the fact that I solved my own problem quite simply (after a 2 year hiatus, largely caused by people on here over complicating stuff). But that was not directed at you specifically man, your responses were very helpful, they just were not what I needed, and apparently weren't what this guy needed either.

Variable loop sampler w/ crossfade