Leadbelly

> The specific returned message can be pre-configured on the device at runtime -> it is not yet known at compile time. I think this is also solved with the...

You could use the `BufferTryResize` trait instead of `BufferResize`. This will allow you to do sysex operations and also support the full feature set for the channel voice messages.

`data()` should always return the size of the message buffer. `TimingClock::data` **should** therefore return a buffer size 1. It seems there's a bug in this area - thanks for flagging...

If you pin to version 0.6.4 the issue should be fixed.

Sorry about the delayed response. I wanted to put out a feature release (0.7.0) before getting back to you. It's a little tricky to critique your implementation without knowing more...

Regarding your question about using the newer `midi2` protocols. Yes, you'd have to use [`Ump`](https://docs.rs/midi2/0.7.0/midi2/buffer/trait.Ump.html) buffers instead to do things the modern way. You could always use the `Ump` buffer...

Here's an example of how such an iterator might be implemented. Being `no_std` compatible means you have to jump through a lot of hoops with statically sized buffers, but it's...

As far as I can see from the OpenDeck spec, these buttons should never need to send SesEx messages. Seems like SysEx is only used during a configuration stage, not...

Ok, cool. Looking into [the schema for these MMC messages](https://en.wikipedia.org/wiki/MIDI_Machine_Control) it seems that the longest possible message would be: ``` F0 7F 06 =44goto =06 01 F7 ``` Which is...

> In addition, what makes the matter even more complicated: There is not only Buttons that should be configured, there are also other types of input elements (analog inputs or...