A nice addition to the crate would be some "Incubator" types (name notwithstanding), which could be fed with packets / bytes and then polled for valid messages.
Considerations
The solution should be #![no_std] friendly
We should accommodate parallel buffering where appropriate.
Especially for Sysex8 messages where the spec explicitly indicates they can be streamed in parallel.
Clock messages will probably need special handling because they can always come between packets of other message types.
FlexData and UmpStream have explicit limits on their message size (see the specs for deets).
A nice addition to the crate would be some "Incubator" types (name notwithstanding), which could be fed with packets / bytes and then polled for valid messages.
Considerations
#![no_std]friendlySysex8messages where the spec explicitly indicates they can be streamed in parallel.FlexDataandUmpStreamhave explicit limits on their message size (see the specs for deets).