Removing / limiting accelerometer data when wrapping around from max to min
Hi
I'm converting the accelerometer data from a microbit to MIDI CC# values in max, but need to limit the data once it reaches the maximum rotation, rather than it jumping back to minimum (and vice versa).
As the numbers are not always sequential, the change is not always from 127 to 0, but can be an arbitrary high value to an arbitray low one.
Detecting a large jump is quite simple, but the following values will be almost sequential but still beyond max rotation.
Any ideas?
(patch imitating approximate output attached)
Thanks
Wrong patch!
here you go...
The solution I came up with when I was working on this type of devices, was through [accum] : as long as/if incoming acceleration data is positive, you accumulate +1 values from 0 to 127, and -1 values from 127 to 0 when it is negative. You can also add an adjustable threshold to filter out deltas between 2 consecutive incoming values when they are too small, in order to control the slider's up/down speed.
Drawback is that the speed is steady (the only piece of information captured is the direction of rotation)., which is a bit contradictory with the idea of an accelerometer !
I'm sure smarter and more accurate options exist, but this is the only simple and workable one I have been able to imagine !
You would as first tame output at sender side, to
adapt to your needs, for midi 0 - 127 it should be simple.
for exmple set accel to send -100 – 100 range,
and only if value changed more than set threshod.
you can calculate delta to step up or down from current CC value,
limit 0 - 127 is no big deal, or ?
The problem (as I faced it) is : say you move the accelerometer in one direction => acceleration increases between 0 and 100, and the slider starts moving accordingly. When it reaches 80, for instance, you stop moving the accelerometer. What you want is that the slider stops moving as well. But as the acceleration rate suddenly goes to 0, then the slider abruptly moves down to 0 at the same time, as well !
Hi
Thanks for responding both of you.
Sébastien: I probably wasn't clear enough. I'm not actually reading acceleration, but the rotation (angle?) of "roll" and "pitch" (left-right and forwards-backwards):
Source Audio: Because I am having another issue (which seems to be some weirdness with the microbit - I've tried two microbits and they behave the same), as soon as you reach near the end of one axis' range the other axis jumps to max or min, so filtering out the extremes just causes this glitch but with a narrower useable range:
I've tried limiting the range in the above makecode image from say -90 to 90, but that predictably just gives the same issue, but sooner.
Both: You are onto something - if I am measuring delta, rather than absolute values, I may be able to avoid the glitch as well, by then filtering out larger jumps when measuring delta.
Source Audio: Ideally I want as much range as possible - but that means doing the serial>MIDI conversion Max side (which was my original plan) however I need to then do some ASCII filtering (as that is what the microbit sends over serial) and I was hoping to avoid going down that rabbithole (again) as I was finally getting something mostly useable out of these rubbish little devices we have where I teach.
Both: I'll have a go at measuring the change rather than absolutes and see how I get on.
Thanks
Source Audio:
Also tried this:
But the cross-axis glitch is still an issue.
if that cross-axis glitches don't happen when sending raw data
over serial, then mistake must be in the code that does the conversion
to midi.
I know nothing about that microbit devices, how do you program them ?
and ... is it making sense to use output as absolute values,
instead of mesuring delta to get rotary encoder kind of up/down control ?
No time to fine-tune, but, starting with your original patch, here is a rough idea of what I was referring to in my initial post :
NB : I 'm very interested in this thread. I spent a lot of time trying to get these types of electronic gyroscopes to work. I gave up : it seems straightforward at first, but, by nature, these sensors tend to shift and drift, and it requires lots of physics and coding knowledge I dont't have to make them work properly from scratch.
Alternatively, where possible, I now use my smartphone with free apps like MultiSense OSC. Smartphones contain the same devices, but also the massive engineering working-time, that is necessary to have them generating reliable and reproducible data !
example for accelerator -100 ~ 100 to midi using delta.