Use flows instead of interface listeners

[Burtan]

Hi,

I think it would be more idiomatic for kotlin to use flows for midi inputs instead of interface listeners. At least lambdas should be provided. What do you think?

[atsushieno]

Probably...! I have to say it's quite awkward right now. On lambdas I wonder if that is not going to shut out Java language users unnecessarily though (current setXxxListener() would work for them). It is a Kotlin library and if lambdas improve our experience a lot then I'd go for it, bu I thought SAM works for our listener. If you come up with a PR that'd be great.

[sed0]

It's possible to add Flows alongside listeners like this for example:

interface MidiInput : MidiPort {
    val messageReceivedFlow: Flow<MidiMessageReceivedEvent>
        get() = callbackFlow {
            setMessageReceivedListener { data, start, length, timestampInNanoseconds ->
                trySend(MidiMessageReceivedEvent(data, start, length, timestampInNanoseconds))
            }

            awaitClose {
                setMessageReceivedListener(null)
            }
        }

    fun setMessageReceivedListener(listener: OnMidiReceivedEventListener?)
}

data class MidiMessageReceivedEvent(
    val data: ByteArray,
    val start: Int,
    val length: Int,
    val timestampInNanoseconds: Long,
)

Not the best solution I guess, but it's easy, and it doesn't eliminate Java support.

[JBramauer]

One thing where flows/channels make our lives easier as devs is thread handling, especially since the current onMidiMessageReceived() listeners might run on whatever thread - depending on the MidiAccess implementation, I guess.

E.g. for JvmMidiAccess I noticed that KmLog outputs [Java Sound MidiInDevice Thread] as a log tag while everything else is [AWT-Event-Queue-0]