4 ms·

> I'm working on an OSC based DAW built with Qt (https://ossia.io https://ossia.io) Ah, cool. I remember siting in on part of the 2017 LAC workshop for i-score

> I'm working on an OSC based DAW built with Qt (https://ossia.io https://ossia.io) Ah, cool. I remember siting in on part of the 2017 LAC workshop for i-score (i-score was renamed to ossia score, right?). Once you remove the embedding criteria Qt itself becomes a much more feasible option. I haven't used score, much, though I should likely play around with it given the amount of OSC work that I've done around zyn.

jcelerier 8y ago
oh.. then we've met ! I was the one giving the workshop, and had a good time with you people :) (and yes, there was a rename). By any chance, have you looked into OSCquery (https://github.com/mrRay/OSCQueryProposal https://github.com/mrRay/OSCQueryProposal) ? It's a protocol we're currently a bunch working on and which is starting to make some inroads even in paid media software ; it greatly facilitates interoperation between multiple OSC-compliant software since it allows multiple software to easily query all the OSC nodes of each other through simple JSON over websocket communication.
- fundamental 8y ago
  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.

jcelerier 8y ago

oh.. then we've met ! I was the one giving the workshop, and had a good time with you people :) (and yes, there was a rename). By any chance, have you looked into OSCquery (https://github.com/mrRay/OSCQueryProposal https://github.com/mrRay/OSCQueryProposal) ? It's a protocol we're currently a bunch working on and which is starting to make some inroads even in paid media software ; it greatly facilitates interoperation between multiple OSC-compliant software since it allows multiple software to easily query all the OSC nodes of each other through simple JSON over websocket communication.

fundamental 8y ago
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.