[gsharp-devel] suggested change of terminology

[Eolin KB]

Hello Robert, Christophe and others!

In my reply below EMJ are my initials (Erik Magnus Johansson)

----- Original Message ----- 
From: "Robert Strandh" <strandh at labri.fr>
To: <gsharp-devel at common-lisp.net>
Sent: Wednesday, August 02, 2006 8:07 PM
Subject: [gsharp-devel] suggested change of terminology


> Hello,
>
> 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.

EMJ: But they can indeed move and they also get distinct names at each 
position: F clef on the fifth line is called sub-bass clef, on the fourth 
line bass clef, and on the third line baritone clef; a G clef on the second 
line is called treble clef, and on the first line french violin clef.

> Having thought about it for a while, I am now suggesting a change in
> the behavior of Gsharp, and a corresponding change to the
> documentation.  My suggestion is partly based on the difficulty for an
> end user to know the number of each staff line.
>
>  I suggest changing the "Insert Staff Above/Below" commands so that
>  they do not prompt for a line number for the clef, and instead just
>  use the default staff line for each clef.  Furthermore, I suggest
>  that "f" and "bass" be equivalent choices and that "g" and "treble"
>  be equivalent choices.

EMJ: See my first comment why "g" (clef) and "treble" are not equivalent.

>  Finally, I suggest adding commands to move the clef of a staff up or down 
> one line.

EMJ: Good!

>  Internally, I suggest changing the names of the clefs to :g, :f, and
>  :c.

EMJ: Good!

> Comments?
> -- 
> 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
>