Re: [Haskell-cafe] GHC's timing: Now solid enough for music?

Vivid has combinators to schedule music with sample-accurate timing (it's as simple as prepending e.g. "doScheduledIn 0.2" to any VividAction, where 0.2 is 0.2 seconds from now - everything will be precise relative to that start time). "doScheduledAt" is another useful one. You can also write to a file with precise timing by prepending e.g. 'writeNRT "foo.wav"'. Still, I'd be curious to know the more-general answer to the question of how accurate we can expect forkIO and threadDelay to be, under normal load. E.g. how often/by how much does threadDelay take longer than needed to wake? To my ears and a few quick tests it's usually surprisingly good. Tom

El 2 jul 2018, a las 19:26, Jeffrey Brown escribió:

I just discovered Tom Murphy's Vivid-Synth[1], a Haskell library that lets you control SuperCollider. (A few very slight changes allowed me to get it to work in Stack instead of Cabal, as described here[2,3].)

TidalCycles[4] also controls SuperCollider from Haskell. It does tortuous backflips to hand the timing job over to SuperCollider. If I recall correctly, that was because SC's timing was more solid than Haskell's.

I modified the Vivid demo to go faster and have a few more voices[5], and tried running it at the same time as Spotify and Youtube and apt upgrade and loading LibreOffice and playing some music in VLC, and I detected (by ear) no timing errors.

Can I expect GHC's maybe-new rhythmic stability to hold up?

[1] http://www.vivid-synth.com/ [2] https://github.com/vivid-synth/vivid/issues/5 [3] https://github.com/JeffreyBenjaminBrown/vivid/commit/3d25266d4495d9dd8e573f3... [4] https://tidalcycles.org/ [5] https://github.com/JeffreyBenjaminBrown/vivid/blob/jbb/jbb/sine.hs

-- Jeff Brown | Jeffrey Benjamin Brown Website | Facebook | LinkedIn(spammy, so I often miss messages here) | Github