Lasse Munk

Anyone got any ideas of why groove won't play in reverse (-1) if I set the reverse first, then gives it a startloop message? (Meaning, it seems that if you want to reverse it, you'll have to startloop then reverse.)

groove-wont-reverse-on-startloop

this might not be your issue at all, i might be guessing, but just in case...

"startloop" does only what it literally means, starts from only the 'start' of the loop. if you try and reverse just as you play from the 'start' of the loop, it does what is expected, plays the 'start' of the loop first then reverses to wrap around to the end of the loop(only if looping is turned on for groove~, otherwise, if looping is off, it will start at the starting point of the loop and then reverse until it hits the beginning of the buffer~, this means playback of only one sample if the starting point is the same as the beginning of the buffer~). in other words, in reverse, 'startloop' still means 'start' of the loop. if you want a true reverse, you might want to trigger the exact millisecond value of the end point into the left-inlet of groove~.

this whole startloop-reversing problem(not really problem, more like a lack of convenience in the 'startloop' message being too literal), is more easily seen when you set loop on, but then trigger a stop after every loop. i just use change~ and some ordered triggering of forward and reverse direction along with the end-loop point into left-inlet of groove~ to get a true reverse:

this might not be your issue at all, i might be guessing, but just in case...
"startloop" does only what it literally means, starts from only the 'start' of the loop. if you try and reverse just as you play from the 'start' of the loop, it does what is expected, plays the 'start' of the loop first then reverses to wrap around to the end of the loop(only if looping is turned on for groove~, otherwise, if looping is off, it will start at the starting point of the loop and then reverse until it hits the beginning of the buffer~, this means playback of only one sample if the starting point is the same as the beginning of the buffer~). in other words, in reverse, 'startloop' still means 'start' of the loop. if you want a true reverse, you might want to trigger the exact millisecond value of the end point into the left-inlet of groove~.

________________________________
*Never fear, Noob4Life was never here!*


Noob4Life, this is very helpful. I'm just having a whole load of problems with groove right now and I needed this. Also, just a quick question, what does loopinterp do? I can't seem to get a solid explanation in a forum.

I was also battling this and came up with something, that I am not sure works 100% but tried to do what the above patch does plus a few more things.

The goal was to make an all purpose playback engine that uses groove plus:

1. Works off a set of numbered buffers like "foo.1 foo.2" by just choosing the number portion so that we can easily algorithmically pick and play buffers.

