[gsharp-devel] Microtones
Christophe Rhodes
csr21 at cantab.net
Sat Jun 16 18:26:38 UTC 2007
Magnus Jonsson <magnus at smartelectronix.com> writes:
> On Sat, 16 Jun 2007, Christophe Rhodes wrote:
>
>> Magnus Jonsson <magnus at smartelectronix.com> writes:
>>
>>> I have got basic microtonal support working and I have attached a
>>> patch of my changes. There is no integration with the GUI yet (and I
>>> am not sure how to do that).
>>
>> As a temporary solution (maybe for your own experimentation rather
>> than to commit anything), a simple command such as Set Tuning would
>> do? There wouldn't necessarily be any need for that to be reflected
>> graphically. (In the longer term, it would be nice to develop a
>> status area or other representation of certain global properties of
>> the score, such as tempo and intended tuning...)
>
> Yes, that would do I guess. I am still not very at home in clim/esa so
> I can't really say.
Something like, for instance,
(in-package :gsharp)
(define-gsharp-command (com-set-tuning :name t)
((tuning '(member :12-edo :quarter-comma :fifth-comma :sixth-comma)))
(let ((segment (segment (current-cursor))))
(setf (tuning segment) (find-tuning tuning))))
Where you probably need to define FIND-TUNING (see below).
>>> Are the changes and additions in the patch okay with you guys? If so I
>>> will commit it to CVS once the midi package has been updated.
>>
>> I've got some comments below.
>>
>>> - (tempo :initform 128 :initarg :tempo :accessor tempo)))
>>> + (tempo :initform 128 :initarg :tempo :accessor tempo)
>>> + (tuning :initform nil :initarg :tuning :accessor tuning)))
>>
>> It might be nice to have a slightly more symbolic default: a
>> designator for twelve-tone equal temperament of some kind? Or maybe
>> NIL is such a default in the context of Common Practice Notation, at
>> least in this day and age...
>
> Okay, changed to :12-edo. Twelve equal divisions of the octave. EDO is
> tuning theory jargon.
Right, but I'm afraid I wasn't clear enough -- or at least, I think
that we'd probably be better served defining some objects with useful
introspective properties, rather than bare symbols.
So for instance, from a little bit of Wikipedia browsing, there's this
hierarchy that I'm expecting to see shredded to bits...
regular-temperament
p-limit-just-temperament
twelve-edo
linear-temperament
miracle-temperament
...
...
We don't necessarily need to add all of these at once, but one thing
that we probably /do/ need to think about is saving and loading these
things. A TUNING probably needs to inherit from GSHARP-OBJECT, and
have a method for saving its slots via PRINT-OBJECT /
PRINT-GSHARP-OBJECT (and the method for SEGMENT needs similarly to be
adjusted). The idea, however, would be that if the tuning object
representing 12-EDO could be of the same general class as one
representing a linear-temperament, then the saving and loading code is
probably a lot simpler. FIND-TUNING then is a fairly thin wrapper
about MAKE-INSTANCE on these classes.
(As far as I can tell, despite our previous discussion, 12-EDO is not
a linear temperament, as a linear-temperament has two independent
generators, one of which is the octave, whereas 12-EDO only has the
ET-semitone -- but be careful with believing anything I say; my
exposure to mathematical properties and categorization of tuning
systems is very recent, limited to one conference I attended last
month).
>> (That's not necessarily to say that what you posted is unacceptable --
>> just to suggest aiming a little bit higher if possible :-)
>
> Yeah, it would definitely be more cool to do it that way. That may be
> a future revision if an itch develops. As it is now it should at least
> work with 4-voice choir pieces and the likes, right? I haven't learned
> yet how to make polyphonic music in gsharp and how it is represented
> internally but I assume one layer corresponds to one voice.
One layer corresponds to one voice, yes; you get polyphony in the
multiple-voice sense by having multiple layers, so for that what you
have is enough (to experiment, you can do M-x Add Layer, to get two
layers on one staff). The catch is that you can also get
simultaneities in a single layer, for e.g. keyboard music; to see
that, use capital note-name letters to add notes to the current
cluster; these wouldn't be representable with the proposed
implementation. (I'm here thinking of notational examples like that
at the top of <http://users.bigpond.net.au/d.keenan/sagittal/>)
> This reminds me that the play-buffer command is unimplemented. What is
> the difference between play-buffer and play-segment?
I'll have to defer to Robert here, but my understanding is that a
buffer is intended to be made up of a sequence of segments, a segment
being a sufficiently homogeneous section of musical material that it
makes sense to consider it as having some constant properties (when it
comes to layout, and so on).
>> I'm not sure (I Am Not A Tuning System Expert), but isn't this a
>> log-tuning scale? Sure, it's linear, but in log-frequency space,
>> rather than frequency space...
>
> For some reason tuning theorists call it linear temperament. I agree
> it is confusing.
Linear temperament, yes -- but that's unfortunately not the same as
"linear tuning", as far as my limited understanding of the
classification goes.
> A favorite of mine is to stretch the octave slightly in order to not
> compromise the fifth too much but still have sweet thirds: 1201 cents
> octave and 698 cents fifth (anything thereabouts is fine).
OK, summarizing my understanding here (so correct me if I'm wrong):
what's going on here is that putting the origin at a given note, from
the fifth and the octave we can generate the other notes by moving
around the helix of fifths (it's not a circle unless we've especially
arranged that 12*fifth = 7*octave, where those are measured in cents).
Which means that my question about "which key are we in?" is almost
misguided -- that is, the frequencies of C-D-E-F-G-A-B-C are a
constant multiple of those of D-E-F#-G-A-B-C#-D -- the reason that
it's not totally misguided is that one of these tunings which arranges
that the A above middle C is 440Hz is a constant frequency multiple
away from, say, one which arranges that the D above middle C is 293.66
(its 12-EDO value).
Cheers,
Christophe
More information about the gsharp-devel
mailing list