arockmez

I'm very surprised when using groove~ in Max 7. I tried to make a Xfade between 2 groove~ objects playing the same audio file (a 12000ms sample). The main idea is to make a ping-pong between two groove~ objects, this way when the main groove~ is fading out, the second groove~ will appear fading in and so on.

I was stuck for a while because my patch works for a random time and both groove~ objects stop playing. I isolated the problem and that's what i'm pasting here as a patch. I tried the same patch in Max 6 and it works, so i'm guessing it could be a bug in Max 7 groove~ because groove~ now is hugely improved.

1) The audio file (i tried a 12000ms file) is loaded properly in the #0audio buffer~

2) XFade 0.05 means that when the sync signal from the Left groove~ reaches 95% this will fade out as the Right groove~ fades in in it's first 5%

3) I used %loop_start% and %loop_end% to set the #0window buffer~ behavior to provoke the fade in and out. I REMOVED THIS PART OF THE PATCH BECAUSE it isn't related with the issue. I'm aware i'm not using @loop 1 in the groove~ object.

4) When you press the "Start ping-pong" message on the Left groove~ the ping-pong should start between Left and Right groove~ objects and it does indeed, but only for a while, and this time is random in Max 7, in Max 6 it lasts forever as it should, i think. The startloop message is arriving properly, but somehow the groove~ is ignoring it...

am i missing something? or this is a bug?

I was stuck for a while because my patch works for a random time and both groove~ objects stop playing. I isolated the problem and that's what i'm pasting here as a patch. I tried the same patch in Max 6 and it works, so i'm guessing it could be a bug in Max 7 groove~ because groove~ now is hugely improved. 

1) The audio file (i tried a 12000ms file) is loaded properly in the #0audio buffer~
2) XFade 0.05 means that when the sync signal from the Left groove~ reaches 95% this will fade out as the Right groove~ fades in in it's first 5%
3) I used %loop_start% and %loop_end% to set the #0window buffer~ behavior to provoke the fade in and out. I REMOVED THIS PART OF THE PATCH BECAUSE it isn't related with the issue. I'm aware i'm not using @loop 1 in the groove~ object.

groove-bug-max-7

anybody? checked the issue again and it's still happening

I found the startloop message confusing, especially when you have a negative speed and/or a loop end < loop start.

My piece of advice: replace "startloop" with "0.", or with the loop start value.

Hi,
I found the startloop message confusing, especially when you have a negative speed and/or a loop end < loop start.
My piece of advice: replace "startloop" with "0.", or with the loop start value.
Hope that helps.


Thank you so much! i'm a litte bit busy right now but i'll try your version ASAP

It suddendy stopped like before :( i'm returning to analyze what's happening...i contacted Max support but i wasn't able to reproduce the issue

Here is a very quick video where you can see the issue three times at a random different point:

i'm still trapped trying to figure out the reasons

When you just turn the DAC on for first time, the sync signal jumps from 0 to 1 (only if target buffer~ exists, because the 0 sample would be the final sample) suddenly and this never happens again if you turn the DAC off and on. I don't know how, but maybe this is driving some objects crazy

you are sending sig 1. to the groove~ causing it to count up to 1 (you can see it count if you give the buffer a size). here is how i load groove- send 0 to sig on load then toggle 1 to start counting.

Thank you WIL...fortunately Cycling74 people were able to reproduce the issue and it is one indeed. Under certain conditions the problem recorded in the video happens.

Groove~ bug? (Max 7)