Try adjusting the attack and position controls – for shorter notes like the ones you mentioned, it's possible to set the start position of the note after the initial attack, resulting in quiet or inaudible notes.

Thank you! Adjusting the Position setting fixes the problem of not being able to hear anything when selecting "El. Tom", "Snare", or "Vox. Hit". (I had made the wrong assumption that having the potentiometer centered would be a "neutral" setting.)
What persists is the problem of many MIDI notes not being played (unless a relatively long time has passed since the last note has been triggered). Is this supposed to be a playable synth in the sense that you can play actual musical lines with it? Even a monophonic synth has to have the ability to re-trigger notes (start a new note even if the envelope of the previous one hasn't been full played yet). Is the Open NSynth Super supposed to have this capability?
So, similar to what mgiuli has posted as a separate issue, it would be helpful to be able to do some debugging whether the MIDI receiving side is the limiting factor or whether the problem is on the audio playback side. I will look into it, but if Open NSynth Super already has some built-in debugging capabilities it would be helpful to know.

I've run into the same problem as jditte, midi notes not triggering until a long amount of time has past. Shortening the decay doesn't seem to make a difference. Any suggestions?

I made the following changes. Are they effective?

--- MidiThread.cpp.org
+++ MidiThread.cpp
@@ -117,7 +117,11 @@
 
 			if((header & 0x0f) == channel){
 				synthMutex.lock();
-				synth.on(note, static_cast<float>(velocity) / 127.0f);
+				if (velocity == 0) { // support zero velocity note on
+					synth.off(note);
+				} else {
+					synth.on(note, static_cast<float>(velocity) / 127.0f);
+				}
 				synthMutex.unlock();
 			}

You should be able to send MIDI notes in sequences or manually from any DAW, keyboard, or sequencer; the device should support polyphony and fast sequences of notes without issue. It may be worth checking with an alternative device to what you are using currently to test that your machine is sending MIDI correctly (i.e. sending noteoff signals).

I have been using my MIDI master keyboard for testing, which has been controlling the rest of my MIDI setup for many years without any problem. Thus, I don't think that there is a problem with the MIDI stream that is sent to the NSynth Super (but I will double-check).

The Open Nsynth Super is supposed to be polyphonic? Then there definitely is a major issue. I am using this image

https://storage.googleapis.com/open-nsynth-super/images/onss_1.1_full.img

and the old version of the Raspberry Pi 3.

Is anybody else using this configuration and getting polyphony and fast sequences just fine?

I'm going to try a different MIDI controller and see what happens. The one I used works just fine on other gear.

@haigarmen if you have a usb to midi you could probably try writing some midi in ableton and sending it directly to the nsynth

@jditte The image you mentioned is well tested with fast sequences, polyphony etc… using the RPi 3B. Good luck with your testing!

I've now tried a couple of midi sources and they all seem to result in the NSynth dropping notes and no polyphony. Feels like a software problem but could it be the hardware?

@haigarmen I was wondering the same thing. Did you also order the NSynth Super Semi-Assembled from Squaro Engineering on tindie?

@jdttle yes, it was the same one. Hmmmm

@haigarmen I noticed that the IC (in the midi area) that you had on your board looked different from mine which I ordered from the parts list. could be just that it looks different but I have noticed other differences as well such as the audio jack so its worth looking into

@elimuro I will certainly have a closer look at the components on the board...

I soldering a new 6N139 Optocoupler onto the board after reading a suggestion from closed issue no 34 #34 but it didn't make any difference. Still getting intermittent midi notes and no polyphony. I'd like to find a test script that will help me assess whether I'm receiving all the MIDI info correctly. Anyone have a suggestion?

You can add some logging in this file:

like that

ofLog(OF_LOG_NOTICE,"note: " + ofToString(note));

and after

ofLog(OF_LOG_NOTICE,"velocity: " + ofToString(velocity));

Giving the note from the midi to the sound producing algorithm is happening here:

in ~/opt/of/apps/open-nsynth/open-nsynth run

• $ make -j4
• stop nysth service sudo service open-nsynth stop
• run compiled app $ bin/open-nsynth

And finally you could add usbmidi functionality like done here: #29

OK, problem solved. The hardware was fine. It was a pure software issue. Open NSynth Super's MIDI parser ignores several MIDI specifications. As t-asano had pointed out above, a Note On message with a velocity of zero has to be interpreted as a Note Off message. This was the first problem. The second problem was that the MIDI parser could not handle running status. According to MIDI specifications, when two messages of the same type are sent in sequence, the status byte does not have to be repeated to reduce the number of bytes that have to be transmitted. I am attaching my version of MidiThread.cpp.
MidiThread.zip

@haigarmen Please give it a try and let me know whether it also solves your problem. (Let me know if you don't know what to do with the file. I can provide you with some instructions.)

@jditte I am also having the same issue as haigarmen, I have tried 3 midi controllers

KORG Microkorg midi out- I am able to get single notes and arpeggios via the arpeggiator button. No polyphony.

Roland A-300 Pro- single notes work. No polyphony

M-Audio Oxygen 8 v2- the same as @haigarmen- some single notes, long delays needed between each note press and some missed notes. No polyphony.

I haven’t been able to get polyphony out of any of the controllers I tried. The Roland midi controller seems to work best, but it still seems to lose notes. I am completely new to coding, but willing to learn/try. I used the 16gb lite disk image provided on this site.
If your file fixes these issues, I would be happy to try to implement it, however if you could give me a few more details or send me in the right direction, I would be grateful!

Sure, would be happy to. To replace the file and recompile the application you will need access to the Raspberry Pi. Hook it up to an HDMI monitor and a USB keyboard and boot it. Initially, you will see a copy of the Open NSynth Super screen. Hitting the ESC key will get you to a login prompt. Use the username "pi" (without quotes) and the password "raspberry" to log in. As the SD card is mounted as read only by default, you will need write access by remounting it: "sudo mount -o remount,rw /". Now you have two options:

1. You can connect the Raspberry Pi to your WiFi network and enable the SSH server. This would be my recommendation as it will always allow you to access the Raspberry Pi remotely even when it is built into a NSynth Super case. To do so, follow the instructions here to connect to the WiFi network from the command line:
   https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md
   Once you have made sure that you are connected, go into the Raspberry Pi configuration ("sudo raspi-config"), choose "Interfacing Options", "SSH", and enable the SSH server. You might have to reboot the Raspberry Pi ("sudo shutdown -r now"), but then you should have remote access via an SSH client (like PuTTY in case you are using Windows) for remote access to the command line and an SFTP client (like WinSCP in case you are using Windows) for file transfers. Remember that you always have to remount the file system for write access after a reboot if you want to modify files.

2. Option 2 would be to copy the new MidiThread.cpp file to a USB flash drive and mount it from the command line following these instructions
   https://www.raspberrypi-spy.co.uk/2014/05/how-to-mount-a-usb-flash-disk-on-the-raspberry-pi/
   if you only want one-time access.

Either way, you will have to replace the file MidiThread.cpp in the folder /home/pi/opt/of/apps/open-nsynth/open-nsynth/src/. Rename the original file (in case you would want to switch back to it) and copy my new file to this folder. Move one level up in the hierarchy ("cd ..") such that you are in /home/pi/opt/of/apps/open-nsynth/open-nsynth/. From there execute the command "make -j4", which will recompile the application. Make sure that it actually compiles (you should see two long lines with lots of options) and that you don't get any errors. After another reboot you should be good to go. The newly compiled version of the app should be running automatically.

In case you wanted to go back to the original version of MidiThread.cpp, delete my version of the file, rename the original file back to MidiThread.cpp, touch it to make sure that the file is newer than the previous build ("touch MidiThread.cpp"), otherwise nothing will be compiled when executing "make -j4" from the appropriate directory (see above).

Good luck and let me know whether it fixes your problem!

jditte I tried your MidiThread.cpp file and recompiled the app, playing Midi notes seemed to not trigger any sound but the screen would react by going straight to the command line interface behind the OLED overlay. After a few Midi notes it seemed to crash.

Sorry to hear! This is pretty strange. So, you still had a monitor attached when testing it? I don't see why it should hurt, but I have never tested running the NSynth Super with a monitor attached. You might want to give it a try without. Also, did you reboot before testing it? You certainly wouldn't want to have multiple instances of the app running. Also, I have only done limited testing so far, but everything seemed fine. It certainly didn't crash on me when bombarding it pretty heavily with sequences of short notes and multiple notes in prallel for a minute or so, but let me do some more testing to make sure that it is stable... Do you get sound when having all controls in the same setting and using the original MidiThread.cpp? Did you try to reboot when the crash happened and did the same thing happen again right away?

@jditte It has been strange, I can't seem to even get back to a compiled version with original MidiThread.cpp. I've copied the original back into /home/pi/opt/of/apps/open-nsynth/open-nsynth/src/MidiThread.cpp but it behaved the same way as with your MidiThread.cpp file. Then I deleted all the src files and recompiled and same deal. And I've been restarting between compiles. So close but yet so far....

Did you use the "touch" command on the original MidiThread.cpp before recompiling? It won't create a new executable if none of the source files are newer than the last build. What exactly do you mean by you deleted all source files and recompiled? How can you still compile without source files? Or did you mean you removed the object files?

I'll try to be clearer about what I mean. I downloaded the original src files from this repo before recompiling and I did use the touch command. What are the object files?

if you replace any code you have to go to this folder
/home/pi/opt/of/apps/open-nsynth/open-nsynth/ and run make -j4
then
sudo service open-nsynth stop
to stop the instance of the app started while booting the rpi
and
bin/open-nsynth to run the new compiled version.
If you get some errors while compiling or while running bin/open-nsynth you can paste them here and we can help you.

@haigarmen The object files are what the compiler creates from the source files. (You can find them in the obj directory; save level as the src directory.) These object files then get linked together to create the application.
I have now been able to do some more testing. The NSynth works perfectly fine for me for minutes. It certainly doesn't crash. The only strange observation is that, after minutes of playing, the volume gradually decreases until I can't hear anything anymore, but this doesn't seem to be a MIDI-related problem. I yet have to figure out what is going on.
@haigarmen If you are able to record the MIDI stream that causes the crash in your case please feel free to send it my way. I would be happy to give it a try and, in case it should crash my device, too, do some debugging what is going on...

Thank you for this thread. After months of giving up on mine and letting it gather dust, this fix did the trick. Anyone have an idea of why this was needed? Did the bug only affect boards sold by Squaro on Tindie? That's where mine was from too.

No, this is a pure software issue, not at all hardware-related. The way the MIDI parser was implemented was not fully compliant with the MIDI specifications. Whether or not you experience problems with the original software depends on what equipment you use to send MIDI information to the NSynth. Problems occur if either
a) the MIDI stream contains real time messages, or
b) the equipment sends Note On messages with zero velocity instead of Note Off messages, or
c) the equipment takes advantage of "running status".

is the Nsynth MPE compatible?

Hey, im having the same problems here. Shouldn't that be fixed already? Tried the 16Gb and 64Gb version. Bought on Tindie and midi notes are only played in weird intervals. Im trying to replace the MidiThread.cpp file from a USB stick, but its always saying 'read-only'.
I mounted the sda1 as pointed here. I try to copy the file after point 4. of the Tutorial with
sudo cp /media/usb/MidiThread.cpp /home/pi/opt/of/apps/open-nsynth/open-nsynth/src/MidiThread.cpp
How do I get write access?

Edit April 2020: My problem was the midi keyboard. Bought a Artuaria Keystep and everything seems to work.

@Fluqz Did you remount the filesystem ("sudo mount -o remount,rw /") as explained in my post from May 30th, 2018 above?