<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 class=""><br>
On Apr 13, 2016, at 12:20 PM, Neil Johnson <<a href="mailto:neil.johnson71@gmail.com">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 class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>