I'll try to ignore DIN MIDI stuff... however:
With the current code (Teensyduino 1.60) in usb_midi.c there is the following problem: If you (by mistake or for bug-finding purposes) send a SysEx without terminating 0xF7 then the data gets added...
The reason the MIDI specs allow for System Realtime Messages to be inserted into a SysEx transmission is to keep those "realtime" messages, erm, "realtime". I.e. if you send timing clock together with SysEx you want this to be sent at roughly the...
Looking at usb_midi.[h|cpp] it doesn't seem like that much extra work to add SysEx buffers per cable and add detection for implicit termination. But given the fact that there is even a commercial (with open-source code) Teensy based MIDI...
Exactly that. - That's why I went with interleaving my send code with calls to my input reading/parsing (in addition to a smaller USB_MIDI_SYSEX_MAX value). That also means if your MIDI library provides a function to write a larger buffer of...
Had a look at the "official" Teensy MIDI library. The function sendSysEx() does exactly what I do and writes all bytes to the serial output, one byte at a time. That means, in reality it writes it into a FIFO with most likely 64 bytes of size and...
I'm using my own "library". It can use very small SysEx buffers because it was initially developed for PIC16F where you can (almost) count available memory with the fingers of just one hand.
Found another workaround in the meantime: The SysEx...
I'm currently testing a Teensy 4.0 based USB <-> "DIN MIDI" interface. To make sure it passes large amounts of SysEx data correctly I tried a loopback test connecting the DIN MIDI out with the input and then from the computer sending out large...