[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