On Wed, 12 Dec 2007, John Lato wrote:

> One of the things I'd like to see is a conventional way to represent
> audio data in haskell.  What I've been using so far is:
> type Sound = Double
> type SoundFrame = [Double]

I'm using this this representation, too, and I hesitate to change it,
because it is the only one which gives you full flexibility in terms of
feedback, e.g. for filter implementation. I also thought about a type
class for audio signals, but this could only support the least common
denominator. Currently I think that efficiency should be achieved by the
optimizer, in contrast to using special types everywhere. E.g., there
could be a function like

chunky :: [Double] -> [Double]
chunky = fromChunky . toChunky

which is an 'id' function upto laziness and efficiency. It could be fused
with subsequent and preceding operations on lists to efficient operations
on chunky lists. Many signal operations perform stateful computations on
the sample values in time order, and I need to implement only this scheme
and write optimizer rules for it. Then you can e.g. fuse
  toChunky . listGenerate osci   --->    chunkyGenerate osci

> and using [SoundFrame] for the output of my decoding functions.  Which
> is fine, as far as that goes.  However, it's probably not the best
> option.  A storablevector (if it were made lazy) would likely be more
> efficient, both in terms of memory usage and processing.

I like to try StorableVector soon.

>  An arrow approach (looking at YampaSynth) could be usable too, but I
> figured I'd have quite enough work to do without that. Are there any
> suggestions here?

Multiple times I tried to get something useful from Arrows for signal
processing. E.g. I process physical units and these must be checked before
the low-level signal processing takes place. Even for this task Arrows
couldn't help me so far, and the solutions without Arrows are simpler. So,
currently I live quite well without Arrows.  :-)

> That's why I took the approach of writing encoders and decoders
> instead of wrapping libsndfile.

Can libsndfile work on streamed data?

> Anyway, thanks for letting me know about your projects.  I've only
> just started using Haskell, so I'm not very familiar with the
> landscape yet.

It would be great to have more content for
 http://www.haskell.org/haskellwiki/Category:Music
_______________________________________________
haskell-art mailing list
haskell-art@lists.lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art

Reply via email to