[Music Suite] Intonation type names

[Hans Höglund]

Hi Edward,

I am considering renaming some things in the Music.Pitch.Intonation module: as you wrote it I thought I should ask for your opinion first ;) Basically I want to get rid of the "Interval" and "Ratio" suffices by renaming the type like this:

Intonation -> Tuning

IntoneInterval -> Intonation

FreqRatio -> Freq

In other words, the type representing mappings from intervals would be called 'Intonation', while the type representing mappings from a pitch name to an absolute frequency would be called tuning (i.e. think the word "tuning" implies that a reference pitch have been chosen, i.e. A = 440Hz).

I am also not 100% sure we should retain the distinction between absolute and relative frequency. Of course it is nice to follow the vector/point separation principle throughout, but it might be overkill when it come to SI-units like Hertz.

Any thoughts?

Btw. I am now located in London, so if you are in town some day it might be possible to meet up.

Regards,

-

Hans Höglund

Composer, conductor and developer

hans [at] hanshoglund.se

hanshoglund.com

https://twitter.com/hanshogl

https://soundcloud.com/hanshoglund

http://github.com/hanshoglund

[Hans Höglund]

> I don't mind about the naming really -- if there's any confusion, I just
> glance at the type signature. So, bearing in mind that I don't actually
> care(!), my suggestion would be the other way round: tuning for the
> general case

That makes sense, I'll go with intonation being `Pitch -> Hertz` and tuning being `Interval -> Hertz(Ratio?)`.

> My reasoning behind introducing the FreqRatio type was to keep the
> expression of the 'synTune' and 'makeBasis' functions as clear as
> possible. Perhaps if it were possible to make an instance of VectorSpace
> with Hertz as both the point *and* the vector type, that notation could
> be retained?

Yes Hertz can be an instance of AffineSpace (the "point" class) with itself as its Diff ("point" to "vector" type function), as with the Double (really Double^n) instances. If will try that and see if it makes the API more intelligible.

> Also, I've just noticed the IsInterval instance for Hertz, and I'm a
> bit confused -- is it assuming some particular tuning system, and what
> is the role of (o,d,c) in general? To my mind, intervals are *anything*
> that:
> a) add and subtract like vectors, and
> b) have a special vector called a unison such that (unison - i) is
> "negating" the interval i (though this is actually redundant because
> all vector spaces necessarily already have this property)
> c) have a special vector called an octave such that (octave - i) is
> "inverting" the interval i.

In IsInterval (o,c,d) is simply a serialization of the name, i.e. octaves, chromatic steps (mod 12) and diatonic steps (mod 7) – all common names have a serialization like that: { m3 -> (0,2,3), _M3 -> (0,2,4), m9 -> (1,1,1) ... }. The role of this class (and its sibling IsPitch) is to make expressions shorter in cases where common pitches and intervals are not being used. It is similar to Num and IsString in that respect: the language does not force you to write `fromInteger 2` or `fromString "hello"` to work with Int and Text as opposed to Integer and String.

You are right, the IsInterval instance is really assuming a "pure" intonation and should probably be removed. On the other hand I *would* like to be able to use things like `up _P8` on (say) a value of type `Score Hertz`. But that would probably be having the cake and eating it too...

Hans