This is the first time that I think I've seen the proposal. When I was building https://github.com/fundamental/rtosc https://github.com/fundamental/rtosc I was

This is the first time that I think I've seen the proposal. When I was building https://github.com/fundamental/rtosc https://github.com/fundamental/rtosc I was pretty heavily influenced by the work done within liblo and libmapper. I personally really like their implementation, but like all of the options adoption drives success. With rtosc there is https://github.com/7890/oscdoc https://github.com/7890/oscdoc support (XML/XLST based) as well as a more standard json schema https://github.com/mruby-zest/osc-bridge/blob/master/schema/test.json https://github.com/mruby-zest/osc-bridge/blob/master/schema/... . For the running application the discovery mechanism is in the vein of oscit where there are special discovery paths and everything is over UDP OSC. One of the limitations for ZynAddSubFX is making discovery a multi-step process, since there is a very large number of OSC paths (if you count out all enumerations it's ~4,000,000). So flat listings don't really work and even if that's resolved the rest of the information needs to be presented in a compact/efficient format for the system to be performant. I'd say the OSCQueryProposal looks like it falls back on HTTP concepts and javascript conventions too heavily and adds more verbosity than I'd personally prefer. Looking over the options that I had considered in the past I'm looking at libmapper again for some possible future ideas and work.