On Fri, Feb 25, 2011 at 5:58 AM, Hudak, Paul <[email protected]> wrote: > 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.
Just out of curiosity, what benefits do you see from this extra layer of abstraction? In other words, why write: score = instrument Flute m1 realize score [(Flute, myFluteInst)] rather than realize (instrument myFluteInst m1) To me it just seems like an arbitrary name to pick (what if your instrument doesn't fit into the predefined names, or if you have thousands of instruments, one per note, or if 'realize' gets an instrument it doesn't understand?). > 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. This sounds like something I've noticed, and if it's the same thing, I agree. But I disagree that you need to separate orchestra and score to get it. Namely that notes are described hierarchically (e.g. phrase1 `then` phrase2 :=: part2 or whatever), but that many musical transformations only make sense on a flat stream of notes. For example, decide which note a string would be played on and pick a corresponding corresponding base note + bend. You can't do this without a memory of which notes have been played (to know currently sounding strings) and maybe a look a little ways into the future (to pick between alternatives). Hierarchical composition has no access the previous and next notes, so it winds up having to be a postprocessing step on the eventual note output stream, which means you have to have something in between the score and the sound. By why be limited to one one instance of this player and a static score -> player -> sound pipeline? The way I have it set up, this postprocessing (maybe like a Player in Euterpea) is interleaved in the score itself. So, say if I want to play a given run with a swing feel, I can wrap 'swing' around just the run. There's no need to put a "swing" attribute into the score type and then teach the Player how to interpret "swing"---this is what I would call having to set up knobs that you get when orchestra and score are separate. And then this swung output can be further composed as part of the score, which I believe is unavailable once you get to Player, e.g. tweak notes after the swing is applied if I decide one should be earlier or later. If I understand correctly, in Euterpea you would have to do this tweaking after the Player, and couldn't do it in the score, unless you set up a "post-swing-teak" attribute and added support to the Player. It doesn't seem like that far-fetched of a thing to need to do. This is analogous to wanting to make a reversed instrument and then write score for that instrument, without having to run the render cycle twice. I'm not totally convinced the integration is valuable, but seeing as almost all other systems don't have it, it seems interesting to experiment with one that does and see where it leads. Maybe another way of putting it is that different interpretations of abstract instructions like legato are not necessarily always along instrument (piano vs. violin) lines: it may vary from phrase to phrase, or section to section. _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
