stream-based interface

[ssfrr]

I think that a stream-based API would work well for MIDI, and would work for both file I/O and reading/writing from devices.

Related to #31, loading a MIDI file (or connecting to a MIDI device) would give you a MIDIStream, from which you could read/write vectors of MIDIEvents

One question is how to handle multi-track files. I'm not sure whether it makes more sense to have them be separate streams, or whether the MIDIEvents should just have a track ID as a field.

Right now I'm just spit-balling some ideas, so feel free to ignore (of course). Sometime in the next few weeks I'm actually hoping to interface with some MIDI hardware, so I'll be able to contribute some PRs then.

[JoelHobson]

Awesome, I look forward to the PRs 👍. If we go with FileIO (see my comment on #31)... I'm not sure about going with track IDs on the track events or not. It might actually simplify working with midi data, since distributing the events to different tracks can be handled by the write functions. On the other hand, keeping the events grouped by track in their own arrays seems like it might be a little easier to reason about while you're working on a file. Honestly, I could go either way with this.

[rafaqz]

Where is this at currently?

Live streaming midi would be amazing, and I barely even make music anymore. But it would be great for controlling live science visualisations via Reactive.jl signals - think Visualize.jl or Jupyter notebooks via Interact.jl. All these interactive plots everyone is making really want physical controls at some stage, and MIDI has that covered...

[JoelHobson]

Unfortunately, no one's made any pull requests, and I don't plan to work on it any time soon. I agree though, it'd lead to some really neat applications.

[rafaqz]

Sure. I'm guessing a wrapper for portmidi would do it, but could be a separate module that depends on MIDI. But who knows if I will ever have time either...

Edit: rtmidi seems preferable https://github.com/thestk/rtmidi