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
The ability to automatically refresh the list of inputs as devices are connected and disconnected.
The ability to select "None" as an input.
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.
The text was updated successfully, but these errors were encountered:
In my existing work on a next-gen MIDI select, I added a few key features, including:
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.
The text was updated successfully, but these errors were encountered: