hi all,
Thinking aloud ....
I'm wondering if any one who is already using accelerometers in their
max patches would be willing to share what kinds of ways they are
using the data, and how they go about making it useful.
I've started thinking about this more as I've just bought a Wii
remote. Although you can get linear position data using IR (I've only
tried it with candles so far!), the easiest stuff to get from the
remote is acceleration data and switches.
One of the main ways that I use controller data is to control the
position of the grain playback head in a buffer, and the pitch/speed
of playback. Although I'm thinking of other interesting things that
can be done with acceleration, I still want to be able to control
buffer position, and I think that this is the biggest challenge in
using accelerometers - somehow converting acceleration, which always
tends to rapidly return to zero, into some kind of linear/positional
data. (I'm thinking handheld here - obviously if you have the sensor
mounted on something which rotates (like a bike wheel) or
continuously moves in some other fashion this is not such an issue,
but what I want is to use handheld sensors).
My suspicion is that accelerometer output is by definition unusable
for something like linearly moving a playback position - but I'd love
to be proved wrong! I suppose moving the sensor in a circle, faster
or slower, would be one way to do this - you'd need strong arm
muscles though. Hm - thinking about this - the acceleration in any
one axis would still be constantly changing, so maybe that isn't the
solution.
So far 2 ways of interpreting the data have occurred to me:
1. Linear(ish) - apply the accel data directly to a parameter;
alternatively scale, reverse, or map it (eg with [table]). I think
I'm calling this the "weeow" option, as that's the main result of
using the data like this - you get a fairly rapid change as you move,
and then there's always a return to a zero point as the movement
stops. Offsetting, scaling and mapping just changes the shape of the
weeow (weeeoooeeoooeeow? oweewweeewoeeweweo? )
One interesting visual analogue of this is that effect where you
create a kind of a virtual screen for a projected image by rapidly
waving a thin wand up and down in the air through which the image is
being projected. (tiring).
2. Thresholds - more rapid movements fire off different events (delay
times, effects settings, configurations etc etc). Though as you have
to pass through lower thresholds to get to the higher ones (your arm
doesn't instantly jump from one speed to another - at least, my
doesn't!), there'd need to be some way of detecting the peak point of
a movement unless you actually want all of the settings from zero to
the current peak of a movement.
One way I'd thought of using this is to direct the threshold triggers
to a randomised playback position value so that bigger, faster
movements cause more randomisation of playback. Doing something like
this with 2dwave~ and munger~ might also produce something interesting.
Anyway, that's as far as I've gotten with this. What thoughts/
suggestions do others have about using this kind of sensor?
thanks
David
