hello julian, this mechanism would only be an expense if you use it, ie. "/s_new -2" would send "/n_id x" other uses would remain unchanged.
currently a small, simple client process that wants to use scsynth has to pick some random id's and hope for the best. having a reliable mechanism for establishing groups and 'long-lived' nodes would make writing clients much simpler and less error prone. to be clear, writing works where many simple autonomous processes interact with scsynth is not well supported at present. requesting a node-id in advance or a node-id range seems to me a worse design, since scsynth would then have to require the client to 'release' these (ie. scsynth would have to keep the node-ids allocated until the client explicitly releases then, since scsynth has no way of knowing if the client still requires them, or indeed if the client still exists, etc. etc.) bests rohan also, rather often if you are generating many nodes (>100/sec) you do not need to communicate with them individually, ie. you can use "/s_new -1" and then communicate via the parent group(s), which you'd setup in advance with "/g_new -2"... Julian Rohrhuber <[email protected]> writes: > Well, theoretically, scsynth couls supply a client with free node > ids, but this would require a round trip for each synth. Considering > that ids may be used at a rate appropriate to granular synthesis, > this makes not too much sense. What you do in sclang normally is to > give each client a unique integer id and divide up the integer id > space into the maximal number of clients (I think it is 32 in sclang > currently), providing each client with their own id range. > > The best solution would be if sclang would send this number when a > client sends a request to /notify, but it is not implemented, so you > need "human communication" here.. > > we ususally just give everyone an id. > >> > If someone can give me some pointers on how to go >>> about assigning nodeID ranges in Haskell I would >>> appreciate it. >> >>how are you currently assigning node numbers? you >>just need to use different numbers for each client. >> >>more widely: resource id management really needs to >>reside at scsynth since clients cannot reliably know >>what ids are in use. sclang uses a global variable but >>it is "per interpreter" and of course knows nothing >>about any other clients (sclang or otherwise). >> >>there ought to be another mode to s_new (like -1, >>perhaps -2) such that the server allocates an id and >>returns an n_id message to the client. it'd be >>straightforward to write and would solve a lot of >>problems! (likewise for g_new and b_alloc etc. etc.) >> >>bests >>rohan _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
