This page is only visible to admin users. Sorry!

This page is only visible to signed in users.

Contact <link>support@cycling74.com</link> if you believe you're seeing this page in error.

You don't have permission to view this page.

Activity

Billing History for { name }

Licenses

There was a problem removing the addon. Please try again.

Are you sure you would like to remove the <name>{addonName}</name> addon from your Max subscription? Your {addonName} addon license will remain active until the end of your current billing cycle.

{name} was successfully removed from your Max subscription.

Remove Addon

There was a problem resuming your subscription. Please try again.

Are you sure you would like to resume <name>{addonName}</name>? Your billing cycle will be reactivated and you will be billed as normal on {renewalDate}.

Your subscription has been successfully resumed.

Resume Subscription

There was a problem cancelling your subscription.

Are you sure you would like to cancel <name>{licenseName}</name>? Your license will remain active until <expiry>{expiryDate}</expiry>, at which point your subscription will expire and the license will be deactivated.

Your subscription has been successfully canceled.

Cancel Subscription

Next, start up the Max application and sign into your account (Help > User Account and Licenses).

Max has been successfully activated.

You must be signed into your account to activate Max.

Activate Max

Create a New Post

Edit Article

The list of what we're discovering about Max and our users grows each day. We tackle everything from hardware reviews to re-reading books from decades past.

Get the Latest on Max and our Community

Articles

Sign Out

Sign in to authorize License

Authorize Max

Filter by Format

Filter by Language

Find books related to learning Max.

Books About Max

Here are the artists and educators helping people get creative in Max

Meet Our Max Certified Trainers

Certified Trainers

{ firstName } { lastName } - Certified Trainer

There are no open positions at this time.

Please check your inbox for further instructions.

Forgot Password

Error

Success

Actions

Create Forum Topic

Edit Forum Topic

{category} Forum

There was an error submitting your details. Please try again.

Thank you for your submission! Someone will be in touch with you soon.

NFR / Industry Accomodations

Please make sure you use the link you received by email.

There was a problem retrieving your invitation.

Your account has been successfully created. To manage your institutional licenses, please go to <authLink>https://auth.cycling74.com</authLink> and sign in with your newly created account.

You must be signed out to view this page.

Create an Account

Find more details on our <link>Status Page</link>.

Under Maintenance

We are currently carrying out a scheduled maintenance of our website. Some functionality is temporarily unavailable. We appreciate your patience.

Name

Sort By

{ category } Packages

Share a Max Project

Edit Project

Image Notes

Important Notes

Max Projects come in all shapes and forms. Over the years, our users have shared over a thousand ideas and projects with us. We're proud to showcase them here.

Find Inspiration from other Max Users

Cycling '74 will review it within a week and may make minor edits before publishing it, so your project looks best and reads well in our project gallery.

Thank you for your submission! Your project is currently pending.

Account Recovery

Bundled

{ name } { version } Release Notes

There was a problem changing your password. Please try again.

You can now <link>log in</link> with your updated credentials.

Your password was changed successfully.

Reset Password

Your purchase has now been linked to this account. Next, start up the Max application and sign into your account (Help > User Account and Licenses).

Retrieve License

Type

Search the Cycling '74 forums and website

Search {query}

Please enter your educational details

Your Max for Live or Live Suite serial number is required for this purchase. <link>Need help finding your serial number?</link>

There was a problem updating your subscription. Please try again, or contact support@cycling74.com if the problem persists.

Cannot add RNBO

Confirm Subscription Addon

Thank you for your purchase

Thank you

Retrieving your order details, please wait...

Contact <link>support@cycling74.com</link> if you have questions/issues.

Couldn't sign in. Please check that your username/email and password are correct.

Sign in with your Cycling '74 account

There was a problem creating an account. Please try again.

Successfully created your user account! Please check your email for one last verification step.

Create a Cycling '74 account

Select a Product

Thank you! Your request has been successfully submitted to our support team. Please check your email.

There was an error sending your application. Please try again.

There was an error sending your request. Please try again.

By submitting this iLok request, you understand that you will be notified when an asset is deposited to your iLok.com account. After receiving that notification, you can transfer the asset to your iLok USB stick. Please be aware that all iLok requests are manually processed so it can take up to 48 hours to fulfill your request during normal business hours (Monday-Friday, 9am-5pm Pacific Time).

Important Information

Thank you! Your request has been successfully submitted.

Please note that we are no longer taking submissions for Tools and no longer supporting the Tools section, so you may run into broken files and URLs. You can contribute to the Cycling '74 Community by submitting a Package or using the forums instead.

Max Tools Archive

Edit Tutorial

Tutorials are an ideal way to accomplish a task, learn a new strategy or brush up on your skills. In addition to our in-app Examples, Tutorials and Help Files, you can find new ones here.

Explore the Online Tutorials

Tutorials

Thank you. Please start Max and sign in to use your license

Upgrade

Sign In

Your account requires verification. Please check your inbox, or <link>click here to send the verification email again</link> if you didn't receive it.

Unverified Account

Do you have an activation code?

Already own Max 8 and ready to authorize?

Trouble? Please email <link>support@cycling74.com</link> for help.

If you're new to Max, this is just for you.

Thanks for verifying your account!

You're one step closer to being part of the Cycling '74 Community.

Verify Your Cycling '74 Account

Failed to request a new verification e-mail: {message}

A verification email has been sent to { email }. Please check your inbox.

Can't find your verification e-mail or only have an expired one?

There was a problem verifying your email change. Please try again.

There was an error verifying your email address.

Your email address has been successfully verified. Thank you!

Verify Your Email Address

A user token is required to verify your email address. Please follow the link you received via email.

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