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

Add modern input/output selector for MIDI (and MIDI-like components). #5

Open
the-t-in-rtf opened this issue May 18, 2020 · 0 comments

Comments

@the-t-in-rtf
Copy link
Contributor

In my existing work on a next-gen MIDI select, I added a few key features, including:

  1. The ability to automatically refresh the list of inputs as devices are connected and disconnected.
  2. The ability to select "None" as an input.
  3. The ability to specify a simple string indicating the name of a preferred device.

I would like to extend the UI components in this package to support those features. In addition, I'd like us to consider a few other ideas.

The concept of a preferred device should continue to support matching by device name, but IMO needs to be fleshed out a bit better. As an example, I have multiple pairs of identical devices, to use them as preferred inputs, I had to rename one of them using a control panel. It would be useful IMO to have the ability to search by manufacturer and device, especially when talking about multiple inputs/outputs (see below).

I can also see adding a rollup panel to allow selecting multiple inputs and outputs from a single UI. The multi-panel should be able to select all matching preferred devices simultaneously.

Another big discussion point is persistence. We have made use of preferred devices in part because that's the only way we have to avoid selecting the same inputs every time we reload a page. If we are going to allow people to create complex setups, it would be nice to provide a means of persisting the selected inputs and outputs. We may want to address this more generally, but we could also try it on a smaller scale here to see what approach seems to make the best sense.

Finally, as there is no means of creating virtual inputs or outputs in the WebMIDI API, I think we should also consider defining an abstract contract that MIDI devices satisfy, and which "MIDI-like components" can implement to be included in the list of inputs and outputs. I will write up this work separately perhaps as a precursor to working on this issue.

To test many of these things, we'd either need mock "MIDI-like" components, or better, to have a cross-platform dev dependency that can be used to create virtual MIDI inputs/outputs that can be detected by the WebMIDI API. I will write that up as another precursor so that we can at least remind ourselves what the options are, even if we end up using mocks for now.

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

1 participant