(Since I don't read Haskell Cafe, I dropped it from the cc list.) I just wanted to mention that at Yale we are still working on CCA (causal commutative arrows) to get higher performance digital audio. Although it may seem objectionable to use arrows at all, it has some key advantages. For example, you can write recursive signals with no problem, and they will (theoretically) get optimized as well as straight-line code.
Unfortunately, there are some major hurdles still in front of us. We'd like to use an automated system like Template Haskell to do the optimizations for us, but it has some annoying limitations that have made it difficult to use in practice. Furthermore, if you have structural recursion (for example a nested filter) then it needs to be unwound at compile time (perhaps using inlining). Finally, it's not entirely clear how to handle things like delay lines and multiple clock rates. But the good news if that these problems can be solved, then every program can be optimized / normalized into a single loop with NO arrow combinators, which is then highly amenable to good code generation. Best, -Paul Hudak Sent from my iPad On Jan 2, 2011, at 9:04 AM, "Henning Thielemann" <[email protected]> wrote: > > On Sun, 2 Jan 2011, Stephen Tetley wrote: > >> I'm trying to make a Stream library, hopefully efficient enough for >> audio synthesis in the style of Jerzy Karczmarczuk's Clarion. > > I am trying to code real-time audio synthesis in Haskell for some years > now. I can tell at least, that it is not so easily done. Even with the > right data structure, GHC's optimizer does not always make, what you need. > Thus the most efficiency I get by using LLVM to construct signal > processing code at run time, so far. (see synthesizer-llvm package) > >> As performance is important, the obvious model is the Stream-Fusion >> library, but 'cons' is problematic in this style. > > Yes, 'cons' is problematic. I think efficient 'cons' needs a material data > structure, not just a generator function as in stream-fusion:Stream. > >> data Stream a = forall st. Stream !(st -> Step a st) !st >> >> For infinite Streams the Done constructor can be removed from the Step >> type, a truly infinite is never done: > > For audio synthesis you need also finite signals. Or am I missing > something? > > At least I found that the 'Skip' constructor can be omitted for audio > synthesis: > > http://hackage.haskell.org/packages/archive/synthesizer-core/0.4.0.4/doc/html/Synthesizer-State-Signal.html > > >>> bad_loopy :: [Int] >>> bad_loopy = S.append1 (S.take 10 v) [] >>> where >>> v = 1 `S.cons` v > > The problem is that S.cons must take the internal state type of 'v' and > must wrap it in a new type. Thus every S.cons makes the internal state > more complicated. This is inefficient for several applications of S.cons > and impossible for infinitely many calls. > > > In order to get both elegant laziness and efficiency I played around with > a head-strict list implemented via Storable. Here an efficient 'cons' > seems to be doable: > http://code.haskell.org/storablevector/Data/StorableVector/Cursor.hs > > However if there remains only one bit of laziness in an inner loop, you > will not get good efficiency. > _______________________________________________ > haskell-art mailing list > [email protected] > http://lists.lurk.org/mailman/listinfo/haskell-art _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
