my idea is to use (m/seed “dummy”) to create a discrete flow of chars, and then consume it slowly, perhaps by creating another discrete flow of ticks and then figuring out how to alternate them

broadly, i think discrete things are best modeled in missionary not electric

(defn delayed-seed [d xs]
  (m/ap (m/? (m/sleep d (m/?> (m/seed xs))))))

((->> "hello"
   (delayed-seed 1000)
   (m/reduce (fn [_ x] (prn x)) nil))
 #(prn :success %) #(prn :failure %))

m/sleep solutions all drift don’t they?

this one yes, it's a fixed delay. But you could build a fixed rate with m/sleep too

(defn fixed-rate-seed [d xs]
  (m/ap (let [[x t] (m/?> (m/seed (map vector xs (iterate (partial + d) (System/currentTimeMillis)))))]
          (m/? (m/sleep (- t (System/currentTimeMillis)) x)))))

wow thank you!

what is the difference between fixed-rate-seed and delayed seed? i don't think i understand "drift"

oh is it because the later values depend on the sleep of the previous values?

gpt4 knows about missionary! i wonder how correct this is

in java, (thread/sleep N) will sleep at least N seconds, generally a couple ms over, so if you repeat these sleeps you’ll drift away from a true clock

i see

how about in javascript? i assume not so

also these differences probably don’t matter too much for ux, so we are good

just interesting

in js chain of setTimeout will drift, setInterval should not

and drift by couple ms, right?

at most

nothing too crazy

a couple ms per tick

right right

i wanted to add noise anyway lol

ty!

the corrected ticker, which leo shows, uses platform sleep (which is blurry) but then measures how long it actually took, thus adjusting for the variance

perfect

very elegant