(Re)naming pattern composers

[yaxu]

There are already a few ways to compose two patterns together by matching events and merging their values, union, add, mul, sub, and add.

union isn't a good name for this, because they all do a union. The distinguishing feature is that when doing the union, a.union(b) it replaces values from pattern a with values from b. So I propose renaming it to set (as in, set the values to, not set theory).

A variant that keeps values in a could be called const.

Where matching events don't have the same timespan but do overlap, currently you end up with the intersection as a fragment of the pattern on the left (pattern a in the above). We can also have variants setRight, addRight, mulRight etc. This is a bit ambiguous though, especially forconstRight, because there's confusion about whether it's the fragment structure, or the value that we're taking from the rightmost pattern. Maybe setFlip, constFlip etc for 'flipping' the structure is better? This assumes that taking wholes from the left is default.

Then there is the variant where the intersections of matching events are treated as whole events. E.g. where "1 2 3" + "10 20" gives 11 [12 22] 23. One possibility is using the suffix 'Sect' for intersection. setSect, addSect etc. I quite like this because you can also think about it dividing events into sections.

(In Tidal, this is done with operators like |> for set, >| for setFlip |< for const, |<| for constSect, |+ for add, +| for addFlip, + or |+| for addSect, etc. This works nicely, but because javascript doesn't support custom operators, and there aren't enough to overload, we have to find a reasonable way to do this with words instead. Still, it would be nice to alias + for add)

All of the variants so far assume that we're composing patterns by aligning cycles and seeing which events intersect, then combining them. There are more possibilities though! For example, squeeze, which aligns cycles on the right with event timespans on the left.

"1 2 3".addSqueeze("10 20")
===
"[11 21] [12 22] [13 23]"

... and then we might want to flip and squeeze:

"1 2 3".addSqueezeFlip("10 20")
===
"[11 12 13] [21 22 23]"

I think there could be a lot of uncharted possibilities for squeeze.. and probably other structural ways to combine patterns.

[yaxu]

Implemented in #83

[yaxu]

Merged

[felixroos]

this might be another way to combine patterns #53

[felixroos]

This looks all really good. Let me write down some lists to help my brain a bit:

1. there are 2 main aspects of haps:

• a. value: hap content
• b. structure: temporal structure, where the haps land in time

2. strategies to merge values

• a. add / mul / sub / div: binary arithmetic operations, "0 1".add("1 2") === "1 3"
• b. set: assign to object values: n("0 1").set(room(.5)) -> {n:0,room:.5}, {n:1,room:.5}
• c. keep: keep value as is, only merge structure
• what else?

There are shorthand pattern methods to set for each value type: n("0 1").room(.5) === n("0 1").set(room(.5)). Here .room is the shorthand.

3. strategies to merge structure

• a. '' (empty): use structure from the left
• b. flip: use structure from the right
• c. sect: merge structure from left and right
• d. reset
• e. restart

for reset and restart, see #53 + discord discussion

4. pattern composers = combination of 2 and 3

Using both strategies for values and structure, we can generate all possible ways of pattern interaction:

<valueStrategy><structureStrategy>

.	add	set	keep
''	.add	.set	.keep
flip	.addFlip	.setFlip	.keepFlip
sect	.addSect	.setSect	.keepSect
reset	.addReset	.setReset	.keepReset
restart	.addRestart	.setRestart	.keepRestart

5. Thoughts

I'm not sure if I like the '' / 'Flip' / 'Sect' naming. For my understanding '' (or 'Left') / 'Right' / 'Both' would be more logical. Also, the sect is pretty close to set.

.	add	set	keep
''	.add	.set	.keep
left	.addLeft	.setLeft	.keepLeft
right	.addRight	.setRight	.keepRight
both	.addBoth	.setBoth	.keepBoth
reset	.addReset	.setReset	.keepReset
restart	.addRestart	.setRestart	.keepRestart

Also, it would be easier to think about this stuff if we had some better wording for "strategy to merge values" + "stategy to merge structure"

6. How does reset / restart / squeeze fit in here?

Are those siblings to '' / flip / sect ? Or would it make sense to resetFlip resetSect ?
Edit: okay its a sibling.

7. default pattern methods for structure?

With reset and restart as part of the structure family, the default cases .reset and .restart don't make much sense

We could use

Pattern.prototype.reset = Pattern.prototype.keepReset;
Pattern.prototype.restart = Pattern.prototype.keepRestart;

[felixroos]

yes i meant to associate a value that is then combined with the target pattern using a function

[yaxu]

I see, have you seen the when function?

strudel/packages/core/pattern.mjs

Lines 580 to 587 in 47717e8

	when(binary_pat, func) {
	//binary_pat = sequence(binary_pat)
	const true_pat = binary_pat._filterValues(id);
	const false_pat = binary_pat._filterValues((val) => !val);
	const with_pat = true_pat.fmap((_) => (y) => y).appRight(func(this));
	const without_pat = false_pat.fmap((_) => (y) => y).appRight(this);
	return stack(with_pat, without_pat);
	}

I think you're looking for this but with appLeft instead of appRight.. So maybe a whenFlip..

