Re: [haskell art] Mixing sound files with haskell
On Jun 21, 2014 12:47 AM, Anton Kholomiov anton.kholom...@gmail.com wrote: Yes, you can. Csound is not only a programm (compiler) but also a C API. There are bindings for C, Java, Python. There is also a Haskell binding to the Csound API. Although I think it's a bit out of date, I'll try to update it this week. John We can generate a Csd file, and the execute it within other program. We can interact with csd over OSC-messages and with API over channels 2014-06-21 0:10 GMT+04:00 Ben Burdette bburde...@gmail.com: Cool! If I have my own interface written in haskell, in QT or openGL for instance, can I trigger events in csound from that? It looks like the csound gui stuff is csound communicating with itself, and not haskell communicating with csound. Ie, we tell csound to create a slider, and then start csound, but after that haskell has no interaction. Is that correct? I'm looking to run a program on a raspberry pi that has no keyboard or gui itself, and control the sound output from haskell, which would read network messages and play sounds in response. So the realtime input would be from another machine. I looked at csound-expression for this but I couldn't figure out if realtime interaction from haskell is possible. Maybe through OSC messages? On 06/20/2014 01:50 PM, Anton Kholomiov wrote: Yes, you can even create Gui-widgets https://github.com/anton-k/csound-expression/blob/master/tutorial/QuickStart.markdown#gui-elements I have to admit that keyboard interaction is not so thoroughly tested. It can be buggy.. You can make an issue in github) Any help is welcome 2014-06-20 23:34 GMT+04:00 Ben Burdette bburde...@gmail.com: Nice! That looks easy to use. Is it possible to kick off sample playback from haskell in real time, in response to keyboard events for instance? On 06/20/2014 01:17 PM, Anton Kholomiov wrote: I wanted to mix a drum-loop with the tanpura sound to play along with bansuri flute. I've got a short drum-loop and looong file of the tanpura drone and haskell. So I've done it with my library csound-expression and moved the usefull functionality in the library. Now it's much easier to play sound files. And.. I'd like to announce the new version of the library 'csound-expression' [1] With new functions it's very easy to read and playback sound files. recently I wanted to make a simple mix of drum loop with harmony. With new functions it's as simple as ~~~ module Main where import Csound.Base -- ten minutes totalDur = 10 * 60 main = dac $ takeSnd totalDur $ tabla + mul 0.5 tanpura where tabla= loopSnd tanpura - f - sp.mp3 tanpura = loopSndBy 8 Teentaal.wav ~~~ ~~~ -- to read file in loop loopSnd :: String - (Sig, Sig) -- to read file in loop with given period loopSndBy :: D - String - (Sig, Sig) -- to take only given amount of seconds from file takeSnd :: Sigs a = Double - a - a -- to scale signals with the given signal mul :: SigSpace a = Sig - a - a ~~~ D is a Double inside dsl, Sigs is a type class for tpules of signals. There are functions to read wav-files with the given speed. Here is how we can listen to the file in reverse in the terminal: ~~~ ghci :m +Csound.Base readWav (-1) fuzzy-buzzy-sound.wav ~~~ The functions `readWav` and `loopWav` take a speed of playback as first argument (and it's signal. We can change it over time) ~~~ readWav :: Sig - String - (Sig, Sig) loopWav :: Sig - String - (Sig, Sig) ~~~ You can look at all new functions at https://hackage.haskell.org/package/csound-expression-3.2.3/docs/Csound-Air.html#g:13 Sorry for skipping the docs. I hope that description above helps somehow. I''m going to fix it soon. [1] https://hackage.haskell.org/package/csound-expression-3.2.3 Cheers Anton -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/1LjVC2esBoyvTI5wy6etKT To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/7BRSvu88fS55f1gDWxCc0x To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/4c5MI0ikR08Yxg2oPjXDZg To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/13lg0yE0z0Hq3IVZZOKCEW To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] Mixing sound files with haskell
When csound6 first came out, the API hadn't changed at all. However I think there have been some additions since then, which I haven't added. I would be surprised if anything was deprecated from the API, although of course it's possible. On Sat, Jun 21, 2014 at 11:03 AM, Anton Kholomiov anton.kholom...@gmail.com wrote: Be aware that Csound has made a big step forward in the version 6. And it's different from pre 6 version. I don't know what hCsound uses. Csound 6 brings to the table the parallel execution and execution on the fly. It's possible to create instruments during the execution of the main file. We can load new instruments and invoke them live. Good news that Csound should work on Rasp Pi. It's lighweight enough (see [1]). [1] http://www.csounds.com/journal/issue18/beagle_pi.html Cheers, Anton 2014-06-21 20:51 GMT+04:00 Ben Burdette bburde...@gmail.com: Ok good to know! The csound api is a separate thing from csound-expression then. I thought they were two implementations of the same interface, that clears things up for me. I got hCsound to compile (on debian), I just had to add the line: include-dirs:/usr/include/csound to hCsound.cabal. Haven't tested it beyond that though. On 06/21/2014 10:12 AM, John Lato wrote: On Jun 21, 2014 12:47 AM, Anton Kholomiovanton.kholom...@gmail.com wrote: Yes, you can. Csound is not only a programm (compiler) but also a C API. There are bindings for C, Java, Python. There is also a Haskell binding to the Csound API. Although I think it's a bit out of date, I'll try to update it this week. John We can generate a Csd file, and the execute it within other program. We can interact with csd over OSC-messages and with API over channels 2014-06-21 0:10 GMT+04:00 Ben Burdettebburde...@gmail.com: Cool! If I have my own interface written in haskell, in QT or openGL for instance, can I trigger events in csound from that? It looks like the csound gui stuff is csound communicating with itself, and not haskell communicating with csound. Ie, we tell csound to create a slider, and then start csound, but after that haskell has no interaction. Is that correct? I'm looking to run a program on a raspberry pi that has no keyboard or gui itself, and control the sound output from haskell, which would read network messages and play sounds in response. So the realtime input would be from another machine. I looked at csound-expression for this but I couldn't figure out if realtime interaction from haskell is possible. Maybe through OSC messages? On 06/20/2014 01:50 PM, Anton Kholomiov wrote: Yes, you can even create Gui-widgets https://github.com/anton-k/csound-expression/blob/master/tutorial/QuickStart.markdown#gui-elements I have to admit that keyboard interaction is not so thoroughly tested. It can be buggy.. You can make an issue in github) Any help is welcome 2014-06-20 23:34 GMT+04:00 Ben Burdettebburde...@gmail.com: Nice! That looks easy to use. Is it possible to kick off sample playback from haskell in real time, in response to keyboard events for instance? On 06/20/2014 01:17 PM, Anton Kholomiov wrote: I wanted to mix a drum-loop with the tanpura sound to play along with bansuri flute. I've got a short drum-loop and looong file of the tanpura drone and haskell. So I've done it with my library csound-expression and moved the usefull functionality in the library. Now it's much easier to play sound files. And.. I'd like to announce the new version of the library 'csound-expression' [1] With new functions it's very easy to read and playback sound files. recently I wanted to make a simple mix of drum loop with harmony. With new functions it's as simple as ~~~ module Main where import Csound.Base -- ten minutes totalDur = 10 * 60 main = dac $ takeSnd totalDur $ tabla + mul 0.5 tanpura where tabla= loopSnd tanpura - f - sp.mp3 tanpura = loopSndBy 8 Teentaal.wav ~~~ ~~~ -- to read file in loop loopSnd :: String - (Sig, Sig) -- to read file in loop with given period loopSndBy :: D - String - (Sig, Sig) -- to take only given amount of seconds from file takeSnd :: Sigs a = Double - a - a -- to scale signals with the given signal mul :: SigSpace a = Sig - a - a ~~~ D is a Double inside dsl, Sigs is a type class for tpules of signals. There are functions to read wav-files with the given speed. Here is how we can listen to the file in reverse in the terminal: ~~~ ghci :m +Csound.Base readWav (-1) fuzzy-buzzy-sound.wav ~~~ The functions `readWav` and `loopWav` take a speed of playback as first argument (and it's signal. We can change it over time) ~~~ readWav :: Sig - String
Re: [haskell-art] code golf: diatonic transposition
This is what I would suggest also. Sometimes called a movable-do system, because do (C) is always the root, but the actual pitch it refers to varies with the key. Although, if you are interested in going outside church modes, you'll need more flexibility. If the modes are all symmetric, as is true for Western tonality under equal temperament, and some exotic systems like Harry Partch's, then simply use numbered scale degrees with an adjustment parameter. If the modes aren't symmetric, such as with just intonation (e.g. B Major has different pitch ratios than C Major; I think this is true for carnatic music also), then the concept of a diatonic transposition may not even apply. John L. On Thu, Jan 26, 2012 at 6:55 AM, Anton Kholomiov anton.kholom...@gmail.com wrote: I was doing it with additional parameter which stands for root note of the scale. You can treat A, B, C notes not as absolute things but relatives to the root. Then to transpose in scale you can shift the root note by given number. Anton ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] request for review - circular buffer performance
Hello all, In a nutshell, after some discussion and review, I concluded that there are only two circular buffer implementations worth considering in Haskell (3 if you only need access to the end of the buffer) - a mutable implementation and a Data.Sequence-based one. Somewhat to my surprise, my tests show that the Data.Sequence implementation both performs better overall and scales better. I'm not certain that I trust my methodology or implementation, and I would greatly appreciate if anyone would be willing to review my work or provide comments. Details can be found at http://johnlato.blogspot.com/2011/07/circular-buffers.html Thanks very much in advance. John L. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Wed, Feb 23, 2011 at 8:50 AM, Stephen Tetley stephen.tet...@gmail.comwrote:
On 22 February 2011 23:41, Evan Laforge qdun...@gmail.com wrote:
I'm not super knowledgable about supercollider, but isn't it basically
a synthesizer which you configure by sending OSC over, and can then
play it by sending more OSC?
SuperCollider classically was a real-time tuned Smalltalk-like
language for sound synthesis. The language allows you to do pretty
much any symbolic processing you would expect - of course some things
will be easy whereas others will be hard.
Here's the score to play a scale from Stephen Travis Pope's book
'Sound and Music Processing in SuperCollider':
defaudioout L, R; -- Declareoutputs.
deftabletabl1, env1; -- Declare2wavetables--onefor theenvelope.
start { -- Playascoreinthestart function
-- time instrument dur pitch amp
[0.00, ‘chorus_instr, 0.25, 48, 0.5].sched;
[0.25, ‘chorus_instr, 0.25, 50, 0.5].sched;
[0.50, ‘chorus_instr, 0.25, 52, 0.5].sched;
[0.75, ‘chorus_instr, 0.25, 53, 0.5].sched;
[1.00, ‘chorus_instr, 0.25, 55, 0.5].sched;
}
Score and orchestra are the same language - I'm guessing start is the
equivalent of main. SC has a GUI toolkit so you can make elements
controllable in real-time via sliders and the like.
From my (admittedly limited) experience with SC, they're the same language
only insofar as you can intermix lines with score and orchestra control,
however the orc/sco division seems alive and well. The above code uses the
score metaphor. The instrument 'chorus_instr' is created with the orc
metaphor (likely a synthdef). The supercollider server understands both,
either creating (or modifying) signal processes, or turning them off and on,
as instructed, but there are two layers of control.
It's certainly useful to be able to mix the two in the same document, but I
think there's a useful gulf between signal processing and note scheduling.
John
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
On Sat, Feb 19, 2011 at 9:14 AM, Sebastian Fischer fisc...@nii.ac.jpwrote: On Sat, Feb 19, 2011 at 2:05 AM, John Lato jwl...@gmail.com wrote: On Fri, Feb 18, 2011 at 1:14 AM, Sebastian Fischer fisc...@nii.ac.jpwrote: Maybe one of the simpler structures presented there (like random access lists) provides faster indexing. I believe the difficulty with random access lists is in dropping references to old data. I don't see how to do so efficiently. Instead of shifting all elements through the buffer you could store an index to the oldest element and increase it (modulo size) when overwriting. Then the only operations you need internally are reading and writing at arbitrary positions, for which IntMap also seems like a good candidate. You could also try the new hash maps: http://blog.johantibell.com/2011/02/new-faster-containers-library.htmlalthough I don't see a reason why they should be faster than IntMaps. This was the first thing I tried, with vectors. It seems that writing to arbitrary positions is not necessarily fast though. With vectors the entire vector needs to be copied. With IntMaps, writing is O(min(n,W)), and ends up being significantly slower than cons'ing onto a finger tree. Lookups are also much slower, somewhat to my surprise. I think random access lists would also require a lot of data copying with this approach. I've been following Johan's announcements as well, but at least for now they aren't quite as performant as IntMaps (according to his tests). One thing which might be better is a set of cascaded real-time queues, for which several implementations exist. The implementation gets a little complicated though, and I expect it would be equivalent (or worse than) using a finger tree directly. John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
On Fri, Feb 18, 2011 at 1:14 AM, Sebastian Fischer fisc...@nii.ac.jpwrote: 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 Thanks very much for this useful link. It's given me some items to think about. I believe the difficulty with random access lists is in dropping references to old data. I don't see how to do so efficiently. Since finger trees support efficient access to both ends, they work well in this regard. It's only accessing data in the middle which is a problem. I also haven't tried an IntMap yet, which may be better still. Thanks, John ___ 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] Haskell art?
On Fri, Feb 4, 2011 at 2:14 AM, Evan Laforge qdun...@gmail.com wrote: On Thu, Feb 3, 2011 at 5:27 PM, John Lato jwl...@gmail.com wrote: On Thu, Feb 3, 2011 at 10:26 PM, Evan Laforge qdun...@gmail.com wrote: I should have mentioned Pianoteq back there as an exception to no interesting physical models since the '90s thing. But it's pretty specialized, and since it's proprietary who knows what they're doing in there anyway. I always assumed it was a very well-tuned waveguide model. But I haven't actually used it myself. Yeah, they have some other stuff going on too, with sympathetic resonance. It might be a separate technique because when they changed algorithms, pitch bend affects the string but not the resonance, which sounds quite strange. I believe they have mentioned that they have more accurate models but don't use them for fear of no longer being realtime. That's pretty funny; I should check it out. It seems like it should be possible to get speedups with parallelism as well. Not as easily as you might expect, unfortunately. More precisely, the most interesting systems are those in which options for parallelism are most limited due to non-linear effects. Well, how about multiple strings, coupled through a soundpost and the air? Would it be naive to run each string on its own processor? I suppose if it gets the sympathy through a sample stream then you've got at least a one sample delay which might be enough to mess things up... With FD methods, couplings are at present the primary parallelization difficulty. It's easy to run each string on its own processor if there are no couplings between them. If there are couplings, that serves as a synchronization point within the computation at each sample, and at present there's too much communication to make it worthwhile. What's worse is that the coupling calculations need to be very precise or the whole model will almost certainly degenerate. John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Hello, I'm John Lato, a musician/technologist currently based outside of Dublin. I'm the author of a few audio-related Haskell packages: hCsound: http://hackage.haskell.org/package/hCsound sndfile-enumerators: http://hackage.haskell.org/package/sndfile-enumerators although I'm probably better-known for my non-audio work on the iteratee package. I'm at last in a state where I can start using Haskell for real work, although most of it isn't ready for release yet. Recently I've been concentrating on physical modeling, an audio EDSL[0], and a csound-ish front-end based on that EDSL. [0] http://tanimoto.us/~jwlato/haskell/xdsp/ ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Thu, Feb 3, 2011 at 8:05 PM, Evan Laforge qdun...@gmail.com wrote: I'm at last in a state where I can start using Haskell for real work, although most of it isn't ready for release yet. Recently I've been concentrating on physical modeling, an audio EDSL[0], and a csound-ish front-end based on that EDSL. Can you give any more details on the physical modeling part? I'm interested because I have a VL1, and in the 20 (?) years since its release I still haven't heard anything that sounds better, just a smattering of almost-as-good. CMJ occasionally has an article that sounds interesting, but they never seem to come with usable code. Is the state of the art still '90s waveguides? Waveguides are popular primarily because they're cheap to calculate. Their fidelity is not great for certain classes of instruments though. My code is an implementation of a finite difference method, as described in Stefan Bilbao's book Numerical Sound Synthesis (among other sources). The finite difference method produces excellent results, but is extremely computation intensive. I've only recently managed to get to the point where interesting models can run in real time. Currently I have models of striking bars and plates. Stefan's got some audio samples on his pages (along with some more interesting models, and some Matlab code too) so you can check the quality yourself[0], but unfortunately I'm not able to release my work at this time. An EDSL to assemble physical models would be interesting. There's tassman, but it's not a textual language (one of those boxes and lines things), has only middling models, is real time (so it can only use cheap models), and of course is proprietary and seemingly abandoned (no development in many many years). Even with all that, as far as I know there's nothing else out there like it. Sorry if I gave the wrong impression, but my EDSL and my physical modeling work are entirely separate at this time. I do have both text-based and programmatic interfaces to the phys. modeling stuff though, so it is be possible to generate systems and scores. I guess the text interface could be considered a DSL. John [0] http://www2.ph.ed.ac.uk/~sbilbao/nsstop.html ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Thu, Feb 3, 2011 at 6:46 PM, Anton Kholomiov anton.kholom...@gmail.comwrote: sorry i've started new thread, it goes here Hi I'm making dsl's for music/sound composition. Hope some day i will stop making dsls and do some music with them. But haskell makes it difficult. With haskell It's too interesting to write dsl than things that dsl's suppose to describe. I have this problem too. Recently I've been most interested in designing a new general-purpose programming language, but I have a lot of background to study before I could actually make any progress. John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Thu, Feb 3, 2011 at 10:26 PM, Evan Laforge qdun...@gmail.com wrote: I should have mentioned Pianoteq back there as an exception to no interesting physical models since the '90s thing. But it's pretty specialized, and since it's proprietary who knows what they're doing in there anyway. I always assumed it was a very well-tuned waveguide model. But I haven't actually used it myself. Waveguides are popular primarily because they're cheap to calculate. Their fidelity is not great for certain classes of instruments though. My code is an implementation of a finite difference method, as described in Stefan Bilbao's book Numerical Sound Synthesis (among other sources). The finite difference method produces excellent results, but is extremely computation intensive. I've only recently managed to get to the point where interesting models can run in real time. Currently I have models of striking bars and plates. Stefan's got some audio samples on his pages (along with some more interesting models, and some Matlab code too) so you can check the quality yourself[0], but unfortunately I'm not able to release my work at this time. Yes, I read his CMJ article with great interest, even though I don't understand the math. In my case, a non-realtime model is not such a problem because I already have to incrementally recompute a changed score, so incrementally recomputing the sound would just be one more step in that direction. Though I suppose this could still get annoying if the computation time to real time ratio is too high. In that case (say a minute to render a second) then perhaps the technique lends itself to a cheaper approximation? Even if not, it's always possible to automatically generate a sample set and use that as the mockup. My results are better than that. The most complex systems I've run so far are about 3:1 with my code, although Matlab is slower than that by orders of magnitude. Simpler stuff is generally closer to 1:2. It seems like it should be possible to get speedups with parallelism as well. Not as easily as you might expect, unfortunately. More precisely, the most interesting systems are those in which options for parallelism are most limited due to non-linear effects. I've seen lots of percussion and woodwind models, but bowed strings are conspicuously absent. Is there something particularly hard about it? Yes and no. Bowed strings are easily modeled with waveguides driven by sawtooth waves. In fact, many plucked string models will work pretty well if you just change the driver from an impulse to a sawtooth. I think that's why bowed strings are mostly absent, intellectually they aren't as interesting as other problems. Of course generating a true-to-life sound requires a significant investment of time tweaking your model (and driving signal) precisely. Sorry if I gave the wrong impression, but my EDSL and my physical modeling work are entirely separate at this time. I do have both text-based and programmatic interfaces to the phys. modeling stuff though, so it is be possible to generate systems and scores. I guess the text interface could be considered a DSL. It seems to me that an input of a set of signals for parameters like resonator length, mallet impulse, breath pressure, whatever, and a signal for output is already a sufficient interface. I suppose if you want to go lower level and hook the output of one model to the input of another then you get into DSL territory. I guess these audio DSLs all tend to boil down to piping sample streams around anyway---the main difference is the set of included primitives. Anyway, if you ever are able to release your work, then I'd be very interested in giving it a try. I noticed that most audio examples don't actually hook them up to a real score so you can hear a musical usage rather than a demonstration, but this is something I'll (eventually) be in a pretty good position to do. I have some hope that I'll be able to release it relatively soon. John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
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 that the transformations must be done in a pre-compilation stage in order to present the normal form to GHC for the optimizer to produce the best results. In effect, this is similar to Henning's work with LLVM in that both involve metaprogramming. Currently, I've put together a small language that allows for constructions like the following: fir1 = 0.5*x + 0.5*x `z` 1 iir1 = 0.8*x + 0.2 * y `z` 1 fir2 = fir1 . fir1 filt1 = (0.1*iir1 + 0.9*fir2) + y `z` var 0 The compileArr function generates arrow code that is suitable for the ccap preprocessor, then ccap's output is compiled. The resulting core is optimal so far as I can tell. Best of all, since the result is just a function, you can use it with nearly any sort of stream representation (lazy bytestring-alikes, lists, iteratees). I have a plan to make long delays efficient, but I haven't had a chance to implement it yet as I've been working on another project. Hopefully it'll work out. 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. Finally, in a blog post a while back sigfpe mentioned using comonads for lazy audio. I spent about 20 minutes on this and although the semantics are nice, I couldn't figure out a way to get good performance for recursive functions (iir filters etc.). Has anyone else tried this? John On Tue, Jan 4, 2011 at 3:45 AM, Hudak, Paul paul.hu...@yale.edu wrote: (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 lemm...@henning-thielemann.de 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
[haskell-art] Linux Audio Conference (Call for participation)
Hello, Probably many of you are aware of this, but I'd like to get some Haskell representation at this year's LAC! Any Open Source music software would be welcome, even if it's not Linux-based. The submission date is approaching, so please submit if you haven't already. John [cross-posted from LAA/LAD] [Please distribute] Paper-submission, call-for-music and registration are now open for the Linux Audio Conference 2011 - May 6-8 2011, Maynooth, Ireland More information: http://lac.linuxaudio.org/2011/ As in previous years, we will have a full program of talks, workshops and music. The Linux Audio Conference 2011 will include several concerts. We are looking for music that has been produced or composed entirely or mostly using GNU/Linux or other Open Source music software for: * The Electroacoustic Music Concerts * The Linux Sound Night * Sound installations ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
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 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 that the transformations must be done in a pre-compilation stage in order to present the normal form to GHC for the optimizer to produce the best results. I'm also working on this at the moment, and I believe the reason for the not-so-good performance is the large amount of variable juggling introduced by the CCA transformations (which I guess GHC will largely optimize out when compiling via Template Haskell). Unfortunately I don't see how to really solve this without just-in-time compiling; even if you optimize the juggling, you still have to synthetise the necessary juggling functions runtime. Balazs That was my conclusion too, which is why I gave up on this approach. I would really like to see something like MetaOCaml for Haskell, which would I think be ideal for this application. John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] hsndfile
Hello,
I recently upgraded to hsndfile-0.4.0, and I have a few questions about its
operation. My test program is pretty much this:
test = do
(info, chunks) - Sound.File.Sndfile.readFile file
print info
putStrLn Max is:
print $ foldl' myMax 0 chunks
myMax :: Double - Sound.File.Sndfile.Buffer.Vector.Buffer Double - Double
myMax a = max a . V.maximum . V.map abs . fromBuffer
Initially I tried using readFileChunks, but I never got any data from it.
The info would print out, but the calculation of the maximum value would be
0 because chunks would be an empty list. I tried using several different
numbers for the first argument to readFileChunks, such as 1, 2, 8, and 1024
(is it the number of frames to read?), but always received an empty list.
Could any point me to what I'm doing wrong? This is with ghc-6.12.1.
After I couldn't get readFileChunks to work, I tried to use plain readFile.
This produced output, but not quite what I was expecting. Note that now
chunks should be a (Maybe Buffer), however I'm using foldl' from
Data.Foldable so it works with a Maybe.
Now it works and reports the proper answer, but when I run the program with
+RTS -s it shows low memory usage. Very low.
40,488 bytes allocated in the heap
1,484 bytes copied during GC
6,124 bytes maximum residency (1 sample(s))
14,356 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
However, the system monitor shows that the program is occupying about 230MB
of RAM. For my test file the this program reports:
Info {frames = 17479453, samplerate = 44100, channels = 2, format = Format
{headerFormat = HeaderFormatWav, sampleFormat = SampleFormatPcm16,
endianFormat = EndianFile}, sections = 1, seekable = True}
so 230MB seems consistent with allocating a single vector of Doubles.
So my second question is, why is this memory usage not reported by +RTS -s,
or -hT?
Thanks very much for any help.
Cheers,
John
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] hsndfile
Hi Stefan,
Thanks for the quick reply.
On Wed, Sep 22, 2010 at 10:59 AM, Stefan Kersten s...@k-hornz.de wrote:
hi john,
On 22.09.10 11:37, John Lato wrote:
Initially I tried using readFileChunks, but I never got any data from it.
The
info would print out, but the calculation of the maximum value would be 0
because chunks would be an empty list. I tried using several different
numbers for the first argument to readFileChunks, such as 1, 2, 8, and
1024 (is
it the number of frames to read?), but always received an empty list.
Could any
point me to what I'm doing wrong? This is with ghc-6.12.1.
you're not doing anything wrong; i think the reason is that the way
readChunks
is implemented the file handle is closed prematurely. this function needs
to be
removed from the interface.
Ok, then I'll try the handle version.
Now it works and reports the proper answer, but when I run the program
with +RTS
-s it shows low memory usage. Very low.
40,488 bytes allocated in the heap
1,484 bytes copied during GC
6,124 bytes maximum residency (1 sample(s))
14,356 bytes maximum slop
1 MB total memory in use (0 MB lost due to fragmentation)
However, the system monitor shows that the program is occupying about
230MB of
RAM. For my test file the this program reports:
Info {frames = 17479453, samplerate = 44100, channels = 2, format =
Format
{headerFormat = HeaderFormatWav, sampleFormat = SampleFormatPcm16,
endianFormat
= EndianFile}, sections = 1, seekable = True}
so 230MB seems consistent with allocating a single vector of Doubles.
So my second question is, why is this memory usage not reported by +RTS
-s, or -hT?
i'm not sure either, maybe because the memory is allocated on the heap by
malloc? this might indicate a memory leak, i'll investigate. i'm currently
on
the road and won't have the time to look into the problem before sunday ...
I'll try asking on haskell-cafe, maybe somebody there will know.It's not at
all urgent, so whenever you get a chance to look at it is fine by me. I
doubt it's a memory leak in any case.
Thanks,
John
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] LLVM = Lively Lovely Virtuosic Music
Thanks for sharing; very nice indeed. On Mon, Aug 16, 2010 at 10:25 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: I asked a friend to perform a song on my Haskell-LLVM-Softsynth. It's more lovely than an extensive technical demonstration. http://www.youtube.com/user/amigalemming#p/a/u/0/GNiAqBTVa6U ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] methods for dealing with garbage collection
On Mon, May 24, 2010 at 9:56 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Mon, 24 May 2010, John Lato wrote: On Sun, May 23, 2010 at 5:47 PM, Henning Thielemann With the LLVM based signal processing EDSL that I developed recently (http://arxiv.org/abs/1004.4796) you could in principle generate fast signal processing code from GHCi. However sadly, in LLVM-2.6 GHCi aborts with a failed LLVM assertion, whereas LLVM-2.5 could be pursuaded to work with GHCi with a bit of effort. Thanks for sharing that paper; I look forward to reading it! I've done some experimenting with LLVM code generation recently, unfortunately it didn't work out quite how I would have liked (mostly due to OS/llvm version problems on which progress has been made). I've just begin experimenting with a CCA-based system instead, and it would be interesting to compare the two once my work is a little further along. In particular, I think the CCA code with ghc's LLVM backend could be competitive. Actually I use causal arrows for the LLVM code generation (additional to the causal arrow code in http://code.haskell.org/synthesizer/core/src-4/Synthesizer/Causal/Process.hs). However it will certainly need some more time until GHC supports CPU vector types, and even more time to support CPU specific vector operations. Both of these features are already available in LLVM. For instance I have written some ix86 specific optimizations: http://code.haskell.org/~thielema/llvm-extra/src/LLVM/Extra/Vector.hs http://code.haskell.org/~thielema/llvm-2.6/ I've just finished the paper, and I had thought that LLVM only supported vector operations on Apple/OS X. It seems that this is no longer true, which is great progress. I did note that you use causal arrows, however (at least from reading the paper) it seems that you aren't yet making use of the most significant contribution of the CCA framework, namely the algorithm to reduce any causal commutative arrow to a normal form of one function and an initial state. Maybe in your case the LLVM optimizer is able to perform similar transforms, but it would be interesting to see if their procedure would affect your code generation framework. It may be a bit of work to implement, unfortunately. The CCA algorithm is polymorphic over arrow types, but since your arrows are LLVM black boxes instead of functions I think you'd need to create proxies to represent your basic generators and processes. The CCA work is still in progress so there are some ongoing changes. Also I just noticed that their ArrowInit class specifies ArrowLoop as a superclass, when IMHO it should be the other way arround. I suspect they did this for interoperability with the existing ArrowLoop, similar to the Functor/Monad mess. Best, John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] methods for dealing with garbage collection
On Sun, May 23, 2010 at 5:47 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 23 May 2010, Sönke Hahn wrote: On Friday, May 21, 2010 11:45:18 am John Lato wrote: You could try compiling the time-critical stuff with ghc -O2, then just load the object files with ghci. That might give better results. IIRC, you can configure ghci not to run the code interpreted but to compile it first. This is certainly equivalent to the -fobject-code option and means that modules are compiled (and optimized) when loaded. I thought that might be the case, but I didn't know if ghci would perform all the optimizations that ghc would. As far as I know, expressions you type into GHCi are not compiled (and thus not optimized). Then expressions like mix signalA signalB can be fast, if 'mix' is monomorphic (I'm afraid a 'SPECIALISE mix' is not enough), but slightly more complicated examples like oscillator wave freq where 'wave' is a function, are slow, since the 'oscillator' and 'wave' must be inlined for efficient execution. With the LLVM based signal processing EDSL that I developed recently (http://arxiv.org/abs/1004.4796) you could in principle generate fast signal processing code from GHCi. However sadly, in LLVM-2.6 GHCi aborts with a failed LLVM assertion, whereas LLVM-2.5 could be pursuaded to work with GHCi with a bit of effort. Thanks for sharing that paper; I look forward to reading it! I've done some experimenting with LLVM code generation recently, unfortunately it didn't work out quite how I would have liked (mostly due to OS/llvm version problems on which progress has been made). I've just begin experimenting with a CCA-based system instead, and it would be interesting to compare the two once my work is a little further along. In particular, I think the CCA code with ghc's LLVM backend could be competitive. Best, John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Most simple way to make some noise
On Wed, Nov 18, 2009 at 9:20 PM, Balazs Komuves bkomu...@gmail.com wrote: Hi, as a beginner I have a beginner's question: Which is the most simple way to make my haskell programm play a sound? It really depends what kind of sound you want to make. Play a beep, or a .wav file, or a waveform generated by your program, or just play a piano-like sound, etc...? Completely true, a little more context would be helpful here. Another crossplatform solution is PortAudio; I have no experience with it. http://hackage.haskell.org/package/portaudio I have used PortAudio on Mac and it works well. Should work on Linux too, and most likely works on Windows. It may be lower-level than what you're looking for. If you want just to play back a .WAV sample on Windows, there is the PlaySound function in the Win32 API, which makes this trivial; it is very easy to call this using the Haskell FFI. http://msdn.microsoft.com/en-us/library/dd743680(VS.85).aspx There is the Sox library http://hackage.haskell.org/package/sox. Sox is good on linux, but I don't know that I would consider it cross-platform. (I was hoping that there was a WindowsLinux library with a simple command to play a note for a given time or some other simple solution for simple sound production). Unfortunately we are not there yet :) If you want to play an audio file, then I would look at sox or portaudio. If you want to do audio synthesis, then possibly Haskore-synthesizer or YampaSynth may suit, but the impression I get is that they're relatively linux-centric. If you're looking to doing more complicated audio synthesis, then either the supercollider or csound bindings may be a better choice. I know that csound is cross-platform and will handle audio output for you, although compiling hCsound on windows can be tricky. Cheers, John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] what do people use for audio output
Hello, I'm interested to know what libraries/techniques people use for audio output (through DAC/audio device) from Haskell programs. I'd like to know about people who are doing actual audio processing in Haskell (e.g. passing buffers/streams of data) rather than playing back files or controlling an external program (e.g. SuperCollider). If anyone is willing to share their techniques, I'd like to know. Thanks, John Lato ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] OT (sort of): new haskell audio blog
On Fri, Feb 13, 2009 at 4:50 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Wed, 11 Feb 2009, John Lato wrote: I'd like to announce that I've begun a blog for my explorations of audio programming in haskell. The first posts deal with developing a high-performance, iteratee-based, WAVE reader. Please do look if you're interested. http://johnlato.blogspot.com/ Why converting from Word8s to Int16 or Double? StorableVector can store Int16 or Double directly. If you worry about binary compatibility and endianness, wrap Double or Int16 in a newtype with a Storable instance which respects the endianess in the WAVE file. But maybe I misunderstood the problems completely. I thought about that, but it isn't clear how to make it work with Iteratees. In particular, enum_fd_random can only work with one element type at a time, so doing this would require one iteratee on Word8 to read the format, then running another iteratee to read the data. This should be much easier for user code to work with, I think. John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] OT (sort of): new haskell audio blog
Hello, I'd like to announce that I've begun a blog for my explorations of audio programming in haskell. The first posts deal with developing a high-performance, iteratee-based, WAVE reader. Please do look if you're interested. http://johnlato.blogspot.com/ Sincerely, John Lato ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
On Tue, Dec 9, 2008 at 4:45 PM, stefan kersten [EMAIL PROTECTED] wrote: hi john, John Lato wrote: Using unsafeFreezeIOCArray and my stream implementation provides the fastest version yet, with an average of about 1.9s per run. This is in the hsndfile.hs test code as function test1. For the record, the stream implementation and fold I'm using are copied from Data.ByteString.Lazy. I changed the types to suit this code, but that's the source. thanks for posting the code. i'm not very convinced of lazy IO, but i'd be very interested in incorporating an iteratee based approach into hsndfile. i'm currently finalizing various api changes and extensions (mostly to do with abstracting both mutable and immutable buffers) and when i'm done i'll have a look at what you did in hsoundfile-3. obviously oleg's iteratee code is not hackaged yet, and i couldn't find it anywhere else, do you have any pointers? thanks, sk Hi Stefan, It's available at http://okmij.org/ftp/Haskell/Iteratee/ His DEFUN slides and notes, found at http://okmij.org/ftp/Streams.html#iteratee, are also helpful. I think it's pretty obvious how to apply this to hsndfile. However, I just noticed that Oleg has posted a TIFF library using an Iteratee approach. It supports seeking/random access and various other things that directly apply to the matter at hand. Looks like I'll have to do some studying again... http://okmij.org/ftp/Streams.html#random-bin-IO ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
On Fri, Dec 5, 2008 at 7:04 PM, stefan kersten [EMAIL PROTECTED] wrote: Henning Thielemann wrote: Thank you for this benchmark! I'm particularly interested in StorableVector because I hacked it quite a bit and use it for my own signal processing. I would also like to know how Fusion+Inlining improves the picture, but I do not know if there is anything to fuse at all in this simple example. Can you show us the actual test you run? I would then compare with my fusing signal data type from the synthesizer package. yes, thanks john, very interesting ... i'd also be interested in the benchmarking code ;) I'll try to post the code tonight after work. I'll also post the library versions I tested, which in all cases were the latest available on Hackage at the time I ran my tests. One thing to keep in mind is that, in general, the benchmarking code is pretty simple. I was trying to approach this from the point of view of an average user (e.g. me), who may not be familiar with all the Haskell optimization strategies. I doubt there's anything to fuse in this example, but I don't know much about fusion implementations. I have tried inlining certain functions, but either there was no change (which was my expectation), or a slight slowdown. hsndfile - a recursive I/O function reads a chunk from the file (using IOCArray type) and accumulates the maximum values from each chunk. I attempted to create a framework like used for HSoundFile-3, however performance dropped dramatically; I suspect the slowdown is mostly from the process of freezing mutable arrays to immutable arrays. for CArray i've been using unsafeFreezeIOCArray, which does an O(1) conversion (simply keeping the pointer to the mutable array). Thanks, I'll try that. For chunked data types, all data is with chunk size 1000. All timing/memory data is the median value from multiple runs. In general different runs had very similar performance. Timing results: HSoundFile-3, StorableVector - real 16.5s HSoundFile-3, UArr- real 15.7s HSoundFile-3, List - real 17.6s Is this the plain Prelude [] type? Why are List and StorableVector similar in speed? Yes, it's the plain Prelude [] type. I expect they're similar in speed because of the particular implementation of AudioBuffer in HSoundFile-3. Specifically, the AudioBuffer class has a fromList function which is used to create the buffer from a Data.Binary decode operation. The UArr API is somewhat optimized for this use case, however I believe it's relatively inefficient for StorableVector. If someone more familiar with StorableVector were to write the AudioBuffer instance, I think it would perform better. Adding specialized instances for AudioBuffer UArr and AudioBuffer StorableVector would likely produce a significant gain; about 10% for UArr and probably less for StorableVector. Changing the AudioBuffer class to avoid the intermediate List is trickier. Last time I tried, I don't believe I found a successful approach. Given my results, my next approach will be an Enumerator API that uses hsndfile to actually read from the file. I think that would have nearly all the performance of hsndfile with a functional, composable interface. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Haskell audio I/O packages
Hello, This is the sort of thing that most people would put in a blog post, but I don't have a blog so I'm sending it to this list, since I think most readers would be interested. I've recently been doing some tests of different sound file I/O packages in Haskell, and I would like to share the results. My test script involves reading a 66MB Wave file, a stereo recording at 44,100 / 16. The entire file is processed to determine the peak sample value. This is of particular instance to me because it involves scanning a large amount of data in its entirety, the file format is extremely common, and the process seems representative of the sort of operations often encountered doing audio work. I tested the following packages: Codecs hsndfile WAVE in addition, I tested two experimental interfaces to my library, HSoundFile. I did not test the current published interface, HSoundFile v. 2. The first interface I am experimenting with uses a smart handle approach, and in some ways is very similar to a Haskell implementation of libsndfile. I refer to this as HSoundFile-3. The second interface uses an enumerator streams overlaid on a Word8 enumerator, derived from Oleg's Iteratee package. I refer to this as Enumerator. All packages are haskell only, except hsndfile, which is a binding to the C libsndfile library. Test harnesses: HSoundFile-3 - a stream type is created to hold AudioBuffers. A recursive reader function uses unsafeInterleaveIO to read the entire file on demand. A strict foldl processes the Stream chunks to achieve the final value. Enumerator - An Iteratee is processes all values as received Codecs - the data list is processed by a strict foldl WAVE - the data list is processed by a strict foldl hsndfile - a recursive I/O function reads a chunk from the file (using IOCArray type) and accumulates the maximum values from each chunk. I attempted to create a framework like used for HSoundFile-3, however performance dropped dramatically; I suspect the slowdown is mostly from the process of freezing mutable arrays to immutable arrays. API type: HSoundFile-3 - strict reads/writes of buffers Enumerator - enumerator-based strict I/O Codecs - read/write entire file into data structure WAVE - lazily read file into list hsndfile - strict reads/writes of buffers Data Types: HSoundFile-3 - custom AudioBuffer class. Implementations are provided for UArr Double, List Double, and StorableVector Double Enumerator - enumerates Doubles Codecs - array of Doubles WAVE - [[Int32]] hsndfile - custom Buffer class with Array constraint. Implementations are provided for IOCArray and StorableVector. For chunked data types, all data is with chunk size 1000. All timing/memory data is the median value from multiple runs. In general different runs had very similar performance. Timing results: HSoundFile-3, StorableVector - real 16.5s HSoundFile-3, UArr- real 15.7s HSoundFile-3, List - real 17.6s Codecs - real 1m20s Enumerator - real 19s WAVE- real 29.1s hsndfile - real 2.0s Memory results (running test program with -hT) HSoundFile-3, StorableVector - 457,674,398 bytes x seconds HSoundFile-3, UArr - 531,452,404 bytes x seconds HSoundFile-3, List - 532,806,405 bytes x seconds Codecs - 5,869,214,258 bytes x seconds Enumerator - 957,845 bytes x seconds WAVE - 986,310,412 bytes x seconds hsndfile - 23,160 bytes x seconds A few notes: I did make an HSoundFile-3 implementation that used only UArrs, not the AudioBuffer class. This implementation was about 2 seconds faster for this test than the shown implementation, however I didn't think the extra efficiency was worth the more restrictive API. Anyway, that's what I've found so far. I was very hopeful that at least one of the pure haskell packages would be similar to hsndfile, but unfortunately I haven't found anything at this time. It's certainly beyond my ability. Cheers, John ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
