Cycseq branch - backward compatibility

[yaxu]

TODO

• [x] chew
• [x] cycleChoose
• [ ] deconstruct - implement in Show?
• [ ] every' (everyBack?)
• [ ] fastSqueeze
• [ ] fit
• [ ] fit'
• [x] foldEvery (better name?)
• [ ] ghost
• [ ] ghost'
• [ ] ghost''
• [x] grain
• [ ] interpolate
• [ ] interpolateIn (?)
• [ ] jux
• [ ] jux'
• [ ] jux4
• [ ] juxBy
• [ ] juxcut
• [ ] juxcut' (these need sorting out)
• [ ] layer?
• [ ] mono
• [ ] permstep
• [ ] pick
• [ ] pickF
• [ ] plyWith
• [ ] randArcs (?)
• [ ] randStruct (?)
• [ ] randrun (?)
• [ ] rangex
• [ ] sameDur (?)
• [ ] scramble (for random)
• [ ] select (rationalise with pick / pickF?)
• [ ] selectF
• [ ] sew
• [ ] shuffle (for random)
• [ ] silent (?)
• [ ] slowCat
• [ ] slowSqueeze
• [ ] slowappend
• [ ] slowspread
• [ ] slowstripe
• [ ] smooth
• [ ] spaceOut
• [ ] spread
• [ ] spread'
• [ ] spreadChoose
• [ ] spreadf
• [ ] spreadr
• [ ] squeeze (?)
• [ ] squeezeJoinUp (?)
• [ ] stackwith (?)
• [ ] step
• [ ] step'
• [ ] steps
• [ ] stitch
• [ ] stretch
• [ ] stripe
• [ ] substruct
• [ ] swap (?)
• [ ] swing
• [ ] swingBy
• [ ] tabby
• [ ] timecat (?)
• [ ] toScale / toScale (?)
• [ ] uncollectEvent / uncollectEvents
• [ ] ut (reimplement with sequence ?)
• [ ] wait/waitT (transition ?)
• [ ] whenmod
• [ ] within / within'
• [ ] draw/drawLine/drawLineSz

From 'simple' module ?

• [ ] higher
• [ ] louder
• [ ] lower
• [ ] quieter
• [ ] slower
• [ ] faster
• [ ] crunch
• [ ] scratch
• [ ] skip
• [ ] left (?)
• [ ] right (?)

Move to Sequence

• [ ] lindenmayer
• [ ] lindenmayberI
• [ ] markovPat
• [ ] runMarkov
• [ ] seqP / seqPLoop - reimplement with sequence

Removed

• stut
• offadd
• samples
• samples'
• chunk' - use chunk with negative number

Renamed

• iter' -> iterBack
• collectBy -> _collectBy
• collectEvent -> _collectEvent
• collectEventsBy -> _collectEventsBy

[yaxu]

@dktr0 I've been working on some major changes in the cycseq branch, towards tidal version 2.0, that have broken tidal-parse. I think things can be mostly backwardly compatible in terms of end-user code but the internals have changed quite a lot.

For example Pattern is now a typeclass, and the datatype formerly known as Pattern is now called Signal that implements it. This makes way for Sequence as a second instance of Pattern with a different representation oriented around sequences, which could be seen as a formal representation for the mininotation that will allow a lot more flexibility.

There's also a lot of added stuff, for example much more flexible strategies for aligning patterns. I can go into more details if you like.

So the question is what to do about tidal-parse. I think easier for now would be to get it compiling as-is. I.e. so tidal-parse still parses tidal 1.9.x syntax and behaviour and nothing more. Then if/when tidal-2.0 is released we can look at adding the additional operators and worry about this new signal type.

Does that sound good? Would you be interested in/have some time spare to help with the changes (if needed, it might turn out super simple, not sure..) and trying it out in estuary?

[dktr0]

@yaxu sounds good! If not too much changes about the "surface" syntax of tidal-parse, it probably is fairly straightforward - there's not a lot of exposure to Tidal's "internals" in tidal-parse. Is tidal-parse still working okay with 1.9.x?

[dktr0]

(I guess a lot of type signatures will change...)