lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Towards a new pitch representation


From: Carl Sorensen
Subject: Re: Towards a new pitch representation
Date: Thu, 30 Dec 2010 21:30:25 -0700



On 12/30/10 3:55 PM, "Felipe Gonçalves Assis" <address@hidden>
wrote:

> Hi Carl,
> 
>> 
>> Hi, Felipe.
>> 
>> I've looked at your patch, but I'm having a bit of trouble seeing how the
>> patch resolves the issues that are identified in issue 1278.
>> 
>> I must admit that i've not yet fully understood Hans's emails on issue 1278.
>> 
>> How do your new two-element alterations improve the situation?
>> 
> 
> You don't need to go back to those emails. I hope the attachment in my
> last email can help. But for a simple example of how my patch works,
> when you type, e.g., ciseh' in a LilyPond input file, this is mapped to a
> pitch that has as alteration (1 . -1), meaning "one semitone minus one
> quarter-tone", which might then be typeset as a sharp with a down-arrow.

Are you using a two-element list, or a cons cell?  The two are not the same.

I seem to remember looking in the code, and seeing scm_cadr calls, which
implies that your alterations would be (1 -1), not (1 . -1).

For (1 . -1), you'd get the 1 with car, and the -1 with cdr.

For (1 -1), the car is 1, and the cdr is (-1), or (-1 . ()), so you need
cadr to get the -1.

If we are going to move to a list for alterations, the list should probably
be rationals, rather than integers, in order to be most general.  Thus it
should most likely be (1/2 -1/4), rather than (1 -1).

Alternatively, you will need a property somewhere which is a list of the
base units for each alteration, so that an alteration would be (1 -1), and
the alterationMagnitude would be (1/2 1/4).

In the current patch, you force all alterations to be lists (or cons cells,
whichever you have implemented).  This will break lots of old scores.  It
would be cleaner to allow alterations to be numbers (as they were in the
past) or lists.  Then the old code would work.  Otherwise, you'll need to
make a convert-ly rule which may be a bit tricky.

I think that as long as you *allow* but don't require the extended pitch
representation, it's likely to be very well accepted.

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]