Bug with midi USB hanging notes - with possible fix

[MichaelPNolan]

So I just wanted to put this here - not sure if it belongs here or elsewhere but its more a solution (possibly) with the known bug. Assuming its not fixed in some versions.

Short story: calling other things from USBMidi_HandleShortMessage that do communications seems to cause a communications loss and consequently notes don't turn off.

So the behaviour is hanging notes (note off not triggering)
The cause is assumed to be inefficiency causing lost communications.
My observation while debugging a different issue with a SSD1306 that wouldn't work on Core0 on one version I wired up even though it works on my seemingly identical ESP32 on the breadboard. I had to fix something that was causing a lot of noise/buffer under-run in the sound processing when the screen was being refreshed too much. I ended up turning off this:

So basically if you are writing a string to where-ever (in this case to a little OLED or to Serial then you stand to lose some messages if your routing takes too long. So something I did was left a flag in my own call to this miniScreenString not to refresh the screen but just update the string that will later be written when the screen updates.
So now when its like this - i stopped getting dropped notes or at least it happens far less often so far.

The call is in the usbMidiHost library of this project and this is my forked version

`inline
void UsbMidi_HandleShortMsg(uint8_t *data)
{
            //you can call the display miniScreenString(int sector, String s,bool refresh)
    #if (defined DISPLAY_1306) && (defined NOTE_TO_SCREEN)
    miniScreenString(15,1,"N#:"+String(data[1]),LOW);
    #else
    Serial.printf("shortUSB: %02x %02x %02x\n", data[0], data[1], data[2]);
    #endif
...`

So you could perhaps make some kind of defined term to switch off calling something external during this. Particularly if it triggers wire or serial comms while you are still processing more items in the USBMidi.
I was experiencing issues with hanging notes using a midikeyboard via the USBmidihost to trigger notes before I put the screen on but the way it is now its not using Serial.printf and its very fast to write a string into another library. If I bypass any call out and figure out another way to monitor notes.

The bigger issue I face is making my SSD1306 work reliably (not display garbage) when I use it on Core0 but that's not part of this project its just something I'm working through.

[marcel-licence]

Hi, thank you for this.
I've checked the forked version. I would expect getting problems with the audio loop when you try to access I2C (accessing the SSD1306) or also try to process the SPI for the USB host module.
My initial idea was to put all slow tasks on Core0 (to avoid the buffer underruns on core1).

The call on Core1 (for example "UsbMidi_ProcessSync") is just to get the slowly collected data in sync with audio task to avoid any glitches or collision by data access by both cores at the same time.

For the displays I put data when running Core1 just into an buffer. Core0 checks this buffer for new data and displays it.

You can also compare midi_interface.ino to my latest revision. I've fixed a little problem caused by aftertouch messages which might also appear when receiving other messages.

I didn't used the USB host for a longer time but I can try it.
Thx a lot for sharing your results =)

[MichaelPNolan]

Thanks, I'll look to update to midi_interface.ino.

I've been working a lot at trying different ways to get things to run smoothly on Core0. Its totally correct that they don't cause the IC2 audio loop interruptions running from there. Even small delays cause audio glitches. Some libraries are not Core0 friendly on ESP32 such as Wire or the AdafruitGFX or oled but its not on every ESP32?! Confusing.
If I put UsbMidi_ProcessSync(); and the loop on Core0 then EasySynth module ends up also running from Core0 which works but you can end up with sound dropping out on left or right. So I have to make a kind of midi message buffer/queue that can service calling the appropriate Synth functions during Core1 loop. I want to do that anyway so it can link into my Arpeggiator which I'm going to bring from my stand-alone project into this "synth in a box with USB midi". I'm still not up to the serial midi type hardware interface but will get there. Currently I'm looking at simplifying the Oled communications to change libraries to something that works reliably on Core0. I also have a queue situation there so that messages to update the parameters that can be reflected in the Graphics are processed from Core0 even if data was sent from Core1. I've never really done a project where I had the resources of multiple cores to manage.

