On Mar 6, 2009, at 5:34 AM, Tim Blechmann wrote:
+1
Is there a technical objection to my suggestion of a second group node type, that allows parallelism within it? It seems to me this is a fairly simple and elegant idea that just might do exactly what we need: tell the server that this bunch of nodes must follow this other node, and precede the next node, but within it, it's a free-for-all. The group node that we have now would be a "serial group," and the new type would allow parallelism among its immediate children. So if you wanted to distribute several source --> effect chains among different threads, you would have a "parallel group" containing a number of "serial groups." Within the serial groups, order of execution is guaranteed, but each of these serial groups contained within the parallel group could run independently on a separate processor. This is loosely inspired by Faust's parallelism operator, adapted to sc's node structure. There could easily be a technical reason why this would simply not work, but in the absence of that reason, it seems to me this is a reasonably small conceptual leap for end-users and it would also involve the least surgery. (I would say, whatever the final user interface is, it has to be simple. SC is confusing enough as it is!) hjh : H. James Harkins .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman |