Active sensingv2

[lathoub]

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 Settings

Sending Active Sensing

ActiveSensing is send Settings::ActiveSensingPeriodicity ms after the last command

Turn on sending Active Sensing using the overwritten UseSenderActiveSensing in Settings

Note:

Both UseReceiverActiveSensing and UseSenderActiveSensing 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)

[coveralls]

Coverage remained the same at 89.363% when pulling 37ef1d4 on ActiveSensingv2 into ff3052c on master.

[lathoub]

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)

[franky47]

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.

[lathoub]

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

arduino_midi_library/src/midi_Defs.h

Line 64 in ff3052c

static const uint8_t ErrorActiveSensingTimeout = 1;

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....

[franky47]

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.

[lathoub]

Just implemented the 'having it's own handler' and its memory neutral (balanced the additional bit checking code calling the error handler)

[lathoub]

How do we call this thing?

using ActiveSensingTimeoutCallback = void (*)(bool active);

or

using ActiveSensingExceptionCallback = void (*)(bool timedOut);

...

[franky47]

I'd go for active, false on timeout and true when stream resumes activity.

[lathoub]

false on timeout and true when stream resumes activity.

Active Sensing tested (both receiver and sending)

[lathoub]

@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?

[franky47]

Yes we can include this in the next release.