I suspect we will disagree here (that’s OK).
The Group class is only a thin abstraction layer representing a group node in the server. Because of its name, we want to press it into service for other purposes, but in my opinion, this is a conceptual error.
Group simply is not a general-purpose node organizer. It’s a resource, which you can organize into higher-level behaviors. I think (again, my opinion) is that it’s easier to think in terms of organizing, on the client side, the given resources in the server, rather than to try to get the server resources to do things they were not designed to do (or to implement new server features).
Theoretically, this would require numCutGroups x numSamples groups for each orbit…
I was a bit concerned about scalability… there would be a point where the matrix gets too large to be practical.
and in order to know which to free, sclang would have to traverse the whole tree for each cut.
I think I was assuming a collection of groups would be keyed according to the cut group ID, which should eliminate some of the traversal? If the collection is organized according to the requirement, then it’s not “go check everything to see if it matches,” but “go directly to this part of the tree.”
In any case… a control input can’t have more than one value in one control cycle. So, using a single control name will not satisfy the requirement of releasing multiple cut groups at exactly the same time. So I think you’re left with:
- Enforce a minimum wait time for successive cut triggers. (5 cut groups freeing within 8 ms shouldn’t be too bad.)
- Or use a group matrix.
- Or track node IDs belonging to cut groups.
- Or uses buses as scztt suggests.
Of buses:
Hm, so when a new synth is started, the bus has to be zero again.
Could you use a synth to set the value for exactly one control period?
hjh