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

Jan 15, 2012 at 1:47am

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

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).

#61247
Jan 15, 2012 at 2:18am

Yeah so it would play from 900 to 1000, then 0 to 100, then back to 900.

#220767
Jan 15, 2012 at 6:18am

is this what your looking for? open file, then set position/length.

Attachments:
  1. PosLeng.maxhelp
#220768
Jan 15, 2012 at 8:11pm

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)?

#220769
Jan 15, 2012 at 9:41pm

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.

Attachments:
  1. PosLeng2.maxhelp
#220770
Jan 15, 2012 at 11:04pm

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.

#220771
Jan 16, 2012 at 1:52am

I think what you are looking for can be found here.
http://www.youtube.com/user/MUST1002
Look through tutorials 9 on grains.

#220772
Jan 16, 2012 at 8:58am

Ooh those look great. I hadn’t come across this guy’s videos before.

#220773
Jan 16, 2012 at 9:33pm

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.

#220774
Jan 16, 2012 at 9:54pm

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?

Patch:

– Pasted Max Patch, click to expand. –
#220775
Jan 16, 2012 at 10:00pm

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 +~/%~.

#220776
Jan 17, 2012 at 4:40am

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?

#220777
Jan 17, 2012 at 8:45am

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?

#220778
Jan 17, 2012 at 10:47am

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.

#220779
Jan 17, 2012 at 10:04pm

I think the solution is to treat continuous audio as “instances”. That way you can envelope each instance.

#220780
Jan 17, 2012 at 10:27pm

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.

#220781
Jan 18, 2012 at 8:21pm

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.

#220782
Jan 18, 2012 at 8:30pm

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.

#220783
Jan 18, 2012 at 8:56pm

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)

#220784
Jan 18, 2012 at 11:28pm

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.

– Pasted Max Patch, click to expand. –

And the poly named “grain~” based on sugarsynth

– Pasted Max Patch, click to expand. –
#220785
Jan 18, 2012 at 11:35pm

Yup, this is better.

Replace the contents of [p scrub] with this:

– Pasted Max Patch, click to expand. –
#220786
Jan 19, 2012 at 2:03pm

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.

#220787
Jan 19, 2012 at 11:35pm

Sounds like you are getting it all worked out.

#220788
Jan 19, 2012 at 11:43pm

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.

#220789
Jan 20, 2012 at 4:05am

I will take a look as soon as I get a chance. Busy with some other right now.

#220790

You must be logged in to reply to this topic.