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.
let
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
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?