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

MinidInput::connect take self ownership #90

Open
YievCkim opened this issue Aug 13, 2021 · 3 comments
Open

MinidInput::connect take self ownership #90

YievCkim opened this issue Aug 13, 2021 · 3 comments

Comments

@YievCkim
Copy link

Hi,

I don't understand why this function takes self ownership. This prevents to reuse MidiInput instance. Moreover I have noticed that MidiInput::new raises an InitError when the same name is reused for the connection. Is there a way to reuse a MidiInput instance ?

@Boddlnagg
Copy link
Owner

Boddlnagg commented Aug 13, 2021

I agree that this is probably not the most flexible design, but I think the original reason was that some backend required it, or was otherwise very hard to write without this "limitation".

Looking at the code now (a few years after I implemented it), I think it was the ALSA backend, where MidiInput is essentially a snd_seq_t, and snd_seq_t can only handle one open input "channel" at a time, because snd_seq_t itself is used as a buffer for the incoming events (s.a. the comment at https://docs.rs/alsa/0.5.0/alsa/seq/struct.Input.html).

If anyone is familiar with ALSA and can chime in and offer a better solution, I'd be happy to change this.

@YievCkim
Copy link
Author

Yes I have finally found a workaround with message passing. Thank you for the explanation. I am on MacOSX but I have several linux too. I will try to take a look.

@sourcebox
Copy link

This seems to be related to #86

sowbug added a commit to sowbug/groove that referenced this issue Dec 8, 2022
Because of Boddlnagg/midir#90, this is some of the weirdest
Rust code I've ever written.
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

No branches or pull requests

3 participants