[sdiy] MIDI velocity

[Tom Wiltshire]

I can't say I've particularly noticed with MIDI keyboards, but I've had the effect on acoustic pianos. Black notes play louder for the same effort. My understanding was that better players than I adjust their technique to account for the difference.

But I agree - different curves is much easier, especially for rubbish players like me!

On 24 Apr 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. :-)
> 
> /mr
> 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 this...
> 
> -Amos
> 
> 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> wrote:
> > 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)
> 
> Brian
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy