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

Move to RTIC and update dependencies #1

Merged
merged 1 commit into from
Nov 19, 2020

Conversation

perlindgren
Copy link
Contributor

Hi

Cool project!

I have updated your repo to RTIC v5, and changed up the dependencies. As I don't have a "stomp" box, I cannot test that it actually stomps as intended :) It compiles, that is the only thing I checked.

So please try it before accepting the PR.

I would be happy to discuss further capabilities of the usbd-midi implementation. A while back I implemented a midi-fader (used for scratching) in Rust (and just the bare necessity to get midi working). I experienced some compatibility problems, it worked in Linux and Windows, but not under OSX. Comparing the behavior of USB communication using Wire shark, and found that OSX is actually assuming even an input device to accept outgoing packages. With this implemented on the target side (actually just ignoring the data) I got it working also under OSX. I used a bluepill as well by the way.

Best regards.
Per

@perlindgren
Copy link
Contributor Author

(I think the only "controversial" potentially breaking change should be the move to

stm32f1xx-hal = {version="0.7.0", features = ["rt", "stm32f103", "stm32-usbd"]}

@perlindgren
Copy link
Contributor Author

perlindgren commented Nov 15, 2020

Just a small comment. It seems that the usb-device + usbd-midi + stm32-usbd actually works out the box on OSX as well. Under OSX it appears as a midi device with one input (to host) and 0 outputs, thus its not required to actually implement the midi-out on the device (meaning midi-in from the embedded target point of view). This was not verified directly on the rust-midi-stomp but rather on the stm32f723-disco, I'm working on some examples there, with the intention to make a PR to the stm32f7xx-hal.

In any case, the usbd-midi could be extended with more functionality, and some constants currently defined in the application could potentially be moved to the library.

@btrepp
Copy link
Owner

btrepp commented Nov 19, 2020

Hi :). I don't actually have the device with me (it worked so was given to my guitarist friend to use :). However hardware wise it was just a bluepill, with switches. In fact in development I just shorted it with some leads.

I'm not surprised it works well on OSX, my friend used it on a Mac laptop.

Agree some of the items could do with a bit of a cleanup, the usb midi spec was a hard read, so it ended up being a large amount of trial and error and also looking at C. Most of which always implemented 2 inputs and 2 outputs, I suspect because one example was copied around/ported many times.

@btrepp btrepp merged commit 4e31027 into btrepp:master Nov 19, 2020
@btrepp
Copy link
Owner

btrepp commented Nov 20, 2020

I'm also very happy to collaborate on improving the usbd-midi library. I don't have a pressing need, but I love micro work. So if there is some goal or way we can manage work on improving the lib I'm happy to develop it further.

@perlindgren
Copy link
Contributor Author

Hi. I'm thinking about supporting midi out from the host. I haven't looked at that since my early experiments some years back, but I don't think it should be that hard. There is this Rust+USB group on Matrix (I tried to invite you but failed as the bridge did not support PMs it seems). The group discusses the audio class and other USB related stuff. As Midi is part of the Audio Class, I think we could discuss it there to start out.

@btrepp
Copy link
Owner

btrepp commented Jan 1, 2021

@perlindgren I did just merge a PR that should add in the midi out from the host rust-embedded-community/usbd-midi#3

Do you have some more info about the rust+usb group on matrix?. I can't find it in the embedded wg list.
If there is a usbd-audio crate, it makes a lot of sense to merge the usbd-midi codebase into that crate.

@perlindgren
Copy link
Contributor Author

perlindgren commented Jan 1, 2021

Hi btrepp (and others).

A while back (a month or so) I did a survey of existing midi abstractions in Rust (not usb midi in particular but midi in general). I found that https://crates.io/crates/helgoboss-midi offered a nice abstraction (I guess you all might have seen that at some point). The problem was that this crate did not compile under no_std. I made an initial no_std conversion and PR:ed it, after some discussions and iterations it is now merged. (There were no significant changes needed, error handling required some feature gating basically.)

I also started out on a complete re-write of usdb-midi based on the helgoboss-midi abstractions, but shelved it for a while. I got to the point of cleaning up the device descriptors and got basic send/receive working (however it was hand coded, and not built as a proper device abstraction). I hope to dedicate time to finishing it.

Not sure how it (usb midi) will best fit into the whole Rust embedded audio ecosystem and the relation to usb-audio in general. One main blocker here is that to properly implement usb audio class devices, we need support in the Rust usb abstractions for synchronization (establishing a back channel for accurate sample rate feedback needed for high quality sound transport). Midi will be part of the equation here, so I'm considering making it modular, perhaps breaking out the descriptor generation into a separate crate, and providing a very light weight crate using that and the helgoboss-midi abstractions to form a minimal usbd-midi crate. In that scenario usdb-midi could work as a stand alone crate as well, if you don't want the full audio-class functionality.

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