-
Notifications
You must be signed in to change notification settings - Fork 79
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
Comments
The reason is that midir is trying to abstract from the platform, but the platforms vary significantly in their MIDI APIs. 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. |
Thank you for your kind and quick reply. I'll indeed be using |
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.
The text was updated successfully, but these errors were encountered: