How to wrap around 'zero' with min/max points in groove~?

    Jan 15 2012 | 1:47 am
    So I'm working on a patch that plays from a section of a buffer. So if it's a 1000ms sample, playing a 200ms section of it, so 200-400, or 700-900, or 900-100. How do you do that last one? (playing across the 'zero' of a buffer).
    I normally use groove for dynamic start/end points, but you can't set the min higher than the max (or vice versa).

    • Jan 15 2012 | 2:18 am
      Yeah so it would play from 900 to 1000, then 0 to 100, then back to 900.
    • Jan 15 2012 | 6:18 am
      is this what your looking for? open file, then set position/length.
    • Jan 15 2012 | 8:11 pm
      I was thinking that it might have to come to a phasor~. I suck at phasor/play.
      That kind of does what I want. But now how to do jump to arbitrary positions within that defined window? And then let it play through?
      What I'm actually building is a virtual skipping CD player, where you can write to the CD in realtime. So there's a skipping/jumping engine that jumps around within a specific window (currently min/max points for groove, those position/window is doable I guess). Then there's the playback engine, which is easy with groove as I just send it a number to its first inlet and that's it.
      To have the phasor~ jump around like do I send it a float between 0 and 1 in it's right inlet (proportional to where I want to jump in the sample)?
    • Jan 15 2012 | 9:41 pm
      You can see what see what I did here to make it jump around using random or drunk. You can adjust the metro to the length you want it to play after each jump, I have it set to 1 sec. You can change the metro in real time or using presets while recording so after each jump the length that is played will be different.
    • Jan 15 2012 | 11:04 pm
      That works well but the idea is to jump around arbitrarily within the given 'length' selection.
      So in a 1000ms example, with position at 500ms and length of 100ms, sending it random (or drunk) jumps within that window only, and not the whole buffer.
    • Jan 16 2012 | 1:52 am
      I think what you are looking for can be found here. Look through tutorials 9 on grains.
    • Jan 16 2012 | 8:58 am
      Ooh those look great. I hadn't come across this guy's videos before.
    • Jan 16 2012 | 9:33 pm
      I actually went through all those tutorials and have a patch that will do what you want, but I have embellished it so bad that i am having difficulty working backwards to get to the original basic patch. But I know the patch uses an rsliser to select beginning and end pouts then you can move the rslider through your track, and it will bounce around randomly within the amount selected by the rslider. Its all there in the Grains tutorials. Good Luck.
    • Jan 16 2012 | 9:54 pm
      Ok, those tutorials were great and between that and your patch I figured something out. It's actually much easier to have the position/window type controls rather than absolute start/end points, as I don't need to keep the sample length in mind.
      Now the question/problem is, how do you edit window or position (this one is the worst) without it sounding horrible while you move it?
    • Jan 16 2012 | 10:00 pm
      In thinking about it more I guess noise is unavoidable when moving the playhead, but is there a way to have position/window change without altering the playhead (only the constraints for them), so if you move position, the playhead doesn't jump/move until it's outside the given window, rather than being dragged around by +~/%~.
    • Jan 17 2012 | 4:40 am
      In the max Extras menu open Examples Overview> In the MSP section go to Sampling and the first patch is called Granularized. This patch scrubs cleanly through an audio file. You have to explore around in the guts of the thing but I think it uses poly~ and an envelope abstraction. You know how to get inside a bpatcher?
    • Jan 17 2012 | 8:45 am
      I've messed around with that patch a bit, but not a lot. I will take a look inside to see what's up there as that does in fact move things around smoothly.
      I guess I'll find out by looking, but I'm guessing it doesn't use the +~/%~ method?
    • Jan 17 2012 | 10:47 am
      Also thought that smoothing grains would be easier than smoothing continuous/cycling playback as you can just envelope the grains and you wont get noise when moving, but you can't exactly envelope ongoing audio. Hmmm.
    • Jan 17 2012 | 10:04 pm
      I think the solution is to treat continuous audio as "instances". That way you can envelope each instance.
    • Jan 17 2012 | 10:27 pm
      Hmm, so making it 'faux granular'?
      I guess I could also have a granular engine running along side of it, and scrub via that when scrubbing (unmuting the granular synth and crossfading it in), then go back to the normal playback. A bit expensive perhaps, but it beats that shitty dragging sound, particularly when my interface is going to be built around dynamically changing/moving that window.
      So what's the lowest CPU 'vanilla' granular synth that does clean scrubbing? Granularized and SugarSynth both pack a CPU punch and do a ton of shit I don't need if it's only a cross fading/cleanup job.
    • Jan 18 2012 | 8:21 pm
      It occurred to me (after searching the forum a bit) that a more elegant solution would be to have a second playback object playing the whole time that I crossfade over to whenever the playhead is being moved which only gets told to jump position when the playhead meets the end of the window (wherever it may be at the time) and jumps to the start of the window and continues playing. It would crossfade back to the 'live' version once the scrub is done being moved.
      Probably some conditional stuff to deal with (like when the window is longer than the loop end point and it wraps around), but that would be more ideal than granular frozen/scrubbing.
    • Jan 18 2012 | 8:30 pm
      This is something that is out of my range of knowledge, since I am still searching for a concrete solution to the "dirt/noise/pop/scratch" issue myself. As far as CPU. I am using a 13" stock macbook pro (2.5 years old). The granulized patch uses about 3-4% CPU.
    • Jan 18 2012 | 8:56 pm
      It's outside my knowledge too, but thats par for the course with my max explorations.
      I can picture doing that relatively easily with groove by comparing the playhead and the loop maxpoint, if the playhead is higher than the maxpoint, then jump to the loop min, and that way it will always stay within the given window, but as per the original point of this thread, groove wont let you wrap around the zero, so it would be using the audio rate example you gave me, which again is doable, but my audio rate chops are not good.
      I guess the main difference is that I don't actually want to scrub the playhead, I want to shift the window which contains it, so the playhead is still playing normally.
      A couple of snags with this is if I'm moving the starting point past the playhead, that's actually scrubbing the playhead territory, but I guess I can just force a jump to the middle of the window which the playhead meets the min point.
      4% isn't bad, but when it's only an auxiliary feature that only does stuff sometimes, it's not super appealing. Not to mention that I would prefer an actual playing playhead, as opposed to the frozen/sliding one.
      Which are you trying to do? (scrub, or window shift)
    • Jan 18 2012 | 11:28 pm
      Ok, figured out a solution that uses 1% cpu when playing back/scrubbing, might be able to make it so it only uses CPU WHILE scrubbing, as opposed to while playing back.
      Also has a nifty 'wraparound' window/range display.
      And the poly named "grain~" based on sugarsynth
    • Jan 18 2012 | 11:35 pm
      Yup, this is better.
      Replace the contents of [p scrub] with this:
    • Jan 19 2012 | 2:03 pm
      Just discovered a bummer. It looks like the [%~] breaks everytime the main phasor hits 0 causing a hiccup in playback as the modulo resets back to zero too.
      That tutorial you showed me would work but it uses [line~] so it wouldn't be sample accurate looping as it would be bang based.
    • Jan 19 2012 | 11:35 pm
      Sounds like you are getting it all worked out.
    • Jan 19 2012 | 11:43 pm
      I thought I had it licked last night, until I noticed it would hiccup every now and again. Tracking that down got me onto the %~ problem, which I've been stuck on.
    • Jan 20 2012 | 4:05 am
      I will take a look as soon as I get a chance. Busy with some other right now.