Closed kovaxis closed 4 years ago
I noticed it's kind of a pain to push midi events to tracks when writing a smf file, because MetaMessage and SysEx only take references so all the message data has to be constructed beforehand and stored separately..
(In the loop that pushes the midi msgs it's not possible to push the data (that should be borrowed) to a storage Vec and borrow from that, because rustc gives an error because push
borrows the whole Vec mutably so previously elements can't also be borrowed immutably.)
It would be more convenient if messages with owned data could also be written, without sacrificing read performance.
(Unfortunately, even Cow
has some overhead due to the match
on every access.)
In 0.5
both problems were solved.
The ergonomics issue could have been solved using arenas (see typed-arena). In order to save some downloads and reduce friction, a simple arena is now included as midly::Arena.
This way both performance and ergonomics can be achieved :)
Smf
being generic overTrackRepr
is a feature for advanced users that gets in the way of the documentation for basic users (which should be the large majority if the 80/20 rule is worth anything). Begginers shouldn't have to pay for features they don't use.Ideally there should be separate types like
Smf
likeSmfBytemap
. Since deferred parsing already avoids most allocations, why not do it right and avoid all allocations? Perhaps a standalone function that returns a(Header, TrackIter)
tuple, withTrackIter
being an iterator yielding actual tracks (not like the currentTrackIter
that yields events).