It's undocumented, so it's hard for me to read. Also the math terms are a bit over my head, that might be part of it. But it's interesting, because I've been working on a similar system. Well, similar only in that in order to represent pitches I wind up with high and low level representations, but I think the actual realization of that is totally different.
I just have a pitch as a function which takes a key and a set of transposition signals (e.g. diatonic, chromatic, cents, hz) to a frequency, and then a scale is just a Map String Pitch. So I think it's more flexible than yours since the pitch is very general, e.g. it can respond to any kind of transposition or key it feels like, and e.g. retune over time or relative to the intonation of other pitches. But then less flexible since it's a function, so you can only manipulated it through its arguments. That makes a lot of analysis impossible. I think this tradeoff between code and data is fundamental. Can you talk about why you chose this particular representation and what it allows you to do? I guess you could write transformations at various levels, e.g. diatonic transposition at AbstractPitch1, or something else at AbstractPitch2 (I don't know what an "ordinary pitch" is), and perhaps impose vibrato or something at AbstractPitch3 (though your pitches seem to be discrete and not signals, though I guess you could just make a list of them). But these uses probably aren't what you had in mind. The example piece seems like it's just a note list, so it doesn't really demonstrate the interesting things made possible by the three layer thing. Also, it seems like you're focusing on scales with 7 diatonic steps? The Name type with its A-G implies that it's hardcoded that way. On Sat, Aug 31, 2013 at 12:04 PM, Edward Lilley <[email protected]> wrote: > Greetings everyone. This is my first mailing list post, so apologies if > I'm unwittingly off-topic etc. > > I've recently been working on a little project to aid my own > explorations into computer-aided composition & music > representation. I've (rather blandly) named it 'AbstractMusic', and it > can be found on Github[1]. > > It's designed around the idea of separating the process of producing > music into different layers of abstraction; each layer of abstraction > having its own idea of what a pitch, interval and duration is; and a > triple of (pitch, interval, duration) types can be used to create a > 'note' type. > > For example, among the pitch types there are: > - AbstractPitch1, which represents scale degrees > - AbstractPitch2, ordinary pitches (derived from AbstractPitch1 by > applying a scale) > - AbstractPitch3, a frequency in Hertz (derived from AbstractPitch2 by > applying a tuning system) > > Each type makes as few assumptions as possible about what it might be > transformed into -- in particular, AbstractPitch2 does not assume > 12-equal temperament, so C-sharps are distinct from D-flats -- it's up > to the tuning system to determine how to deal with > accidentals/augmentation/diminution etc. > > See the file Tuning.hs for implementations of some common syntonic > (meantone) and equal temperaments. The internal representation of > pitches and intervals is as a free Abelian group -- i.e. a pair of > integers representing that interval in a particular basis. This means > that most common tuning systems can be implemented quite succinctly as > some linear transformation of that internal representation. > > I've produced one major example so far, which a piece of keyboard music > by Guillaume Costeley which uses 19-equal temperament. See the file > Costeley.lhs, or this[2] page for synthesised (Csound) and typeset > (Lilypond) output. Please see the files Examples.hs and Canon.hs for > more examples, e.g. a fragment of Pachelbel's canon. > > (You may notice that I'm no expert in Csound -- both the Csound and the > Lilypond output are rather primitive at the moment) > > > Edward Lilley > > > > [1]: https://github.com/ejlilley/AbstractMusic > [2]: http://www.ugnus.uk.eu.org/~edward/costeley/ > > _______________________________________________ > haskell-art mailing list > [email protected] > http://lists.lurk.org/mailman/listinfo/haskell-art _______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
