Digital piano build

[max.wwwang]

One big issue however, is that there is clear latency between the keystroke and the sound. This is intolerable.

1. If building on the Arduino family boards (I've already ordered another Arduino big brother Mega2560 for its number of pins, before becoming aware of the latency issue), is it possible for me to remove the perceivable latency?

It should not be a problem with a Mega2560 to do the key scan including velocity and meet the 1ms per note on message speed MIDI brings to the table. It might need bare metal programming though.

Make sure that the other parts in your setup do not add to the latency.

Having to use a Teensy 4.1 to do the 88 key scanning to meet latency is absolute bullshit. I have done similar projects with 8051 based MCU's about 40 years ago. The idiocy of this age. We need a 600MHz processor to do a simple task. 

Thanks. I hope when Mega2560 arrives, all problems will be solved. By the way, it's from Aliexpress and is said to have the CH340G chip. Hope it's ok.

Can one code with Mega2560 in a way that is not bare metal programming? (I don't think so, but I can be wrong.)

I agree with you that Teensy must be an overkill, speed- or frequency-wise. But 1) if there is a better/faster solution with the same cost, why not? Who cares the 'waste' of computing power? 2) According to AI, Teensy is particularly suitable for this type of application with MIDI-related capabilities integrated (please correct me if not true); 3) as I said, I'm interested in the pathway without relying on a PC connected; and 4) most importantly, like what I experienced, due to some bottleneck in the workflow, or due to some settings, you often won't get the full potential of your MCU. The overall performance is determined by the weakest link in the whole system, and when the system is complex, it's often not easy to find where this link is. (I would be very happy if someone can tell me how I can get rid of the latency with a Nano, then I can explore further the option of Nano + 2x 4067 multiplexer chips to enable the 88 keys and speed sensing.)

All thoughts are welcome (e.g. various technology pathways, hardware solutions/options, pros and cons, etc.). I had a bit of experience in MCU/Arduino coding (reasonably conversant with C/C++) but am very new to MIDI projects like this.

[pcprogrammer]

I hope when Mega2560 arrives, all problems will be solved. By the way, it's from Aliexpress and is said to have the CH340G chip. Hope it's ok.

I have a Mega2560 board from Aliexpress and it is just fine. Not sure which serial to USB chip is on it though, but the CH340 works for me. It is used on many of these Arduino clone boards.

Can one code with Mega2560 in a way that is not bare metal programming? (I don't think so, but I can be wrong.)

Sure the Arduino way can be used, just as for the nano. Doing bare metal is not super difficult though. I have done it for the nano, and I'm sure you will be able to find plenty of examples on the internet.

I agree with you that Teensy must be an overkill, speed- or frequency-wise. But
1) if there is a better/faster solution with the same cost, why not? Who cares the 'waste' of computing power?

I do not know what you paid for the Mega2560, but I don't think that the Teensy comes at the same cost.

2) According to AI, Teensy is particularly suitable for this type of application with MIDI-related capabilities integrated (please correct me if not true);

Don't depend to much on what AI tells you. MIDI is a protocol and the interface is based on a bog standard UART with optical separation. Based on this practically any MCU has MIDI-related capabilities integrated. It is very simple and there are lots of examples in the Arduino world that generate MIDI and draw out the hardware needed for it. If it is only for transmitting a single non inverting buffer like the 74LVC1G126 can do the job. Add a decoupling cap, two resistors and a DIN connector.

3) as I said, I'm interested in the pathway without relying on a PC connected; and
4) most importantly, like what I experienced, due to some bottleneck in the workflow, or due to some settings, you often won't get the full potential of your MCU. The overall performance is determined by the weakest link in the whole system, and when the system is complex, it's often not easy to find where this link is. (I would be very happy if someone can tell me how I can get rid of the latency with a Nano, then I can explore further the option of Nano + 2x 4067 multiplexer chips to enable the 88 keys and speed sensing.)

All thoughts are welcome (e.g. various technology pathways, hardware solutions/options, pros and cons, etc.). I had a bit of experience in MCU/Arduino coding (reasonably conversant with C/C++) but am very new to MIDI projects like this.

Dropping the PC is a very good idea and simply done by having the nano output the MIDI directly by making use of the MIDI output hardware shown below. MIDI_TX is connected to the nano TX pin. Feed the MIDI output into a hardware synthesizer and see if the latency is still there. If so look into how to improve the code on the nano. Will be a good learning exercise in optimizing code.

