I've been using the CCA package with good results so far. Several people
(including myself) appear to have tried performing the CCA transformations
with a GADT rather than Template Haskell, without much success. Although
the code is transformed to normal form, performance isn't good. I suspect
Hudak, Paul schrieb:
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
Hi,
On Tue, Jan 4, 2011 at 11:40 AM, John Lato jwl...@gmail.com wrote:
I've been using the CCA package with good results so far. Several people
(including myself) appear to have tried performing the CCA transformations
with a GADT rather than Template Haskell, without much success. Although
On Tue, Jan 4, 2011 at 12:23 PM, Balazs Komuves bkomu...@gmail.com wrote:
Hi,
On Tue, Jan 4, 2011 at 11:40 AM, John Lato jwl...@gmail.com wrote:
I've been using the CCA package with good results so far. Several people
(including myself) appear to have tried performing the CCA
John Lato schrieb:
The other big problem is the name of the z function. I would like to
call it z-, but that's not an allowed name. Unfortunately -z is
allowed as an operator name either. So for now it's backwards for
convenience.
I'd suggest to call it 'delay' since I find it much more
Hudak, Paul schrieb:
In the meantime I am more and more moving to Arrows or Arrow like
structures. On the one hand it is often the more appropriate data
structure since it models exactly the causality of signal processes and
has much less risk for memory leaks (compared to lazy lists). On the
(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
Hi Henning, thanks.
For me, I can live without real-time. Real-time would be nice of
course but the simplicity of Jerzy's Clarion (non-real-time, solely a
renderer) is compelling: eliding counting the lines of code for the
stream type and the WAV file I/O, Clarion can produce audio in 2-3
lines
On Sun, 2 Jan 2011, Stephen Tetley wrote:
Un-optimized, with a head-strict stream (basically Wouter Swierstra's
Stream with a bang on the element), rendering currently takes minutes
to generate seconds. But as well as the Stream representation, I've
plenty of room to optimize the WAV file
