Added support for Active Sensing and SysEx command segments (v4.4.0) #138

lathoub · 2020-02-04T09:47:47Z

Added Sender Active Sensing - switch in Settings

Active Sensing is intended to be sent repeatedly by the sender to tell the receiver that a connection is alive. Use of this message is optional. When initially received, the receiver will expect to receive another Active Sensing message each 300ms (max), and if it does not then it will assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation..

From: https://www.midi.org/specifications/item/table-1-summary-of-midi-message Active Sensing. This message is intended to be sent repeatedly to tell the receiver that a connection is alive. Use of this message is optional. When initially received, the receiver will expect to receive another Active Sensing message each 300ms (max), and if it does not then it will assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation.

Receiver active Sensing is not implemented (yet)

Very long SysEx mesaages are cut in to multiple command segments Where a normal SysEx starts with F0 and ends with F7, the first segment will start with F0 and end with F0, the middle section (optional) start with F7 and ends with F7 - the last segments starts with F7 and ends with F0

lathoub · 2020-02-10T14:15:29Z

continuous-integration fails due to the use of mills() in the code, not sure how to fix it.

… other serializers lift and shift of the Serial code into a seperate class, allowing for other serializers as AppleMIDI, USBMIDI, ipMIDI, BLE-MIDI

lathoub · 2020-03-04T18:55:26Z

lift and shift all Serial code into a separate class (serialMIDI), allowing for other serialisers, such as AppleMIDI, USBMIDI, BLE-MIDI, ipMIDI

The code is smaller than the standard 4.4.0 release (4108/337 vs 4126/370), no speed penalty.

(Checks fails because of the use of millis() - which should be totally fine)

lathoub · 2020-03-04T18:56:07Z

@franky47 What are your plans with feat/4.4.0?

Avoids reparsing of the stream in the transport layer, in order to get the MidiType

franky47 · 2020-03-07T07:29:12Z

src/midi_Settings.h

@@ -70,7 +70,7 @@ struct DefaultSettings
    termination, the receiver will turn off all voices and return to
    normal (non- active sensing) operation..
    */
-    static const bool UseSenderActiveSensing = false;
+    static const bool UseSenderActiveSensing = true;


The default should probably be false to avoid spamming other devices. It can be an opt-in behaviour when disconnection detection is desired.

I've been thinking about it as well, some devices have it as default (Roland, and recently a Cinara box), other don't. Happy to switch it off.

Gives more control over the bool value. Typical value is 300 (ms) - an Active Sensing command is send every 300ms; or 0 (zero) to disable sending ActiveSensing

franky47 · 2020-03-07T09:30:15Z

src/midi_Namespace.h

@@ -27,7 +27,7 @@

 #pragma once

-#define MIDI_NAMESPACE                  midi
+#define MIDI_NAMESPACE                  midi_v440


Changing the namespace here will break existing code that references it directly (eg: midi::ControlChange)

…serialMIDI

before the specific callback are called, a generic mMessage callback can be fired to inform the user that 'a' message has been received.

added send(MidiMessage) for Bridge application (that convert MIDI transport x into MIDI transport y), avoiding parsing entry a stream, setting up all callback - whilst this allows for passing the content, without to much processing/parsing. Had to move mPendingMessageExpectedLenght into MidiMessage to avoid parsing the data again, just to know the size Added Bridge example (untested)

franky47 · 2020-03-11T19:48:43Z

src/serialMIDI.h

