Re: Haskell and sound (was: [Haskell-cafe] Toy application advice wanted)
For what it's worth, SOE and Haskore provide support for reading and writing MIDI files, and for generating both score and orchestra files in csound. But there is no direct support for sound files, nor is there support for real-time MIDI. -Paul Claus Reinke wrote: (SOE's music component includes Midi file support, and also talks about csound)? ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
On May 6, 2004, at 6:59 PM, S. Alexander Jacobson wrote: I think someone wrote a book about multi-media apps in Haskell (I've seen a chapter somewhere from Conal Elliot) but I don't remember what it was. Probably Paul Hudak's The Haskell School of Expression. http://www.haskell.org/soe/ I had forgotten about this; maybe the soundwave GUI app idea is not so unrealistic? I haven't read SOE, but my impression is that it comes with a simple graphics library, and an on-topic book might get a novice up to speed quickly. Regards, Frank ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
Sound on linux tends to center around the jack sound architecture. This is a demon for connecting audio and midi gadgets as it were by jack-leads. From a brief look, it seems very callback oriented. It seems to be highly thought of by knowledgable audio types, and the bee's knees for low latency. It could be fun to figure out ways of writing jack-clients and plugins in Haskell. Would it be difficult, or stupid? Are callbacks to Haskell from C a problem? I suppose an interesting jackable component written in Haskell would of necessity something more midi than audio oriented. Peter Hancock ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
It could be fun to figure out ways of writing jack-clients and plugins in Haskell. Would it be difficult, or stupid? Are callbacks to Haskell from C a problem? Callbacks to Haskell are very easy using the ffi extension supported by Hugs, GHC and NHC. If components are standalone apps, that's all you need to do. If components are more like libraries, you'll need to take care of initializing the Haskell runtime, etc. (The ffi has calls to do this though I think only GHC implements them.) I suppose an interesting jackable component written in Haskell would of necessity something more midi than audio oriented. Because of raw performance or GC delays? 1) Performance If you take just a little care, GHC can generate some pretty fast code and generating 88 thousand samples per second (i.e., CD-rate stereo) isn't really that much on your typical PC hardware. Or, if you want to be able to use Hugs or GHC just isn't fast enough, you could write the inner loop in C and use Haskell to control how it is invoked. (I'm assuming that most audio ops can be expressed in terms of a few generic convolution operators.) We had good luck with this sort of approach at Yale when doing real-time visual tracking. (The important things to know about visual tracking are that you process megabytes of data per second and the more frames per second you can process the more reliable the tracking.) The 'inner loop' was written in C or hand-bummed assembly code and the rest was written in Haskell. Performance was something like 99.9% of equivalent C code. 2) GC delays. GC systems are usually tuned to minimise overhead but can usually be persuaded to minimise the average or worst delay by specifying different sizes of different allocation arenas and explicitly invoking the garbage collector. Again, this is something we did at Yale with the visual tracking. You'd probably do very well with a simple policy like invoking the GC N-times per second of sound processed. -- Alastair Reid ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Haskell and sound (was: [Haskell-cafe] Toy application advice wanted)
Sound on linux tends to center around the jack sound architecture. This is a demon for connecting audio and midi gadgets the problem with os-specific solutions is that they, and code based on them, don't work on other platforms - reduces the target audience and the potential gain for anyone wanting to invest time. for graphics, we've got OpenGL, and a nice Haskell binding to it, so I wonder whether there's a similar option for sound? e.g., does anyone have experience with PortAudio/PortMusic/PortMidi? PortAudio - portable cross-platform Audio API (platforms including Windows, Macintosh (8,9,X), Unix (OSS), SGI, and BeOS) http://www.portaudio.com/ PortMusic APIs - Platform Independent Libraries for Sound and MIDI ( PortMusic is open-source and runs on Windows, Macintosh, and Linux. Currently, libraries support Audio I/O and MIDI I/O) http://www-2.cs.cmu.edu/~music/portmusic/ would that be a useful basis for a portable Haskell sound binding? or has anyone already implemented such bindings, for this or any other sound API (SOE's music component includes Midi file support, and also talks about csound)? cheers, claus ps. just had a look at their mailing list archives, and saw a reply by Roger Dannenberg, confirming that PortMidi is still being developed http://www.create.ucsb.edu/pipermail/media_api/2004-May/000305.html (given his background in functional real-time control and music languages, he should be interested if anyone wanted to provide a Haskell binding!-) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskell and sound (was: [Haskell-cafe] Toy application advice wanted)
On Fri, 7 May 2004, Claus Reinke wrote: for graphics, we've got OpenGL, and a nice Haskell binding to it, so I wonder whether there's a similar option for sound? e.g., does anyone have experience with PortAudio/PortMusic/PortMidi? Looking over the PortAudio specs it's good for a software processing environment but not a lot of use to eg a game. OpenAL appears to be much the other way round. -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskell and sound (was: [Haskell-cafe] Toy application advice wanted)
Looking over the PortAudio specs it's good for a software processing environment but not a lot of use to eg a game. OpenAL appears to be much the other way round. The thing that always confused me about OpenAL (www.openal.org) is the following part of the spec: OpenAL Fundamentals OpenAL (henceforth, the AL) is concerned only with rendering audio into an output buffer, and primarily meant for spatialized audio. There is no support for reading audio input from buffers at this time, and no support for MIDI and other components usually associated with audio hardware. Programmers must relay on other mechanisms to obtain audio (e.g. voice) input or generate music. other potential options, depending on intended use: Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. http://www.libsdl.org/ MidiShare is a musical operating system for Macintosh (MacOS Classic and MacOSX), Windows 3.1, Windows 95/98, Windows NT/2000/XP, Atari and Linux. Result of many years of research and development undertaken by Computer Music Research Laboratory of Grame, MidiShare provides high level services to the field of computer music and MIDI applications. http://www.grame.fr/MidiShare/ others? cheers, claus ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
On Wednesday 05 May 2004 04:46, Ben Lippmeier wrote: http://www.haskell.org/libraries and look at how many seperate GUI libraries there are - I counted 16 - then ask what made the developer for the 16th one choose to start over. The fact that the 16th one is a wxwindows binding justifies this quite well :) V. -- Si puo' vincere una guerra in due e forse anche da solo si puo' estrarre il cuore anche al piu' nero assassino ma e' piu' difficile cambiare un' idea [Litfiba] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
On May 3, 2004, at 5:52 PM, [EMAIL PROTECTED] wrote: I've got an interesting task this week for my job. (Note that this will undoubtably last for longer than a week). I'm evaluating several high-level languages as development vehicles for our next suite of applications. The languages I'm currently considering are Scheme, Erlang, and Haskell... The toy application I've designed for myself is a simple GUI-based app that can load a Sun .au format sound file, display its waveform in a window, perform some simple filtering, play the sound for the user, and then save the changed sound file back out to disk. If I get familiar enough with the respective environments I'd like to add zooming in/out and scrolling to the waveform display... I have an amortized four days (32 hours!!!) to implement this simple application in Haskell... Any advice/pointers/flames welcome. Thanks in advance. Frankly, I think it's completely unrealistic to expect to be able to fairly evaluate Haskell in 32 hours. As you noted yourself, Scheme and Erlang, being strict, are much closer to conventional programming languages than Haskell is, so it's easier to transfer skills to them. Furthermore, they're untyped, and learning how to exploit Haskell's static typing is one of the bigger hurdles to learning how to exploit Haskell. Even if, as you wrote in a later post, you lower your sights to something less ambitious than a full-blown GUI app (which I think is a good idea), it's hard get a grasp on concepts like laziness, recursive datatypes, parametric polymorphism, monads, type classes and so on in less than a week, even for experienced programmers. At best, I imagine you'll come away curious and hungry for more; but clearly that doesn't suffice for a language evaluation. Of course, the fact that Haskell can't be grasped in a day (or week) can be construed as a practical argument against its adoption. On the other hand, if you accept that there's no such thing as a free lunch, you might consider that a merit; what is the point of adopting a new language if it doesn't change the way you think about programming, and let you write old programs in new, perhaps better, ways? [1] While Haskell is IMO the best programming language around, and I want to encourage its broader adoption, if you want a well-designed language with good implementation and support which permits swifter skill transfer, may I (strongly) recommend you add Objective Caml to your list of candidates? Once you acquire some experience with an ML-like language such as OCaml, which after all resembles Haskell in many ways, you will, I believe, find yourself better equipped to evaluate Haskell. Regards, Frank [1] Think about polynomials and real numbers. Complex numbers were, I believe, invented specifically to ensure that every polynomial equation has a solution. So, to address some problems, we need to take a step backward before we can take one forward. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
I'm finding wxHaskell very nice, and a wxWidgets binding is something many other advanced languages don't have (even OCaml). The only downside is having a 'Hello World' GUI application with 7 Mb... but it runs quite well and smooth once it's loaded. --- []s, Andrei de A. Formiga --- Vincenzo aka Nick Name [EMAIL PROTECTED] wrote: The fact that the 16th one is a wxwindows binding justifies this quite well :) V. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
David Roundy wrote: I think that sounds like a good idea (not doing a GUI just yet) but would recommend that perhaps you could do something pretty impure in terms of file or directory browsing. That wouldn't involve going beyond the standard libraries, but might give you some idea of the expressive power of the languages in terms of IO actions. I'm thinking something like a recursive grep, or wc -l... except preferably a bit more tailored to the sort of IO you'll have to do in your actual application. I guess the trick would be in finding something tough enough, since wc -l would be something like a two-liner... A one-liner: main = interact (show . length . lines) - Lyle Kopnicky ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
On Wed, 5 May 2004, Frank Atanassow wrote: Frankly, I think it's completely unrealistic to expect to be able to fairly evaluate Haskell in 32 hours. As you noted yourself, Scheme and Erlang, being strict, are much closer to conventional programming languages than Haskell is, so it's easier to transfer skills to them. Yeah, I'm starting to see the difficulty in recommending a language I can barely dabble in up the chain (not as bad as pointy hair bosses, but still not computer scientists). Furthermore, they're untyped, and learning how to exploit Haskell's static typing is one of the bigger hurdles to learning how to exploit Haskell. That was one of the things that attracted me to Haskell...the type system. I enjoyed strong typing in ML when I played with it in college. At best, I imagine you'll come away curious and hungry for more; but clearly that doesn't suffice for a language evaluation. Certainly. Of course, the fact that Haskell can't be grasped in a day (or week) can be construed as a practical argument against its adoption. On the other hand, if you accept that there's no such thing as a free lunch, you might consider that a merit; what is the point of adopting a new language if it doesn't change the way you think about programming, and let you write old programs in new, perhaps better, ways? [1] This is the crux of the argument. I don't understand how we can make good programming languages more popular. My son was born just a couple of weeks ago, and I barely have enough time now to keep up with anything in my career/field; I was lucky I convinced my management to let me do a (too-) brief language survey. But without having thought in Haskell for at least a couple of months, how can I hope to promote it successfully? How can I get a couple of months proficiency in Haskell unless I've promoted it successfully? (Co-routines? =) While Haskell is IMO the best programming language around, and I want to encourage its broader adoption, if you want a well-designed language with good implementation and support which permits swifter skill transfer, may I (strongly) recommend you add Objective Caml to your list of candidates? Once you acquire some experience with an ML-like language such as OCaml, which after all resembles Haskell in many ways, you will, I believe, find yourself better equipped to evaluate Haskell. Thanks for this...I actually just added ocaml to my list last night. I was looking over the programming languages shootout and read some of the source. It looks pretty neat. I spent last night writing a simple object system from scratch in Scheme with macros, and starting thinking about all the things I'd have to do to implement any kind of type safety, and it just sort of clicked that ocaml might be an interesting solution. Thanks again for your comments (and everyone's). -- Mike J. BellThis is all just my opinion. Outside of a dog, a book is man's best friend. Inside it's too dark to read. [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
On Mon, May 03, 2004 at 11:27:41PM -0400, [EMAIL PROTECTED] wrote: Anyway, I'm starting to ramble, but I talked to a friend who has similar feelings but is actually pretty good at Common Lisp. He suggested I refocus my energies, and I agree: instead of biting off more than I can chew, and having to learn a whole wad of APIs that aren't really about the language (read: wxHaskell or gtk2hs/the like, or audio packages etc.), just code some really simple problems. Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a master state holder and many slaves. Or quicksort. Etc. etc. So I'm going to head down that path right now, and try to get a feel for the languages in a slightly more pure fashion. I'll still try to get performance metrics out of them, but I'm not going to bang my head against the wall learning new languages, GUI toolkits, and FFIs all in two weeks. I think that sounds like a good idea (not doing a GUI just yet) but would recommend that perhaps you could do something pretty impure in terms of file or directory browsing. That wouldn't involve going beyond the standard libraries, but might give you some idea of the expressive power of the languages in terms of IO actions. I'm thinking something like a recursive grep, or wc -l... except preferably a bit more tailored to the sort of IO you'll have to do in your actual application. I guess the trick would be in finding something tough enough, since wc -l would be something like a two-liner... -- David Roundy http://www.abridgegame.org/darcs ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
Mike, I'm evaluating several high-level languages as development vehicles for our next suite of applications. .. just code some really simple problems. Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a master state holder and many slaves. Or quicksort. Etc. etc. I would be careful about using your experience with these toy programs as an indication of how suitable functional languages (and lazy ones in-particular) are as 'development vehicles' for your applications. A functional programmer's idea of a 'toy' program tends to be somewhat different from a C++/GUI programmers one. Lazy functional languages lend themselves nicely to parsing, list processing, search trees and the like - but if you're planning to load a wave file, apply a filter and then display the result on the screen .. then let's just say that you've got an adventure ahead of you, and it's not going to take 2 weeks. ... as far as GUIs are concerned, check out http://www.haskell.org/libraries and look at how many seperate GUI libraries there are - I counted 16 - then ask what made the developer for the 16th one choose to start over. Haskell is lazy all the time. That's awfully nice...I'm not sure if there's a performance penalty somewhere, but assuming there isn't, kudos to it. There is.. and its name is 'space leak'.. and the function mapAccumL :: (acc - x - (acc, y)) - acc - [x] - (acc, [y]) is by far the most elegant way of expressing it :) BTW: I've just dedicated the next 3 years of my life to trying to write non-toy programs in lazy functional languages... adventure is the operative word.. not can't. Ben. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Toy application advice wanted
Hi folks, I've got an interesting task this week for my job. (Note that this will undoubtably last for longer than a week). I'm evaluating several high-level languages as development vehicles for our next suite of applications. The languages I'm currently considering are Scheme, Erlang, and Haskell. Scheme and Haskell have fairly wide acceptance in their particular roles (Scheme as the pretty lisp, supporting higher-order functions and mostly strict [until you roll your own laziness with macros], and Haskell the absolute purest language with no side effects and fully lazy evaluation). Erlang has a really nice distributed computing model, and has a nice union of non- and side-effect qualities (although it's completely strict). The toy application I've designed for myself is a simple GUI-based app that can load a Sun .au format sound file, display its waveform in a window, perform some simple filtering, play the sound for the user, and then save the changed sound file back out to disk. If I get familiar enough with the respective environments I'd like to add zooming in/out and scrolling to the waveform display. This application should allow me to see all kinds of different characteristics of the language/implementation, such as performance (how fast can the filter run), I/O (how fast can I load/save data to disk), OS interaction (how easy can I play the audio), user acceptance (how easy is it to do GUI programming) and of course the software engineering goals of modularity, correctness, and simplicity. The end goal is for me to have three working programs, in three different languages, so that I can present to my boss the performance/software engineering characteristics of each system to choose our next development language. So I'm writing you to solicit help. I have an amortized four days (32 hours!!!) to implement this simple application in Haskell. Can anyone point me to example code, supporting libraries, tutorials, etc. that are in this area of development? If I have to dumb down some of my application in order to make a great discovery about a language, that's fine. I'm expecting some great differences between these three programs. Any advice/pointers/flames welcome. Thanks in advance. Mike -- Mike J. BellThis is all just my opinion. Outside of a dog, a book is man's best friend. Inside it's too dark to read. [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Toy application advice wanted
On Tue, 4 May 2004, Bill Walsh wrote: I am amazed that you can even think of doing anything in a week. I have been at it for at least 15 years: one project; one dead set proof-of-concept . Well I'm sure you're doing something much more useful/worthwhile than I! =) I understand that the example program I initially thought of is rather, well...typically imperative. That's sort of the reason I chose it. Not only does it have real-world ramifications to my customer (the problem domain is similar) but it will hopefully show me the worst of the best. I.e., Haskell is a beautiful language [disclaimer: this comes from me not really being a Haskell programmer, but admiring it from afar if you will] and can express some unbelievably advanced concepts elegantly, but is it really nasty doing normal software crap like loading a bunch of data, popping up GUI windows, etc. etc.? I was hoping that I can piece together something fairly quickly within two weeks in those three languages. They don't have to be robust, or even beautiful. In fact, I can guarantee they won't be. But the real point of the exercise is for me to figure out which environment is the easiest for me to get along with. I will follow your progress with intense interest. Your are obviously an experienced programmer, but it is your analytical skills which interest me most. Well, I am an experienced programmer, but certainly not in the same class as most lambda-junkies as yourselves. I have a long sordid history of programming in imperative languages and I've been bitching about switching for long enough that it's time to put my money where my mouth is, so to speak. I've dabbled in Scheme and Erlang and ML. To be frank, I've all but discarded Erlang as a viable language. Don't get me wrong...it's got some great features; I just think that I could easily implement Erlang in Scheme or Haskell and be quite happy. (At some point in the future when I'm smarter =) So to me, the real question is: Haskell, the pure, or Scheme, the dirty? Haskell is lazy all the time. That's awfully nice...I'm not sure if there's a performance penalty somewhere, but assuming there isn't, kudos to it. Scheme lets you be selectively lazy with macros. At least it's highly customizable (for instance, pattern matching can be implemented in Scheme with macros, whereas other languages that have fixed special forms are quite limited). But Scheme lets you change things if you want to! (The Haskell afficianados gasp). Let's face it...in most long-running applications, data changes a lot during the lifetime of a program. So somehow, you have to manage the repercussions of state changes. Haskell does this with monads. (I'm still wrapping my brain around them, but...) Apparently monads plus some syntactic sugar are like functions that return a value and the next function, which in turn returns a value and the next function, etc. so that referential transparency is maintained. This is a heckuva lot of work to do (set! foo 'bar). I hope I'm not far off base with this. I guess it boils down to this: Haskell ensures that your bindings are never ever ever corrupted, and thus the sematic value of your program is never compromised from the outside. The cost of this is a sharp learning curve, and quite possibly a performance hit. Scheme lets you tromp all over stuff (well, you get the picture), in effect letting you still have control over when you really need to do something imperative for performance or simplicity reasons. I'm not sure which I *like* better. So far neither is visually appealing, mostly because I'm not familiar with them. Scheme seems to have a slightly bigger population than Haskell, which of course means squat because if I really cared about how many programmers of language X there are out there I'd just code in Java (which, sadly, I'm doing now). Anyway, I'm starting to ramble, but I talked to a friend who has similar feelings but is actually pretty good at Common Lisp. He suggested I refocus my energies, and I agree: instead of biting off more than I can chew, and having to learn a whole wad of APIs that aren't really about the language (read: wxHaskell or gtk2hs/the like, or audio packages etc.), just code some really simple problems. Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a master state holder and many slaves. Or quicksort. Etc. etc. So I'm going to head down that path right now, and try to get a feel for the languages in a slightly more pure fashion. I'll still try to get performance metrics out of them, but I'm not going to bang my head against the wall learning new languages, GUI toolkits, and FFIs all in two weeks. =) Thanks for the replies so far, I really appreciate them. -- Mike J. BellThis is all just my opinion. Outside of a dog, a book is man's best friend. Inside it's too dark to read. [EMAIL PROTECTED]
