Cycseq branch - backward compatibility
yaxu opened this issue · 3 comments
TODO
- chew
- cycleChoose
- deconstruct - implement in Show?
- every' (everyBack?)
- fastSqueeze
- fit
- fit'
- foldEvery (better name?)
- ghost
- ghost'
- ghost''
- 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
@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?
@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?
(I guess a lot of type signatures will change...)