Release 1.5

Author: brunchboy

CHANGELOG.md

@@ -6,6 +6,11 @@ This change log follows the conventions of
 
 ## [Unreleased][unreleased]
 
+Nothing so far.
+
+
+## [1.5] - 2020-10-24
+
 ### Fixed
 
 - It is now possible to send long SysEx payloads split across multiple
@@ -28,6 +33,7 @@ This change log follows the conventions of
   38](https://github.com/DerekCook/CoreMidi4J/issues/38).
 
 
+
 ## [1.4] - 2020-02-09
 
 ### Fixed
@@ -56,6 +62,7 @@ This change log follows the conventions of
   whenever code is pushed to the master branch on GitHub.
 
 
+
 ## [1.3] - 2020-01-03
 
 ### Fixed
@@ -66,6 +73,7 @@ This change log follows the conventions of
 - A mistake in the sample code in the project Read Me, thanks to
   [@git-moss](https://github.com/git-moss).
 
+
 ## [1.2] - 2019-09-05
 
 ### Fixed
@@ -79,6 +87,7 @@ This change log follows the conventions of
   `<Unknown device>`. We now use a slightly more complex but reliable
   mechanism, so device names should always be available.
 
+
 ## [1.1] - 2017-09-16
 
 ### Fixed
@@ -129,6 +138,7 @@ This change log follows the conventions of
 
 - Dependencies and build tools were updated to their latest releases.
 
+
 ## [0.9] - 2016-08-23
 
 ### Added
@@ -138,6 +148,7 @@ This change log follows the conventions of
   version of CoreMIDI4J which is in use. (If this method is not found,
   then the version is unknown, but must be 0.8 or earlier.)
 
+
 ## [0.8] - 2016-07-03
 
 ### Fixed
@@ -151,6 +162,7 @@ This change log follows the conventions of
 
 - Dependencies and build tools were updated to their latest releases.
 
+
 ## [0.7] - 2016-04-20
 
 ### Added
@@ -176,6 +188,7 @@ This change log follows the conventions of
   CoreMidi4J as a Java extension, and recommend that you remove any
   older version you have placed in the Extensions directory.
 
+
 ## [0.5] - 2016-03-19
 
 ### Fixed
@@ -184,13 +197,15 @@ This change log follows the conventions of
   showing up with null values for their names, descriptions and
   vendors.
 
+
 ## [0.4] - 2016-01-18
 
 ### Fixed
 
 - MIDI Timestamps are now properly translated between Java and
   CoreMidi. This may be the only MIDI SPI which achieves this.
 
+
 ## [0.3] - 2016-01-09
 
 ### Fixed
@@ -227,7 +242,8 @@ This change log follows the conventions of
 - Initial Public Release
 
 
-[unreleased]: https://github.com/DerekCook/CoreMidi4J/compare/V1.4...HEAD
+[unreleased]: https://github.com/DerekCook/CoreMidi4J/compare/V1.5...HEAD
+[1.5]: https://github.com/DerekCook/CoreMidi4J/compare/V1.4...V1.5
 [1.4]: https://github.com/DerekCook/CoreMidi4J/compare/V1.3...V1.4
 [1.3]: https://github.com/DerekCook/CoreMidi4J/compare/V1.2...V1.3
 [1.2]: https://github.com/DerekCook/CoreMidi4J/compare/V1.1...V1.2

CoreMIDI4J/pom.xml

@@ -6,7 +6,7 @@
 
   <groupId>uk.co.xfactory-librarians</groupId>
   <artifactId>coremidi4j</artifactId>
-  <version>1.5-SNAPSHOT</version>
+  <version>1.5</version>
 
   <packaging>jar</packaging>
 

README.md

@@ -102,6 +102,28 @@ CoreMidi4J, and use its implementation of `getMidiDeviceInfo()`
 wherever you would otherwise have used the standard one, and your
 users will always only see working MIDI devices.
 
+### Watching for MIDI Device Changes
+
+If you would like to be able to automatically update your user
+interface when the user connects, disconnects, or powers on/off a MIDI
+device, you can call
+[`addNotificationListener(listener)`](https://deepsymmetry.org/coremidi4j/apidocs/uk/co/xfactorylibrarians/coremidi4j/CoreMidiDeviceProvider.html#addNotificationListener(uk.co.xfactorylibrarians.coremidi4j.CoreMidiNotification))
+(also provided by the `CoreMidiDeviceProvider` class). This will call
+register a listener method to be called whenever such changes to the
+MIDI environment occur.
+
+> NOTE: If you use `addNotificationListener` on a non-macOS system, it
+> needs to periodically scan the MIDI environment on a background
+> thread. We have learned that the version of `getMidiDeviceInfo` in
+> `javax.sound.MidiSystem` is not thread-safe, and if more than one
+> thread uses it simultaneously, it will return invalid devices which
+> throw exceptions when they are used. Because of that, you should
+> only use the version of `getMidiDeviceInfo` provided by
+> `CoreMidiDeviceProvider`, which uses synchronization to avoid this
+> problem. Even if you are not using `addNotificationListener`, our
+> version of the method is safer if you are using multiple threads for
+> your own purposes.
+
 For more details, you can consult the CoreMidi4J [API
 documentation](https://deepsymmetry.org/coremidi4j/apidocs/) or even
 the source code, or simply keep reading.