Open crcdng opened 1 year ago
Hi @crcdng,
Many thanks for putting attention to this!
This is a step in the right direction, but transition (which interpolate is implemented through l) uses ID in latest Tidal:
The current type signature is thus Sound.Tidal.ID.ID -> ControlPattern -> IO ()
as far as I can tell. What version of Tidal are you on?
Hi @crcdng,
Many thanks for putting attention to this!
This is a step in the right direction, but transition (which interpolate is implemented through l) uses ID in latest Tidal:
The current type signature is thus
Sound.Tidal.ID.ID -> ControlPattern -> IO ()
as far as I can tell. What version of Tidal are you on?
1.9.4
I think the issue here (and I believe similarly in https://github.com/tidalcycles/tidal-doc/pull/216) is that the signature in the documentation...
Type: interpolateIn :: Time -> [ControlPattern] -> ControlPattern
does not match the text and the example below it:
"Morph control values between patterns in a given number of cycles. The first argument supplied to interpolate is the ID of the new pattern that is created and the second is the number of cycles."
d1 $ sound "arpy*16" # cutoff 100
interpolateIn 1 2 $ sound "arpy*16" # cutoff 16000
And in the source code file you referenced above there is actually a third variant which does not match either version:
interpolateIn :: Time -> Time -> [ControlSignal] -> ControlSignal
The interpolateIn
that the end user gets is defined in BootTidal.hs in v1.9: https://github.com/tidalcycles/Tidal/blob/3b44c5fb514721fb255901523e71ab1487da4f9d/BootTidal.hs#L46
The transitions need re-integrating into the current main branch. We should tidy things up in the process so that the internal helpers are given different names to the end user functions, maybe prefixed with _
.
fixes the type signature of interpolateIn