Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

format and simplify oranization #1

Open
wants to merge 19 commits into
base: main
Choose a base branch
from
Open

format and simplify oranization #1

wants to merge 19 commits into from

Conversation

x37v
Copy link

@x37v x37v commented Mar 27, 2023

  • run cargo fmt
  • remove empty files
  • reduce the module depth and complexity (it is a simple project but using it as a library wasn't that simple)
  • a few misc changes/enhancements

@x37v
Copy link
Author

x37v commented Mar 27, 2023

hey @132ikl care to check this one?

@132ikl
Copy link

132ikl commented Mar 27, 2023

Sure, although it might be a couple days before I'm able to get around to it

@132ikl
Copy link

132ikl commented Apr 5, 2023

I haven't forgotten about this, just been crazy busy. Will review as soon as I can 😅

};

let cable_number = CableNumber::try_from(u8::from(raw_cable_number)).expect("(u8 >> 4) < 16");
let cable_number =
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be handled as a ParseError/similar instead of just expecting? If the MIDI packet is malformed for some reason this could reasonably happen, and straight up crashing in a try_from is probably not ideal. Maybe there should also be a sanity check here for the MIDI magic string (I assume that's what the first 4 bytes are?)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0xFF >> 4 == 0xF which will never fail here, so maybe it should just be .unwrap() but I don't think we need a parse error

src/constants.rs Outdated
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe constants could be grouped into namespaces, eg. constants::usb, and misc. constants can just live in the top-level module, eg.

pub mod usb {
    pub const USB_CLASS_NONE: u8 = 0x00;
    pub const USB_AUDIO_CLASS: u8 = 0x01;
    // ...
}

pub const MIDI_PACKET_SIZE: usize = 4;
pub const MAX_PACKET_SIZE: usize = 64;

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reduced the public constants to 6 total, the additional usb module seemed a bit excessive for use and navigating docs..

Comment on lines 8 to 10
pub struct MidiPacketBufferReader<'a> {
inner: core::slice::Chunks<'a, u8>,
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for using a normal struct instead of a tuple struct here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nah, I'll make it one

Comment on lines 4 to 5
const MIDI_IN_SIZE: u8 = 0x06;
const MIDI_OUT_SIZE: u8 = 0x09;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be moved to constants?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

they're not pub, only used in this file, so I don't think so

@x37v x37v requested a review from 132ikl April 23, 2023 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants