Dynamic manipulation of pattern length (and start/end points)

I'm thinking there might need to be two fixes. First, add abs to the definition of lingerIn as follows:
lingerIn :: (Pattern Time, Pattern Time) -> Pattern a -> Pattern a
lingerIn a@(t1,t2) p = slow (abs (t2 - t1)) $ zoom' a p

However, there also will likely need to be a function that adjusts the Arc to prevent "negative" spans, so to speak...for example, lingerIn (0.75,0) n "c5" takes place in the arc between 0.75 and 0, which would be a reversed Arc. I don't know the helper functions for this kind of thing, but I imagine they exist.

Edit: Just realized this doesn't address what you mention @ndr_brt, but I wonder if it is due to a similar issue.

Strudel has an interesting approach to this called reset:

The original pattern is 'reset' at the start of each event in the pattern on the right.

It would be good to backport this to tidal!


I tried some things and came up with this:

eventStart = withEvent (\e -> e {value = 1 - wholeStart e})
rotL' = tParam rotL
reset b p = (rotL' $ eventStart b) p

d1 $ (reset ("t*4" :: Pattern Bool)) (n "0 1 2 3" # s "arpy")

which seems to work at least for some basic examples that i've tried..
the type signature should probably be fixed to Pattern Bool -> Pattern a -> Pattern a, so one doesn't have to be verbose with the types

I wanted to ask you @yaxu why rotL isn't lifted to the pattern level yet (as i did above). Are there any cases where that would break things / result in unexpected behaviour? I tested it a little bit and although it has a very complex behaviour when patterned it seems to do what it should

1 Like

I think the operators <~ ~> are patterned, and rotL and rotR are kind of internal functions, that aren't patterned out of efficiency. But I have also found that they're useful as plain functions too.. Due to the heavy use of $ in Tidal, <~ and ~> often need some brackets to get them to work.

Javascript doesn't allow custom or overloaded operators at all, so everything is a function or method there. These functions are called early and late which I think is a bit friendlier than rotL and rotR, maybe we should backport these names too?

1 Like


yes, I think that would be nice, I think I prefer those names over rotL and rotR

so maybe keep rotL and rotR for internal things and add early and late as prefix versions of ~> and <~ ?

1 Like

Sounds good!

1 Like