Absolute position of arc (& weird jumpy values? (bug?))

[Rodrigo]

So in working on some arc turntable 3d printed funny business (thread) I was trying to figure out a way to get absolute position out of the arc. I figured this should be possible with fairly high accuracy since it is spitting out delta values in any given direction.

In a conversation with @tehn years ago I do vaguely remember him mentioning something about acceleration, so don’t know if that happens internally, or if that was something that he (or others) implemented on the computer-side of things, but that may screw around with absolute position stuff.

So first, has anyone does this in Max-land, or know if apps that do this? (I’m thinking using accum or something, just to keep track of a value between 0-1023 and scaling that to 0-1, but wasn’t sure about the acceleration thing.

In addition to that I noticed something that seems buggy or glitchy

I’ve made a video showing what I mean:

jittery delta values from an arc4

Basically, when moving quickly and consistently on an arc4, I get high delta values (13/14/15) that are interspersed with low delta values (1/2), creating this jittery spiky output which I had to smooth for the turntable demo video I made.

I compared it to my older arc2 and I don’t get values like that out of it, so wondering if this is normal for newer arcs or if something else is going on.

[ellips_s]

I occasionally see those spikes in high delta values with my arc (from the very first run of the most recent edition back in 2016?).

There a couple of Stretta abstractions hiding within some of the Beap objects named [bp.arc.accum-1] and [bp.arc.accum-2] which do exactly this using [accum]. i often use the second one either in tandem with [jit.arc.knob] which utilizes some jitter matrix trickery and values ranging from 0-499, or a clamp it to any arbitrary value and roll my own list or jitter matrix visualization.

I’ll often use those abstractions as a jumping off point for quick behavioral changes, such as reversing rotation or wrapping values with modulo.

[Rodrigo]

I was able to whip something up with accum quite easily and get accurate absolute position. Surprisingly even with the jittery output of the arc4.

Mine is from that era I think, so I wonder if it’s a firmware thing or something.

[ellips_s]

in my experience the delta jitter can be tolerable within a sufficiently wide data range. usually i opt for 500 or larger depending on context but even midi style 0-127 can be fine. smoothing can be helpful in certain situations of course, but i’ve largely not needed it in various max projects or dabbling in c/ansible

i’ve never used another arc model tho so i don’t have a baseline to compare to

[tehn]

whoooa sorry for the delay.

those spikes are super wrong. do they happen with every single knob? or just one?

if just one, the optical disk might be messed up somehow— easily cleaned after inspection if you disassemble.

if it’s all of them, then mind-blown and i’ll have to investigate further.

[Rodrigo]

No worries.

Ok, double-checked with all the knobs and it appears that it’s happening with all of them:

Video:

arc4 jitter (all encoders)

So it’s jittery across all of them, and on one of them (enc3 in this case) there were bigger gaps in the large numbers, where I’m turning the knob quickly and consistently but only get values of 1-2 as the output (towards the end of the video).

If I move at a much slower pace the numbers don’t seem so erratic, and you can kind of see in the multisliders at the start of the video, at at the right-most extreme of them is more “normal” looking output (n.b. the multislider range is -20 to 20 here).

[zebra]

… is that actually weird?

what it looks like to me is that there are a bunch of normal-looking delta reads with zeros or near-zeros in between.

if the deltas are being polled very very fast, this makes total sense. i’m assuming that’s the case (but @tehn, confirm/deny?)… i would then further assume that later revision polls faster so there are more zeros.

further i’d hypthesize that there’s an interrupt-driven accumulator whose output is then polled. when you’re turning faster, there is a tendency for bigger changes to accumulate between reads.

so you would want a sliding mean filter on this output, with a window size appropriate to the actual gestural rate you’re interested in. without that, i’m not sure it’s easy to say whether the values are plausible or not. (actually, just a partitioned total/mean would also do it i guess, but would be less responsive.)

[Rodrigo]

Yeah, it wasn’t until I compared to my older arc2 that it started getting me thinking. When I filter the output it’s nice and smooth, and if I run it ‘as is’ into an accumulator, the output is just fine too.

There does appear to be something, at minimum, “wrong” with my 4th encoder though, where even when moving it, there are long periods of little to no output (as you can even see in the screenshot).

[tehn]

the thing is, there shouldn’t be zeros… because the arc doesn’t bother sending a 0 delta. deltas should be smooth increase and decrease.

let me double-check with hardware here what to confirm what i think i’m supposed to see.

just to say— this looks like some sort of data corruption

[tehn]

checked macos and on norns, i am astounded at this datastream.

i’ll have to debug on the firmware and try to do some forensics. this definitely wouldn’t have been ship-worthy, some i’m wondering what happened.

will follow up.

[Rodrigo]

To be clear, even though the multislider looks like it, there are never zeros being sent. The lowest values I get a re 1 and -1, though it does get jumpy and weird as shown elsewhere.

I have a couple other computers handy which I can test things on, so let me know if there’s something I can do on my end to help spelunk.

(this is MacOS 10.14.6 using Max 8.1.5 with the BEAP-bundled version of serialosc)