2. Play at any speed 0. to 1. (I usually don't play back faster, only slower).

3. *and* play backwards. This was surprisingly tricky and I had to do exactly what Noob4Life has with his using info~ to get the playback start jiggered.

What I have seems to work as intended but I can't believe that this is the most elegant way to do this but this was the best I could figure. There may be some ways to simplify or make it more robust.

The trick is to bang info~ after you choose a buffer and get the length of the current buffer and use that as the playback start position but only if going backwards.

Otherwise we can just send 0. as the inskip & the buffer symbol. So you needed to use some conditionals. I just used the brute force [if ] object. It is pretty Kludgy i guess.

-- Concerns that haunt me (i was hoping someone would have chimed in on my other thread on groove but my post is the only one :(

1. I am not sure it works in all cases (seems too) or that the order of operations is entirely correct. I aimed to set the input to sig first then the float for the playback start position then the buffer. Perhaps that is wrong, or perhaps that isn't the order I am actually getting anyway.

2. I haven't tried looping anything yet, but i don't see why that woundn't work.

3. I am suspicious of the fact that I didn't need to send the stop message.

and (file under: I know this broke but it is 5 am):

4. the "bang when done" of splay (or the line~ you used to control play~) is gone, so we need to hack one together. Turns out there is one you can crib from the help patcher. Which works great in the case that you are playing forward. It doesn't bang when done if you play backwards, which sucks. I need to fix that since i used the bang when done in play~ & sfplay a lot to sync other events. I am not sure what to do to fix this.

The goal was to make an all purpose playback engine that uses groove plus:
1. Works off a set of numbered buffers like "foo.1 foo.2" by just choosing the number portion so that we can easily algorithmically pick and play buffers.
2. Play at any speed 0. to 1. (I usually don't play back faster, only slower).
3. *and* play backwards. This was surprisingly tricky and I had to do exactly what Noob4Life has with his using info~ to get the playback start jiggered.

The trick is to bang info~ after you choose a buffer and get the length of the current buffer and use that as the playback start position but only if going backwards. 

Otherwise we can just send 0. as the inskip & the buffer symbol. So you needed to use some conditionals. I just used the brute force [if ] object. It is pretty Kludgy i guess.
-- Concerns that haunt me (i was hoping someone would have chimed in on my other thread on groove but my post is the only one :( 

3. I am suspicious of the fact that I didn't need to send the stop message.
and (file under: I know this broke but it is 5 am):

4. the "bang when done" of splay (or the line~ you used to control play~) is gone, so we need to hack one together. Turns out there is one you can crib from the help patcher. Which works great in the case that you are playing forward. It doesn't bang when done if you play backwards, which sucks. I need to fix that since i used the bang when done in play~ & sfplay a lot to sync other events. I am not sure what to do to fix this.


loop interp takes the end of the loop and the beginning of the loop and interpolates across wave form discontinuities that would result from joining them in an attempt to de-click the loop. Works great in some cases, less great in others depending (i guess) on how far apart the two points are. If click are still present at the loop point you would need to use the bang when done portion (the exact thing that is broken in my patch haha) to trigger a ramp or env that would remove the click.

If your input samples are nicely manicured with smooth envelops you likely are good to go in the case that you are looping whole files. If you are looping points internally, well try loop interp and see if i helps.

in this respect the [grooveduck] object gives similar results to (the best solution of...) banging an envelope from [groove~]'s sync outlet.

trapezoid~ is even better than grooveduck.

Trapezoid is what i am using. But it is kind of sore topic for me. haha

https://cycling74.com/forums/trapezoid-confusion

Trapezoid is what i am using. But it is kind of  sore topic for me. haha

https://cycling74.com/forums/trapezoid-confusion


ok, it must be one of those days... i made a little abstraction example of one of the ways i like to use it for ramping.

the advantage of trapezoid is the it can do everything the grooveduck does, but more, as you can easily shape the type of curve for 'effects' as well as clip-reduction. having said that, grooveduck is an abstraction for help/demo, you can easily mod that too. also i expect the much missed jhno made that before trapezoid~ existed.

That looks amazing. I am going to look at that tonight when i get home and see what i can learn.

I battled groove and reversing/looping/one-shotting myself today; I couldn't get the method noob4life offered above to work reliably for my needs ('scrubbing' the playback speed whilst the sample plays).

The following does seem to work reliably, however, and uses essentially the same method as noob4life outlines. The patch also implements volume enveloping to avoid clicks at loop points and start/stop of playback.

Hopefully this will be of help to the next weary groover who passes through this thread

https://cycling74.com/forums/bizarre-groove-behavior

since there is more complete info on this thread.

this is the behavior when you call "startloop". it used to drive me nuts too but you can just use "loop 1" or "loop 0" instead. so if you want to reverse the direction just multiply rate * -1, and when you want to restart the loop query buffer length (which is actually the end) and use this for the start point. bam!

its definitely not a bug though. they are just taking the "start" in "startloop" literally.

moved my reply from a different thread: https://cycling74.com/forums/bizarre-groove-behavior
since there is more complete info on this thread.

I made a little combination of your patches which works perfectly for me now. I can set start- and endpoints within the buffer and I can trigger very fast which makes it interesting for integrating the patcher in a sampler.

Hey guys,
I made a little combination of your patches which works perfectly for me now. I can set start- and endpoints within the buffer and I can trigger very fast which makes it interesting for integrating the patcher in a sampler.
Thanx for your inspiration.
Have fun
Peer


Made a mistake....the delta~ is too much....

BUT: the patcher only works if u trigger the play again after the whole sample between start- and endpoint's been played. didn't figure out yet how to make it work when i want to trigger the play-buttom several times in a row before the sample reached the endpoint.

Made a mistake....the delta~ is too much....
BUT: the patcher only works if u trigger the play again after the whole sample between start- and endpoint's been played. didn't figure out yet how to make it work when i want to trigger the play-buttom several times in a row before the sample reached the endpoint.
i'm working on it.....


that should make it....hopefully no more bugs...of course it's a basic version without loop function etc - but that's no problem to add

that should make it....hopefully no more bugs...of course it's a basic version without loop function etc - but that's no problem to add
cheers
Peer


Here's a version with looping adding. I've also tidied the patch and added the ability to change playback speed/direction whilst the sample (or loop) is playing.

thanx...i didn't do all that cause i'm using the patcher within a poly~ which I use for a sampler. so the playback speed is determined by the key I stroke on my midi-keyboard ;-)

Groove won't reverse on startloop