-1

In the MIDI library from the Arduino (FourtySeven MIDI library), there exist a function to get the length and bytes of a System Exclusive message:

Functions

getSysExArray()
template<class SerialPort , class Settings > 
const byte * MidiInterface< SerialPort, Settings >::getSysExArray 

getSysExArrayLength to get the array's length in bytes.

However, since the Arduino Mega (in my case) has only 8 KB of memory, how can I get a MIDI SysExclusive message which is longer?

Also, I even have added a 128 KB SRAM (23LC1024), but that doesn't help me if I cannot store it in pieces.

Ignacio Vazquez-Abrams mentioned I should 'read' the message, however what message do I get if the system exclusive message is too large to be stored in (internal) SRAM? The read message (see here also does not have a partial read.

Update:

After a test with a large message, it seems the message is not received by the Arduino MIDI library.

| improve this question | |
  • That's why you have to do it on the fly instead of relying on a function for it. – Ignacio Vazquez-Abrams Jul 23 '17 at 22:28
  • 3
    If you really, really want to do this, you'll need to rework the library internals to make use of your external memory, or else extract what you actually care about on the fly. Realistically you have chosen the wrong board for this task. You should look into using something with ample directly mapped memory instead, if you anticipate wanting to deal with very large messages. Possibly a large Cortex-M part (maybe a high end Teensy?) or perhaps a small embedded Linux board with megabytes of dynamic RAM. – Chris Stratton Jul 23 '17 at 22:44
  • 1
    That may depend on what exactly you mean by fast latency and how far into the kernel you can push the critical parts. Though a very good architecture can be to have a small MCU that does simple fast tasks and is supervised by a larger "embedded computer" which does more data intensive communication ones. – Chris Stratton Jul 23 '17 at 23:02
  • 2
    Do realize that anything coming over midi streams in byte by byte over the serial link - if you have logic to find the start and end of regions of interest, you can start writing that out to memory as received, and then return to ignoring what you don't care about. It's also at a slow enough rate to do some processing as the data arrives, and should not be a problem for an embedded operating system as long as you use a real serial port and not one tunneled over a laggy USB connection. – Chris Stratton Jul 23 '17 at 23:05
  • 1
    For minimum latency try to avoid sending the data on a round trip over RF. Instead, use commands sent via RF to alter an algorithm which processes it locally. That said, you can just stream the serial data over the RF link, process it there, and send it back. Midi data rates are pretty slow compared to what 2.4 GHz digital radio modules support. It's only if you need to allow retries or have a bad packetization algorithm that you hit latency problems. – Chris Stratton Jul 23 '17 at 23:07
1

This library tries to make its programming interface as simple as possible, which means that SysEx messages are put completely into a buffer in the internal memory, which means that larger messages cannot be handled.

The only way to handle larger messages is to read the bytes directly from the serial port, and parse the MIDI messages yourself. (The MIDI specification has a helpful flowchart about MIDI parsing in the first appendix.) When you have detected the start of your large SysEx, you can then do whatever you want with the following bytes, e.g., handling them as a stream, or write them to external RAM)^.

| improve this answer | |
  • Thanks for your answer ... I'm sure I will be able to read it directly without the library, and possibly I will go that way later. But not to continuously change my 'design', I continue for now with the MIDI library and using your way (reading directly from Serial) later. But very good to know it can be done that way fairly easily. It would even reduce the latency further if I can start handling bytes already without having to wait for the entire message, especially for critical latency messages (mostly non system exclusive messages). – Michel Keijzers Jul 24 '17 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.