On Wed, Feb 2, 2011 at 6:11 PM, alex <[email protected]> wrote: > So, why not hit reply and introduce yourself (even if you've posted > already), and reveal your interest in haskell and/or art, whatever > that may be. I'll do it too, but someone else go first :)
My name is Steve and I'm a doctoral student at the Input Devices and Music Interaction Laboratory at McGill University. Officially my work centers around using force-feedback devices for audio interaction. This involves a lot of physical modeling, robotics, DSP programming, etc. However, I have a computer science background, not engineering, so I constantly get 'distracted' by trying to find better ways to express my programs :) Unofficially, I'm in love with programming language research and spend more time than I should reading papers about type theory etc., but I haven't really designed any language myself (to any significant extent) because it seems that any time I come up with an idea, it's either been proven uninteresting, or already implemented in Haskell or some other language! Anyways, due to the field I work in, one subject area I find myself obsessed with is the seeming conflicts of interest between functional programming and real-time guarantees (for writing DSP programs, etc). The former allows more powerful ways to express programs and modularize logic, but seems to often require methods for abstracting machine architecture such as garbage collection, which is not compatible with time determinism. Avoiding GC seems to require the use of more restrictive languages like in the case of FAUST, which is basically a declarative DSP description language. I'd like to eventually find just the right balance between time determinism and general-purpose programming. My observation is that in several audio programs I've written, I always end up using C because that's the only way I know to write an audio loop that won't glitch, but then my central "mixing" routine grows into an uncontrollable monster because I can't split it up easily for various reasons. I'm hoping that getting into things like llvm-synthesizer or FAUST might allow me to write functional mixing routines that I can more easily split up into smaller functions. However, I find FAUST not quite expressive enough for some of the complex buffer juggling I've had to do in the past. Anyways, my current line of thought is that to solve this problem we need something like the current line of eDSLs which compile to other languages (Atom, Copilot, llvm-synthesizer, etc), but which can additionally communicate seemlessly with a non-real-time portion of the program written in full Haskell. Maybe something like this exists? My dream would be to take a program written in a high-level language which consists of a real-time and non-real-time portion, and be able to compile it to a regular executable, and then take the same program and compile it against a different back-end (using not much more than a compiler switch) which would provide the real-time portion as a binary for the DSP board I am using for robotics, and the non-real-time portion as a host executable that would load it and communicate with it. Steve _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
