All notable changes to this project will be documented in this file. This change log follows the conventions of keepachangelog.com.
Nothing so far.
1.1 - 2017-09-16
- Calling
close()more than once on aCoreMidiSourcewould lead to a crash as the same block of memory was attempted to be freed more than once. - Implemented the rest of the MIDI SPI contract for tracking and closing transmitters and receivers.
- We now close any devices (and their transmitters or receivers) when the underlying CoreMIDI device disappears.
- It turns out that Java instantiates many, many instances of our
CoreMidiDeviceProviderclass, each of which was getting added to the listener list to be notified when the MIDI environment changed, causing the device list to be rebuilt hundreds of times more than it needed to be. We now work around this by only calling the listener on the most-recently constructed instance.
- We now allow you to distinguish between multiple devices of the same type by showing the user-assigned name of the device (and of the port, if there is more than one port on the device), as discussed in Issue 21. This changes the names reported for many devices, as noted here.
- If the user changes a device or port name while Java is running, the device information is properly updated, although the device itself retains its object-level identity and opened state.
1.0 - 2017-05-14
- A long-standing crash or hang when trying to use CoreMidi4J from JavaFX was fixed by @mpsalisbury.
- You no longer
need to call
System.exit()to end your program even when MIDI environment changes have occurred while it was running. - A potentially uninitialized variable was fixed in the native code.
- Dependencies and build tools were updated to their latest releases.
0.9 - 2016-08-23
- A new static method
getLibraryVersion()inCoreMidiDeviceProviderso that client software can determine the 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
- The method name
removeNotificationListener()inCoreMidiDeviceProviderwas previouslyremovedNotificationListener(), which was inaccurate. - A variety of gaps in the API documentation were addressed.
- Dependencies and build tools were updated to their latest releases.
0.7 - 2016-04-20
- The native library is now bundled inside the CoreMidi4J jar and extracted automatically when appropriate, so CoreMidi4J can be embedded in other projects, avoiding the need for end users to install anything.
- An enhanced version of
getMidiDeviceInfo()is available for use in place of the standard one found injavax.sound.midi.MidiSystem. This version filters out the broken MIDI device implementations offered by the standard Mac Java MIDI environment.
- MIDI devices with null descriptons or vendors coming from the native library are no longer considered erroneous, and instead are given default values equivalent to what the standard implementations have.
- The installation instructions no longer recommend installing 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
- Under certain settings for system languages, MIDI devices were showing up with null values for their names, descriptions and vendors.
0.4 - 2016-01-18
- 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
- Running status bytes are now handled properly, as is interleaving of all other MIDI commands with bytes of System Exclusive messages.
- Multiple messages sent in the same packet, as well as multi-packet messages from CoreMidi are properly processed.
- Further progress towards supporting MIDI timestamps.
0.2 - 2016-01-01
- Handling of MIDI Timing Clock messages interleaved within the bytes of incoming System Exclusive messages.
-
Notifications of changes to the MIDI environment can now be requested.
-
First steps towards supporting MIDI timestamps.
- Initial Public Release