ktmidi 0.6.2 release

[atsushieno]

Happy holidays! Today I tagged and released ktmidi version 0.6.2 to Maven Central (I released it just now, so it would take a while for it to actually show up).

It is more or less "celebrating revive of development environment" release (as I have been quite unable to work on it on macosx-arm64 until I could migrate to rtmidi-javacpp solution from a few days ago).

ktmidi 0.6.2 introduces some API breakages. I'm sorry if you are affected, but we often need them (and for not-that-unnecessary changes, please bear with that as there are API parts that are still evolving).

(The API diff tool, Metalava, Gradle integration has been unavailable until I can switch to Gradle 8.x... it brought in build breakage very easily, as well as plugin incompatibility with earlier versions of Gradle) very recently, and even when I brought it back, temporarily by enabling Gradle 8, the API output options could not be the same as what we generated earlier with Metalava before.)

Anyhow, here are the highlights for this release.

ALSA and RtMidi backend changes

• RtMidiAccess backend has replaced its binding parts from atsushieno/rtmidi-jna to atsushieno/rtmidi-javacpp. rtmidi-jna has been dependent on JNAerator which had stopped maintenance for years, and it lacks support for non-x86/64 CPU on any platform.
  • rtmidi-jna builds on Apple Silicon, and I believe they build on Linux Arm64 and Windows Arm64 too - they do not exist on GitHub Actions and unlike Kotlin Multiplatform gradle-javacpp does not have any intuitive cross-compiling options so far, so they are left unverified.
  • (There have been long struggle with the packaging and package resolution that resulted in release delay...)
• midiProtocol property on virtual MIDI PortCreatorContext makes it support MIDI 2.0 protocol on a virtual MIDI port. It is based on what MIDI 2.0 June 2023 updates expect (in other words, it does not expect promotion via Protocol Negotiation on each port). Right now, AlsaMidiAccess is the only backend that supports this property.
• ALSA backend (AlsaMidiAccess): we have revamped the way how atsushieno/alsakt builds. Now alsakt bundles libasound.so version 1.2.10. With this change, now even if you have Linux Kernel 6.5 without libasound.so 1.2.10 (e.g. you installed kernel-6.5 on Ubuntu 22.04 stable release), alsakt and ktmidi apps would still work with the latest ALSA version. It is important for midiProtocol support.
• The latest AlsaMidiAccess comes with a handful of bugfixes that made virtual connections simply impossible.

improvements on incomplete SysEx handling

Thanks to @AlecJY, there have been a couple of SysEx handling improvements:

• Support multi-packet sysex messages in JvmMidiAccess (Support multi-packet sysex messages in JvmMidiAccess #53)
• Fix sysex processing in Midi1 (namely F7h support) (Fix sysex processing in Midi1 #54)

MIDI-CI improvements (ongoing)

• Following ktmidi v0.5.0, MIDI-CI support has been upgraded to MIDI 2.0 June 2023 Updates. There has been various breaking changes in CIFactory, CIRetrieval, CIInitiator and CIResponder (and there will be more, it's highly evolving area at the moment).
• Now we have partial Property Exchange support in CommonPropertyService class, used as CIResponder.propertyService property. It's not much useful yet, but we could evolve it to have real MIDI-CI based MIDI 2.0-ish apps.
  • I have been using JUCE v7.0.9 which comes with a new juce-midi-ci module and its CapabilityInquiryDemo app to confirm interoperability. I still did not build any useful app yet (only patching kmmk locally for now) but I hope to come up with something useful for exploring MIDI-CI devices.
  • It comes with our own dev.atsushieno.ktmidi.ci.Json implementation (I avoided adopting kotlinx.serialization just for this JSON serialization in Property Exchange. MIDI-CI Common Rules for Property Exchange also comes with some restrictions on their JSON header construct and our own implementation would work better in the future.