"Rohan Drape" <[EMAIL PROTECTED]> writes: > (and are biased to using many single threaded > connections, hence wait design etc.)
that was a little terse, to clarify: wait in hosc discards any non-matching messages in the queue until it receives the waited for message. error handling at sc3 is subtle. most commands can fail in some way, and if they do they send back a /fail message. if synchronous commands succeed they send nothing. asynchronous commands will send back either a /done message at some unknown time in the future, or a /fail message. it is also possible to request various notification messages, which can arrive at arbitrary times. and bundles and cascaded errors make this more complicated still. there are obviously many approaches to working with this. sclang uses global shared state, which doesn't translate well to haskell or to a many-lightweight-processes environment. so, when using haskell i: 1. view /fail messages as fatal user error and don't attempt to monitor them, instead relying on the scsynth stderr text to work out what went wrong. 2. send all async commands using the hsc3 async function which is just (send fd ... >> wait fd "/done"). wait ought to time out so that getting a /fail in place of a /done does not hang the interpreter but there is a problem with the socket library so the relevant code in hosc is commented out, see: http://www.haskell.org/pipermail/libraries/2005-October/004435.html 3. use separate threads for any notification monitoring (and only monitor for /tr messages). 4. use a single short lived udp connection per 'interaction' with the synthesiser. the most notable problem with this approach is node & buffer id management. i think the correct way to address this is to write [s|g]_new & b_alloc variants at scsynth that allocate a known unused identifier and reply with an /id message. it seems that it ought to be possible to make this fast enough, but i'm not expert enough to know how, and it's not likely to interest the sc3 people as they have the global-state-at-client solution all coded up. however, this'd allow for independent processes to safely use the synthesiser. at present one needs to have a separate process that allocates ids and hope that all other processes go through that mechanism, which is a pain & in any case unreliable in the general case. (given the nature of the server the only process that actually *definitely* knows what id's are in use when a _new/_alloc message arrives is the server itself...) rd _______________________________________________ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
