Musescore is sending lots of midi garbage data!
Hi,
I'm testing the Musescore with some hardware devices connected as midi output, I have noticed after monitoring the Musescore midi output that it sends midi note off for all 128 notes and always resets CC and pitch-bend midi messages as if it was sending a midi Panic! This causes an overload of information that results in huge delays on the external devices being played!
I don't think this is necessary, there is only the need to keep track of the played notes an nothing more, at most you can have the Program Change and even that why don't let the external devices be configured as they are without any Program Change being send? Why make a mess?
Am I missing something? How to configure just to send the midi Note on and off being played and nothing else? Otherwise the software becomes unusable with external instruments!
Thanks
Comments
I checked this, out of interest - see the attachment of a score and the resulting MIDI events of an initial segment, as recorded by Reaper with the ReaControlMIDI FX.
Yes, the default leaders and trailers are quite heavy; and if multiple staffs use the same MIDI channel (as my piano), the leaders/trailers are sent multiple times; I'll create a (medium-prio?) issue for that.
Also there seem to be unnecessary CC2 messages - I'll open another issue for that.
"Problem" is that in 2017, the stance was:
We were (and still are) worried that if we offer minimal support for MIDI out, we would get many feature requests to improve it, sometimes in ways that are not possible, or that we prefer to not spend our time on, or that would make MuseScore complex to use for users who don’t care about MIDI.
These are valid concerns; arguments for improvement need to consider them.
H.M.
In reply to I checked this, out of… by hmmueller
Hi, thanks for your reply,
Yes, I read that statement too, but the interesting thing is that the improvement requires less than more, so let's see:
LESS:
1. No need for pitch bend messages;
2. No need for CC messages as you said;
3. No need to send all off notes at the beginning (to release what?) (starting with 128 unnecessary messages, worst delay of all);
4. No need to Program Change because it's only able to achieve 128 programs when the modern devices have 16x that with CC messages, not to mention that many instruments get unresponsive for a while after a Program Change (could be optional though).
MORE (Not critical):
1. A panic button if the worry of unreleased keys and badly configured CC parameters is that great;
2. Instead of 128 notes off messages at the end it would be better to keep an uint16_t[8] array of integers resulting in 128 bits (8*16) for each key status (1 for pressed) and release only those that remain as 1 at the end (bitwise operators for each uint16_t > 0).
I understand that even if simple it will always require some work, nevertheless I strongly believe that these changes will add a lot of functionality to the software.
I know some C++ I even did some stuff in midi so I'm familiarized with bitwise operators in regard to keep the keys status and send the absolute needed messages (ex. note off). Unfortunately my knowledge is more about micro controllers than computer software. I would like to help though!
Best regards.
In reply to Hi, thanks for your reply,… by seixasrui
"the improvement requires less than more" ... hm. Software is a beast - I can tell you as a software architect. In many cases it is easier (even much easier) to just call a standard function that "does everything" - here, "resets all MIDI things".
Going the fine-grained route, i.e. knowing when to send what or not, requires much more work. I assume that this is the reason for these reset sequences of MIDI events.
In my piano example, one can see that the same long reset sequence is even sent twice on the same channel; the reason is probably that there is not even a simple boolean state variable (per channel) in MuseScore that would remember whether this reset sequence was already sent. But, to be fair, handling such a state variable creates (well-understood, but still) problems: (a) the design might change from a stateless one to a stateful; (b) the flag must be reset on all non-resetting events - if there is no single entry-point for all these events, this might pollute more code than one likes; (c) testing gets harder, as always with stateful systems. But of course, as your complaint shows, stateful systems can (could) be much more efficient than stateless ones ... but I digress more and more.
Let's hope one of the MuseScore developers finds some fun in optimizing away these large reset sequences ...
H.M.
In reply to "_ the improvement requires… by hmmueller
Ok, I understand that, delegation is better than DIY. But even so, in this case the problem is the reset done at the beginning not the delegation itself, so, it's a matter of doing it or not. At the end it makes sense because the playing changed the sate of the Instrument while sending notes to it, however, at the beginning there is no need to reset anything because no state of the plugged in instrument was yet changed, that's my point, and I don't believe both reset actions at the beginning and at the end are absolutely dependent on each other.
The only reason I see for starting playing with a reset is to get the Program Change of the respective configured instrument, and if so it brings more problems than the ones it tryies to solve as you already realized.
I also noticed that this behavior propagates to the exported midi files, meaning that due to the limited midi bandwidth, like 2 midi messages per millisecond, so the first Note On midi messages will start to be played with an audible delayed timing (128/2 = 64ms). On top of that, forcing Program Change on all scenarios will be disruptive on some instruments, so in conclusion, there are many reasons to make the starting reset optional.
I was made to believe that the essence of musescore were the notes and nothing else as your initial quoted statement seems to imply.
Rui