From eed79c7fde33be710ea429047fb3119b0f079ccd Mon Sep 17 00:00:00 2001
From: alex <alex@slab.org>
Date: Thu, 20 Feb 2025 20:19:19 +0000
Subject: [PATCH] hedgedoc dumps

---
 hedgedoc-dumps/uzu-notation.md | 177 ++++++++++++++++++++++
 hedgedoc-dumps/uzumaki.md      | 267 +++++++++++++++++++++++++++++++++
 2 files changed, 444 insertions(+)
 create mode 100644 hedgedoc-dumps/uzu-notation.md
 create mode 100644 hedgedoc-dumps/uzumaki.md

diff --git a/hedgedoc-dumps/uzu-notation.md b/hedgedoc-dumps/uzu-notation.md
new file mode 100644
index 0000000..0339efe
--- /dev/null
+++ b/hedgedoc-dumps/uzu-notation.md
@@ -0,0 +1,177 @@
+# uzu notation
+
+[![](https://doc.patternclub.org/uploads/18d2d283-3f66-49c9-a665-a581bc7ee7c7.jpg)](https://alaineymarybelle.pages.dev/csgmiph-uzumaki-anime-release-date-2024-season-photos-qccivln/)
+
+.. or mondo notation, maxi notation ... 
+
+we could use this document to collaborate on the fuzzy idea of a new/alternative/unifying notation for patterns.
+
+please feel free to edit any part of this document!
+
+## the scope of this document
+
+what even are we trying to discuss?
+i'm not sure yet, but let's work it out.
+some ideas:
+
+- how can a new tidal notation look like
+- how should we call it?
+- how can we unify the existing tidal dialects
+- how much should we unify?
+- what's the common ground of tidal dialects
+- do we need a "specification"?
+
+## names
+
+there was some discussion about finding a new name for the family of tidal-like languages.
+maybe this name would also be the name of the not-yet-existing, but potentially existing-sometime-in-the-future custom notation we're talking about here?
+
+- uzu https://skdesu.com/en/meaning/%E6%B8%A6-uzu/
+- I quite like 'uzulang', as a bit of a hat tip to esolang and ixilang
+- ..?
+
+## family tree of uzulangs
+
+Languages that have most or all of:
+- patterns of pure functions of time(spans)
+- combinator library for transformating and combining patterns
+- mini-notation styled after Bol Processor's polymetric expressions
+- GPL compatibility?
+- the author(s) call it an uzulang
+
+Namely:
+
+- [tidal](https://github.com/tidalcycles/Tidal)
+- [vortex](https://github.com/tidalcycles/vortex)
+- [strudel](https://github.com/tidalcycles/strudel)
+- [web tidal](https://github.com/matthewkaney/web-tidal)
+- [zwirn](https://github.com/polymorphicengine/zwirn)
+- [modal](https://github.com/neo451/modal/wiki/Syntax)
+- ...?
+
+## links
+
+- [inter-innards channel](https://discord.com/channels/779427371270275082/1339566754946482287)
+- [mondo channel](https://discord.com/channels/779427371270275082/1309830817739968544)
+- [mondo repo](https://github.com/tidalcycles/mondo)
+- [idea: using ":" for function args](https://discord.com/channels/779427371270275082/1191011773311107153/1308376724840513566)
+- [maxi notation discussion on strudel github](https://github.com/tidalcycles/strudel/discussions/96)
+- [alex's uzumaki musings](https://doc.patternclub.org/87ZlbW8NSbWUrkzRRz0SjA?both#)
+- alignment of elements
+    - [algorithmic pattern forum post](https://forum.algorithmicpattern.org/t/aligning-elements/492)
+    - [GSOC project by Aravind Mohondas - Formalizing Konnakol](https://dev.to/aravindmohandas/formalizing-konnakol-using-haskell-gsoc-22-ekm)
+- [stepwise patterning in strudel](https://strudel.cc/learn/stepwise/)
+- [Bol Processor polymetric expressions](https://bolprocessor.org/misc/docs/bp2-Polymet.html)
+- [Laurie Spiegel - manipulations of musical patterns](https://www.researchgate.net/publication/266316606_Manipulations_of_Musical_Patterns)
+
+## problem zoo
+
+- Generally in programming languages you have an operator that stands for what something does. In Uzus we also want to notate how the arguments are aligned. This creates a bit of a explosion of possibilities. For example [the retired tidal 2.0 branch](https://github.com/tidalcycles/Tidal/blob/2.0-beatmode-retired/src/Sound/Tidal/Compose.hs) ended up with operators like `||.||.` and `||>=`. We need to find some nice way of notating both the 'how' and 'what'.. (In strudel those would be something like `bor.squeeze` and `gte.squeeze` respectively, which isn't that bad)
+- In workshops, people often try and write somethind like the mondo/uzu notation while trying to learn tidal or strudel. It would be nice if it worked.
+- patterning functions is possible in uzulangs like tidal and strudel, but underexplored. Patterns of functions should be first class citizens!
+- functions like `ply` have nice definitions: `_ply n pat = squeezeJoin $ _fast n . pure <$> pat`. We could probably find useful functions just by exploring all the combinations of all the different joins and the elementary transformations. So making joins/binds more readily notable might make a lot of new functionality obvious that we can then give names.
+
+## ideas
+
+### mini notation features everywhere
+
+the new notation could allow using mini notation syntax anywhere in the pattern, so there would be a single DSL that combines the terse mini notation with the expressiveness of a general purpose programming language like haskell / javascript / etc..
+
+- does this mean we try to get rid of "classic" mini notation in the long run?
+
+### a simple ast as the common ground
+
+the common ground between different dialects could be a specification of functions that can be composed together. any dialect could then produce such an ast that can be evaluated / interpreted by this set of functions to create a pattern. 
+the composable functions could have a set of tests that ensure they work the same across implementations
+examples of such functions:
+
+- fast :: Pattern Time -> Pattern a -> Pattern a
+- ply :: Pattern Int -> Pattern a -> Pattern a
+- s:: Pattern String -> Pattern ?
+
+the ast itself could be stringified to something that looks similar to a lisp:
+
+`(fast 2 (s "bd sd"))`
+
+(the structure could of course be expressed in different formats, s-expressions are just one way)
+
+Multiple input languages could produce this ast, for example:
+
+`s("bd sd").fast(2)`
+
+`fast 2 $ s "bd sd"`
+
+`s "bd sd" > fast 2`
+
+
+explorations: 
+
+- [web tidal](https://github.com/matthewkaney/web-tidal) parses haskell style tidal
+- [zwirn](https://github.com/polymorphicengine/zwirn) allows mini notation features everywhere
+- [zilp](https://github.com/felixroos/zilp) allows composing functions with pipes (same order as strudel)
+
+### running tests across implementations
+
+It would be nice to do a kind of test-driven development of multiple implementations.
+
+the specification tests could look like this:
+
+```
+(fast 2 (seq a b))
+
+[ 0/1 → 1/4 | a ]
+[ 1/4 → 2/4 | b ]
+[ 2/4 → 3/4 | a ]
+[ 3/4 → 4/4 | b ]
+```
+
+here, the first block would be the pattern, expressed as an s-expression, while the second block is the first cycle (or more) of the queried pattern. the syntax for the second block is used like this in the strudel snapshot tests, e.g. [examples.test.mjs.snap](https://raw.githubusercontent.com/tidalcycles/strudel/aabc82bedd0370fa5cf6b616b1340d32b153cea8/test/__snapshots__/examples.test.mjs.snap)
+
+these tests could be parsed and evaluated by any implementation
+
+a simpler and probably more robust approach would be to only declare equivalent patterns (skipping the literal event notation):
+
+```
+(fast 2 (seq a b))
+(seq a b a b)
+```
+
+Note that the above test would fail in a stepcount-aware uzulang, but this would pass:
+
+```
+(extend 2 (seq a b))
+(seq a b a b)
+```
+
+It could be nice to categorise or tag tests with features. In the above example, uzulangs that implement stepwise patterning should fail the first test, but pass the second one.
+
+<details>
+    <summary>dialogue about this</summary>
+
+One problem with this is that tidal/strudel also has event fragments. Could add another timespan, but some implementations mind not deal with them. They could just ignore the original/whole timespan though.
+
+
+yes.. i think there's also a notation for that iirc
+
+An alternative or additional approach could just be having a way to supply two patterns that are equivalent. E.g. in the above it could be
+
+(fast 2 (seq a b))
+(seq a b a b)
+
+
+yep thats an interesting idea. i wonder if some things might be hard to test this way, but maybe not
+
+In some cases I think it would just make the tests more robust.. For some things we might fundamentally change something but the test would still work as it would represent a basic assumption rather than a particular input/output.
+
+
+it would also be a lot easier to implement on the language side. parsing a lisp is very easy + no need to parse the custom event syntax
+
+shall we keep this as a dialogue or digest it back into an idea
+
+maybe we use summary tags for this, let me test
+                    
+I thought you were going to suggest chatgpt then
+    
+haha no just html
+    
+</details>
diff --git a/hedgedoc-dumps/uzumaki.md b/hedgedoc-dumps/uzumaki.md
new file mode 100644
index 0000000..8946332
--- /dev/null
+++ b/hedgedoc-dumps/uzumaki.md
@@ -0,0 +1,267 @@
+# Uzumaki
+
+Imaginary tidal derivative maxinotation
+
+## Step count basics
+
+A 'pure' value, twice per cycle, count of 1
+
+```js
+fast 2 [a]
+```
+
+The same, but with count of 2
+
+```js
+density 2 [a]
+```
+
+Count of 2
+
+```js
+[a a]
+```
+
+Count of 2
+
+```js
+[a!2]
+```
+
+Count of 1
+
+```js
+[a*2]
+```
+
+Count of 2
+
+```javascript
+[[a a] b]
+```
+
+Count of 4 (step marker)
+
+```javascript
+[[= a a] b]
+```
+
+## Patterned parameters
+
+Notation for aligning patterns of patterns
+
+### `fast` factors
+
+Pure factor
+
+```js
+fast 2 [a]
+// same as
+[[a a]] // count unchanged at 1
+```
+
+Patterned factor - default alignment (cyclewise inner join)
+```js
+fast [2 4] [a]
+// same as
+[[a [a a]]] // count unchanged at 1
+```
+
+Patterned factor - stepJoin
+```js
+fast ^[2 4] [a]
+// same as
+[[a a] [a a a a]] // count becomes 2
+```
+
+### `density` factors
+
+Pure factor
+
+```js
+density 2 [a]
+// same as
+[a a] // count 2
+```
+
+Patterned factor - default alignment (cyclewise inner join)
+```js
+density [2 4] [a]
+// same as
+[a [a a]] // patterned count [2 4]
+```
+
+Patterned factor - stepJoin
+```js
+density ^[2 4] [a]
+// same as
+[a a a a a a] // count 6
+```
+
+## `euclid`
+
+A function with a parameter that sets the count
+
+```js
+euclid 3 8 "a"
+// same as
+[a - - a - - a -] // count 8
+```
+
+innerJoin
+
+```js
+euclid [3 5] 8 "a"
+// same as
+[a - - a - a a -] // count 8
+```
+
+```js
+euclid 3 [8 16] "a" 
+// can't be bothered to type it out, but patterned count [8 16] ..
+```
+
+stepJoin
+
+```js
+euclid ^[3 5] 8 "a"
+// same as
+[a - - a - - a - a - a - a -  a -] // count 16
+```
+
+```js
+euclid 5 ^[8 16] "a"
+// same as
+[a-aa-aa-a--a--a--a--a---] // count 24
+```
+```js
+euclid ^[3 5] ^[8 16] "a"
+// same as
+// count 48, not sure what order..
+```
+
+## Truer cyclic behaviour
+
+For example in tidal, `iter 4 "a b c d"` creates a pattern over four cycles. The default behaviour should instead tend towards maintaining a cycle.
+
+```js
+iter 4 [a b c d]
+// same as
+[a b c d b c d a c d a b d a b c] // count of 16
+```
+
+If the live coder does want to maintain the pace of the source pattern then a function name modifier/suffix could do that, maybe `iterover`..
+
+## Embedding patternings
+
+```javascript=
+[a b (fast 2 c)]
+// same as
+[ a b c*2]
+```
+
+```js
+[a b c d (iter 4 [a b c d])]
+// same as
+stepcat [a b c d] (iter 4 [a b c d])
+// same as
+[a b c d a b c d b c d a c d a b d a b c] // count of 20
+```
+
+## Simplified syntax
+
+Everything should be possible just with [] to enter mininotation land, and () to go into function land. i.e. all the behaviour can be described with functions.
+
+From there, we can think about how to best use the remaining brackets {} <> and other non-alphabetic characters */^ etc.
+
+opinion 1: <> should be another way to enter miniland, because it's very common
+opinion 2: " could be synonymous for [] ... why? because it makes things more backward compatible to regular mini notation, also " is easier to type on most keyboards. not sure if we should only allow it on the top level or if it should work everywhere
+
+```js
+"a b (fast 2 c)"
+// same as
+[a b (fast 2 c)]
+// same as
+<a b (fast 2 c)>*3
+```
+
+```js
+"a [b c]"
+// same as
+[a [b c]]
+// same as ?
+"a "b c""
+```
+
+the last example might be a bit confusing, because double quotes have no direction, so it's harder to read
+
+
+## Patterns of functions
+
+Patterning functions should also be possible:
+
+```js
+^[fast slow] 3 "a b c"
+// same as
+[a b c]*3 [a b c]/3 // count of 6
+```
+
+```js
+^[expand contract] 2 "a b c"
+// same as
+[a@0.5 b@0.5 c@0.5 a@2 b@2 c@2] // count of 7.5
+```
+
+```js
+^[(fast 2) (iter 4)] "a b c d"
+[a@0.5 b@0.5 c@0.5 d@0.5 a@0.5 b@0.5 c@0.5 d@0.5 a b c d b c d a c d a b d a b c] // count of 20
+```
+
+## Other binds
+
+Aside from `[]` for a cyclewise innerBind and `^[]` for a list-like stepwise bind, there are a lot of other possibilities. We need to find nice syntax for them..
+
+Cyclewise:
+* inner `|^`
+* outer `^|`
+* mix `|^|`
+* trig/reset
+* trigzero/restart
+
+Eventwise (?):
+* squeezein `||^`
+* squeezeout `^||`
+
+Stepwise:
+* list-style `^`
+* polymeter 
+* Zip
+* ...
+
+## Applicative
+
+Some functions don't deal with structure but only values, e.g. arithmetic, boolean and bitwise operators (multiply, subtract, not, bitwise and etc). There are unary (i.e. single argument) functions like boolean `inv` and numerical `negate`, which can be straightforwardly implemented with a functor map, as they do not deal with structure at all.
+
+There are also a lot of binary (i.e. two arguments), including arithmetic, boolean, and bitwise functions, which in tidal are inline operators.
+
+'Patternifying' such functions can be done in a nicely standardised way, as the composition of structure is completely separate from the composition of values. They can also be notated in terms of the operator, and not the constituent patterns, e.g. for `add` with a 'squeeze in' applicative lift:
+
+```js
+[1 2 3] ||+ [10 20]
+// same as
+[11 21 12 22 13 23] // count of 6
+```
+
+The count is a bit ambiguous in the above, it could be a count of three like 
+
+```js
+[[11 21] [12 22] [13 23]]
+```
+
+But that could be expressed like:
+
+```js
+[1 2 3] ||+ [[10 20]]
+```
+
+