-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase the sysex input buffer size on Windows #200
Comments
The value used by python-rtmidi is actually 8196 bytes (should probably be 8192). |
Interesting - in my tests, any messages over 1024 bytes are not received. FL Studio is able to receive these messages (using their alpha build where their buffer size is increased), so I am certain that this is an issue in Here is the code for the project I am using to test this: https://github.com/MiguelGuthridge/fl-sysex-overflow |
I'm sorry, but I don't currently have the time to debug this myself, nor do I have a Windows or FL Studio installation to test it with. On Windows reception of SysEx messages up to 8192 bytes length should be supported. At the moment I can only offer this advice:
If none of these options work for you, then I'm afraid python-rtmidi might not be the right tool for the job on Windows. The MultiMedia API RtMidi uses is fairly limited compared to ALSA on Linux or CoreMIDI on macOS. There is libremidi, which uses more modern MIDI APIs on Windows, but I don't know whether anyone has created a Python wrapper for it yet. |
According to the RtMidi Tutorial, RtMidi supports sysex messages with a maximum size of 1024 bytes. All larger messages are discarded.
A project I am working (https://github.com/MiguelGuthridge/Flapi) on uses sysex messages to communicate with an isolated Python environment, and this limitation on the size of messages makes receiving responses from the environment very unreliable.
Would it be possible to increase this buffer size in
python-rtmidi
to allow for larger messages to be exchanged? Making it 64KB or so would be a good compromise between reliability and low memory footprint.The text was updated successfully, but these errors were encountered: