jussi-kalliokoski
commented
11 years ago I've spent some time thinking about this feature lately and I want to share some ideas and open questions I have. At the simplest, what I see we could have is this:
dictionary MIDIPortOptions {
string name;
string manufacturer;
string version;
}
partial interface MIDIAccess {
MIDIInput createVirtualOutput(MIDIPortOptions options);
MIDIOutput createVirtualInput(MIDIPortOptions options);
}
As you can see, createVirtualInput() creates a MIDIOutput, naturally, since the return value is not the resulting port but an API for making it do things, i.e. in order for a MIDI output port to generate output, you have to define that output.
The resulting ports would naturally have no id since they don't correspond to any actual ports, virtual or physical.
One open question is whether we want to have these as factories on the MIDIAccesss interface or as global constructors. On one hand, for the basic uses of the ports it doesn't make any sense to require user consent, there's no fingerprinting potential since even the id is not exposed, nor do the ports really do anything unless the user explicitly connects them somewhere manually or via another piece of software (s)he's running.
However, this needs to be thought through. I've heard that some iOS apps use virtual MIDI ports to communicate with each other. If that is the case, we need to consider whether a web app pretending to be another native application should be considered a potential risk. In the worst case nightmare scenario an app would be transmitting Lua (or similar) code via MIDI which could result in a cross-application scripting attack, possibly leveraging all the privileges the user has granted that application. Another, much likelier case would be that a user's credentials would be transferred from one application to another, similar to OAuth except that the authentication would happen in another application instead of on the web, and an intercepting application could steal these credentials.
toyoshim
marcoscaceres
cwilso
notator
joeberkovitz
agoode
bja-ableton
neauoire
F1LT3R
jbflow
some1else
caseydwayne
xXGoziXx
tobiasBora
dderiso
rianhunter
mjwilson-google
In speaking with Korg at NAMM, they really wanted to have the ability to define virtual MIDI input/output ports - e.g., to build a software synthesizer and add it to the available MIDI devices when other apps/pages query the system.
Yamaha requested the same feature, even to the point of potentially creating a reference software synth.
We had talked about this feature early on, but cut it from v1; truly adding the device into the list of available MIDI devices to the system (e.g. other native Windows/OSX apps could access) would likely be quite hard, involving writing virtual device drivers, etc., which is why we decided not to feature in v1. We might consider a more limited feature of virtual devices that are only exposed to web applications; this might still be a substantial amount of work to add, but I wanted to capture the feedback.