[gsharp-devel] suggested change of terminology

Eolin KB eolin at telia.com
Thu Aug 3 09:49:15 UTC 2006


----- Original Message ----- 
From: "Robert Strandh" <strandh at labri.fr>
To: "Christophe Rhodes" <csr21 at cam.ac.uk>
Cc: <gsharp-devel at common-lisp.net>
Sent: Thursday, August 03, 2006 4:39 AM
Subject: Re: [gsharp-devel] suggested change of terminology


> Christophe Rhodes writes:
> >
> > > In private email, Magnus Johansson told me that a "treble clef" is a
> > > "G clef" on line 2 (in Gsharp terminology) and a "bass clef" is an "F
> > > clef" on line 6 (idem).  This is not the terminology that Gsharp uses
> > > at the moment.  In the book by Ross, I can't find any support for what
> > > Magnus told me, but on the other hand, it is consistent with it.  Ross
> > > simply says that the treble clef and the bass clef never move.
> >
> > This is true.  There are other names for other clef/line combinations
> > (e.g. "tenor", "alto" and "soprano" for various positions of the C
> > clef).
>
> OK, so instead of my initial suggestion, I now make the following one:
>
>    I suggest changing the "Insert Staff Above/Below" commands so that
>    they initially prompt for a clef.  The only choices possible will
>    be names of clef/line combinations (treble, bass, soprano, tenor,
>    alto) and no question about the line will be asked.

EMJ: The possibility of having a staff without a clef is desirable.

>    Finally, I suggest adding commands to move the clef of a staff up or 
> down n
>    lines according to a numeric argument.
>
> > Incidentally, there's a tricky terminological issue.  Moving a clef
> > higher means lowering the pitch of the lines: so naming the command
> > should aim to be clear; maybe Move Clef Up?
>
> Sure, that's fine.
>
> > Fine by me, though it gets more complicated, again.  Firstly, there's
> > the issue of the 8va treble clef, which has a (slightly) different
> > glyph.
>
> Right.  I guess that could be one of the choices.
>
> > Secondly, there's the issue that several orchestral
> > instruments have transposing clefs -- that is, a clef where the
> > pitches played sound a constant interval away from the notated pitch.
> > (Normal examples: trumpets and clarinets, the latter having the
> > additional amusement that there are several instruments and several
> > transpositions).  This should probably be handled by the clef object
> > rather than the name for the glyph, but it does add to the complexity.
>
> I agree.  I suggest introducing a "transpose interval" to a clef that
> will handle that, and that will initially be 0 (is it possible to
> indicate it with a numeric value?),

EMJ: Yes, for example in semitone steps, e.g. clarinet in Bb would have -2. 
Some scores have this number (2) written below the clef; it is not to be 
considered a standard, though, as is the case of octave transposing 
instruments.

> and that can be altered.  It would probably be nice if the input method 
> could either take that interval
> into account (for people who think about pitch rather than notation)
> or not (for the others).

EMJ: Normally not, if I understand you right. When you are working on a 
transposing score and want to input notes in a part for e.g. trumpet in Bb, 
you usually want to input the tranposed notes and not the sounding ones. 
That is, you want to type c for getting a written C inserted though it will 
sound a Bb when played. But if the mentioned feature is optional, why not? 
Some may perhaps become very happy with it.

Regards,
Magnus

>
> -- 
> Robert Strandh
>
> ---------------------------------------------------------------------
> Greenspun's Tenth Rule of Programming: any sufficiently complicated C
> or Fortran program contains an ad hoc informally-specified bug-ridden
> slow implementation of half of Common Lisp.
> ---------------------------------------------------------------------
> _______________________________________________
> gsharp-devel site list
> gsharp-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/gsharp-devel
> 





More information about the gsharp-devel mailing list