bsl / bsl/send-sds

Utility gets confused when unexpected packets are returned on MIDI bus

Open
#7 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
22
Forks
7
PR merge metrics
No merged PRs in 30d

Description

I ran into two issues with my E-my ESi-32 on firmware 2.10, both which seem to confuse the utility and break sending of samples. Of course the problem lies with the hardware unit, but it can be solved in software.

The issues that I observed are:
- When initiating a MIDI Sample Dump, it sends a Time Signature packet that confuses the utility. The length of this Time Signature packet is variable, yet always larger than SDS_RESPONSE_LENGTH, so that breaks the utility's logic.
- The unit sends corrupted SysEx packets (I observe multiple Start-Of-SysEx bytes, like `F0...F0...F7`). This issue can be mitigated by dropped what was read so far upon detecting a new `F0` (SOX) while waiting for an `F0` (EOX)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating SDS_RESPONSE_LENGTH and the MIDI SysEx receive/parsing loop in the utility. Reproduce the E-mu ESi-32 responses described in the issue, then verify that unexpected Time Signature packets and a new F0 while waiting for F7 no longer disrupt sample sending.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, linux
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.