[sdiy] MIDI velocity

rburnett at richieburnett.co.uk rburnett at richieburnett.co.uk
Sun Apr 10 13:05:07 CEST 2016


Thanks for sharing the details Paul.

I've got my PIC working properly as a non-velocity sensitive keyboard at 
the moment, just scanning the lower contacts.  There's a software timer 
for each key but they're just being used to debounce the key-up 
transitions at the moment.  No aftertouch strip on my keybed, but the 
scanner PIC also reads the pitchbend and mod wheels.

-Richie,

On 2016-04-10 10:23, P Maddox wrote:
> for 002/001/008 we read all the switches, we never stop reading them
> for anything (that'd be suicide for latency).
> when the first switch is made a timer is reset, when the second switch
> (of the same key) is made the timer is stopped.
> It's important to note there is a timer for each key, not just one,
> this timer is incremented at a regular interval.
> This timer value is passed through a look up table and sent as a note
> on with the velocity.
> 
> The lookup table allows us to 'tailor' the feel of the response so we
> can get a good feel, believe it or not a straight linear response is
> horrible to play expressively.
> 
> I can't remember the timing off by hand, but if you do it too slow you
> loose resolution, do it too quick and your wasting time because you
> only need 7 bits of resolution.
> 
> our keyscanner also reads the aftertouch, that also has a lookup table
> as the response from the FSR is just horrible!
> 
> On 9 April 2016 at 23:08, <rsdio at audiobanshee.com> wrote:
> 
>> On Apr 6, 2016, at 4:20 PM, Hugh Blemings <hugh at blemings.org>
>> wrote:
>>> OnSo I did a bit of poking at a KX-76 a little while back and
>> wrote about it here
>> http://hugh.blemings.id.au/2015/09/26/keyboard-tinkering/ [1]
>>> 
>>> It uses the main MCU for scanning, about 1kHz update rate and
>> appeared to adopt the stop scanning until key closure detected
>> approach discussed elsewhere in the thread.
>> 
>> I've been thinking about this every since it was discussed, and I
>> don't see how it would work for a polyphonic keyboard scanner.
>> 
>> One the one hand, if all you need is monophonic operation, then
>> there's no drawback to stopping the scanning as soon as any key
>> starts. That would simply be first-note priority. You wouldn't be
>> able to implement last-note priority, though.
>> 
>> The problem with stopping the scanning is this: How do you know
>> that another key won't trip its first switch contact while you have
>> the scanning stopped to measure the timing from the earlier key
>> press?
>> 
>> Having looked at the JU-1, where the whole key matrix is scanned on
>> each 4 ms timer event, I can see how it might appear that the
>> scanning is stopping and starting, but I'd like to see more details
>> from any synth design where someone believes that velocity sensing
>> is actually implemented by stopping the scan every time a new note
>> is detected.
>> 
>> Thanks for the writeup. Fairly interesting. If you have any more
>> timing measurements in your notes, it might be worth a followup with
>> more details.
>> 
>> Brian Willoughby
>> Sound Consulting
>> 
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy [2]
> 
> 
> 
> Links:
> ------
> [1] http://hugh.blemings.id.au/2015/09/26/keyboard-tinkering/
> [2] 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




More information about the Synth-diy mailing list