Re: Discussed here: (issue 321830043 by fedel...@gmail.com)

2017-04-03 Thread Graham Percival 
Cute solution, I like it.

Cheers,
- Graham

On Fri, Mar 31, 2017 at 10:49:27AM +0200, Federico Bruni wrote:
> It won't be in english only. It's up to translators. With this patch they can:
> 
> a) not translate the file, so the content of that section will be in english 
> _within a translated page_. No maintenance needed.
> 
> b) translate the file and maintain it across updates
> 
> I think I forgot to add a better comment at beginning of gsoc.itexi.
> I will do it in the coming days.
> 
> Sorry for the bad email subject. I didn't realize until today how Rietveld 
> creates it.
> 
> Il 31 marzo 2017 09:31:20 CEST, Urs Liska  ha scritto:
> >I don't really know what that technically means, but I'm OK with having
> >the GSoC page in English only.
> >
> >This page is being heavily edited for a certain period each year, and
> >the "target audience" has to be able to read it in English anyway.
> >
> >Urs
> >
> >
> >Am 31.03.2017 um 09:06 schrieb fedel...@gmail.com:
> >> Reviewers: ,
> >>
> >> Message:
> >> Please review
> >>
> >> Description:
> >> Discussed here:
> >>
> >https://lists.gnu.org/archive/html/lilypond-devel/2017-03/msg00277.html
> >>
> >> web: move Google Summer of Code information in included/
> >>
> >> So translators can choose not to translate this node of
> >community.itexi.
> >> GSoC page gets quite frequent updates and keeping the translations
> >> up-to-date may be cumbersome and not worth the effort (as GSoC
> >> applicants are required to speak english).
> >>
> >> Please review this at https://codereview.appspot.com/321830043/
> >>
> >> Affected files (+401, -385 lines):
> >>   A Documentation/included/gsoc.itexi
> >>   M Documentation/web/community.itexi
> >>
> >>
> >>
> >> ___
> >> lilypond-devel mailing list
> >> lilypond-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/lilypond-devel
> >
> >-- 
> >u...@openlilylib.org
> >https://openlilylib.org
> >http://lilypondblog.org
> >
> >
> >___
> >lilypond-devel mailing list
> >lilypond-devel@gnu.org
> >https://lists.gnu.org/mailman/listinfo/lilypond-devel
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

Re: Google SoC

2017-04-03 Thread Flaming Hakama by Elaine 
On Thu, Mar 30, 2017 at 5:57 PM,  wrote:

>
> -- Forwarded message --
> From: Carl Sorensen 
> To: "Winston, Charles R." , "
> jefferyshiv...@gmail.com" , "
> lilypond-devel@gnu.org" 
> Cc:
> Bcc:
> Date: Thu, 30 Mar 2017 21:19:27 +
> Subject: Re: Google SoC
> Charles,
>
> On 3/30/17 8:33 AM, "Winston, Charles R." 
> wrote:
> >
> >Anyway, I would love for either of you to pass my draft proposal on to
> >the list. It can be found here:
> >https://docs.google.com/document/d/1TZLsCovyvqBhahS3Vy7LJMRqyp-
> C8ZanHTuCOP
> >PTNAg/edit?usp=sharing
> >
> >
> > C8ZanHTuCO
> >PPTNAg/edit?usp=sharing>
> >Of course, thanks again for all the help. I welcome any and all feedback
> >to improve this, and really hope to get to work on this in the summer!
>
>
> Thanks for sharing your proposal.  It's a great start.
>
> The major challenge I see with the proposal right now is that it's
> somewhat superficial.  It could have been written by someone who just read
> what's available on the mailing list, and doesn't reflect much
> understanding of what goes on under the hood in LilyPond.  I realize that
> getting in to LilyPond is a big undertaking, but I think you could make
> the proposal shine if you had a bit more clarity on how your work will fit
> within the greater aspect of LilyPond.
>
> For example, your midterm goal is to complete the implementation of the
> new representation.  But what does that mean?  When the implementation is
> complete, what will we see?  Does it change any input or output?  If it
> doesn't, how will we know that the implementation is complete?
>
> Note that I'm not arguing that you need to have input or output by the
> midterm deadline.  I'm just asking some questions to try to help you
> clarify what "implementation is complete" means.  The more specific you
> can be, the better we will be able to judge your ability to complete the
> project.
>
> Let me know if you have more questions.
>
> Thanks,
>
> Carl
>


