Closed kolektiv closed 4 months ago
(Oh, and this doesn't have an action, except implied - it's mainly to start a discussion - would unifying those two approaches make sense? And have I understood correctly, in which case maybe I'll submit a few doc tweaks?)
Hi @kolektiv , this library tries to follow the original CoreMIDI model as close as possible. The new EventList concept was added to support MIDI 2.0, but previously only the PacketList existed.
About having a builder method that consumes in the PacketBuffer, feel free to contribute something similar to EventBuffer::with_packet. If you see the code it is pretty simple, it just pushes the data mutably and returns itself back.
Hi @chris-zen - thanks, that's what I'd gathered from the change history. If I get a few minutes I'll do so in terms of a PR; as you say, it's not a complex change. I've decided to work from a MIDI 2.0 perspective with this project, so I'll actually be using the EventBuffer/List anyway, but it would be nice to unify the two.
Sorry for a random thought, I started using the lib today and have puzzled through a few things. One thing that would be nicer is if PacketBuffer consumed itself and returned Self like EventBuffer currently does. It makes things easier with bindings, and also avoids the need for a &* deref when sending, etc.
EventBuffer is a little nicer to work with in that way, but it did take me a while to work out that EventBuffer only supports the new Unified Midi Packet format - I believe? It's not really mentioned anywhere specifically! If you want to send old-style MIDI I think PacketBuffer is still the way?