Move stuff to new register function

[felixroos]

getting rid of all usages of Pattern.prototype.define,Pattern.prototype.bootstrap, Pattern.patternify, patternifyN

[felixroos]

refactoring is mostly done, removed all all old define calls + stuff that is no longer needed. Had to rename csound to loadCsound to avoid overwriting the new toplevel csound function. Tests still fail.. some listening / testing to do

[felixroos]

not sure how to handle this: 306004e ref #245

[felixroos]

after looking at the failed snapshot tests, I think it's safe to overwrite the snaps. There are 3 reasons why things changed:

1. haps are reordered (can be ignored)

• example "someCycles" example index 0 1` mismatched
• example "sometimes" example index 0 1` mismatched
• tune: outroMusic 1` mismatched
• tune: belldub 1` mismatched => haps are just sorted differently

2. voicings in different octave after refactoring (sounds the same)

• example "voicings" example index 0 1` => different range
• example "addVoicings" example index 0 1` mismatched => voice leading did not work at snap time
• tune: loungeSponge 1` mismatched => 1 octave down
• tune: festivalOfFingers 1` mismatched => 1 octave down
• tune: caverave 1` mismatched => 1 octave down

3. mini notation random operators were stateful

• example "degrade" example index 1 1` mismatched => now stateless "?"
• example "degradeBy" example index 1 1` mismatched => now stateless "?"
• tune: arpoon 1` mismatched => now stateless "?"
• tune: sampleDemo 1` mismatched => now stateless "|"
• tune: delay 1` mismatched => now stateless "|"

1 seems to be normal with the new register function. it already happened in #286

2 looks like the old data had wrong octaves the whole time. I listened to all the failing examples / tunes, they sound exactly the same as before

3 comes from the fact that the mini notation had a stateful handling of random values. I would remove that behavior, as it is undeterministic and leads to bugs, e.g. #245

[yaxu]

Tidal has a 'defragment' function that combines adjacent parts with the same whole and value. Along with sortHapsByPart this can be 'good enough' for comparing equivalent but differently fragmented patterns in tests.

Just having a go at porting defragment..

[felixroos]

Just having a go at porting defragment..

do you plan to add it to this PR or should we merge this one first?

[yaxu]

I can do it as a separate PR