Jeffrey Brown wrote:
Thanks, everybody! Those were incredibly informative answers. This list is amazing.
Heinrich's suggestion of compiling with "-threaded" was by itself sufficient to get the first rhythm to sound right.
The second rhythm, however, still blurs into a string of beeps of the same duration even after I throw all of Heinrich's and Carter's suggestions at it by doing this:
ghc --make fast -threaded -fno-omit-yields -with-rtsopts -C0
(although I should admit to not really knowing what I'm doing when I run that) where fast.hs is this:
import Control.Concurrent import Text.Printf import Control.Monad import System.IO main = do hSetBuffering stdout NoBuffering mapM_ note (cycle [1,1,2]) beat = round (10^6 / 10) -- measured in microseconds note :: Int -> IO () note n = do threadDelay $ beat * n printf "\BEL\n"
I therefore suspect I have to teach myself, as Brandon suggested, a realtime scheduler. This seems like a general, powerful thing: http://hackage.haskell.org/package/atom
I would be hesitant to attribute your problem to the scheduler. An alternative explanation could be the following: The sound file played by the terminal when it encounters the \BEL character is longer than 100ms. A new sound will be played only when the previous sound has finished playing, so the terminal will queue \BEL characters until the previous ones have finished. But since they arrive too fast, there will never have any pause in between and you hear a constant rhythm. I can't test this theory because the \BEL character doesn't work in my Terminal application, but I have just listened to a kick drum sample on autorepeat and got a tempo of less than 200bpm. This means that the file is significantly longer than 100ms (or that starting the file from the beginning again takes a long time, but I did not notice any extended silence). An length of 100ms would correspond to 600bpm. To test this theory, you can try to sweep through lower tempi like 200bpm-500bpm and look for the threshold when the actual tempo plateaus even though you are increasing the scheduling tempo. This should be correspond to the length of the audio file. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com