thetechnobear

Ive got a device which sends out pressure data (range 0..4095), but I want to convert this to velocity (for using on midi note).

I wandered if anyone here had done anything similar, that had worked well.

the obvious solution is to use dX/dT but Im wandering if this is really how midi devices (say keyboards work)

my current solution, is to take N samples of the pressure, and to average the pressures over N (sample rate should be constant time), I also exclude drops in pressure. - but Im not really happy with this (doesnt feel right)

my problem is really, about thinking about examples, and what the user expects.

e.g. if we use 5 samples, is really the velocity the same?

of course then we get 'oddities', where pressure is backed off

so is it really best to go for the max value over time t, and then use max(P)/t, or an average?

I also want to create negative velocity for key release, which I will use the same strategy.

Im also planning resultant pressure thru a velocity curve, to allow some configurability

Thanks for any help, or pointers to appropriate info

hi,
Ive got a device which sends out pressure data (range 0..4095), but I want to convert this to velocity (for using on midi note).

my problem is really, about thinking about examples, and what the user expects.
e.g. if we use 5 samples, is really the velocity the same?
0, 1, 1, 4095,4095
0, 1024,2048,3192,4095

of course then we get 'oddities', where pressure is backed off
e.g.
0,1024,2048,4095,3800
0,4095,4095,4095,3800

I also want to create negative velocity for key release, which I will use the same strategy.
Im also planning resultant pressure thru a velocity curve, to allow some configurability 

Thanks for any help, or pointers to appropriate info
Mark


pressure-to-midi-velocity

you may well have already got this far, but this is how I assess dynamic force (aftertouch) and quasi-instantaneous velocity. There is of course a trade-off between averaging and latency and sensitivity. If you're ultimately scaling down to 0-127 I suppose this is less of a concern.

As for the "noise" - differentiating between intentional and non-intentional release velocities - I guess you may have to do some further averaging. HTH

ps, the [pow], [expr], [curve~] and [itable] objects allow for non-linear mappings.

Hi
you may well have already got this far, but this is how I assess dynamic force (aftertouch) and quasi-instantaneous velocity. There is of course a trade-off between averaging and latency and sensitivity. If you're ultimately scaling down to 0-127 I suppose this is less of a concern.

ps, the [pow], [expr], [curve~] and [itable] objects allow for non-linear mappings.


so this patch works on the difference between the value at t and t+50ms.

This has the slight issue with, only if you pressed a key really quickly (expect hi velocity), but as you say unintentionally release slightly. Advantage you have though, is you do have an upper limit for the velocity (the issue I have with my approach of averaging values over time)

I think I possibly am guilty of over-thinking this though, as the time frame is pretty small, so perhaps a simple approach with a velocity curve will be fine (the curve would smooth out the unintentional releases I think)

One thing, Im doing this in the external currently Im wondering if it might be an idea to put in Max, I was concerned about efficiency but Im finding Max is pretty quick at these sorts of things.

Thanks,
so this patch works on the difference between the value at t and t+50ms.
This has the slight issue with, only if you pressed a key really quickly (expect hi velocity), but as you say unintentionally release slightly. Advantage you have though, is you do have an upper limit for the velocity (the issue I have with my approach of averaging values over time)
I think I possibly am guilty of over-thinking this though, as the time frame is pretty small, so perhaps a simple approach with a velocity curve will be fine (the curve would smooth out the unintentional releases I think)

pressure to midi velocity