Re: Microtonal accidentals

[Hans Aberg]

On 3 Nov 2013, at 18:15, Joseph Rushton Wakeling <address@hidden> wrote:

> On 03/11/13 17:55, Hans Aberg wrote:
>> As a preparation, LilyPond might get intervals: it is going to be too 
>> complicated to write out names for all pitch combinations.
>> 
>> A pitch is defined by a written pitch plus a sequence of intervals added to 
>> it. Accidentals are a special case: intervals not changing the scale degree.
> 
> You've raised a very important point that I was going to mention myself in 
> slightly different wording.
> 
> There needs to be a way of defining pitches that separates the work of 
> defining staff notes from the work of defining alterations, and constructs 
> pitch names as a combination of the two.
> 
> The current method where (using English names) c, cf, cs, d, df, ds, e, ef, 
> es, f, ff, fs, g, gf, gs, a, af, as and b, bf, bs are all defined, just 
> doesn't scale when you are dealing with many different kinds of microtonal 
> alteration.
> 
> It's just about feasible, if you really want to, to define a quarter-tone 
> scale this way.  You can see this in the answer that I gave last year to a 
> user who was interested in defining a 16th-tone scale:
> https://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00443.html

I have just defined pitch names for E53 note c with accidentals, using Graham’s 
file regular.ly:
      cff cffu cffuu cfdd | cfd cf cfu cfuu | cdd cd c cu |
      cuu csdd csd cs | csu csuu cssdd cssd | css r2. |
Here, d (resp. u) is down (resp. up) one E53 comma (tonestep). I just checked 
with midicomp that the output is correct. 

> So, there needs to be a way of saying: these are the staff pitches and the 
> staff positions they correspond to (define c, d, e, f, g, a, b) and these are 
> the alterations and the accidentals they correspond to (define -s, -f, etc.), 
> now give me my list of available pitch names ...
> 
> That isn't a precondition of solving the microtonal notation issue but it 
> would be strongly complementary.

It might be implemented in anticipation, as it is going to be complicated to 
test otherwise.