fix: panic on connect to input

[dsgallups]

Checking that the input length is equal to 3 is my band-aid to deal with timing + sensing commands from the keyboard.

Fixes #42, #28

This PR conflicts with #29. However, I would recommend NOT merging that PR for two reasons:

1. This crate, as mentioned in midly integration for comprehensive message parsing #35 handles only two messages properly: note is on and note is off. While handling other messages is most likely a future directive of this crate, I believe that the current crate structure should not, and cannot account for other statuses without midly or a significant structural change.
2. Zeroed data bytes mean different things for different statuses. So, this might do nothing, but I believe it would make more sense to throw away statuses without data bytes given the current implementation. Not doing this could be deceptive. In the example provided by cargo run --release --example input giving Result::unwrap() on an Err value: PoisonError { .. } #28, You will see that the data-less messages passed are the same status of active sensing. This crate in a vacuum, however, doesn't have the capability, nor should be capable of handling that case until comprehensive message parsing is resolved.

Obviously then, there's a pitfall of this PR as well. ONLY status types with 2 data bytes are available in the Resource. This means that the publicity of the message is incomplete. I'd argue this is okay, for now, but providing invalid zeroed data to a status without those bytes is far more deceptive when implementing logic. Of course, I'm assuming most dependents use the is_note_on and is_note_off methods exclusively, and parse the provided bytes afterwards.

Maybe then, the MidiMessage struct should be changed to

#[derive(Debug, Clone, Copy, Eq, PartialEq)]
pub struct MidiMessage {
    pub status: u8,
    pub d1: Option<u8>,
    pub d2: Option<u8>
}

Or even better:

#[derive(Debug, Clone, Copy, Eq, PartialEq)]
pub enum MidiMessage {
    NoteOn(Channel, u8, u8), // Could get *real* fancy, parsing status + data pair as a particular key and newtype Velocity
    SongSelect(u8),
    ActiveSensing,
    // i.e.
    TimeSignature(Notation, u8, u8), //Clocks per click, 32nd notes per 24 clocks
    NoteOff(Channel, Key, Velocity),
    ...
}

impl MidiMessage {
    pub fn is_note_on(&self) -> bool {
        match self {
            MidiMessage::NoteOn(_, velocity) => velocity != 0,
            MidiMessage::NoteOff(_, _) => true,
            _ => false
        }
    }

    pub fn velocity(&self) -> Option<u8> {
        match self {
            MidiMessage::NoteOn(_, velocity) | 
            MidiMessage::NoteOff(_, velocity) => velocity,
            _ => false
        }
    }
    ...
}

Or, I can just help implement midly for this crate, as correct parsing of statuses will be important to me soon. Thanks for your consideration!!

[dsgallups]

Honestly, after looking into midly, I'm thinking about making an extension crate for them. I don't quite agree that not parsing the u7 as a particular key (like a Key enum) is at all beneficial for the average user: https://docs.rs/midly/latest/midly/enum.MidiMessage.html.

[dsgallups]

@BlackPhlox Hate to ping! Could you look at this PR for me? I may take this crate in another direction, so might not be necessary. Just want to contribute a bit to your awesome work!

[BlackPhlox]

@BlackPhlox Hate to ping! Could you look at this PR for me? I may take this crate in another direction, so might not be necessary. Just want to contribute a bit to your awesome work!

No worries, busy time of year for me, just went on holiday today, but something have come up besides bevy_dolly. Great to see your interest for this! 🚀 I'll get back to you asap!