[sdiy] MIDI velocity
yo at vacoloco.net
Sun Apr 24 23:06:21 CEST 2016
yeah, I figured it was related to the length of the key.. the white key
when you hit it on the edge has further to travel.. so the same velocity
results in a slower switch action.
easy enough to fix in software with a LUT though :)
On 24 April 2016 at 19:47, Mattias Rickardsson <mr at analogue.org> wrote:
> Hi Amos,
> I've experienced it too, and I guess it's due to simple geometry and
> mechanics. Hitting a black key gives it a higher angular velocity than a
> white key gets when hit with the same force - for two reasons even:
> You probably hit the white key at a further distance from the pivot point
> *and* the white key has a higher weight and a higher moment if inertia.
> These factors add up to a noticeable difference, and having separate
> velocity scalings for black and white keys seems like a good idea. :-)
> Den 24 apr. 2016 7:04 em skrev "Amos" <controlvoltage at gmail.com>:
>> I'm curious to hear if others have noted significantly different switch
>> timing (relative to actual played velocity) for black keys versus white
>> keys, on those Fatar keybeds.
>> My experience is that the black keys seem "hotter" than the white keys,
>> enough that I have to use separate curves for black versus white to get
>> consistent-feeling MIDI velocity output. I chalked it up to geometry and
>> physics and went about my way, but I didn't notice any similar comments so
>> far in this thread so I thought I'd ask if it was just me experiencing
>> On Wed, Apr 13, 2016 at 9:24 PM, <rsdio at audiobanshee.com> wrote:
>>> On Apr 13, 2016, at 12:20 PM, Neil Johnson <neil.johnson71 at gmail.com>
>>> > I wrote:
>>> >> About 7 years ago when I was writing the keyboard scanning code for a
>>> >> Siel Opera 6 I had a simple scheme for scanning and measuring play and
>>> >> release velocity (not many folks seem to know about release velocity
>>> >> although some synthesizers do recognise it).
>>> >> Using an Atmel ATMega8 scanning the entire keyboard every 1ms I run
>>> >> 4-state state machine for each key, where the states are UP,
>>> >> GOINGDOWN, DOWN, GOINGUP, and an 8-bit counter for each key.
>>> >> Debouncing is handled by the algorithm rather than a separate
>>> >> debouncing step. With the right encoding of the states you can do
>>> >> most of the testing and state transitions using btiwise operations, 8
>>> >> keys at a time (on a 32-bit processor you could do 32 keys at a time).
>>> >> I'll try and dig out the code and sling it up on github sometime.
>>> >> It's all in C, no assembler required.
>>> > Found it, and hosted up on github:
>>> > https://github.com/nejohnson/kbdscan
>>> > The keyboard scanner talks to a 74LS154 on the keyboard assembly, and
>>> > generates key on and off events with associated velocities. There's
>>> > also code for reading some analogue inputs and a footswitch, but
>>> > that's not important right now.
>>> Thanks for sharing this!
>>> I was going to suggest that having the 'LS154 on the keyboard assembly
>>> is a great design choice, because that allows a simple, 14-pin connector,
>>> but then I realized you probably were stuck with that choice because of how
>>> the Siel Opera 6 was designed. Sure enough, looking at the schematic I see
>>> 8 row bits, 4 column address bits, power and ground. (feel free to swap the
>>> row and column nomenclature as you prefer - Roland seems to use the
>>> opposite terms)
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
> Synth-diy mailing list
> Synth-diy at synth-diy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Synth-diy