Sorry for the slow reply, had a virus come to stay, wasn't invited the
bastard. Anyways, thanks for all the suggestions! spaceOut seems to be the
closest to what i'm after. i'm now trying to sweep the filter cutoff for
each sample triggered but not sure how i change it per sample. for example,
d1 $ fast 4 $ spaceOut [0.09,0.1..0.8] $ sound "hc" # cutoff (scale 200
4000 $ slow 4 $ sine)
only changes the cutoff at the start of each group of samples. and this...
d1 $ (# cutoff (scale 200 4000 $ slow 3 $ sine)) $ fast 4 $ spaceOut
[0.09,0.1..0.8] $ sound "hc"
is pretty close to the effect i'm after but the modulation is independent
of the "hat rush". still sounds cool but not quite there. is it possible to
tie in the cutoff pattern with the spaceOut pattern somehow?
On Wed, Jan 17, 2018 at 4:40 AM, Jeffrey Brown <jeffbrown.the(a)gmail.com>
The latest version of Sound.Tidal.Epic has a facility for continuous
sinusoidal warping of time. It lets you slow down a waveform by specifying
how much you want to delay the 90 degree phase (the 25% mark). It leaves
phase 0 and 180 unaffected, and arrives at phase 270 (the 75% mark) faster,
In the rest of this I'll say "25% of the way through" instead of "at
equal to 90 degrees", etc. because it's more intuitive.
For instance, suppose we define the Epic `f` to be a unit-duration loop
that plays a 1 at time 0, a 2 at time 1/4, a 3 at time 1/2, and a 4 at time
f = fast 4 $ cata 1 [1..4]
Let's define next a transformation `w`, which will warp time in the
following manner: (1) It will leave unchanged what happens 0% and 50% of
the way through the waveform (because that's where a sinewave is equal to
0). (2) For the first half of the waveform, it will slow things down. At
"peak lag", the wave will be slowed down so much that what would have
happened 25% of the way through instead happens (in this case) 30% of the
way through. (3) In the second half of the wave it speeds up,
symmetrically; what would have happened 75% of the way through the cycle
instead happens 70% through.
We can define that function as follows:
w = warp 0.001 0.30 1
The last argument is its period. The second to last indicates that we are
slowing down the 25% mark to land on the 30% mark. The first is a
tolerance, necessary because internally it converts floating points to
rational numbers. (If I knew it was cpu-friendly I would just set that
tolerance to a very low number.)
Here's how it looks in action. (plist is just a function that
pretty-prints a list.)
> plist $ arc f (0,1) -- the original (non-warped) Epic
((0 % 1,1 % 4),1)
((1 % 4,1 % 2),2)
((1 % 2,3 % 4),3)
((3 % 4,1 % 1),4)
> plist $ arc (w f) (0,1) -- the warped Epic
((0 % 1,3 % 10),1)
((3 % 10,1 % 2),2)
((1 % 2,7 % 10),3)
((7 % 10,1 % 1),4)
On Tue, Jan 16, 2018 at 7:15 PM, Alex McLean <alex(a)slab.org> wrote:
> Very interesting use of spaceOut!
> There is one way of continuously shifting time, using the 'nudge'
> parameter. It adds on the given amount of time (in seconds), so if you
> give it a sine function you get the effect of time speeding up and
> slowing down:
> d1 $ sound "bd*8" # nudge (slow 4 sine)
> d1 $ (chop 32 $ sound "bd [cp ht]")
> # nudge (slow 4 sine)
> The 'nudge' parameter has some drawbacks - you can't shift backwards
> in time very far, and if you shift it into the future you'll find that
> live coded changes take longer to take effect.
> In theory this sort of thing should work better:
> d1 $ (slow 16 $ toRational <$> sine) ~> sound "bd*16"
> In practice it doesn't work well at all, due to internal weirdness
> with causality, or something...
> On 16 January 2018 at 16:23, Mike Hodnick <mike(a)kindohm.com> wrote:
> > I think what you're asking is to change the speed of a pattern's cycle
> either discretely (e.g. single speed per cycle, or within a cycle) or
> continuously (speed increases/decreases continuously throughout a single
> cycle). You can't really change a cycle's speed continuously, but you can
> kind of approximate it.
> > *Caveat: I can't explain the concept of a "cycle", in terms of
> very well. The words "cycle" and "time" and "speed"
mean different things
> to different people, so I apologize if I'm mixing up the Tidal vocab here.
> > I guess the easiest way to change cycle speed within a cycle is to use
> the "fast" and "slow" functions, and to pass patterns of values
> > -- use a pattern for fast/slow
> > d1 $ fast "1 1.5 2 2.5" $ sound "bd*2 cp*2 [ch lt] drum"
> > d1 $ slow "1 1.5 2 2.5" $ sound "bd*2 cp*2 [ch lt] drum"
> > d1 $ fast "<1 1.5 2 2.5>" $ sound "bd*2 cp*2 [ch lt]
> > but I'm betting this doesn't produce the effect you want. But how
> about this:
> > I just recently learned about the "spaceOut" function, which spaces
> the speed of a cycle by a list of values without mangling the cycle
> boundaries. In other words, the next cycle does not start until the
> previous one ends, and a cycle will not be cut off until it is done playing:
> > d1 $ spaceOut [1,1.5,1.25,2,0.5,0.75] $ sound "bd*2 cp*2 [ch lt]
> > You can approximate continuously increasing/decreasing speeds with a
> linear list of values:
> > d1 $ spaceOut [1,2,3,4,5] $ sound "bd*8"
> > d1 $ spaceOut [5,4,3,2,1] $ sound "bd*8"
> > or with better Haskell syntax:
> > d1 $ spaceOut [1,2..5] $ sound "bd*8"
> > d1 $ spaceOut [1,1.1..5] $ sound "bd*8"
> > And then you can easily go off the deep end:
> > d1 $ stack [
> > (# pan (slow 5 sine)) $ spaceOut [1,1.1..5] $ sound "bd*8",
> > (# pan (slow 4 sine)) $ slow 1.1 $ spaceOut [5,4.9..1] $ sound
> "cp*8" ]
> > ^^ have not tested any of this code, use at your own risk
> > Does this get you closer to what you're going for?
> > -Mike
> > --
> > Mike Hodnick
> > mike(a)kindohm.com
> > On Tue, Jan 16, 2018, at 5:26 AM, Pete Marshall wrote:
> >> Hello all,
> >> I'm new to Tidal so apologies in advance if this is a dumb question.
> Is it
> >> possible to vary the spacing of sample triggers within a pattern? I'd
> >> to replicate the effect of the clock speeding up or slowing down
> >> tinkering with the cycles per second (global) clock. From what I can
> >> gather, it seems that sample triggers are always evenly spaced within a
> >> pattern, is that correct?
> >> Cheers,
> >> Pete
> >> _______________________________________________
> >> TidalCycles mailing list -- tidal(a)we.lurk.org
> >> To unsubscribe send an email to tidal-leave(a)we.lurk.org
> > _______________________________________________
> > TidalCycles mailing list -- tidal(a)we.lurk.org
> > To unsubscribe send an email to tidal-leave(a)we.lurk.org
> blog: http://slab.org/
> TidalCycles mailing list -- tidal(a)we.lurk.org
> To unsubscribe send an email to tidal-leave(a)we.lurk.org
Jeff Brown | Jeffrey Benjamin Brown
, so I often
miss messages here) | Github <https://github.com/jeffreybenjaminbrown>
TidalCycles mailing list -- tidal(a)we.lurk.org
To unsubscribe send an email to tidal-leave(a)we.lurk.org