+
+public:
+	void begin(MIDI_NAMESPACE::Channel inChannel = 1)
+	{


This should probably call mSerial.begin ?

The opposite, the MidiInterface will call this method.
See in MIDI.hpp:

template<class Transport, class Settings, class Platform> void MidiInterface<Transport, Settings, Platform>::begin(Channel inChannel) { // Initialise the Transport layer mTransport.begin();

franky47 · 2020-03-11T19:52:15Z

src/serialMIDI.h

+BEGIN_MIDI_NAMESPACE
+
+template <class SerialPort>
+class serialMIDI


Can you name it with an Uppercase first letter ? Just to be consistent with the rest of the coding style, thanks ! :)

franky47 · 2020-03-11T19:52:37Z

src/midi_Settings.h

-    http://projectgus.github.io/hairless-midiserial/
-    */
-    static const long BaudRate = 31250;
+    static const bool Use1ByteParsing = false;


We should keep the BaudRate as a setting, as some sketches use it, even though there might be better transports, I'd like to minimize breaking changes. But that means the Settings will have to be passed as a template argument to SerialMIDI.

I noticed that mSerial.begin was not called :-( - so added.
Also added DefaultSerialSettings in serialMIDI.h

Requires modification of the test scripts!

franky47 · 2020-03-11T19:55:56Z

src/MIDI.hpp


    mThruFilterMode = Thru::Full;
-    mThruActivated  = true;
+    mThruActivated  = false;


To minimize behaviour changes, thru should stay active by default.

franky47 · 2020-03-11T19:57:19Z

src/MIDI.hpp

+ them thru.
+ */
+template<class Transport, class Settings, class Platform>
+void MidiInterface<Transport, Settings, Platform>::send(MidiMessage inMessage)


Maybe we should pass the message as a const ref, to avoid copies (better performance and memory usage): ::send(const MidiMessage& inMessage)

good catch!

- send: pass the message as a const ref, to avoid copies - add mSerial.begin (with Baudrate - added Settings) - ThruActivated defaults to true - class name serialMIDI => SerialMIDI

mMessage.length is reset to 0 before the callback, so bring back mPendingMessageExpectedLength as before, and set mMessage.length (and not reset it)

lathoub · 2020-03-30T19:18:40Z

Any objection to a "Squash and Merge"?

lathoub added 5 commits August 18, 2019 11:38

stuff to ignore list

fabf429

Update midi_Defs.h

a1bff07

replaced ActiveSensing with Sender Active Sensing

5fab6b3

Receiver active Sensing is not implemented (yet)

lathoub changed the title ~~Feat/4.4.0~~ Added support for Active Sensing and SysEx command segments Feb 10, 2020

lathoub changed the title ~~Added support for Active Sensing and SysEx command segments~~ Added support for Active Sensing and SysEx command segments (v4.4.0) Feb 10, 2020

lift and shift of the Serial code into a seperate class, allowing for…

fc752bc

… other serializers lift and shift of the Serial code into a seperate class, allowing for other serializers as AppleMIDI, USBMIDI, ipMIDI, BLE-MIDI

franky47 mentioned this pull request Mar 4, 2020

State of v4.4.0? #137

Closed

lathoub added 2 commits March 5, 2020 19:58

added Platform class to abstract millis()

1325c23

add MidiType to beginTransmission

1b6a755

Avoids reparsing of the stream in the transport layer, in order to get the MidiType

franky47 reviewed Mar 7, 2020

View reviewed changes

lathoub added 3 commits March 7, 2020 08:37

active sensing defaults to false, to avoid spamming devices

771f923

set ActiveSensing Periodicity in ms

35d1d62

Gives more control over the bool value. Typical value is 300 (ms) - an Active Sensing command is send every 300ms; or 0 (zero) to disable sending ActiveSensing

added namespace reference

08ab5b9

franky47 reviewed Mar 7, 2020

View reviewed changes

lathoub added 3 commits March 9, 2020 09:00

renamed Encoder -> Transport, added MidiType to beginTransmission in …

7bb6407

…serialMIDI

added callback for Message

8905d36

before the specific callback are called, a generic mMessage callback can be fired to inform the user that 'a' message has been received.

franky47 requested changes Mar 11, 2020

View reviewed changes

lathoub added 7 commits March 11, 2020 22:46

changed based on Franky47's feedback

ee4e7b3

- send: pass the message as a const ref, to avoid copies - add mSerial.begin (with Baudrate - added Settings) - ThruActivated defaults to true - class name serialMIDI => SerialMIDI

return reference to Transport layer

4da4538

return a *pointer* (not a ref) to the transport layer

e7588b9

mPendingMessageExpectedLength as before

2734894

mMessage.length is reset to 0 before the callback, so bring back mPendingMessageExpectedLength as before, and set mMessage.length (and not reset it)

DefaultPlatform for Arduino

8fc25fa

strong typing Channel in the callbacks

bc4e940

aliasing for callbacks (and default initializers

c09c8e8

lathoub added 28 commits March 24, 2020 18:03

restored after very funcky commits and rollbacks (Sorry!)

1a59ff0

add Transport layer

32b29d8

removed SerialMock test

c40b37b

Update unit-tests_MidiInput.cpp

a87edb6

Update unit-tests_MidiInput.cpp

8c651f8

Update unit-tests_MidiInput.cpp

cd6fada

Update unit-tests_MidiInput.cpp

406b817

fixed MidiInterface<SerialMock => MidiInterface<Transport

cfb28c3

SerialMIDI should not aware of the channel

7d3064d

Update unit-tests_MidiThru.cpp

8ea424c

Update midi_Defs.h

b3a9854

avoid shadow parameters and buf fix

0474a92

Update CMakeLists.txt

2be7305

Update unit-tests_MidiOutput.cpp

02b8796

Update midi_Settings.h

a83ad9a

Update unit-tests_MidiInput.cpp

7e9923d

Update unit-tests_MidiInput.cpp

3851fae

Update unit-tests_MidiInput.cpp

141fb5e

tmp removed teensy, bug fix sendCommon (unsigned, not byte)

2a75b1f

Update unit-tests_MidiInput.cpp

ed5c218

fix for Leonardo

6d63231

Update DualMerger.ino

ec6f611

adding tests_MidiInputCallbacks

1600ef3

Update unit-tests_MidiInputCallbacks.cpp

bf24cca

preparing to release 5.0.0

d9827a4

added Alternative Pin for Serial port example

1eb1425

default listen on all channel as in #96

478b05e

Update unit-tests_MidiInput.cpp

9227717

franky47 merged commit 2c657a3 into FortySevenEffects:feat/4.4.0 Apr 8, 2020

Added support for Active Sensing and SysEx command segments (v4.4.0) #138

Added support for Active Sensing and SysEx command segments (v4.4.0) #138

Uh oh!

Conversation

lathoub commented Feb 4, 2020

Uh oh!

lathoub commented Feb 10, 2020

Uh oh!

lathoub commented Mar 4, 2020

Uh oh!

lathoub commented Mar 4, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lathoub commented Mar 30, 2020

Uh oh!

Uh oh!