The library you mentioned parses this DSL to a class named Container. It’s not so hard to replicate that in SuperCollider. All rhythm manipulation happens on this underlined representation, so it’s not difficult to port this code to SC.
There is also SequentiableCollection.convertRhythm. It’s limited, but maybe useful for you.
I have some old code that does this kind of thing.
a = RhythmicCell([2, [1, 5, 1]]);
b = RhythmicCell([2/3, [1, -1, 1]]);
[a, b].asRhythmicSeq.plot;
I’ve been exploring working with RTM, but I am separating values and shapes with some inspiration from APL. But that’s not in SC.
example = rtm' [s 1, g 3, 2 |: [s 1, g 1, s 1], s 1]
//or
example = [rtm| (1 -3 (2 (1 -1 1)) 1) |]
(shape, values) = extractShape example
-- raw shape is something like
-- Shape: ShapeNode () [ShapeNode () [],ShapeNode () [],ShapeNode () [ShapeNode () [],ShapeNode () [],ShapeNode () []],ShapeNode () []]
shapeAsList = [4, 0, 0, 3, 0, 0, 0, 0]
Manipulating this seems weird, but after some time, I find it achieves much more than working with traditional trees. Pattern matching with complex arbitrary trees is very error-prone. APL-like approaches are computationally simple, and once you know what to look for, you don’t get errors after that.
Creating a simple DSL is something I sometimes think about. But I never found something to stick with.
–edit: @jamshark70 has developed a DSL with rhythmic features. There are other initiatives in the past too.