<div dir="ltr"><span style="font-size:12.8px">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.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">easy enough to fix in software with a LUT though :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 April 2016 at 19:47, Mattias Rickardsson <span dir="ltr"><<a href="mailto:mr@analogue.org" target="_blank">mr@analogue.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Amos,</p>
<p dir="ltr">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: <br>
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.</p>
<p dir="ltr">These factors add up to a noticeable difference, and having separate velocity scalings for black and white keys seems like a good idea. :-)</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">/mr<br>
</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">Den 24 apr. 2016 7:04 em skrev "Amos" <<a href="mailto:controlvoltage@gmail.com" target="_blank">controlvoltage@gmail.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.  <div><br></div><div>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...</div><div><br></div><div>-Amos</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 9:24 PM,  <span dir="ltr"><<a href="mailto:rsdio@audiobanshee.com" target="_blank">rsdio@audiobanshee.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On Apr 13, 2016, at 12:20 PM, Neil Johnson <<a href="mailto:neil.johnson71@gmail.com" target="_blank">neil.johnson71@gmail.com</a>> wrote:<br>
> I wrote:<br>
><br>
>> About 7 years ago when I was writing the keyboard scanning code for a<br>
>> Siel Opera 6 I had a simple scheme for scanning and measuring play and<br>
>> release velocity (not many folks seem to know about release velocity<br>
>> although some synthesizers do recognise it).<br>
>><br>
>> Using an Atmel ATMega8 scanning the entire keyboard every 1ms I run<br>
>> 4-state state machine for each key, where the states are UP,<br>
>> GOINGDOWN, DOWN, GOINGUP, and an 8-bit counter for each key.<br>
>> Debouncing is handled by the algorithm rather than a separate<br>
>> debouncing step.  With the right encoding of the states you can do<br>
>> most of the testing and state transitions using btiwise operations, 8<br>
>> keys at a time (on a 32-bit processor you could do 32 keys at a time).<br>
>><br>
>> I'll try and dig out the code and sling it up on github sometime.<br>
>> It's all in C, no assembler required.<br>
><br>
> Found it, and hosted up on github:<br>
><br>
> <a href="https://github.com/nejohnson/kbdscan" rel="noreferrer" target="_blank">https://github.com/nejohnson/kbdscan</a><br>
><br>
> The keyboard scanner talks to a 74LS154 on the keyboard assembly, and<br>
> generates key on and off events with associated velocities.  There's<br>
> also code for reading some analogue inputs and a footswitch, but<br>
> that's not important right now.<br>
<br>
</span>Thanks for sharing this!<br>
<br>
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)<br>
<br>
Brian<br>
<div><div><br>
_______________________________________________<br>
Synth-diy mailing list<br>
<a href="mailto:Synth-diy@dropmix.xs4all.nl" target="_blank">Synth-diy@dropmix.xs4all.nl</a><br>
<a href="http://dropmix.xs4all.nl/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://dropmix.xs4all.nl/mailman/listinfo/synth-diy</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Synth-diy mailing list<br>
<a href="mailto:Synth-diy@dropmix.xs4all.nl" target="_blank">Synth-diy@dropmix.xs4all.nl</a><br>
<a href="http://dropmix.xs4all.nl/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://dropmix.xs4all.nl/mailman/listinfo/synth-diy</a><br>
<br></blockquote></div>
</div></div><br>_______________________________________________<br>
Synth-diy mailing list<br>
<a href="mailto:Synth-diy@dropmix.xs4all.nl">Synth-diy@dropmix.xs4all.nl</a><br>
<a href="http://dropmix.xs4all.nl/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://dropmix.xs4all.nl/mailman/listinfo/synth-diy</a><br>
<br></blockquote></div><br></div>