Surrounded all std::err calls regarding message queue limit reached with debug check to prevent flooding of output console

[basshelal]

Fixes #236

Surrounded all std::err calls regarding message queue limit reached with a #if defined(RTMIDI_DEBUG) in order to prevent console flooding when message queue limit is reached.

I filed this issue a while back and no one responded to me whether I was correct or not in my observations/assumptions so I took matters to my own hands.

[garyscavone]

It seems to me that overfilling the queue is a fairly big problem, as messages are then discarded. While printing a message about that problem to std::cerr is perhaps not the best option, I don't think I would want to hide it behind a RTMIDI_DEBUG flag, as most people probably don't compile with that defined. The point is that the user/developer should attempt to keep the queue as empty as possible, no? I took a quick look at issue #236 but it seems to me the problem reported there is more related to usage than a problem with RtMidi.

It would be nice if this "error" could be reported through an error callback function but it might take some work to allow that to happen (since it is inside a system callback).

[basshelal]

Thanks for the clarification and for getting back to me.

If the queue is so important, then yes I agree, hiding it behind the debug flag is a bad idea.

A question regarding the queue though:

How is the queue important from an API point of view, particularly the C interface (I'm building bindings using the C interface)?

From what I could gather, it is only useful for C API users in rtmidi_in_get_message(), where, if the queue is filled, then yes, new messages are indeed discarded instead of being placed into the queue until they are popped from the queue using that same function.

I ask because my bindings don't implement rtmidi_in_get_message() (instead preferring only callbacks) but I do implement rtmidi_in_create(...) ie custom api, clientName and (forced to implement) queueSizeLimit.

If I am right and the queue is only useful for C interface users in rtmidi_in_get_message() and that's it, then I know what to do (see below if interested). Otherwise, please let me know if I'm wrong. I'm in my final stages of design and testing for the bindings and I'd like to know about how to solve this issue.

I'll probably have to solve this issue by making users of my bindings have a flag to suppress the output messages of RtMidi. I use JNR to do the Java to native (C) calling so I'll have to figure out some way to hide these queue messages from the Java console.

[keinstein]

The end user usually can't empty the queue in time. So the people to address are the developers. The best thing RtMidi can do is to inform the calling software. Flooding the logs is never a good idea. If the real cause for the queue overflow is reported it will easily get lost or overseen.

[garyscavone]

I'm not sure what @keinstein is suggesting in the previous comment. To me, the end users of RtMidi are the developers. And why can't people empty the queue in time? The queue can be made larger if that seems to be a problem, though personally I would use the callback scheme rather than the queue if I was developing a MIDI program.

[keinstein]

I'm suggesting to report to the calling software and not to the user of that software. RtMidi is often hidden in some interactive GUI. The end users usually don't see any messages regarding the queue. In their opinion the software should handle these issues (like increasing buffers etc.). But the software dosn't know about the problem because the problem is reported to the end user bypassing the software and thus bypassing the influence area of the developer.

I see only two solutions: Error callbacks or error flags.

@garyscavone I agree with you, that callbacks more follow the realtime paradigm. The queue comes into play when developers don't need exact timing and don't want or can't restrict themselves to functions with predictable run time. Especially JACK is very picky when it comes to violations of the time constraints.