Groove/Poke looper unable to write only part of buffer?

    Dec 21 2011 | 1:07 am
    So I have this looper I built a bit ago. It does everything I want. It's dynamically resizable. You have varispeed (while recording), as well as halfspeed, and even reverse while overdubbing.
    Everything works perfectly......EXCEPT I can't overdub if I change the min/max loop points of groove.
    I know what the problem is, I just don't know how to fix it.
    So I'm using groove's sync output to drive poke, which works nice. You have to do a bit of hackery to get that to work perfectly (see patch). The thing is, because of how groove works, if you change the min/max points, the sync output stays as a signal between 0. and 1.
    The problem is if I change the min/max points, and then overdub, poke is writing based on the the sync signal going from 0. to 1., instead of the scaled version of that.
    An obvious solution would be to use something like scale~, as I can just use the min/max numbers, and scale the sync value accordingly, but I want to use only vanilla Max objects (for compatibility/future-proofing).
    So how can one solve the "scaling signals" problem? Or is there another solution to this?
    Here is the patch (annotated, and with instructions on how to test the problem)

    • Dec 21 2011 | 10:23 am
      FWIW scale~ is included in Max 6...
    • Dec 21 2011 | 12:36 pm
      Well I'll be....I'll give that a spin in a bit.
    • Dec 21 2011 | 2:23 pm
      Works like gangbusters! What a handy object to have in the mix.
    • Jan 21 2012 | 10:33 pm
      Hey Rodrigo,
      Nice hack for the patch, I've been trying to work out the same basic looper and I like how you've done it. Mind if I use it? Out of curiosity, do you have the version with scale~ worked in? Thanks!
    • Jan 22 2012 | 12:08 am
      Go for it, this forum 'built it' as much as I did.
      I used the one that comes with Max6
    • Jan 22 2012 | 7:27 pm
      Hi Rodrigo,
      So I've tried playing around with your patch, and took a look at your party bus (great patch by the way), but I had a question for you about patching style. When I open up either patch and put it into edit mode, there are some serious wire overlaps all over the place, making it a bit hard to understand what's going on. I was wondering if you did it this way for a paticular reason, (when I tried replacing the wires with some sends and recieves, the patch didn't function the same), and if maybe you have an approach to working with all those wires, cause looking at the insides of party bus, it's hard to tell what's connected to what.
      Thanks so much!
    • Jan 23 2012 | 12:59 am
      Hehe, BUSTED!
      Well I tidy as I build, but somethings are just too much. The main source of messiness in my patch is the [mtr] object. It connects to a ton of stuff, and is in the middle of everything, so I decided it would be best to leave that stuff as is.
      Oh wait, you mean wires on top of wires, in a straight line....
      Yeah it's not ideal. I think that comes from coding in Max 4/5 where the option was 'messy' or 'confusing'. I lean towards confusing in that sense. With the new Max6 cables I'm trying to leave it more open and clear, but it's a tough habit to break, particularly for big/complex patches.
      With The Party Van in particular, everything is as encapsulated as I could make it, so if you take the slicer, or the grain unit, you can remove all the wires from it, and it will still work, so it's relatively easy to piecemeal.
      Let me know if you have any questions in particular.
    • Jan 23 2012 | 10:02 am
      Gotcha indeed :).
      It's a matter of preference, but I go crazy with too many wires (leftover nerosis from a summer job as a sound tech as a kid). After a bit of forum reading I found that it's basically okay to replace any max level command that is not order specific with s/r. I did this for your patch and kept the ordering by putting s/r's after the triggers. This left only the sensitve sample level index data still directly connected (don't want extra latency there to be sure). Like I said, to each their own, but you'll note that one advantage of this approach is that if you want to mod it later, some variables you can just change in one spot instead of needing to reconnect everything again. It's seems to work as it did before, although I got rid of the declick and added a feedback control for my own purposes :).
      Thanks again! Next I'll probably try to get it synced to M4L with a gizmo "free elastic" to get a time stretching looper for playing realtime with my band and adjusting to their little tempo changes. Suprisingly among all the software out there, nothing like that really exists yet.
    • Jan 23 2012 | 10:59 am
      I specifically avoided doing s/r's with this as it's much easier to duplicate and use in a bigger patch, without needing to rename things, and then you miss one thing and it breaks everything etc...
      Take a look at this:
      It's the main patch I've been working on, that contains a bunch of these looper modules, some granular synth stuff, and all sorts of things.
    • Jan 23 2012 | 11:10 am
      Just for fun, here's the version with the basic time stretching fft. I had to be careful where to put it so that the overdubs would be the right speed/pitch. Cheers.
      And here's the very basic fft
      Okay, too much fun for one night, time for bed
    • Jan 23 2012 | 11:21 am
      Great work on the party van! Very smooth interface too :). Like I said, it's a difference in preference, as I see what you mean that it's easier to expand out into a bigger patch, although I think s/r's are pretty ok too since you can do find and replace like you would in other code. That's actually the power i see in s/r's (and variables although I haven't got into those yet). is that they allow you to do some tricks like find and replace that work well for other code. Also easier to read IMHO, although I gotta say whatever works for you, cause the party van is a great patch, I just found it really hard to try and pick apart cause of all the wires :).
      Thanks for the all help/conversation and I'll pass along the patch that I work on as it goes (slow but steady :) if you're interested.
      Cheers from Berkeley,
    • Jan 23 2012 | 11:26 am
      Yeah pass it along for sure.
      (I've got the same pfft thing but as a realtime effect going into the looper(s)).
      I didn't think to do the find/replace thing, but just color code all my s/r for easy spotting later on.
    • Jul 25 2016 | 3:52 pm
      Hey guys,
      these patches look very great! Small question though:
      Whenever I am overdubbing on a faster rate, so sig~ in groove~ bigger than 1, I get a huge redux. Does anyone has an idea what the issue could be?