Groove won't reverse on startloop

Works fine here, post a simple patch?

-Ben

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:

hope it helps.

________________________________
*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.

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.

All of the above could be wrong. haha.

-kp--

re loopinterp

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

Brendan

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

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.

attached.