Once we get GUI set in stone, Web UI backed developers will have to deal with custom commands that go beyond parameter changes or existing extensions (e.g. presets operation), such as "get list of sampler file", "load sampler file xxx", etc.
Since Web UI does not have access to those resources in the plugin, it will have to interact with its own AudioPluginService through process() i.e. as MIDI2 messages. At this stage there is no standard way to achieve this i.e. everything is weakly typed, it would be convenient to have some sort of "command" format so that both Web UI host and plugin does not have to implement serialization of requests and responses to and from process() content, manually.
To achieve that, we would need a "command" extension, that takes a command name, and set of arguments of limited set of types (maybe just JSON types: number, boolean, string, array, object, and null). Then host and plugin libraries could support them in terms of automated serialization and dispatching.
It might not have to take an "extension" form, but we'd figure out what could be viable options.
Once we get GUI set in stone, Web UI backed developers will have to deal with custom commands that go beyond parameter changes or existing extensions (e.g. presets operation), such as "get list of sampler file", "load sampler file xxx", etc.
Since Web UI does not have access to those resources in the plugin, it will have to interact with its own
AudioPluginServicethroughprocess()i.e. as MIDI2 messages. At this stage there is no standard way to achieve this i.e. everything is weakly typed, it would be convenient to have some sort of "command" format so that both Web UI host and plugin does not have to implement serialization of requests and responses to and fromprocess()content, manually.To achieve that, we would need a "command" extension, that takes a command name, and set of arguments of limited set of types (maybe just JSON types: number, boolean, string, array, object, and null). Then host and plugin libraries could support them in terms of automated serialization and dispatching.
It might not have to take an "extension" form, but we'd figure out what could be viable options.