[max.wwwang]

I hope when Mega2560 arrives, all problems will be solved. By the way, it's from Aliexpress and is said to have the CH340G chip. Hope it's ok.

I have a Mega2560 board from Aliexpress and it is just fine. Not sure which serial to USB chip is on it though, but the CH340 works for me. It is used on many of these Arduino clone boards.

I believe it should work just fine for most projects. But for my case, I was only suggested by AI that the clone with CH340 (for USB to serial) won't be different from my Nano in terms of latency, only after I ordered one online. But I shall wait and see.

Can one code with Mega2560 in a way that is not bare metal programming? (I don't think so, but I can be wrong.)

Sure the Arduino way can be used, just as for the nano. Doing bare metal is not super difficult though. I have done it for the nano, and I'm sure you will be able to find plenty of examples on the internet.

Sounds like my understanding of what bare metal programming means is wrong. Isn't it code that is run directly by the MCU without relying on an OS (as is the case for, e.g., Raspberry Pi)? I think using the Arduino IDE to program with any of the Arduino families is just bare metal programming. Am I wrong here?

I agree with you that Teensy must be an overkill, speed- or frequency-wise. But
1) if there is a better/faster solution with the same cost, why not? Who cares the 'waste' of computing power?

I do not know what you paid for the Mega2560, but I don't think that the Teensy comes at the same cost.

Well not exactly the same price. But I mean for a one-off hobby project, who would care that difference if the slightly more expensive one is just convenient and more powerful (even if it's overkill)? Anyway I don't mind.

2) According to AI, Teensy is particularly suitable for this type of application with MIDI-related capabilities integrated (please correct me if not true);

Don't depend to much on what AI tells you. MIDI is a protocol and the interface is based on a bog standard UART with optical separation. Based on this practically any MCU has MIDI-related capabilities integrated. It is very simple and there are lots of examples in the Arduino world that generate MIDI and draw out the hardware needed for it. If it is only for transmitting a single non inverting buffer like the 74LVC1G126 can do the job. Add a decoupling cap, two resistors and a DIN connector.

Certainly we should not rely on AI too much. Probably you are right here on MIDI. The problem I have here is the reliance on a serial port emulated through USB, which I understand is the bottleneck as the source of latency.

I'm not sure exactly how by adding 74LVC1G126 this can be fixed. I don't have the full picture view of this pathway. (I mean I need an end-to-end solution, or at least, with a solution that I know how to interface with the existing components or sub-solutions).

3) as I said, I'm interested in the pathway without relying on a PC connected; and
4) most importantly, like what I experienced, due to some bottleneck in the workflow, or due to some settings, you often won't get the full potential of your MCU. The overall performance is determined by the weakest link in the whole system, and when the system is complex, it's often not easy to find where this link is. (I would be very happy if someone can tell me how I can get rid of the latency with a Nano, then I can explore further the option of Nano + 2x 4067 multiplexer chips to enable the 88 keys and speed sensing.)

All thoughts are welcome (e.g. various technology pathways, hardware solutions/options, pros and cons, etc.). I had a bit of experience in MCU/Arduino coding (reasonably conversant with C/C++) but am very new to MIDI projects like this.

Dropping the PC is a very good idea and simply done by having the nano output the MIDI directly by making use of the MIDI output hardware shown below. MIDI_TX is connected to the nano TX pin. Feed the MIDI output into a hardware synthesizer and see if the latency is still there. If so look into how to improve the code on the nano. Will be a good learning exercise in optimizing code.

As said, I'm afraid I don't quite get how this fits with other bits of my project (apart from the connection between Nano and the 74LVC1G126 IC).

Yes, performance optimisation is interesting and may be necessary. But I think it's not the time for it yet. If it's a few orders away from the target, it's unlikely to get it by code optimisation.

I will have a look into the hardware synthesizer pathway (is Teensy Audio Shield one of these?). This way I'm sure the noticeable latency will be gone.

[ledtester]

Guided by AI, I had a proof-of-concept run of my project based on the said Roland Keybed, and an Arduino Nano. Due to the pin limitation of Nano, I'm now only able to wire up 80 out of the 88 keys and one switch only for each key. It now relies on a PC running a Hairless MIDI-Serial Bridge which drives the MS wave table synthesizer to drive the PC speaker and make sound.