One of the main issues can also be with things like String Objects getting corrupted when handled by different Cores, at least people in forums say that. I don't know if its true but I rewrote things to use char arrays to see if it helped or at least remove that concern during debugging.

[MichaelPNolan]

Ok - so I refactored (i've always disliked this term) - or rather incorporated your updates. Not every module but I will.

I see you have UsbMidi_Loop(); in core0 and UsbMidi_ProcessSync(); in the main loop (core1). So this was a revelation.
Also seems you have the a much more frequent processing of theUSBMidi in core1 than I had. So I left it as you set.

My big bug was getting my SSD1306 to run from core0 too - the thing just went corrupt or crashed. I debug it so much I have a #define DISPLAY_CORE (0 or 1) to flick back and forth. So running it as you had set with USBMidi_Loop updates to my display were coming from Core0 and now my display went corrupt running on core1. Boomshanka - so I switched it back to core0 and now its working. I noticed you added this to main page of project
#include <SPI.h> #include <Wire.h>

Here is a soldered together prototype - i haven't put screen in place it's floating in the air.
https://drive.google.com/file/d/1jNhNs8Md0QZn-w6ME8SGb0fWKLOd-EWo/view?usp=sharing

I also noticed you have a monitor which I remember seeing in a video ... VT100. Your calls to that are const char *variable -
I know you aren't here to teach anyone to code but - any clue, why? Does it related to volatile type or preventing some issue passing strings. I've been working to understand the best way to work with strings ... as I said I have queues so that messages are enqueued and dequeued at the time the processing happens from - in this case the Core0 loop.

Thanks for updating your project - I am glad I spent time updating my fork because I was about to try a different library hoping it might fix the issue with the display running from Core0. I have a feeling it has to do with wire and maybe some change you made improved the situation for my display module.
regards
Michael

[marcel-licence]

I know that term. But it often helps to go through it again.

You can increase the loop speed of core 1 for example by processing only one adc after another. In addition to that it might happen that different interfaces (I2C, SPI, UART) block each other. So you can only access one at the time and the other access method will wait for the first one to finish. In case you are not sure if there is any conflict you can also make a stand alone application just running the display for example.

I tried to avoid using the arduino string type because I do not know what happens in case I am using it. const char * will only provide a pointer to data stored in the flash (char by char ... with a 0 at the end). https://en.wikipedia.org/wiki/VT100 By using TeraTerm you could send specific characters (escape codes) via the serial port to manipulate the color or the cursor position etc. It is just a very cheap and simple solution.

You are welcome. More updates will follow, I try to keep the projects in sync and compatible. In addition the new board definition should help to integrate it quickly in a custom design.

Best regards,
Marcel

[MichaelPNolan]

Your updated software seems to be efficient but the midi buffer via usb (since I don't have direct midi yet) still drops note offs. I tested with a couple of midi-keyboards. I thought i had fixed it earlier but i still have hanging notes. I increased the frequency of calling
UsbMidi_ProcessSync but this doesn't seem to resolve losing messages.

So forgive this "thinking out loud" debugging or assuming there is no bug - ask for help in understanding.

I started my own queue to capture messages because I want to change performance to arpeggiator etc in my new version and I could see all the messages printed and find the instances where it missed one. So I'm trying to figure out where messages might be lost ... and understand the whole midi interface situation and assume there might be a bug somewhere or an improvement.
So I went through reading how it works
Ok - so this is what I see that I find ... possibly wrong?
UsbMidi_Poll() is getting the data from the USBmidi .. and you are using uint8_t USBH_MIDI::RecvData(uint16_t *bytes_rcvd, uint8_t *dataptr) and everything seems to make sense. Except that if I push too many keys or make too many messages something gets lost.

There is some need to find if there is more left to poll again and I see there is also ... uint8_t USBH_MIDI::RecvData(uint8_t *outBuf, bool isRaw) variation and in the code in the library that version has this ... bit of code that the other one doesn't:

`        //Checking unprocessed message in buffer.
        if( readPtr != 0 && readPtr < MIDI_EVENT_PACKET_SIZE ){
                if(recvBuf[readPtr] == 0 && recvBuf[readPtr+1] == 0) {
                        //no unprocessed message left in the buffer.
                }else{
                        goto RecvData_return_from_buffer;
                }
        }`

So, I am wondering about this other variation and if it prepares the buffer or has some combination usage?
Then I go to seek how the library advises to use it rather than question your code so I can experiment. I've looked at example code and some forums related to the source. I'll keep digging - maybe its something i'm doing slowing things down.

[marcel-licence]

Hm there are some things to do to identify exactly where the data gets lost. You can also go into the other direction and make things slower to see if it has any effect.
I think UsbMidi_Poll could be the most time critical function. It pulls data via SPI from the USB host. There are buffers in use. For example calling the poll and also the process just once a second may slow things down but can help to identify if messages are lost because of speed or maybe that there are unexpected messages misunderstood by the parser and some data dropped away. I didn't use the host for a long time. Only once to create a possible interface to use.

[MichaelPNolan]

Yes, I'm going to do that experiment soon. Thanks for checking back. I wanT to try dumping unfiltered raw to see if I can find anything parser missed. Regards Michael

…

On Tue, Nov 9, 2021, 04:46 Marcel ***@***.***> wrote: Hm there are some things to do to identify exactly where the data gets lost. You can also go into the other direction and make things slower to see if it has any effect. I think UsbMidi_Poll could be the most time critical function. It pulls data via SPI from the USB host. There are buffers in use. For example calling the poll and also the process just once a second may slow things down but can help to identify if messages are lost because of speed or maybe that there are unexpected messages misunderstood by the parser and some data dropped away. I didn't use the host for a long time. Only once to create a possible interface to use. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTDOQ4EZPMVOI5TCYLKBODULBAMRANCNFSM5GDZZZ4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[MichaelPNolan]

I've been experimenting and best I can do is reduce the chance of a hanging note or missing noteOn .. So I started to wonder about pull up resistors to the USBMidi.
I even made a process lock flag so that the midiUSB call on Core1 puts a hold on the other call from Core0 from happening before it's done. I'm wondering if there is anything else that could be locked while USBMidi_Poll is loading it's buffer.

_"Pull-up resistors are ONLY needed when you have open collector/drain bus drive, as in TWI/I2C. SPI is full logic drive, hence GENERALLY not needed.

There is, however, one situation in SPI where a pull-up could be useful. When the SPI device(s) is disabled (/S line high), the output pin goes Hi-Z so that any other active SPI device can drive that line. Hi-Z means that it has the electrical characteristics of an input (without being able to actually input anything). You Might add a pull-up resistor to this line so that the state will be defined when nothing is driving it (nothing selected). Few SPI systems bother with this detail, but it would keep the master end of the MISO line away from the voltage area near Vcc/2 where the input circuit will take more current (from power supply to ground) than is usual for a CMOS input circuit."_ (found this in a discussion https://www.avrfreaks.net/forum/why-have-pullup-mosi-and-miso)

My circuit does kind of have current issues - my project is unstable unless I add an additional 5v power supply. I have an Oled and a DAC that has a little classD amp onboard ... so if i made too much volume it drained things. I put bypass caps to stabilize. Anyway, it made me wonder if there is a cyclic momentary state in the hardware (perhaps when some other onboard hardware serial communications is active) which is similar. So I'm going to experiment with this to see if it makes any improvement. The code doesn't seem to have any bug (not that I'm sure I would see it) given that it can go a long time without losing a note. Mashing a lot of simultaneous keys presents a very high chance of losing one note. Could that be related to communications too?

[marcel-licence]

Interesting approach. Thank you for sharing your ideas =) The interesting point is that you do 6 reads within the while loop without dropping returning on empty messages. I am currently thinking about the fact if the code is really safe for an execution on two cores. There are always two lines of code executed at the same time: pushing MIDI messages from USB into a buffer, and on the other hand getting messages out of the buffer and pushing this into the synthesizer. It's too long time ago

[MichaelPNolan]

This is just an approach I realized after exhaustively testing every other approach I could think of. So I am basically reading and reading until I get those messages. Now I can play without hanging notes 99.99%. I guess it could be a for loop but I want to perhaps escape the loop if I get success early. I want to do some more analysis what is read out ... at what point in the loop.
There was even a buggy version of this where I didn't escape the while loop until i picked up several midi messages which caused my program to crash ... unless I kept playing on the keyboard ... that was fun. Then the whole Code0 loop was dysfunctional because I was locked in midiPoll but somehow the thing kept running ... and that shows how much can work with parallelism if you really push it. You could spend quite a long time in this loop here waiting for midi reads without breaking it.

Yes, I'm not using Serial2 midi so - the writing and reading simultaneously would need some kind of flow control flag.
My fork of your code can optionally buffer the noteOn note Off and trigger them from the main loop by Servicing another Queue. That is how it is running right now during testing. That is so that I can operate in different playback modes - chords/arpeggios. When I was triggering the notes from the Code0 loop I started to get glitches in an unpredictable way ... so this would be an effect of having things happening in parallel as you say.

[marcel-licence]

Hi, I have some days off and tested the MIDI USB interface today and yesterday. With the Roland Edirol PCR-800 and also the ESI M4U XL I had no issues. I am not sure if some kind of fix was integrated in the meantime. If you like please try the latest version of: https://github.com/marcel-licence/esp32_esp8266_organ

Hitting multiple keys very quickly should generate output like this:
short: 91 39 64
short: 91 3c 6f
short: 91 3e 6f
short: 91 40 69
short: 81 3c 6a
short: 81 3e 65
short: 81 40 4f
short: 81 39 54

The output is enabled in the project. For ESP32 only the define for MIDI_VIA_USB_ENABLED needs to be enabled. If you like please let me know what kind of result you get and also some debug output if problems appear.

Best regards

[MichaelPNolan]

If you put #define ESP32 in the USBMidiHost.ino (or config.h I guess) there are some code #elif matches in usbcore.h (which is indirectly included) that will be triggered. So I think that's good to have if it's going to be referenced.
P5 (the SS pin first parameter) is wired up in your implementation - and P17 second parameter doesn't seem to work anyway even if it is wired up. Maybe there are other parts of the library that might change ... so I added this. Maybe it helped?
The SS pin "allows you to have multiple SPI devices sharing the same MISO, MOSI, and CLK lines." so its probably not crucial but something in usb processing would drop out at times so ... i tried to eliminate any possibility.

#elif defined(ESP32)
typedef MAX3421e<P5, P17> MAX3421E; // ESP32 boards
...

I wired up the interrupt pin but it doesn't seem to be implemented ...
If its just about not calling the usbMidi_loop() often enough because I have code for the oled that might interfere (seems to sometimes) what I did was make a second coreTask0

void Core0TaskInit()
{
    /* we need a second task for the terminal output */
   xTaskCreatePinnedToCore(Core0Task, "Core0Task", 4000, NULL, 999, &Core0TaskHnd, 0);  //orig xTaskCreatePinnedToCore(Core0Task, "Core0Task", 8000, NULL, 999, &Core0TaskHnd, 0);
   xTaskCreatePinnedToCore(Core0USBTask, "Core0USBTask", 8000, NULL, 1000, &Core0USBTaskHnd, 0);  //orig xTaskCreatePinnedToCore(Core0Task, "Core0Task", 8000, NULL, 999, &Core0TaskHnd, 0);
}

This USB dedicated one has a higher priority so I guess it can interrupt the processing of the other.
Since I made those changes - it seems to have stopped dropping notes. It was only doing it intermittently before. It also is more prone to do it in the first 10 seconds of running and then i guess memory use settles in and things stay smooth.

I looked into the interrupt related code but it seems to only be implemented for teensy. I would just like to make it interrupt driven for efficiency anyway.

I still have a while loop in USBMidi_Poll() as well as a flag that gets set if it does read anything and it runs the whole usbMidi_Loop() again to make sure everything is read. You would think once a millisecond or so is enough but ... if a lot of keys get mashed at once it was definitely losing messages.

Your software I will still test but you don't have an Oled as far as I can tell ... and that's an important thing for my little box.

Regards
Michael

[marcel-licence]

Hm I am not sure why you get different results. I do not use the interrupt pin. Using two tasks on core0 might decrease the performance because only one could be active at the time. That was the reason to put all into one function to ensure that there are no unexpected delays.

I made a test with the organ project putting a delay(500); in the loop function. It looks like the USB host can buffer some messages (enough for a complete chord). Only if I play two many notes in the short time I can get losses and also see cc cc cc in the debug output:

short: 91 46 4d
short: 91 46 4d
short: 81 46 1a
short: 81 46 1a
short: 81 43 6f
short: 81 43 6f
short: 81 40 6a
short: 91 43 5c
short: 81 40 6a
short: 91 43 5c
short: 81 3c 42
short: 91 46 4d
short: 81 3c 42
short: 91 46 4d
short: cc cc cc
short: 81 46 1a
short: cc cc cc
short: 81 46 1a
short: cc cc cc
short: 81 43 6f
short: 81 43 6f

Adding an OLED should be feasable. In most designs I am using OLED + SPI controlled by core0 with a good performance.

The SS connection is requied I think. If chip select would be floating you could get random results. I am not sure but I think it also helps to identify the first bit of transmission and avoiding communication problems especially with a high SPI frequency.

I pushed a little change on GitHub. I tested this with two changes in the config.h and the following defines active:
#define BOARD_ESP32_DOIT /* activate this when using the DOIT ESP32 DEVKIT V1 board */
#define MIDI_VIA_USB_ENABLED

[MichaelPNolan]

I'm not surprised - i'm starting to think its just a matter of my code delaying the servicing to the point where it mostly works but occasionally there is a delay ... or glitch. Still testing. My only idea left, other than to work on different solutions and code is to see about this interrupt pin in the USB host shield and make an interrupt call to poll the USB. I've been putting together soldered versions and trying to stabilize everything the best I can or turn parts off that might cause these pauses. Thanks for letting me know you were testing it. Regards Michael

…

On Wed, Dec 1, 2021 at 7:01 PM Marcel ***@***.***> wrote: Hi, I have some days off and tested the MIDI USB interface today and yesterday. With the Roland Edirol PCR-800 and also the ESI M4U XL I had no issues. I am not sure if some kind of fix was integrated in the meantime. If you like please try the latest version of: https://github.com/marcel-licence/esp32_esp8266_organ Hitting multiple keys very quickly should generate output like this: short: 91 39 64 short: 91 3c 6f short: 91 3e 6f short: 91 40 69 short: 81 3c 6a short: 81 3e 65 short: 81 40 4f short: 81 39 54 The output is enabled in the project. For ESP32 only the define for MIDI_VIA_USB_ENABLED needs to be enabled. If you like please let me know what kind of result you get and also some debug output if problems appear. Best regards — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTDOQ6WXSE4GPASTUXIPNDUOYFAVANCNFSM5GDZZZ4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[MichaelPNolan]

It comes down to some kind of pause that happens every now and then such as a low level memory clean up or some delay and wait state that happens intermittently ... because when I would test all would be find, just as you show ... i mean you have to play for a while and a note or many notes come suddenly hanging. What shouldn't happen ... happens because the system pauses. With the current changes that seems to happen less frequently. Regards Michael

…

On Fri, Dec 10, 2021 at 3:44 AM Marcel ***@***.***> wrote: Hm I am not sure why you get different results. I do not use the interrupt pin. Using two tasks on core0 might decrease the performance because only one could be active at the time. That was the reason to put all into one function to ensure that there are no unexpected delays. I made a test with the organ project putting a delay(500); in the loop function. It looks like the USB host can buffer some messages (enough for a complete chord). Only if I play two many notes in the short time I can get losses and also see cc cc cc in the debug output: short: 91 46 4d short: 91 46 4d short: 81 46 1a short: 81 46 1a short: 81 43 6f short: 81 43 6f short: 81 40 6a short: 91 43 5c short: 81 40 6a short: 91 43 5c short: 81 3c 42 short: 91 46 4d short: 81 3c 42 short: 91 46 4d short: cc cc cc short: 81 46 1a short: cc cc cc short: 81 46 1a short: cc cc cc short: 81 43 6f short: 81 43 6f Adding an OLED should be feasable. In most designs I am using OLED + SPI controlled by core0 with a good performance. The SS connection is requied I think. If chip select would be floating you could get random results. I am not sure but I think it also helps to identify the first bit of transmission and avoiding communication problems especially with a high SPI frequency. I pushed a little change on GitHub. I tested this with two changes in the config.h and the following defines active: #define BOARD_ESP32_DOIT /* activate this when using the DOIT ESP32 DEVKIT V1 board */ #define MIDI_VIA_USB_ENABLED — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTDOQ6QPQVSLXLXIMIDPNDUQEIMBANCNFSM5GDZZZ4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[MichaelPNolan]

Thanks for your attention: I'm ending this here.

• i'm saying that its hard because ... everything is edgy. Power - design - code once you start changing and extending or soldering it together.
  1: I can confirm that your code can run without glitches
  2: In certain cases ... it seems like its power fluctuations to the USB host when driving it from the 3.3v rail of the ESP32
  a) I always had a 104 cap but in different versions of the build I put a bigger cap like 22uf or 100uf which improved the situation and it is now almost certain that if there is a power shortage then of the system can keep running but the USB host will drop notes ... which shows how resilient it is that it doesn't crash but has communications issues.
  3: In certain cases its not the power but it's my coding of SSD1306 adafruit library and realted oled GUI that I wrote - so the more I prevent it from doing anything other than when I'm doing a parameter change the less interference there is.
  So ... my ideas kind of mitigated hardware or software issues. I think the 2 different task0 with different priorities is actually a good setup that lets it fire off at a higher priority and so it doesn't really make it so inefficient since there is a lot of idle (wait) time.

I think the extra time polling is perhaps only helpful for the power shortage drop outs and its therefore not the correct approach. So a better power supply and well done bypass caps will improve the USB stability as one would expect.

Regards
Michael

[marcel-licence]

Hi Michael,

just a short question, did you also provide 5V to the USB host module? I've added a second power source to provide the 5V for the attached device for supply.

Best regards,
Marcel

[MichaelPNolan]

Yes - i either powered it with an additional psu, or I powered it from the vin pin. On testing systems I have a 5v 2A PSU that routes in parallel to USB +5 rail (which I cut the track on the USB_HOST so it doesn't share power with the Vss of the USB_HOST as shown in some demos) that way the 3.3v is independent. What I haven't done yet is run 3.3v from a regulator of my own AND 5v. I rely on the ESP_32 dev board regulator and it is supplying the oled, usb_host, DAC and some buttons. So - yeah, it can be perhaps sagging at times. So I have now some more regulators to make a better PSU for it. Regards Michael

…

On Tue, Dec 14, 2021 at 2:03 AM Marcel ***@***.***> wrote: Hi Michael, just a short question, did you also provide 5V to the USB host module? I've added a second power source to provide the 5V for the attached device for supply. Best regards, Marcel — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTDOQ3KQRBFTPNZ45F6WMLUQY7PVANCNFSM5GDZZZ4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[MichaelPNolan]

Incase you get back to this thread here are some new observations:

So I have made a bunch of synths ... and I keep going slowly playing around. The last few all went to Serial MIDI so this thread was kind of quiet.
Today I built a new ESP32 based ml_synth_organ and added USB_Host and ... there we were again in the land of lost and hanging notes. I had actually gotten my other 2 that have USB Hosts to work fine. One of them with your normal USB_Midi_Host library and another with that loop in the UsbMidi_Poll(). I started wondering about voltages and stability.
So I put bypass caps and made sure all the power is more than adequate and smooth. Yes the USB supplies 5v but its not connected to the 3.3v. These days I also add my own additional 3.3v regulator to make sure the pots and whatever else have no sag drawing from the ESP32 dev kit boards 3.3v supply. None of this fixed the problem.

Next I loaded my last version of ESP32_Basic_Synth code and ... perfect, no problem with lost notes and that code has the extra iterations in the midi_poll() function.

Another consideration is that I'm using the ADC Module in my implementation of the ml_synth_organ as well as a 7seg display that I've specifically built. These are running in the same I've written very quick shift register (shift_out) function so that doesn't create much overhead. The reading of the analogue does seem to take enough time to impact the reliability of getting midi notes. Its all about polling fast enough and polling with the loop to catch up on the queue in case a lot of notes trigger together. I changed it to just read one analogue potentiometer and I service that only once ever 10 times (so I guess 12 milliseconds) which has no negative impact on usability. I can probably do it far less frequently or even just process one analogue channel per call instead of looping through them all.

void Core0TaskLoop()
{
    /*
     * put your loop stuff for core0 here
     */
    process7seg();
#ifdef MIDI_VIA_USB_ENABLED
    UsbMidi_Loop();
#endif
    
#ifdef ADC_TO_MIDI_ENABLED
    loop0++; 
    if(loop0>10){
      AdcMul_Process();
      loop0=0;
      
    }
#endif /* ADC_TO_MIDI_ENABLED */


#ifdef OLED_OSC_DISP_ENABLED
    ScopeOled_Process();
#endif
}

So ... what i'm saying is that

1. We know that too much delay will lose notes
2. I am more confident having several soldered together projects as well as using the breadboard that it isn't some power deficiency or floaty ground mistake.
3. I can run multiple sets of code to get different results
4. There does seem to be some validity to my approach when other code is delaying the calls.

Finally:
This bums me out that we are delaying when we could be using the time for servicing. Yet I can't find a solution to replace delay(1); with a shorter delay that doesn't mess up the stability of the software.

    while (true)
    {
        Core0TaskLoop();

        /* this seems necessary to trigger the watchdog */
        delay(1);
        yield();
    }

[marcel-licence]

Hm, hard topic. The delay(1) and yield() is maybe not the perfect solution. It shouldn't harm the code but it is required otherwise the core might crash.

I couldn't see any serious difference. One important feature is missing: a buffer overflow indication. That would help to identify to slow code. In all other cases the usb host should be able to store messages until they are pulled out.

Finally I do not use the RTOS as it is designed. The while true does not allow the RTOS to do its thing and take care of different tasks. I have only two tasks designed. The rest will be handled by DMA or interrupts.

I think I will try to make a little USB to MIDI host project which can be connected to the synth. There are some possibilities.

[MichaelPNolan]

I'm going to try and make an interrupt service routine that is very fast for the USB_Host. I was using the USB_Midi as per your code in this situation but had to start playing to make it playable. Anyway, I'm happy to merely report what I find.

…

On Thu, Feb 17, 2022 at 2:11 AM Marcel ***@***.***> wrote: Hm, hard topic. The delay(1) and yield() is maybe not the perfect solution. It shouldn't harm the code but it is required otherwise the core might crash. I couldn't see any serious difference. One important feature is missing: a buffer overflow indication. That would help to identify to slow code. In all other cases the usb host should be able to store messages until they are pulled out. Finally I do not use the RTOS as it is designed. The while true does not allow the RTOS to do its thing and take care of different tasks. I have only two tasks designed. The rest will be handled by DMA or interrupts. I think I will try to make a little USB to MIDI host project which can be connected to the synth. There are some possibilities. — Reply to this email directly, view it on GitHub <#70 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTDOQ3JY2QTYBSPTYMDWIDU3PZEPANCNFSM5GDZZZ4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: <marcel-licence/esp32_basic_synth/repo-discussions/70/comments/2191100@ github.com>