Music Keyboard matrix scanning

Status
Not open for further replies.

NotoYota

Member
As discussed in another thread I have this M-audio oxygen 8 midi keyboard (25 Keys).
I couldn't get it to work entirely and some parts were non functional. So, I decided to gut the electronics and replace them with my Teensy project instead.
Now I would like to get the keyboard itself working.
So there is this flatcable to the keyboardmatrix which I have to reverse engineer.
But in general I was wondering: is there any reason why one would prefer a hc138 3 to 8 decoder over a multiplexer like a 4051?
Would it be possible to "drive" the columns directly from Teensy pins and "read" the rows using a 4051?
Because: 4051 I have a lot of.
 
I see no reason why you wouldn’t be able to do it like that, it may even be advantageous to have a separate Teensy LC dedicated to decoding the keyboard matrix and outputting it as MIDI to the main Teensy. I’ve found that keyboards usually do this type of thing even when the keyboard doesn’t have MIDI ports so as to cut down the processing time it would take on the main processor. If you do end up doing it that way you can do away with the 4051’s and wire the matrix straight to the Teensy for best results.
 
Thanks.
So there is really no reason why a hc138 is preferable?
I was even thinking of driving the columns using a counter like the 4022. Because there really is no reason to address the columns in random order when scanning a matrix I would say.
So that would be 3 pins to address the 4051 inputs and 1 pin to advance the column counter.
4 pins for an 8x8 matrix... I think that's pretty efficient.
Or even using a 4017 for the columns would give a 10x8 matrix.

Am I missing something obvious apart for the limitation that columns have to be scanned sequential this way?
 
It can be scanned in any order you want it to, it would normally just be in sequential order if you read it using a loop as opposed to calling every single position individually.
 
The keyboard will most probably have a Fatar pinout, check this link out for further info: http://www.doepfer.de/DIY/MKE_keyboards.htm

In case it is not a Fatar pinout, it will most probably be a very, very similar one, so the schematics in the previous link should help you.

A disadvantage would be that, in such keyboards, there's 2 buttons per key, and you calculate the time between the first and second button were pressed to calculate the key's velocity (in case you want/need velocity sensitive keys). Anyway, no, there shouldn't be any big disadvantage in using 4051 or hc138. Actually, the 4051+4022 idea is pretty smart should you need to control it with very few pins.
 
Thanks for the additional info.
It looks like the Fatar pinout indeed. Is that fairly common? I was thinking to skip velocity sensitivity for now. But I am curious the time between the two switches, what order of magnitude time difference are we talking about?
Is it an order of magnitude measurable by a microcontroller?
 
Thanks for the additional info.
It looks like the Fatar pinout indeed. Is that fairly common? I was thinking to skip velocity sensitivity for now. But I am curious the time between the two switches, what order of magnitude time difference are we talking about?
Is it an order of magnitude measurable by a microcontroller?

That time difference can be measured by any Teensy LC or 3.x, but in order to get that with a fine resolution, and thus with a sophisticated musical expression, I'd go with the quicker and more precise hc(t)138 instead of the slower 405x analog CMOS which has definitively a higher settling time and a finite ON resistance which risks to act as a low pass filter and to flatten the signal ramps.
 
So, to answer my own question:
Using a counter (like a 4017 in my case) makes it VERY instable. There is no way for the software to be sure what count is being output (so which column is being addressed) at any moment.
I thought about syncing on the reset signal (since the 4017 is a decade counter but i need only 8 counts i tied the 8th output to the reset pin as well) but thats just patching and would need another pin on the uC.

So, if anybody else is thinking of this: bad idea! :)
 
I guess that to have everything with precise timing, you'll have to sacrifice pins to address the columns in a binary way (3 pins for 8 columns) and to use a decoder IC like the HCT138. Then, you'll still need enough pins to read the rows.
 
Yeah so I figured that out empirically 😁
I just have to be patient until my parts arive in the mail.

Anyways I still am intrigued by the delta time between the velocity sensitive switches.
Is there any documentation about time vs velocity values?
I mean: is there a standard delta time for midi velocity value 127 for example?
 
I don’t know about standard, but the only bare keybed I have to go off of as an example seems to use a small PIC controller to read it and output it as MIDI data, I believe it’s a Fatar last time I looked at it. Using that as an example, however they coded the contoller made it very hard to even reach 127 on velocity so when I ran it into a Teensy I had to boost the velocity so you don’t have to try as hard to get higher velocity. That may have just been a limitation of how they coded it, but I don’t think believe there’s a standard to use, most likely what you deem as comfortable feeling will work, so you may have to experiment with different timings to find what feels more natural.
 
Hello, I'm new here.

I want to contribute to you, follows SCAN MATRIX diagram, very simple to implement,

In my case I use a PIC to run the firmware, however it is simple to implement for TEENSY ...

Thank you,

SCAN_MATRIX.jpg
 

Attachments

  • WWW.GRUPOAGI.COM.pdf
    39 KB · Views: 207
It works as follows:

Here in Brazil, we use 12-line scanning for "low" to "high" detection, so I use the SN74HC138 to make the negative detection, or "high" to "down" using the SN74HC139.

The SN74HC13x is responsible for scanning LINES.

The SN74HC151 is responsible for reading the lines in sequence.

To detect a triggered key, simply send the code 0 to 7 on the SN74HC13x and Read the respective SN74HC151 BAR, each BAR will correspond to a group of NOTES.

All of this must be processed by the firmware.

The hardware is very simple and functional.
 
This hardware is for reading up to 61 keys per session:

Being divided into:
Cymbal up to 24 notes,
Keyboard bottom up to 61 notes,
Top keyboard up to 61 note
 
so eventually would the LC suffice to decade the matrix with enough timing accuracy ?

O tempo de leitura da linhas (HC138 ou HC139) "essas seriam as notas musicais", e as BARRAS ONIBUS (HC151) "essas são as oitavas" (por isso aqui no Brasil utilizamos o HC138 x 2 para formar uma escala de 12 notas).
O tempo de varredura é feito de uma única vêz para toda a matriz, suponha 61 teclas, a scan é feita de uma única vez. Os resultados são armazenados em uma matriz interna no seu FW para posterior processamento. Eu uso fags de sinalização para registrar se as notas foram ou não pressionadas (flag = 1 tecla pressionada, flag = 0 tecla não foi ativada).

Espero ter ajudado.
 
Status
Not open for further replies.
Back
Top