On Thu, Jun 10, 2004 at 12:13:41 -0700, Chris Grigg wrote: > >And from there, it is a small step for hosts to add remote control via OSC. > > I have no objection to taking such an approach. However I think we > should not be quite so loose about saying we'd be 'using OSC' per se > -- if I'm understanding correctly, the proposal would be to use just > the parameter address format part of OSC. We would be leaving out > the whole transport protocol part of OSC. And we would be adding a > significant piece of stuff not currently contained in OSC by > developing our own parameter dictionary. So -- again, if I > understand correctly -- this is more about creating a hybrid than it > is about using OSC outright. Not really. OSC has a number of transports (FIFOs, UDP and TCP), we would use FIFOs (or whatever the local OS equiv is, its platofrm specific). OSC has an addressing mechanism (parameter dictionary?), but no service discovery mechanism, so GMPI needs to specify that, its not hard though. For eg. an OSC message to set "some_parameter", a real-valued parameter value to 1.0 looks like (but in a binary encoding) /some_parameter ,f 1.0 ... > protocol, for example it wasn't clear to me that the sender of an OSC > message is different from the synchronous caller of an API function > because it can't get a return value or even verification that the > message was received and handled, or when. People who actually know > something about OSC should comment on that, I guess. OSC is fully asyncronous, but wether you can tell if/when a message was received depends on the transport. With TCP and FIFOs you can tell the order and probably if it was received (I'd have to think about that more). When you really need it, receivers can ACK. - Steve ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe