You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm experimenting with writing a native shim for the web midi api using the midir crate. The midir crate allows you to list midi inputs and outputs currently connected. The web midi api allows clients to provide an onstatechange callback which allows them to react when new midi devices are made available or unplugged. My question is what's the best way to implement this?
One way would be to manage the state of the inputs and outputs in rust and continuously poll for changes (maybe in a background thread?) and call the onstatechange javascript callback if it changes. This is probably the best solution, however as primarily a JS developer, multithreading is not something I do a lot of and I'm having issues with moving data with this solution.
An other way would be to only provide a way to get midi inputs and outputs in rust and manage the state of the ports in javascript polling them continuously using setTimeout. This would be easier to implement, but I worry would be quite bad for performance (I need to poll every 500ms or less ideally).
I would love to know what anyone who's written native bindings before thinks of these options and any tips you have!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
I'm experimenting with writing a native shim for the web midi api using the midir crate. The midir crate allows you to list midi inputs and outputs currently connected. The web midi api allows clients to provide an
onstatechange
callback which allows them to react when new midi devices are made available or unplugged. My question is what's the best way to implement this?One way would be to manage the state of the inputs and outputs in rust and continuously poll for changes (maybe in a background thread?) and call the onstatechange javascript callback if it changes. This is probably the best solution, however as primarily a JS developer, multithreading is not something I do a lot of and I'm having issues with moving data with this solution.
An other way would be to only provide a way to get midi inputs and outputs in rust and manage the state of the ports in javascript polling them continuously using
setTimeout
. This would be easier to implement, but I worry would be quite bad for performance (I need to poll every 500ms or less ideally).I would love to know what anyone who's written native bindings before thinks of these options and any tips you have!
Beta Was this translation helpful? Give feedback.
All reactions