Open lathoub opened 4 years ago
Good reading on Active Sensing
Another reading on impact of Active Sensing (in Dutch)
The load that Active Sensing would mean for your midi data is heavily overestimated by some. First of all, the command 'only' is sent three times per second and only consists of 1 byte. But more important is that it is only sent when there is no other midi activity. As soon as notes or other midi data pass through the cable, Active Sensing stops. It is therefore virtually impossible for delays in your midi data to be caused by Active Sensing. It is only there when it is needed. At times when other mididata go through the cable, there is midi-activity and therefore Active Sensing is superfluous. After the last midi event has been sent, Active Sensing starts rattling again. Until another midi event is sent.
Translated with www.DeepL.com/Translator (free version)
The terminology for timeouts could be improved, it's not an error but a valid event of the lifetime of the MIDI stream. An error would be if something unparsable or very much unexpected happened, like one of the few unreachable places in the parser.
The terminology for timeouts could be improved, it's not an error...
I kinda agree, the naming for the handler Error
came out of a Parsing error. In the case of ActiveSensing Exception
would be better. A start would to rename
to ActiveSensingTimeoutException
(but the handler is still called ErrorCallback
, it would have been better to have called it the ExceptionHandler).
Also the Exception-bits should be in an enum....
Could it be its own event ?
void onActiveSensingTimeout()
{
// Loss of MIDI activity detected
}
MIDI.handleActiveSensingTimeout(onActiveSensingTimeout)
This would make it opt-in and avoid writing additional code to figure out the type of error or exception in a generic handler.
Just implemented the 'having it's own handler' and its memory neutral (balanced the additional bit checking code calling the error handler)
How do we call this thing?
using ActiveSensingTimeoutCallback = void (*)(bool active);
or
using ActiveSensingExceptionCallback = void (*)(bool timedOut);
...
I'd go for active, false
on timeout and true
when stream resumes activity.
false on timeout and true when stream resumes activity.
Active Sensing tested (both receiver and sending)
@franky47 This has been out for a while (a reworked and optimized version of the current ActiveSensing), is this something to be considered for the next update?
Yes we can include this in the next release.
Active Sensing
2 types of Active Sensing, receiving and sensing of Active Sensing. Work has been based on re-reading literature and online MIDI implementation manuals from various manufacturars.
receiving Active Sensing
Once an Active Sensing message is received, the unit will begin monitoring the interval between all subsequent messages. If there is an interval of Settings::ReceiverActiveSensingTimeout ms or longer between messages while monitoring is active, the
ErrorActiveSensingTimeout
flag is set and the Error callback is called. It is up to the application to stop All Notes. The unit will then stop monitoring the message interval.Turn on receiving Active Sensing using the overwritten
UseReceiverActiveSensing
in SettingsSending Active Sensing
ActiveSensing is send
Settings::ActiveSensingPeriodicity
ms after the last commandTurn on sending Active Sensing using the overwritten
UseSenderActiveSensing
in SettingsNote:
Both
UseReceiverActiveSensing
andUseSenderActiveSensing
can't be set to true, it's one or the other.Serial Settings Example (Hairless MIDI)
Add Hairless example (but currently unrest as hairless is not supported on MaxOS Catalina 64bit)