New Esperanto PO file for 'lilypond' (version 2.19.26)

2016-10-12 Thread Translation Project Robot 
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'lilypond' has been submitted
by the Esperanto team of translators.  The file is available at:

http://translationproject.org/latest/lilypond/eo.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/lilypond/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/lilypond.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

2016-10-12 Thread David Kastrup 
David Nalesnik  writes:

> On Wed, Oct 12, 2016 at 5:52 AM, David Kastrup  wrote:
>
>> Bonus points for recognizing the fragment...
>
> Toccata and Fugue in D minor, BWV 565?

Ah, I should have removed the treble staff altogether so that you'd have
been forced to decipher the accordion chord notation in the left hand.

The chord progression in the right hand is probably characteristic
enough on its own, at least when adding the non-chord bass notes.

I've not actually played this adaption by Anzaghi for standard bass
since I have acquired an instrument with free bass manual since then.
So there is no real point in not playing the organ version mostly.

But the score has nevertheless been useful occasionally as a reference
for particular notational elements.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

2016-10-12 Thread David Nalesnik 
On Wed, Oct 12, 2016 at 5:52 AM, David Kastrup  wrote:

> Bonus points for recognizing the fragment...

Toccata and Fugue in D minor, BWV 565?

DN

P.S. Sorry, nothing apropos the main topic!

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

2016-10-12 Thread David Kastrup 
Johan Vromans  writes:

>> > The bottom line is: What is required in chord c:blah so that .NN can  
>> > be added as a pure addition. It is unfortunate that c:.13 is invalid  
>> > syntax.
>
> Since MusicXML additions are pure additions, would it be safe to turn these
> into (addNN)?
>
> E.g. C + 13 => c:(add13)

Uh, we don't have syntax like that as _input_ syntax?  You mean, allow
c:add13 here?

> Even though that will turn a friendly C13 (user input) via C + 7 + 9 + 11 +
> 13 (MusicXML) into an ugly c:(add7)(add9)(add11)(add13) (LilyPond)...
>
> Otherwise, I'd go for the origional idea of parsing for a preceding digit,
> optionally followed by '+' or '-' (if that would cover all).

Frankly, the .xxx syntax essentially already means "add".  I happen to
be partial to creating a "major" modifier.

Here is how the Italian accordionists do it:


Bonus points for recognizing the fragment...

Here is a somewhat expansive description:


>From the various notations, I find that "M" does fit LilyPond's existing
schemes best as a "major" modifier.

I am not convinced at how the following are rendered.  Particularly c:m5
seems nonsensical, but I'm not too enthusiastic about the others either.

\chordmode { c:dim5 c:m5 c:5 c:maj5 }

Maybe just kill the special effect of "5" whenever it is not first?
There is also the possibility of "whenever it is not alone", but I am
less convinced about what that would do to c:5.6 and similar.

-- 
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

2016-10-12 Thread Johan Vromans 
> > The bottom line is: What is required in chord c:blah so that .NN can  
> > be added as a pure addition. It is unfortunate that c:.13 is invalid  
> > syntax.

Since MusicXML additions are pure additions, would it be safe to turn these
into (addNN)?

E.g. C + 13 => c:(add13)

Even though that will turn a friendly C13 (user input) via C + 7 + 9 + 11 +
13 (MusicXML) into an ugly c:(add7)(add9)(add11)(add13) (LilyPond)...

Otherwise, I'd go for the origional idea of parsing for a preceding digit,
optionally followed by '+' or '-' (if that would cover all).

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel