Scrub an audio loop with an Arc in Max/MSP?

Is there any example around about how to use an Arc knob as a “turntable” emulator ?
Thanks !


Neither is quite a turntable emulation, but you could look at Pear which I wrote, or capstarc by mhetrick which it’s based on. Both use arc to scrub through an audio buffer.


Thanks for the input. Both are nice, but I’m really looking into a turntable way of scrubbing.
I can’t figure a nice way to get the arc’s knob “speed” when you manually turn it, to translate this into a sig~ value to drive a [groove~] object.

1 Like

In Pear I use [route /monome/enc/delta] → [p accum] → [line~] to control a [groove~] (inside [p ring0] and [p ring3]). You can toggle timestretching on and off. I was thinking more of tape scrubbing like Landscape HC-TT as a metaphor so I think I’m not clear on how that would contrast with a turntable metaphor. If you want normal playback when the arc isn’t moving I think you could just add [+ 1.] to the arc speed before [groove~] and get rid of the thing turning off the audio when arc is still.

As far as I know, delta is the way to get speed from arc, but I’d be curious to hear if there’s another way because it’s hard to get much resolution at low speeds that way.


I missed this, it looks like it could be what I’m after.
Thanks you !

1 Like

Not a huge amount to add, but slide~ (or something ease~) on your control signal might give you more of a motor style response.


I just got back on this project, and I’d love some help. I seem to have no luck on the Max forums, so I hope you don’t mind if I post here.

No Arc is involved. I’m currently working on an interactive installation where (amongst other things) a turnstile is equipped with a position sensor, outputting the absolute position (angle) in 360 steps.
Was wondering if it could be used as a “vinyl deck”. The principle is to detect the “instant speed” and use this to drive a [groove~] object.
Here’s a basic patch, roughly working. I’d love to have your thoughts and advices.
Vinyl_Player 2.00.maxpat (48.2 KB)


One thought is that you could use longer slide~ values to give a slower motor response feel to it. Could also drive the rotation from that - to visualise the slowdown:

Vinyl_Player 2.00 alt.maxpat (49.7 KB)

Depends on your application i guess : )

That’s cool, thanks a lot for taking a look.
Damn, I just realized that [slide~]'s ramp times are expressed in samples and not in ms, that’s much better ! And it avoids the clicks when the turntable stops. Thank you for this !

Any idea what causes the vibrato effect ? It’s a bit lo-fi, that could be ok. But I noticed that leaving it playing a long time, it can sort of amplify and go super heavily pitch modulated.

Also, I think there is a proportional relation to be found between the file length and the rate of the [metro], that could allow, if you keep the turntable spinning at a constant speed, to have different files to be loaded with the same amount of pitch shift.

Any idea what would be this proportional relation ? Do you get what I’m talking about ?

Also, @_mark : the actual rotation, in the end, will be produced by a real-world turnstile. The best way to test the patch, in my opinion and in this regard, is to switch to “manual” and move the dial by hand.

Ah yes - makes sense now.

Yeah I hear what i think you mean as the vibrato. It’s coming (I think) from the slight change in the signal every time it loops round. But perhaps it will not be noticeable when you have it connected to the turnstile - which will always be changing speed anyway.

I think I understand, perhaps… but I’m not sure why it matters if you are using groove~ as it just needs a signal for speed. If you can derive that from your turnstile, then it should just play any sound file at that speed regardless of length, no?

I thought I fixed this with the [abs.0] [<0.5] [change] [sel 1] part of the patch. It replaces value jumps by the previous value.

I need to wrap my head around this. It’s one of these situations where I cannot precisely tell what I want…which always is a bad sign.
I guess it’s not bad as it is. And this [*~10] at the bottom… not proud of it…

I think just the amount it shifts around is enough to affect the pitch enough to perceive it as the vibrato you mention, eg:


Tbh it’s probably good enough to just wait until you can hook it up to the sensor. No doubt that will throw up some stuff to fix anyway!

1 Like

Yeah maybe. Meanwhile, I found that reducing the “time grain” of the [line] has a positive effect on the vibrato.
Thanks for the help !

EDIT : found it ! The culprit is in the [p rotate]. change [snapshot 5] to [snapshot 1] improves the vibrato a lot. Another vote for “wait to hook it up to the actual sensor”.


I think that’s generally what I did here:

…but I can’t check. (I’m pretty sure the source code only exists on the old monome forum at this point, and I’m not sure how to convert the url anymore.)

(The twist with mine was that I was also simulating friction and gravity, by inserting generated deltas into the stream at random intervals, but you don’t need that with a manual turnstile. You’ve got actual physics!)

Same code should work, but you have to replace that first object.

Calculating your own deltas is mostly a matter of subtracting the current reading from the previous one (and then probably multiplying the result by -1, to orient it as expected).

The simplest way to do that is a bit harder to describe in text. It’s essentially:
[t f f] → [- 0.]
…but the left outlet of [t f f] goes to the right inlet, and the right outlet goes to tbe left inlet.

The missing step at this point is to handle the wraparound from 360 to 0 and back. And the easiest way to handle THAT is to run your deltas (after the [accum] but before the [line~] through something like [split -359. 359.] (Adjusting your range as needed)

That simply examines each delta and discards any movement that looks like a full rotation in either direction.

(It’s probably better to limit the range even more. Depending how often you check the sensor, it probably shouldn’t have gone half of that distance, after all.)

If you like, you can process the right outlet of split (subtracting a full rotation from the result to produce what should be a correct delta), but that’s more complicated if the turntable is bidirectional, and really, your [line~] object already covers you if a frame is skipped.

It looks like you essentially did all that with this, but I’m not sure I trust it:

And then…

Is that controlling how often you poll the turnstile sensor? (Checking that to generate your deltas more often will have a huge effect on precision)


Entirely off topic, but it kills me that this thing can’t detect which direction you’re spinning:

(I think it would mean rewiring the humbucker somehow to take readings from the individual magnets.)

1 Like

I’ve used [bucket], I think it does the same thing doesn’t it ?

My approach was to check if the delta is too big (which happens on the wraparound point), and if so, instead send the previous delta.
As stated before, this will be handled by a real turnstile, with people spinning on it, so, the [accum] logic doesn’t work here. In contrast with the Arc, if someone spins the actual wheel the other way round, it doesn’t slow down, it almost instantly plays in the opposite direction.

Actually it’s how I poll the sensor simulator. I am not yet able to work with the actual sensor (someone else is building the stuff). But yeah, absolutely, I need a high “sampling” rate of the sensor.

Hope that everything I write here makes sense, you guys are much better at programming than I am !

Ah ! That’s a shame to overlook this !


That actually would need the simulated physics I was talking about, or else each forward movement would make the sound faster and faster, and walking away would leave it playing at the same speed indefinitely.

I guess for testing the logic of any solution, we could use something like Artiphon Orba (letting the 8 notes each represent 22.5 degrees of movement). It’s pretty low-res, though.

(And that brings us back to arc. I’m caught up now.)

How are you developing this so far?

I’m gonna use up this little thing (a 360° potentiometer and a 3D printed plate) and an arduino. That should be very close to the real thing.

1 Like

Interesting discovery about the vibrato effect :
On my computer at least, I noticed that if I bang the polling of the “sensor” every 81ms instead of 82ms, the vibrato seems to be gone. There must be some “flutter” between this polling and something else…maybe the vector size of Max/MSP ? …
That could explain why I witnessed this vibrato growing and growing slowly but surely.
Maybe introducing a bit of randomness in the polling speed could be a solution.
Does anyone understand why this happens ? Seems like a “resonance” effect to me with some settings.

1 Like