[sdiy] MIDI velocity
sleepy_dog at gmx.de
sleepy_dog at gmx.de
Tue Apr 5 20:02:39 CEST 2016
I wondered about this "scanning all the keys all the time".
I'm only familar with stm32 platform (Also cheap! you could even get an
stmf100 in a 144pin LQFP package for about 4,- EUR and do this even
without any muxing matrix stuff or whatever way this is done with such
keyboards :-D ),
and there, I'd have, say, 8 ports of 16 pins each which are enough for
So 4 ports are for all first-switches on all keys, 4 ports are for the
So you might do 8 ports reads, taking 2 cycles each I think, @ 24MHz.
Doing this in a timer interrupt at 8kHz seems feasible.
Each of the 61 keys has a maybe 16bit counter.
24 MHz / 8000 Hz = 3000 cycles for all this stuff, I think 2 cycles x 8
ports, + some checking logic which ports are not all zero and then
looking in more detail at the bits of those which aren't, + (worst
case) 61 conditional increments fit well in those 3000 cycles. You might
even be able to display stuff on an LCD or so with that same processor.
If that 144pin beast is unwieldy, 3x 48pin LQFP stm32f030 for 0.8 €
each, each scanning 1/3 of the keys, one being master and joining all
the MIDI event streams to one, might do?
Or maybe I'm talking nonsense because one can't access all the keyboard
lines that way and one really has to use some kind of muxing logic?
I faintly remember somethig like that with the Fatar synth action keybed
I have lying around... Alas I did not have time yet to build the
monstrous MIDI controller I envision, but am glad to have bought this
before Doepfer apparently stopped selling them... SO who says buying
stuff you don't need right now has to be bad... :-D
Oh, on a tangent again...
Am 05.04.2016 um 18:47 schrieb Ingo Debus:
>> Am 05.04.2016 um 13:43 schrieb Richie Burnett <rburnett at richieburnett.co.uk>:
>> Is it reasonable to expect that I could use a low-end micro (e.g. PIC) to
>> scan a 61-key Fatar velocity sensitive keyboard with sufficient velocity
>> resolution to work well?
> Maybe there’s a smarter way than scanning the whole keyboard all the time? For instance, in wait-for-key mode all the keys are in parallel, so when one key is pressed, the processor can react very quickly (thus measure the time very exactly), without knowing at first which key it was. Then, while the key is travelling, the keyboard is scanned to find the key. Then the processor waits until the key hits its final position and measures the time again.
> It would also be less noisy, because the keyboard is only scanned when a key actually is pressed.
> Some problems might arise, what happens when a key is pressed while another one is on its way?
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
More information about the Synth-diy