Thanks for you interest in improving Lilypond!

As someone who uses a lot of chord symbols, I am hopeful that this effort
will make Lilypond easier to use.

Below are my thoughts after reading your proposal.

Before I dive into that, I wanted to offer the observation that discussions
about chords in lilypond are often difficult because not everyone is clear
that lilypond uses a three step approach:  1) specify chords using input
syntax, 2) input syntax is transformed into a set of notes, and 3) the
exceptions definitions maps each set of notes to chord name markup.

I suppose most people on this dev list are clear about this, but in case
anyone isn't here's my little rant and attempt at clarification:
http://flaminghakama.com/flaming-lilypond-chords



I suspect that the best way to kick off this project is with a survey of
the things that:
* we currently cannot do
* take a lot of effort to do
* can only be done with bad semantics

Such as:

* Omitting the root on chord symbols for repeated slash chords with
repeated roots (such as A- /G# /G /F#)

* Writing chords with two different alterations of the same extension (such
as C7 b9 #9)

* Writing different chord symbols for the same chord in different
circumstances (such as C- in one case and C- b13 in another).

* Having a way to format chord symbols and alterations in different ways
(stacked vertically vs horizontally, and in what order)

I think that gathering these use cases will be the most valuable part of
the process, since what I read in the proposal is a little vague, and
greatly overlaps with existing functionality.

Which is to say, I disagree that "the first action that will take place is
planning, designing, and implementing the modifications to EventChord"
because lacking clear use cases, how will you know what a good
representation is?

Some of the examples above point to additional modeling that is not present
in your proposal.  (Although perhaps this could be done with your existing
proposed model plus some business logic.)



"One specific result of this is a simpler and more powerful process of
chord naming, being able to name much more complex chords than it is
currently able to."

I'm not sure that "the process of chord naming" needs to be simpler, or
could be made simpler.

Most of the properties of the internal representation you suggest (root,
quality and extensions, voicing/inversion/bass note) are already
represented clearly in the input syntax.

The only property you mention that isn't explicit in the chord input syntax
is the scale degree.  However, if you have set a key signature, then the
scale degree could be said to be fully determined.

On the other hand, when doing functional analysis of modulations, there are
typically cases where a few chords should be analyzed with

GSoC project selection

2017-04-03 Thread Urs Liska 
Hi all,

as I've mentioned in my previous post we have to do the project
selection privately. I will write to the "affected" potential mentors
privately. Whoever is interested in participating in this discussion can
write me privately to join the loop.

Best
Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

GSoC applications have been finalized

2017-04-03 Thread Urs Liska 
To all who have submitted final applications for LilyPond/Frescobaldi:

The submission deadline has been closed today (and it is a hard
deadline). The next steps will be

  * We will review the applications
  * We match projects with mentors, then
  * apply for slots
  * Later we will be assigned a number of slots
  * Based on this number we will finally select students
  * On May 4 the accepted students are announced.

So until May 4 we are not allowed to say anything about your chances of
success, so please be patient.

This doesn't rule out any communication, we just can't leak anything
that is interesting to you.

Best for now
Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: Improve internal chord structure

2017-04-03 Thread Urs Liska 


Am 03.04.2017 um 20:05 schrieb Renato Fabbri:
> ok, I revised the proposal:
> https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
> it is better now with many writing corrections but also with some better
> exposition of ideias.
> All the changes were minor, but if you know a way for us to upload this
> updated version of the proposal,
> it might be .worth it.

The GSoC program rules explicitly state that we must not consider any
changes applied to the draft document but base our judgment on the final
PDF version.

This is not to say that the potential mentor will not be influenced by
such changes ;-)

Urs

>
> Best,
>
> On Mon, Apr 3, 2017 at 1:05 PM, Renato Fabbri 
> wrote:
>
>> I took all your observations in account (thanks!) and wrote a proposal:
>> https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-
>> 5tOb6rUFNnEIqc/edit?usp=sharing
>> It is submitted to the GSoC interface.
>> Is closing time for the proposals, so I should only be able to enhance
>> this draft.
>> I should read it again soon and make minor corrections, for example.
>>
>> Best and Thanks once more!
>>
>> On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup  wrote:
>>
>>> Carl Sorensen  writes:
>>>
 On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
  wrote:

> Ok, I looked through the LilyPond code.
>
> Notes:
> *) There seems to be some emphasis on the perspective given in the book
> Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
> Can someone send me a PDF of this book or know how can I find
> an online copy at least of the most important parts for this case?
 I do not have a PDF or a reference.  But I think that the emphasis on
 Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
 chords.  So do Brandt and Roemer.  Lilypond should be able to support
 anybody's view, not just one person's.

