Re: Pitch notation

[Hans Aberg]

On 24 Feb 2007, at 19:37, Carl Sorensen wrote:

> It would be a very simple task for a programmer to write a  
> preprocessor that
> would take notation in the syntax you describe and convert it to  
> Lilypond in
> absolute notation.

Sure, this is what I did with C++, then starting to use Flex and  
Bison to develop my own computer languages. When I write my own music  
programs, like all others, LilyPond will not be necessary at all. :-)

> One fundamental difference between your proposed mixed relative and  
> absolute
> notation (if a number is there, it's absolute; if the number is not  
> there it's
> in the same octave as the last given note) is that Lilypond gives  
> you a relative
> based on the previous note.  This is very convenient for notating  
> music, as you
> can ignore the octave except for two places -- at the start of a  
> piece and when
> you have a jump of a fifth or more.

I had to correct some notes that were wrong, and then look down the  
musical line, to alter those following it. It did not seem intuitive.

But as I said in my first post, there are different ways to reason  
about it. And other than getting used to this or other system, what  
might be a convenient input syntax?

> Your proposed syntax would require a change
> of octave every time notes crossed an octave boundary, which can  
> happen quite
> frequently in many keys.

It was perhaps not clear in my original post.

But the idea is that the octave boundary can be set on any of the 12- 
TET notes. So for example, in C major one might write
  { \hide 3G C D G F G C }
which would be the absolute notes
  4C 4D 3G 4F 3G 4C
If I change the 4F to a 4G, I might write
  { \hide 3G C D G F G' C }
And if it branches upwards, so that there are many notes above 4G,  
one shift to a new octave range:
  { \hide 3G C D G F 4G C G F G D C C, }
which would be
  4C 4D 3G 4F 4G 5C 4G 5F 4G 5D 5C 4C

> I suppose that it would be possible to introduce a third way of  
> entering notes.
>    But I wouldn't want to replace lilypond's current entry method  
> with the one
> you've proposed.

For legacy, it would be difficult to scrap the current relative  
method. And it would not be difficult to merge them, I would think.

For example, one might agree that small case letter are relative to  
the note before, but upper case letter relative to the latest  
absolute note in the environment.

It could be that different types of movements benefit form different  
input syntax. This is why Ijust brought this up as an input.

  Hans Aberg