[yaxu]

Ah no you're not looking for a function driven by a binary pattern.. So addFlip indeed.

[yaxu]

Binary patterns are great though because you can easily invert them.
"a".struct("1 0 [1 0]*2 1".every(4, invert))

and use the same binary pattern across different parts of a pattern, sometimes inverted/shifted, to have a weird shared metrical feel

[yaxu]

Relatedly there's also func:

"0 [2 3]".func(x => (x + 3)/2, [x => 0 - x, x => 7])
===
"1.5 [-2 7]"

[yaxu]

Let's collect words for combining two patterns:

action	options
fragment events from left	'' (default), left, admit, fit, cast, shape, adopt, form
fragment events from right	flip, right, render, affect, impinge, fix, adapt, deform
intersect events	sect, section, merge, meld, interlace, mix, fragment, rend, cut, blend
align sam on left to start of event on right	reset, inhabit, dwell
align cycle zero on left to start of event on right	restart
fit cycles on right to events on left	squeeze, inhabit
fit cycles on left to events on right	squeezeFlip, expand, house

[felixroos]

I'll try to rephrase my idea with struct here:

"0 1".struct("1 2 3", add) so that would be like addFlip.

I meant, instead of (or in addition to) trying to come up with a single function name with the form
<valueStrategy><structureStrategy>, we could make it more explicit by extending the struct function family:

"0 1".add("1 2 3") // structure from left
"0 1".structWith("1 2 3", add) // structure from right
"0 1".mergeWith("1 2 3", add) // merge structure
"0 1".resetWith("1 2 3", add) // reset structure
"0 1".restartWith("1 2 3", add) // restart structure

For me, this feels pretty consistent with the existing API design, as many functions come with an added With, allowing to pass in a function. This comes with the additional benefit of being able to pass a custom function:

"0 1".structWith("1 2 3", (l,r) => l**r) 

[yaxu]

Right that seems promising. So then add and friends need some adjustment so that they also work on primitives, in which case the 'structure from left' aspect of add doesn't apply (as there aren't patterns involved).

I think it might be better this way around:

"0 1".structWith(add, "1 2 3") 

So that this could work:

"0 1".structWith(add, 1, 2, 3) 

.. and I think it reads better that way as well.

[yaxu]

