Re: [haskell-art] purely functional circular buffers
John Lato schrieb: Does anyone know of a purely functional equivalent to a circular buffer? It depends on the application you have in mind. For programming a constant delay of n samples of a lazy list including feedback, you can use a lazy list instead of a circular buffer. For efficiency reasons you can use a chunky StorableVector with chunk size up to n. This is like rolling out the circular buffer to an infinite list. Something simple like let output :: [Double] output = mix (input + delay n output) would work. I'm looking for something that supports efficient insertion and lookup, and doesn't rely upon mutable data. I don't want to use mutable data because I'd like to embed this in CCA, which to my knowledge doesn't yet support Kleisli arrows. Embedding the above idea into an arrow that emits one output sample per input sample would not work. Mutable arrays in the ST monad would help, but this requires that the arrow is built around the ST monad. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
On Thu, Feb 17, 2011 at 6:21 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: John Lato schrieb: Does anyone know of a purely functional equivalent to a circular buffer? It depends on the application you have in mind. For programming a constant delay of n samples of a lazy list including feedback, you can use a lazy list instead of a circular buffer. For efficiency reasons you can use a chunky StorableVector with chunk size up to n. This is like rolling out the circular buffer to an infinite list. Something simple like let output :: [Double] output = mix (input + delay n output) would work. For a constant delay, one of the real-time queues would probably be better yet. A chunky StorableVector can work, but there's a lot of copying unless n is very small. If I use a Sequence for the mutating chunk and vectors for other chunks, it might work well. Sort of like a Builder. I'll try it and report back if I find anything interesting. But I'm really interested in long-ish (several seconds) delay lines with multiple varying taps. The other brillant idea I have involves reconfiguring queue lengths based upon lookups, similar to a splay tree. I may try to implement it but I would be surprised if get it right. I'm looking for something that supports efficient insertion and lookup, and doesn't rely upon mutable data. I don't want to use mutable data because I'd like to embed this in CCA, which to my knowledge doesn't yet support Kleisli arrows. Embedding the above idea into an arrow that emits one output sample per input sample would not work. Mutable arrays in the ST monad would help, but this requires that the arrow is built around the ST monad. Exactly, hence the problem using this with CCA at the moment. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
On 17 February 2011 19:48, Stephen Sinclair radars...@gmail.com wrote: [SNIP] However, there is this common pattern in media- or simulation-oriented programs (like games too): 1. Initialize state. 2. Update state based on initial state. 3. Update state based on state 2. 4. Update state based on state 3. ... or more succinctly.. t=0. Initialize state. t=t+1. Update state based on state t-1. It seems to me that if it can be proven that state t depends only on state t-n, then memory for states before t-n can be reused. If n is known at compile time, which can be true for a lot of signal processing applications, this should be feasible. If states t-n to t are treated as immutable, then it could be considered as pure from an outside perspective, something like the ST monad for instance. [Maybe off going topic, maybe not...] Martin Erwig and Paul Hudak did quite a bit of work around the topic functional update that seems not to have got the attention it might deserve. I've been curious for a while whether this work isn't still pertinent: Paul Hudak Mutable Abstract Datatypes - or - How to Have Your State and Munge It Too Yale Research Report RR-914 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.66.3875 Martin Erwig The Categorical Imperative - Or: How to Hide Your State Monads http://web.engr.oregonstate.edu/~erwig/papers/CategoricalImperative_IFL98.pdf The latter is actually in the ST monad but it still seems quite different from today's state-of-the-art of ByteString, Builders and Stream-Fusion. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
So far the best I've found is Data.Sequence.Seq, which in my tests outperforms mutable vectors, but only for reads from the head or tail of the sequence. Indexing into the middle of the sequence is relatively slow. Data.Sequence is implemented as a finger tree which is the culmination point of Ralf Hinzes talk on Number Systems and Data Structures [1]. Finger trees are versatile but also complicated. Maybe one of the simpler structures presented there (like random access lists) provides faster indexing. Sebastian [1]: http://www.cs.nott.ac.uk/~gmh/bctcs-slides/hinze.pdf ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Hopefully that will help to better explain how I produced those mp3s. One of the things I hope to do in the near future is to clean up and better document the source code for a couple of them so that they can serve as tutorials. I for one would be quite curious to see those. It's the first time I've heard real music (i.e. not just a demo or a sketch) written in haskore. As for the pieces themselves, I like them. Usually algorithmic composition leaves me cold, but these are quite fun to listen to. I like the way pitched instruments are used both rhythmically and melodically in e.g. felis. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Then I tried Modula-3 on Linux. When I later got to know Haskell, I found that I had reinvented lazy evaluation for Assampler. Consequently I moved to the original. I wanted to integrate music composition and signal processing. I wanted programming features for music arrangement, since the many trackers known from Amiga did not offer much structuring and thus required a lot of copy and paste. I wanted programming features also for signal processing, since the interactive graph editing became cumbersome for repetitive signal algorithms like vocoders, although I already added some support for them to Assampler. Coincidentally, my ambition was originally also to integrate music composition and signal processing. That is, I would like to be able write both 'echo phrase' to play phrase with a note-by-note echo and 'reverb phrase' which would play phrase but apply a sample level reverb to it. With most current systems you have to fiddle around with setting up a separate reverb, setting up its control inputs, manually hooking your score language's knobs up to the reverb's knobs, etc. And then there's 'retrograde phrase' vs. 'reverse phrase' to apply music-level and audio-level reverse respectively... most existing systems force you to do an awkward two step process where you record the output of phrase and then re-input it as a sample, then reverse it. It's not just a pure academic interest either... it's musically useful to e.g. tune a comb filter to a musical pitch, or apply a special kind of reverb to a single note, and it's a hassle to manually set up all the plumbing to get that to happen. To my eyes the problem is in the score vs. orchestra division that starts with music-n languages like csound and goes all the way through midi sequencers. Nyquist is the only language I know of that tried to tackle that. However, I've basically given up on that for the moment in favor of just generating MIDI. Just composition is already really complicated without throwing signal processing into the mix. So I wish you best of luck on the signal side, maybe when things on both sides mature I can steal^H^H^H integrate some of that work and finally have the top-to-bottom solution I dreamed of... Coincidentally, I also got my start on the Amiga... perhaps early exposure to trackers let to my dissatisfaction with MIDI and the typical MIDI sequencer :) My current project winds up looking vaguely like a programmable tracker. liveliness. The typical memory leak works as follows: let (prefix, suffix) = splitAt largeNumber xs in processA prefix ++ processB suffix Although this can be perfectly processed in a streaming manner, sometimes GHC does not manage to release the pointer to the beginning of prefix and thus prefix is kept until the processing of suffix starts. I wonder whether Just out of curiosity, how do you find out when this is happening? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