> *) Just so I (and other proponents) get it very clear, what do we need
> beyond our current capability exposed in the snippet:
> http://git.savannah.gnu.org/cgit/lilypond.git/tree/
> Documentation/snippets/chord-name-exceptions.ly
 This capability reflects the current state of LilyPond's chord naming
 structure, which is to try to guess the name of the chord by analyzing
 pitches.  So if you want to define a new chord name, you do it by
 defining the list of pitches in the chord.  It's doable, but the chord
 itself doesn't carry any semantic information.
>>> Except when it does.  Music properties "inversion", "octavation", "bass"
>>> carry semantic information beyond the chord pitch.
>>>
 The proposal is to put the necessary information describing the
 semantics of the chord in the chord itself, rather than trying to
 recreate it from the notes present in the chord.
>>> I am not saying that the current semantic information attached to chords
>>> by the \chordmode parser is suitable for all purposes and/or
>>> defined/utilized/documented to the best possible degree.
>>>
>>> But ignoring it would make for an awkward start.
>>>
 Here's an old proposal that never made it to application:
 https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html

 Here's an interesting discussion on chord names that addresses a
>>> suspended
 chord:
 https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html

 Here's another thread that shows problems with chord naming:
 https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html

 Here's an email discussing another possible benefit of the approach:
 https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html

 And another discussion of some of the challenges:
 https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html

 Here's one that actually started the thinking for the GSOC project:
 https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html

 Somehow the last thread got broken; here's the follow up:
 https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html

 I hope this is helpful.
>>> Certainly something to look through.
>>>
>>> --
>>> David Kastrup
>>>
>>
>>
>> --
>> Renato Fabbri
>> GNU/Linux User #479299
>> labmacambira.sourceforge.net
>>
>
>

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: Improve internal chord structure

2017-04-03 Thread Renato Fabbri 
ok, I revised the proposal:
https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
it is better now with many writing corrections but also with some better
exposition of ideias.
All the changes were minor, but if you know a way for us to upload this
updated version of the proposal,
it might be .worth it.

Best,

On Mon, Apr 3, 2017 at 1:05 PM, Renato Fabbri 
wrote:

