FWIW, I like the score / orchestra distinction. It's not going to solve all problems, but it's pretty convenient most of the time. In Euterpea we actually extend the idea in a couple of ways. First, you can label any Music value with any instrument. For example:
instrument Flute m1 :=: instrument Violin m2 This is a Music value that plays m1 with a flute in parallel with m2 with a violin. But Flute and Violin are abstract, and later they can be mapped to a standard MIDI instrument, or mapped to an instrument you design yourself at the signal processing level (for example, via the renderSF function mentioned below). Currently you can't mix MIDI and signal functions - they must all be either one or the other - but that's something we'd like to fix. "Note attributes" allow passing arbitrary information from the score to the instrument (like csound's pfields), which of course is just ignored by MIDI. Second, as in Haskore, there is an interpretive layer between Music values and the back-end. Specifically, there is something called a Player than generates an abstract Performance from a Music value. A user can define her own Player - for example, you can define a "piano player" that interprets legato differently from a "violin player", or you might define a "jazz player" that introduces a "swing feel". Like instruments, you can have more than one player playing in the same composition. A lot can be done at the Performance level that is much more difficult to do at the Music level, so it provides a convenient level of abstraction. Of course, Euterpea is just a Haskell library, so if a user doesn't like any of this she can just roll her own :) Best, -Paul From: [email protected] [mailto:[email protected]] On Behalf Of Anton Kholomiov Sent: Sunday, February 20, 2011 5:30 AM To: [email protected] Subject: Re: [haskell-art] Haskell art? I've thought about it too. When you compose notes and then apply instruments you get sound and not notes of sound or event it is notes of sound it is nice to be able to convert it to sound and reuse it in another instrument. Here two layer model of orchestra + score is restricting. Sometimes you need to convert notes of sound to sound and use it in another instrument. I've installed Euterpea and there is a function in module "Euterpea.Audio.Render" renderSF :: (Clock p, Performance a, AudioSample b) => Music a -> InstrMap (Signal p () b) -> (Double, Signal p () b) which can do it. 2011/2/18 Evan Laforge <[email protected]<mailto:[email protected]>> > 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 [email protected]<mailto:[email protected]> http://lists.lurk.org/mailman/listinfo/haskell-art
_______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