One big issue however, is that there is clear latency between the keystroke and the sound. This is intolerable.

I have a feeling that the AI code is to blame for the latency.

Can you post the code?

[pcprogrammer]

I believe it should work just fine for most projects. But for my case, I was only suggested by AI that the clone with CH340 (for USB to serial) won't be different from my Nano in terms of latency, only after I ordered one online. But I shall wait and see.

The Mega2560 is indeed the same as a nano (Atmega328), but offers more pins and peripherals. And none of these should be the real source of your latency. Using hardware MIDI instead of the serial to USB adapter on the 2560 or nano should neither, because the CH340 can work with speeds much higher than MIDI baudrate. (MIDI is only 31250 bits per second and with 3 bytes for a note on command it takes 1ms for a note to be send. A good musician might notice latency in the order of 5ms, but most of us won't. On the AVR running on 16MHz this means a lot of instructions.

Sounds like my understanding of what bare metal programming means is wrong. Isn't it code that is run directly by the MCU without relying on an OS (as is the case for, e.g., Raspberry Pi)? I think using the Arduino IDE to program with any of the Arduino families is just bare metal programming. Am I wrong here?

To me using the Arduino framework is similar to using an OS. There is a lot of hidden functionality under the hood that might get in the way of your task of scanning the keyboard and emitting MIDI data.

Bare metal, to me, means starting at the reset vector and write every bit of code yourself, or in case of using libraries make sure to have a good insight in what they do. This gives total control over the MCU/CPU. Attached is a bare metal piece of code I wrote to control a mixing valve for a central heating system. It uses the UART to receive commands and reply to them. Pure C and no libraries needed.

Your keyboard scanning could be done in exactly the same manner.

Certainly we should not rely on AI too much. Probably you are right here on MIDI. The problem I have here is the reliance on a serial port emulated through USB, which I understand is the bottleneck as the source of latency.

It does not have to be. It depends on the host system on how it handles the data if there will be latency or not. On the nano side the UART just outputs serial data and the CH340 buffers it and waits for the host to collect it. Normally this should occur every milli second and as such align perfectly with MIDI speed.

I'm not sure exactly how by adding 74LVC1G126 this can be fixed. I don't have the full picture view of this pathway. (I mean I need an end-to-end solution, or at least, with a solution that I know how to interface with the existing components or sub-solutions).

This would make the nano output true MIDI and allows connecting to a real synthesizer that has a MIDI input. In such a setup the only latency could be caused by either the nano or the synthesizer, and if it turns out to be the synthesizer it means it is a piece of shit. 

If it is the nano, the programming of it is shit.

Keyboard scanning, even with velocity is a very simple process. MIDI is not that hard either, especially when it is only note on and note off messages that need to be send.

I will have a look into the hardware synthesizer pathway (is Teensy Audio Shield one of these?). This way I'm sure the noticeable latency will be gone.

With a hardware synthesizer I mean something like a Korg, Roland or Yamaha synth. These have MIDI and are proofed to be working without to much latency.

But a Teensy 4.1 with an audio shield can be used to, if there is MIDI input and the right firmware to turn it into a synthesizer.

[Peabody]

I have a Roland piano, and while I've never tried it, my understanding is that the piano transmits Midi to a PC over USB directly via some protocol used by audio devices.  I guess the CH340 and its driver would generate additional delay, but maybe that's just a question of baud rate.  On the Pianoworld forum, I see many people running something like Pianoteq to turn their dinky Roland into a Steinway Model D concert grand, and as far as I can tell, latency is not really a problem even then.  And that's with all the complications of processing each note, and many notes together.  So there ought to be a way to make this work.  I don't know about the key scanning.  I would think the Rolands of this world would have a really efficient way to do that, but again, with a fast enough processor that shouldn't be a problem.

[max.wwwang]

I have a feeling that the AI code is to blame for the latency.

Can you post the code?

Of course. Both the code and wiring configuration are attached (both provided by AI with a few attempts after errors identified). Keybed wiring is attached in post #47.

But the code is really simple as this stage, for reasons mentioned (only for proof of concept and due to pin number restrictions). So to me it's unlikely that the problem is with the code (efficiency).

[max.wwwang]

The Mega2560 is indeed the same as a nano (Atmega328), but offers more pins and peripherals. And none of these should be the real source of your latency. Using hardware MIDI instead of the serial to USB adapter on the 2560 or nano should neither, because the CH340 can work with speeds much higher than MIDI baudrate. (MIDI is only 31250 bits per second and with 3 bytes for a note on command it takes 1ms for a note to be send. A good musician might notice latency in the order of 5ms, but most of us won't. On the AVR running on 16MHz this means a lot of instructions.

Yes, likely the 2560 only has the benefit of more pins, meaning I will make use of all of the 88 keys and will be able to have key velocity sensing, but without any change in the issue of latency. If it can be solved with 2560, then probably Nano as well (if along with two 4067 complexor chips, pin number limitation can be worked around).

I estimate the latency currently is in the order of 100ms.

To me using the Arduino framework is similar to using an OS. There is a lot of hidden functionality under the hood that might get in the way of your task of scanning the keyboard and emitting MIDI data.

Bare metal, to me, means starting at the reset vector and write every bit of code yourself, or in case of using libraries make sure to have a good insight in what they do. This gives total control over the MCU/CPU. Attached is a bare metal piece of code I wrote to control a mixing valve for a central heating system. It uses the UART to receive commands and reply to them. Pure C and no libraries needed.

Your keyboard scanning could be done in exactly the same manner.

Ok there may be different levels of bare metal coding. But to me the one example you attached is the same as mine (as attached above). Let me know if I'm wrong.

Certainly we should not rely on AI too much. Probably you are right here on MIDI. The problem I have here is the reliance on a serial port emulated through USB, which I understand is the bottleneck as the source of latency.

It does not have to be. It depends on the host system on how it handles the data if there will be latency or not. On the nano side the UART just outputs serial data and the CH340 buffers it and waits for the host to collect it. Normally this should occur every milli second and as such align perfectly with MIDI speed.

Though I will experiment with a few options, it would be great if the Arduino+PC pathway works (I mean without noticeable latency).

With a hardware synthesizer I mean something like a Korg, Roland or Yamaha synth. These have MIDI and are proofed to be working without to much latency.

But a Teensy 4.1 with an audio shield can be used to, if there is MIDI input and the right firmware to turn it into a synthesizer.

I plan to try the option of Teensy 4.1 + its Audio Shield anyway. My purpose is not just to make a working digital piano (again by "working", I mean without noticeable latency), experimenting with various options, particularly things that were new to me, is a lot of fun and interesting by itself.

[max.wwwang]

I have a Roland piano, and while I've never tried it, my understanding is that the piano transmits Midi to a PC over USB directly via some protocol used by audio devices.

An off-the-shelf Roland digital piano (or any other brand, except for the very basic models) most likely will have such MIDI input/output capabilities. So would have been my KR-4500, but it was faulty and my attempt to repair it failed. So I'm now making use of its keybed only (which I think is the most critical and challenging part for a DIY project), with electronics components that nowadays I have so much freedom of choosing from.

I guess the CH340 and its driver would generate additional delay, but maybe that's just a question of baud rate.

It's possible. But I've tried the highest Baud rates without any difference that I can notice. Sincethere are so many links in the work flow, many of which I don't have a deep understanding of their working, it's not easy to find out where the bottleneck is.

I see many people running something like Pianoteq to turn their dinky Roland into a Steinway Model D concert grand, and as far as I can tell, latency is not really a problem even then.  And that's with all the complications of processing each note, and many notes together.  So there ought to be a way to make this work.  I don't know about the key scanning.  I would think the Rolands of this world would have a really efficient way to do that, but again, with a fast enough processor that shouldn't be a problem.

Certainly there are many many ways. As suggested by pcprogrammer, the latency is very unlikely due to the slow speed/frequency of the MCU. It's somewhere else.

Thank you for mentioning Pianoteq. I think it is one of the so-called VST software (Virtual Studio Technology), or can be used as one.

[pcprogrammer]

I have a feeling that the AI code is to blame for the latency.

Can you post the code?

Of course. Both the code and wiring configuration are attached (both provided by AI with a few attempts after errors identified). Keybed wiring is attached in post #47.

But the code is really simple as this stage, for reasons mentioned (only for proof of concept and due to pin number restrictions). So to me it's unlikely that the problem is with the code (efficiency).

You are using digitalwrite and digitalread, which may be slow. Your Arduino framework based code is nothing like the example I provided. Under the Arduino framework al sorts of initialization is done and using the given functions for reading and writing to pins makes it less efficient than directly writing to and reading from the IO registers. Also using serial write might not be the best option to output the midi data.

Look into what I provided as an example and read the AVR manual to learn about the peripherals and how to make use of them. Search the web on more about how to compile for AVR targets without using the Arduino IDE.

100ms latency is ridiculously high. Old mid 1980's synths used processors like the Z80 or 6809 running on 2MHz never missing a note. Sure these were mainly programmed in assembly language, which was also what I used on 6502 and 8051 based instruments I made back in the day I worked for Steim in Amsterdam.

AVR assembly is not that hard either, but using plain C with direct peripheral register access should do the trick too.

[max.wwwang]

You are using digitalwrite and digitalread, which may be slow. Your Arduino framework based code is nothing like the example I provided. Under the Arduino framework al sorts of initialization is done and using the given functions for reading and writing to pins makes it less efficient than directly writing to and reading from the IO registers.

Don't take this as challenging, but how are digitalwrite and digitalread different from, say, Usart_send() in your code?

Having had another look as your code, I think I now noticed certain difference. For example, you code has the main() function which is the entry point, whereas for the 'standard' Arduino code, the main() function is invisible and hidden, by which the loop() (call back) function will be called. I accept this is different. But then, even in your code, there will be code that causes main() to be called, meaning that in a sense it's still not bare metal. In this sense only if we start from bootstrapping can it be called bare metal coding.

Also using serial write might not be the best option to output the midi data.

Is it a way that I can output midi data without using the (emulated) serial port (when using Arduino)? Keen to know.

Search the web on more about how to compile for AVR targets without using the Arduino IDE.
AVR assembly is not that hard either, but using plain C with direct peripheral register access should do the trick too.

Very keen to know more about coding Arduino without using its IDE. Would appreciate if you can leave some links.

As for assembly, yes it will be fun and I don't mind if it's necessary (I would not pretend to know much about assembly. It just seemed unnecessarily too hard when I was in uni but later realized I should not have been daunted. At that time when with tools like macro in MASM, it should not have been too hard.).

 

[pcprogrammer]

My AVR is a bit rusty, but if I'm not mistaken, the compiler and linker take care of setting up the MCU starting from reset. This is not a lot though. A small bit of code to clear the global variables, which is a simple loop that writes a zero to every byte in use. Possibly also a bit of code to copy initialization data that is not zero to some other variables. Setup the stack pointer, and that is it. Boom jump to main.

In the Arduino IDE you might be able to do the same, but I have no experience with that. Do not use it that much.

Comparing digitalwrite and digitalread to my Usart_send functions is like comparing apples and oranges. I have never looked at the code behind the digitalwrite, but have seen others here on the forum mentioning them being sub optimal. The quickest way to set an output pin is to directly write to the output register of the IO peripheral, which is not the case going on what I have read about it. The Arduino framework is a dark deeply buried pile of code that I stay far away from.

My Usart_send function writes the bytes to be send into a buffer and makes sure the interrupt system is active to handle the transmission of this data in the background. It is very basic and has no checks on buffer overrun, but in this case not a problem, because the system never writes so much data that this can happen. The benefit of a system you design yourself. You can keep it as simple as is needed.

What makes code bare metal, depends entirely on your own definition, but to me that AVR example of mine is. Why, it basically starts at reset, initializes the system in the main function and makes use of the peripheral registers without a HAL in between. There is basically only one more step down to even more bare metal, and that is assembler. For the nitpickers, yes there is machine code, but only a fool would go that far. 

To compile from C to AVR you need a compiler like for instance on Linux gcc_avr. Type "linux avr compiler" into google search and the AI will show you several examples on how to setup the environment and how to compile a program. For windows, I don't know, have not used it for development in over a decade, but I'm sure google will find how it is done on it too.

[ledtester]

After seeing the code I don't think it is the reason for the latency. digitalRead()/digitalWrite() are not the most efficient but they only take a few microseconds to execute.

You can try setting NUM_DRIVES to 1 so only one bank of keys is processed and see if that changes the latency.

[Peabody]

I wonder if you could get an idea of the delay caused by the Midi transmission over serial by adding code to turn on an LED at the beginning of sendMIDI(), and turning it off just before returning from that function. Then you would note the delay, if any, between the LED and the sound.   Of course that blinking would itself add a little delay, but not much.

My memory is that Serial.write() on the ATmega328P Arduinos stores the byte into a buffer, which is then emptied by an interrupt generated by the end of transmission of the previous byte.  I don't know of a faster way to do that if you're sending Midi via serial.  But if you had an Arduino with built-in USB support, such as the Leonardo, Micro or Pro Micro which use the ATmega32U4, it might be much faster.  Here's a video on using these USB-capable processors for Midi:

[pcprogrammer]

The most deterministic way of measuring the latency from the nano itself is with a scope or a logic analyzer. With a scope, connect one channel to the key being pressed and trigger on that signal in single trigger mode. Connect the other channel to the TX pin of the nano. This will show the exact delay between the pressing of the key and the start of the transmission.

With a logic analyzer the principle is the same, and if it is done with a USB based one, or one with loads of memory the full transmission can be captured too.

Checking it through the CH340 is a bit more problematic and most likely requires a protocol analyzer.

The first test is a good way to see if it is the Arduino code being slow or not.

[max.wwwang]

My Arduino ATMega2560 arrived and is now used for the fully functional 88-key piano with key speed sensing. With a good number of rounds of trial and error, AI eventually made it.  I've not attempted to optimize the code. It's in general working. But the latency is similar to when using Nano for 80-key only and without velocity sensing (meaning much simpler code). The experience with Nano gives me good reason to infer that the cause of the latency should be something that is common between both Nano and 2560, not the extra complexity with speed sensing used with 2560, and that code optimisation is not likely to be the fix.

Wiring scheme and code (AI generated) attached.

Still waiting for the Teensy 4.1 board to come to test with other options.

Edit: I only later realised that the version I ordered, with the CH340 chip for USB-serial 'conversion', is the budget clone of the original version, which has instead the ATmega16U2 chip and (according to AI) can work as a native MIDI device, without having to rely on a MIDI-serial bridge app like Hairless. It sucks! 

[max.wwwang]

Another working version that is more efficient (according to AI) without the DigitalRead() calls. No noticeable improvement (as expected).

[ledtester]

I feel it the latency is in the hairless to DAW part of the pipeline.

I asked ChatGPT about midi latency due to the hairless bridge and got this list of things to look at:

https://chatgpt.com/c/6a770254-79f4-83ea-90f0-6cd987ccbfd6

The most deterministic way of measuring the latency from the nano itself is with a scope or a logic analyzer.

Another way is to use a sound card input channel (ie either left or right) to record the output of the TX pin of the Arduino and the other channel to record the output of the DAW like described in this article:

https://www.soundonsound.com/techniques/truth-about-latency-part-1

The resistor shown only needs to be close to 5.1K.

Use a recording program like Audacity to record both inputs.

This will measure the latency between the Arduino sending a message and sound being produced.

[max.wwwang]

I feel it the latency is in the hairless to DAW part of the pipeline.

I asked ChatGPT about midi latency due to the hairless bridge and got this list of things to look at:

https://chatgpt.com/c/6a770254-79f4-83ea-90f0-6cd987ccbfd6

The most deterministic way of measuring the latency from the nano itself is with a scope or a logic analyzer.

Another way is to use a sound card input channel (ie either left or right) to record the output of the TX pin of the Arduino and the other channel to record the output of the DAW like described in this article:

https://www.soundonsound.com/techniques/truth-about-latency-part-1

The resistor shown only needs to be close to 5.1K.

Use a recording program like Audacity to record both inputs.

This will measure the latency between the Arduino sending a message and sound being produced.

Very useful and interesting information. Thank you.

Very unlikely the latency comes from the low processing speed of Nano. Probably somewhere in the chain when the conversion from serial to USB happens, or further downstream.

I will probe around with a scope, but probably not able to pinpoint the cause of the issue this way. Good to know another freeware Audacity; I never expected to get into another entirely new world of sound processing. Yes, it can be used to measure the lapses between different signals, though not sure about the compatibility between the signals from the serial TX pin and the input of the PC sound card (presumably line in not mic). Boy never looked deep into these signals!

[lichurbagan]

Sometimes the keyboard works fine, but occasionally some keys randomly start repeating by themselves, or pressing one key triggers multiple notes at once. Any ideas what might be causing this? Below is the source code:

Maybe some loose cable or short circuit?