> I took all your observations in account (thanks!) and wrote a proposal:
> https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-
> 5tOb6rUFNnEIqc/edit?usp=sharing
> It is submitted to the GSoC interface.
> Is closing time for the proposals, so I should only be able to enhance
> this draft.
> I should read it again soon and make minor corrections, for example.
>
> Best and Thanks once more!
>
> On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup  wrote:
>
>> Carl Sorensen  writes:
>>
>> > On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
>> > > > renato.fab...@gmail.com> wrote:
>> >
>> >>Ok, I looked through the LilyPond code.
>> >>
>> >>Notes:
>> >>*) There seems to be some emphasis on the perspective given in the book
>> >>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
>> >>Can someone send me a PDF of this book or know how can I find
>> >>an online copy at least of the most important parts for this case?
>> >
>> > I do not have a PDF or a reference.  But I think that the emphasis on
>> > Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
>> > chords.  So do Brandt and Roemer.  Lilypond should be able to support
>> > anybody's view, not just one person's.
>> >
>> >>
>> >>*) Just so I (and other proponents) get it very clear, what do we need
>> >>beyond our current capability exposed in the snippet:
>> >>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
>> >>Documentation/snippets/chord-name-exceptions.ly
>> >
>> > This capability reflects the current state of LilyPond's chord naming
>> > structure, which is to try to guess the name of the chord by analyzing
>> > pitches.  So if you want to define a new chord name, you do it by
>> > defining the list of pitches in the chord.  It's doable, but the chord
>> > itself doesn't carry any semantic information.
>>
>> Except when it does.  Music properties "inversion", "octavation", "bass"
>> carry semantic information beyond the chord pitch.
>>
>> > The proposal is to put the necessary information describing the
>> > semantics of the chord in the chord itself, rather than trying to
>> > recreate it from the notes present in the chord.
>>
>> I am not saying that the current semantic information attached to chords
>> by the \chordmode parser is suitable for all purposes and/or
>> defined/utilized/documented to the best possible degree.
>>
>> But ignoring it would make for an awkward start.
>>
>> > Here's an old proposal that never made it to application:
>> > https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
>> >
>> > Here's an interesting discussion on chord names that addresses a
>> suspended
>> > chord:
>> > https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
>> >
>> > Here's another thread that shows problems with chord naming:
>> > https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
>> >
>> > Here's an email discussing another possible benefit of the approach:
>> > https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
>> >
>> > And another discussion of some of the challenges:
>> > https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
>> >
>> > Here's one that actually started the thinking for the GSOC project:
>> > https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
>> >
>> > Somehow the last thread got broken; here's the follow up:
>> > https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
>> >
>> > I hope this is helpful.
>>
>> Certainly something to look through.
>>
>> --
>> David Kastrup
>>
>
>
>
> --
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net
>



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

2017-04-03 Thread dak 

On 2017/04/03 17:39:55, pkx166h wrote:

Fails make doc.



https://codereview.appspot.com/320820043/diff/20001/ly/music-functions-init.ly

File ly/music-functions-init.ly (right):



https://codereview.appspot.com/320820043/diff/20001/ly/music-functions-init.ly#newcode2007

ly/music-functions-init.ly:2007: \\voicify 1,2,3 << @dots {} 

@dots {} 

@dots {} >>
The white space between the macro @dots and the two braces causes make

doc to

fail.


In my defense, make info worked fine.  Texinfo's various backends
apparently have some weird differences.  Will fix.

https://codereview.appspot.com/320820043/

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

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

2017-04-03 Thread pkx166h 

Fails make doc.


https://codereview.appspot.com/320820043/diff/20001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

https://codereview.appspot.com/320820043/diff/20001/ly/music-functions-init.ly#newcode2007
ly/music-functions-init.ly:2007: \\voicify 1,2,3 << @dots {}  @dots
{}  @dots {} >>
The white space between the macro @dots and the two braces causes make
doc to fail.

https://codereview.appspot.com/320820043/

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

Re: Improve internal chord structure

2017-04-03 Thread Renato Fabbri 
I took all your observations in account (thanks!) and wrote a proposal:
https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
It is submitted to the GSoC interface.
Is closing time for the proposals, so I should only be able to enhance this
draft.
I should read it again soon and make minor corrections, for example.

Best and Thanks once more!

On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup  wrote:

> Carl Sorensen  writes:
>
> > On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
> >  > renato.fab...@gmail.com> wrote:
> >
> >>Ok, I looked through the LilyPond code.
> >>
> >>Notes:
> >>*) There seems to be some emphasis on the perspective given in the book
> >>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
> >>Can someone send me a PDF of this book or know how can I find
> >>an online copy at least of the most important parts for this case?
> >
> > I do not have a PDF or a reference.  But I think that the emphasis on
> > Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
> > chords.  So do Brandt and Roemer.  Lilypond should be able to support
> > anybody's view, not just one person's.
> >
> >>
> >>*) Just so I (and other proponents) get it very clear, what do we need
> >>beyond our current capability exposed in the snippet:
> >>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
> >>Documentation/snippets/chord-name-exceptions.ly
> >
> > This capability reflects the current state of LilyPond's chord naming
> > structure, which is to try to guess the name of the chord by analyzing
> > pitches.  So if you want to define a new chord name, you do it by
> > defining the list of pitches in the chord.  It's doable, but the chord
> > itself doesn't carry any semantic information.
>
> Except when it does.  Music properties "inversion", "octavation", "bass"
> carry semantic information beyond the chord pitch.
>
> > The proposal is to put the necessary information describing the
> > semantics of the chord in the chord itself, rather than trying to
> > recreate it from the notes present in the chord.
>
> I am not saying that the current semantic information attached to chords
> by the \chordmode parser is suitable for all purposes and/or
> defined/utilized/documented to the best possible degree.
>
> But ignoring it would make for an awkward start.
>
> > Here's an old proposal that never made it to application:
> > https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
> >
> > Here's an interesting discussion on chord names that addresses a
> suspended
> > chord:
> > https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
> >
> > Here's another thread that shows problems with chord naming:
> > https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
> >
> > Here's an email discussing another possible benefit of the approach:
> > https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
> >
> > And another discussion of some of the challenges:
> > https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
> >
> > Here's one that actually started the thinking for the GSOC project:
> > https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
> >
> > Somehow the last thread got broken; here's the follow up:
> > https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
> >
> > I hope this is helpful.
>
> Certainly something to look through.
>
> --
> David Kastrup
>



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Improve internal chord structure