But do we also make/keep "0 1".structAdd as shorthand for "0 1".struct(add, "1 2 3")? I think the latter is clearer, that structuring and adding are separate things going on. But once you've learned that, maybe it's nice to have the shorthand.
(we also haven't had a proper conversation about camelCase)

[yaxu]

Or maybe even struct and friends should check if the first argument is a function and the later once aren't, so "0 1".struct(add, "1 2 3") could work

[yaxu]

prototype for "0 1".struct(add, "1 2 3")

const _makeOp = curry(function (func, a, b) {
  if (a instanceof Pattern || b instanceof Pattern) {
    return reify(a).fmap(func).appBoth(reify(b));
  }
  return func(a)(b);
});

export const newAdd = _makeOp(a => b => a + b);

Pattern.prototype.newStruct = function (...args) {
  var func = undefined;
  if (args[0] instanceof Function) {
    func = args.shift();
  }
  else {
    func = constant;
  }
  return this.fmap(func).appLeft(sequence(args));
}

[yaxu]

So for operation op (like add, keep, set, ...) and structuring struct (like reset, merge, struct, ...), it could be

1. a.op(struct, ...b)

2. a.struct(op, ...b)

3. a.opStruct(...b)

4. a.structOp(...b)

5. a.op.struct(...b)

6. a.struct.op(...b)

7. Or one more idea, if this is too much to type we could look for initialisms, like

.	.
''	keep structure from left
S	restructure with right
M	merge structure from both sides
Sq	squeeze
X	reset
Xx	restart

to make addSq, addM, etc..

At the moment I prefer 3 or 7, but quite like 1 as well

[yaxu]

we could still support .struct((a,b) => a + b, "1 2 3")
but for compatibility with tidal
.struct("true false")
assumes a binary pattern and keep
whereas
.squeeze("a b")
works with any pattern and assumes set
if we standardise struct on set as well, it applies both values and structure, and becomes a kind of reverse mask..

[yaxu]

Lets also consider using in and out rather than left and right or `` and struct

Then we're either performing an operation to values inside their structure, or taking the values out of their structure.

addIn, addOut, keepIn, keepOut (!), and also addSqueezeIn/addSqueezeOut..

Instead of merge or sect we could then have mid or tween.

[felixroos]

Not sure where to put this, I just took some notes while rereading pattern.mjs after the clean up.
Happened to compare composers and transforms, which is also related to #264 and #36 . (Note that through auto formatting my notes, the double quotes went single)

These are the composers:

const composers = [
  'set',
  'keep',
  'keepif',
  'add',
  'sub',
  'mul',
  'div',
  'mod',
  'pow',
  '_and',
  '_or',
  '_xor',
  '_lshift',
  '_rshift',
  'lt',
  'gt',
  'lte',
  'gte',
  'eq',
  'eqt',
  'ne',
  'net',
  'and',
  'or',
  'func',
];

they are used to programatically define Pattern.prototype methods for different pattern aligment strategies:

['In', 'Out', 'Mix', 'Squeeze', 'SqueezeOut', 'Trig', 'Trigzero'];

Example:

'0 1 2 1'.addOut('1 2'); // = "1 3"
'0 1 2 1'.addIn('1 2'); // = "1 2 4 3"

then there are these curried transformation functions (further called transforms):

const transforms = [
  'add',
  'chop',
  'chunk',
  'chunkBack',
  'div',
  'early',
  'echo',
  'every',
  'fast',
  'inv',
  'invert',
  'iter',
  'iterBack',
  'jux',
  'juxBy',
  'late',
  'linger',
  'mask',
  'mul',
  'off',
  'ply',
  'range',
  'rangex',
  'range2',
  'rev',
  'slow',
  'struct',
  'sub',
  'superimpose',
  'set',
  'when',
];

these can be used as transformation methods like every, echoWith, superimpose etc:

'0 1 2'.superimpose(fast(2));

Let's look at how the two lists overlap:

composers.filter((c) => transforms.includes(c));
['set', 'add', 'sub', 'mul', 'div'];

In this list are functions you can use for both:

note('c3 d3 e3').addOut('1 2'); // works
note('c3 d3 e3').superimpose(add('1 2')); // works
note('c3 d3 e3').superimpose(addOut('1 2')); // what about?

These are functions you can only use as composer:

// transforms that are not composers
composers.filter((c) => !transforms.includes(c));
[
  'keep',
  'keepif',
  'mod',
  'pow',
  '_and',
  '_or',
  '_xor',
  '_lshift',
  '_rshift',
  'lt',
  'gt',
  'lte',
  'gte',
  'eq',
  'eqt',
  'ne',
  'net',
  'and',
  'or',
  'func',
];

example:

note('c3 d3 e3').powOut('1 2'); // composer: works
note('c3 d3 e3').superimpose(pow(2)); // does not work

At last, let's look at functions that can only be used as transforms and not as composers:

// composers that are not transforms
transforms.filter((c) => !composers.includes(c));
[
  'chop',
  'chunk',
  'chunkBack',
  'early',
  'echo',
  'every',
  'fast',
  'inv',
  'invert',
  'iter',
  'iterBack',
  'jux',
  'juxBy',
  'late',
  'linger',
  'mask',
  'off',
  'ply',
  'range',
  'rangex',
  'range2',
  'rev',
  'slow',
  'struct',
  'superimpose',
  'when',
];

Example

note('c3 d3 e3').superimpose(fast('<1 2>')); // transform: works
note('c3 d3 e3').fastOut('1 2'); // composer: doesnt work

Additionally, there is the large list of control params which would also need composed variants e.g. .speedOut()

General questions:

• Which functions should only be (composers | transforms)?
• Which functions should be both composers and transforms?
• Does it make sense to have transforms that also do aligment, like s("bd sd").superimpose(speedOut("1 2 3"))

I still think it might be a nice thing to have an alternative (possibly coexisting) to the matrix style function generation. Like this:

note('c3 d3 e3').structWith(add, '1 2');
note('c3 d3 e3').squeezeWith(add, '1 2');

(struct is used as synonym for out here)

With those, we could also solve the transforms that also do alignment thing with:

s("bd sd").superimpose(x=>x.structWith(speed, "1 2 3"))

[yaxu]

Ah nice!

note('c3 d3 e3').addOut('1 2'); // works
note('c3 d3 e3').superimpose(add('1 2')); // works

Do you mean they do the same? The latter will add events to the original (unless there's something wrong in the implementation or my understanding..).

• Which functions should only be (composers | transforms)?
• Which functions should be both composers and transforms?

Reading your notes, I think there isn't/shouldn't be much of a difference.

"4".pow(2) and friends do work, with default set behaviour. The top-level pow function is defined, but should be. As discussed on discord (I think) we should probably do this dynamically, exporting the functions from the module differently to make this possible, like controls.mjs.

One difference between composers and transforms is that 'composers' come from infix operators in Haskell, so have exactly two patterned arguments, including this. Transforms can have any arity. The other difference is that 'composers' compose together values, with a default or explicit pattern alignment to make that possible.

But really I think these composers are just a certain kind of transform.. Or we could call all of them composers, because the (patternified) 'transforms' compose their patterned arguments together just like 'composers' do.

• Does it make sense to have transforms that also do aligment, like s("bd sd").superimpose(speedOut("1 2 3"))

I think not like this, because the alignment doesn't really belong to the transform, but each of its arguments.

So say we do away with powOut and friends in favour of the new pow.out.

That means we can hopefully support "1 2 3".every(3, rev) as now, but also e.g. every.squeeze("3 4").set(rev, fast(2)). I.e, we can set a different alignment for each parameter.

I'm not sure what that last example ebove would actually do, but it makes me think that we could use func there to be explicit about the functional application, like every(3).func(rev, fast(2)) , making space for just putting a value there like every(3).set(4).. maybe we'd even want to support every(3).rev(4)? probably that would get confusing..