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

Why closures, why threads? #118

Open
pietervandermeer opened this issue Jul 7, 2022 · 2 comments
Open

Why closures, why threads? #118

pietervandermeer opened this issue Jul 7, 2022 · 2 comments

Comments

@pietervandermeer
Copy link

I've used midir to my satisfaction for a while now. However, in a synth or sequencer application you'd need to do intricate timing related code. A closure to handle the incoming MIDI messages just won't cut it. Sure you can use a ring buffer and send the data to your main processing thread, but the problem arises when you reconnect. Is there any reason you chose to use a closure for this purpose? I'd much rather have asynchronous way of working where I just poll for MIDI data every iteration. This is much easier to integrate in a real-time application, which is largely based on state machines. Alsa-rs gets these things right. Cpal and Midir seem to favor closures and even delegating streaming to threads, which just complicates things. It may look cleaner and safer, but it doesn't scale up to professional usage. Unless I'm missing something.

@Boddlnagg
Copy link
Owner

The reason is that midir is trying to abstract from the platform, but the platforms vary significantly in their MIDI APIs.
On Windows, for example, the underlying API for MIDI input is callback-based. So this approach is just easiest to implement on top of all the APIs (but is even incorrect for at least one of them).
I agree that this is suboptimal for professional usage, because it requires additional intricate timing related code (quoting you), but this timing related code tends to require some platform-specific stuff as well. So it would be best if midir could just abstract away all of that in an asynchronous API that really scales to professional usage ... but that would basically require a whole redesign of midir based on an async approach (see #76), which I currently don't have the capacity for.
So at this time I can only recommend to fall back to platform-specific code (e.g. use alsa-rs directly) if this is required for your usecase.

Of course I'd be happy to review any contribution in that direction for midir as well, but as I said, it would be a new/alternative API, and maybe it would even better fit in a separate library.

@pietervandermeer
Copy link
Author

pietervandermeer commented Jul 7, 2022

Thank you for your kind and quick reply. I'll indeed be using alsa-rs in the foreseeable future. I'll keep midir for development targets as timing or being hot pluggable are not important there, and midir has a small footprint and almost zero clutter.

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

2 participants