add missing mini notation features

[felixroos]

Compared to mainline tidal, the following features are missing from the mini notation:

• Tie symbols "_" Mini-notation additions towards tidal compatibility #926
• feet marking "." Mini-notation additions towards tidal compatibility #926
• standalone "!" Mini-notation additions towards tidal compatibility #926
• random choice "|" incorporate elements of randomness to the mini notation #165
• Random removal "?" incorporate elements of randomness to the mini notation #165
• Polymetric sequences "{ ... }" Tidy parser, implement polymeters #336
• Fixed steps using "%"
• Mini-notation for fraction shorthands #65
• Support patterning euclidean values in the mininotation #72
• Only one "modifier" is allowed per "slice" in mininotation #176
• colons
• c3(3,8)? does not work ([c4(3,8)]? does)
• polyrhythms with <> e.g. <bd hh, ht lt mt> support , in < > #886
• range operator "0 .. 6"` support mininotation '..' range operator, fixes #715 #716

For most of them to actually work, the corresponding functions need to be implemented in core.

[felixroos]

correlates with #31

[eilseq]

Tie PR #47

[eilseq]

Feet Marking PR #49

[felixroos]

related #72

[bpow]

Related #165 for random choice and random removal.

[bpow]

Are the various "word-like" operators towards the bottom part of the krill.pegjs file desired?

Because PEG parsers don't perform backtracking, I think if you were to pass something to the parser like mini('slow 2 $ "a b"') that "slow" and "2" both end up being recognized as "slices" (because slices match before the individual command operators) and then the parser gets to the '$' and doesn't know what to do.

My thoughts are that we might not even need these forms of things (since it seems a bit too much like making a little mini-haskell and people wanting to have the additional complexity of many of these functions would just call them in javascript). If that's the overall preference, then that part of the grammar could be cleaned up to reduce future maintenance burden. On the other hand, if there seems to be utility in having them, then I could take a look into reworking the pegjs file so those structures actually get parsed.

[felixroos]

Ah this stuff at the end is not really used at the moment, as mini will wrap everything it gets into double quotes. It can be used with the h function but not much work has gone into that part. The grammar originated from the krill project, where this sort of mini haskell was used, while strudel only uses the mini notation part so far.

I would find it interesting to have a more tidal like way of writing patterns, as an alternative to js, but as you said, the grammar would need some work to properly do that. I am not sure if we need to throw it out, as it might be the starting point for some explorations in the future, though we could mark it as experimental / not maintained or similar. On the other hand, it might be obfuscating the actual grammar that is in use..

I'd say it's up to you if you want to explore this region or not :)

[bpow]

Ahh... those do indeed get parsed properly. I hadn't noticed the behavior of mini to wrap with double quotes, and the haskell-like operators do get properly recognized when outside double quotes and using h instead. So it makes sense to leave that part of the grammar intact.

[felixroos]

ref #562

[felixroos]

just found out that you can do <bd hh, ht lt mt> in tidal. this is not possible with the mini parser atm

[yaxu]

Tidal has [0 .. 3] as shorthand for 0 1 2 3. [0, 0.5 .. 2] might also be nice for 0 0.5 1 1.5 2 but tricky when , is already taken.
In tidal it has to be in its own subsequence, "0 .. 3" and "[0 .. 3] 4" are ok, "0 .. 3 4" and "[0 .. 3 4]" are syntax errors. <0 .. 4> works but (surprisingly) is the same as [0 .. 4]. These edge cases are probably bugs to fix though.

[yaxu]

It could work like this:
https://strudel.tidalcycles.org/?x8seM6I-aCwL