2017-04-03 Thread David Kastrup 
Carl Sorensen  writes:

> On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
>  renato.fab...@gmail.com> wrote:
>
>>Ok, I looked through the LilyPond code.
>>
>>Notes:
>>*) There seems to be some emphasis on the perspective given in the book
>>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
>>Can someone send me a PDF of this book or know how can I find
>>an online copy at least of the most important parts for this case?
>
> I do not have a PDF or a reference.  But I think that the emphasis on
> Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
> chords.  So do Brandt and Roemer.  Lilypond should be able to support
> anybody's view, not just one person's.
>
>>
>>*) Just so I (and other proponents) get it very clear, what do we need
>>beyond our current capability exposed in the snippet:
>>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
>>Documentation/snippets/chord-name-exceptions.ly
>
> This capability reflects the current state of LilyPond's chord naming
> structure, which is to try to guess the name of the chord by analyzing
> pitches.  So if you want to define a new chord name, you do it by
> defining the list of pitches in the chord.  It's doable, but the chord
> itself doesn't carry any semantic information.

Except when it does.  Music properties "inversion", "octavation", "bass"
carry semantic information beyond the chord pitch.

> The proposal is to put the necessary information describing the
> semantics of the chord in the chord itself, rather than trying to
> recreate it from the notes present in the chord.

I am not saying that the current semantic information attached to chords
by the \chordmode parser is suitable for all purposes and/or
defined/utilized/documented to the best possible degree.

But ignoring it would make for an awkward start.

> Here's an old proposal that never made it to application:
> https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
>
> Here's an interesting discussion on chord names that addresses a suspended
> chord: 
> https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
>
> Here's another thread that shows problems with chord naming:
> https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
>
> Here's an email discussing another possible benefit of the approach:
> https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
>
> And another discussion of some of the challenges:
> https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
>
> Here's one that actually started the thinking for the GSOC project:
> https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
>
> Somehow the last thread got broken; here's the follow up:
> https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
>
> I hope this is helpful.

Certainly something to look through.

-- 
David Kastrup

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

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

2017-04-03 Thread lemzwerg 

Very nice!

https://codereview.appspot.com/320820043/

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

PATCHES - Countdown for April 3rd

2017-04-03 Thread James 
Hello,

Here is the current patch countdown list. The next countdown will be on
April 6th.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/




Push:

5108 Let configure find all needed files with guile-2.2 - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/5108
http://codereview.appspot.com/320800043


Countdown:


5109 Allow 'staff-padding to work with MeasureCounter - David Nalesnik
https://sourceforge.net/p/testlilyissues/issues/5109
http://codereview.appspot.com/312580043


5111 Implement spacing-pair for MeasureCounter - David Nalesnik
https://sourceforge.net/p/testlilyissues/issues/5111
http://codereview.appspot.com/319610043


Review:


5113 Parser: discriminate quoted and non-quoted strings - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5113
http://codereview.appspot.com/316430043


5112 web: move Google Summer of Code information in included/ -
Federico Bruni https://sourceforge.net/p/testlilyissues/issues/5112
http://codereview.appspot.com/321830043


New: No new patches at this time.


Regards


James

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