Re: Back in the Pond

2017-06-05 Thread Trevor Daniels
Hi David

Thanks for the update.

You wrote Monday, May 29, 2017 9:56 PM

> Gianmaria Lari  writes:
>>
>> what's the better way to give a financial contribution?
> 
> In Europe's EURO zone (guessing from your name, that would likely be the
> case) SEPA transfers are usually easiest (account number on request) as
> the fees must not exceed in-country EUR transfers.  U.S. and U.K. and a
> number of other countries get fewer fees via Paypal (this mail address
> works fine).

I recently made my usual (small) monthly contribution.  Hope it helps
a little.

> But even with some distractions being off-limits now, at the rate I am
> being able to focus on complex tasks, I expect to be able to only
> contribute lightly to LilyPond's progress in the next month or so.  Not
> a whole lot of bang for the buck I am afraid.

No problem.  It is more important ATM to concentrate on regaining
as much control over your body as possible.
 
> At least apart from the head/neck ache and from the necessity for
> physical exercise and keeping my blood pressure at tiresome levels, my
> intelligence has not taken a hit: it's really mostly damaged wiring to
> various body parts that I have to work with here.  But of course I need
> to get the body back into a shape where I get along with moderate effort
> in order not to take further hits to my bodily health.

It's excellent news that your intelligence is still intact.

> In a nutshell: I'd appreciate support but it will be a bit of time
> before I deliver good value for it again.

We can wait.  We're all rooting for your full recovery!

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Back in the Pond

2017-05-29 Thread David Kastrup
Gianmaria Lari  writes:

> Trevor wrote:
>
>
>> I'll definitely turn on my financial contribution again.
>>
>
> what's the better way to give a financial contribution?

In Europe's EURO zone (guessing from your name, that would likely be the
case) SEPA transfers are usually easiest (account number on request) as
the fees must not exceed in-country EUR transfers.  U.S. and U.K. and a
number of other countries get fewer fees via Paypal (this mail address
works fine).  However, I have to warn that I expect not to do a whole
lot for LilyPond in the next month or so.  I should have started
physical therapy this week but the respective clinic is booked out and I
enquired elsewhere.

The social worker dealing with my case is apparently spreading herself a
bit thin, so I need to improve my tactics.

In other news, I am currently doing my shopping/transportation basically
by foot which is taking its time but is safest for me and other traffic
parties.

And I'm having semi-permanent neck/head ache making focusing harder.
Control over my larynx is not exactly good: swallowing still
occasionally goes bad.  The right vocal fold is mostly paralyzed in
closed position yet and if it doesn't become accessible in a reasonable
amount of time, I'll probably eventually no longer be able to sing alto.
That's currently troubling me more than not being able to tell
heat/cold/pain on my left body side.

But even with some distractions being off-limits now, at the rate I am
being able to focus on complex tasks, I expect to be able to only
contribute lightly to LilyPond's progress in the next month or so.  Not
a whole lot of bang for the buck I am afraid.

At least apart from the head/neck ache and from the necessity for
physical exercise and keeping my blood pressure at tiresome levels, my
intelligence has not taken a hit: it's really mostly damaged wiring to
various body parts that I have to work with here.  But of course I need
to get the body back into a shape where I get along with moderate effort
in order not to take further hits to my bodily health.

In a nutshell: I'd appreciate support but it will be a bit of time
before I deliver good value for it again.

All the best

David

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-20 Thread David Kastrup
David Kastrup  writes:

> David Kastrup  writes:
>
>> Alexander Kobel  writes:
>>
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>>
>> Uh, I thought that people replaced extenders right now?
>>
>>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>>> not motivate any supporters yet.
>>
>> The container context issue would want to be tackled by a melisma
>> translator (working both in Midi and PDF since we want the same results
>> there).  That work is unfinished and somewhat pervasive.  So it's a bit
>> unlikely for 2.20.
>
> I have to grudgingly admit though that picking up the pieces of the
> melisma translator would be rather more appropriate for 2.20 (as it
> wraps up half-finished functionality already in LilyPond) than working
> on arbitrary-precision support.
>
> Well, I'll have to take another look to see what got me stuck last time
> around.

Ugh, now I remember.  The Melisma_translator needs to work reliably in
Midi.  For this it needs to know where slurs start and end.  But the
complex logic matching slur starts and ends based on spanner-id actually
is buried in the slur-engraver and works with actual spanners (some kind
of grob).  Which means that its logic is just not accessible to the
Melisma_translator and would need to get duplicated.

That's where I ran into molasses.

Taking this up where I left it with a fresh mind now, I think that the
best course would be having a Spanner_connect_translator not working
with grobs/spanners but rather the originating events and tieing _those_
together based on values of spanner-id.

Great idea.  Which would totally throw at least half a spanner in the
works of the (almost complete?) multiple-spanner GSoC project.  Which
has already triggered (committed) changes in spanner-id user interfaces
and organisation but those would survive.

This sucks.  I'll have to brood somewhat more over it.

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-20 Thread Alexander Kobel
On 2017-01-20 10:46, David Kastrup wrote:
> Knut Petersen  writes:
> 
>> Hi everybody!
>>
 +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
 ... } has the potential to be a killer feature w.r.t. usability for
 choir literature (especially combined with the upcoming automatic
 extenders). Unfortunately, assignment of lyrics to *container*
 contexts does not work (at least, not reliably), and extender
 generation is completely defunct.
>>> Uh, I thought that people replaced extenders right now?
>> Well, may I cite the notation manual:
>>
>> "extender lines cannot be drawn when there is no associated voice."
>>
>> The autoextender patch only adds extenders at places where extenders
>> can be added without it.
> 
> That does not sound like we should remove __ from lyrics to me.

That already proved to be a source of endless misinterpretations, so be careful 
to complain... ;-)

Two-line summary:
1. (What used to be) __ is added *everywhere.*
2. *Processing (printing)* of LyricExtenders changed such that only the 
extenders you expect to appear are drawn by default.

Because of 1. it would be rather surprising if the need arises to add it 
manually ever again, and thus it should be safe to deprecate and ignore the 
token.
W.r.t. 2., I think all reasonable use cases are covered. If, however, you have 
any example of lyrics without associated voice, where extenders are required 
and working with the old __, please raise your voice now. I can't imagine that. 
(BTW, this has absolutely nothing to do with the \lyricsto ... = ... { ... } 
issue per se. It's just that both are a tremendous simplification for choral 
scores.)


Cheers,
Alexander

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


Re: Back in the Pond

2017-01-20 Thread Knut Petersen

The autoextender patch only adds extenders at places where extenders
can be added without it.

That does not sound like we should remove __ from lyrics to me.


I don't understand that comment.


With the autoextender patch there will be an extender if a melisma is

detected and there is enough place for an extender.


At places where an extender token "__" is/would be ignored by current master

(that's the problem Alexander describes) the autoextender patch does not

change anything.


Knut




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


Re: Back in the Pond

2017-01-20 Thread Alexander Kobel
Hi (almost) everybory (dropping -user)!

On 2017-01-20 10:20, Knut Petersen wrote:
> Hi everybody!
> 
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>> Uh, I thought that people replaced extenders right now?
> Well, may I cite the notation manual:
> 
> "extender lines cannot be drawn when there is no associated voice."
> 
> The autoextender patch only adds extenders at places where extenders can be 
> added without it.

Good catch. From what I spotted, the missing piece is indeed the association 
between lyrics and voices. Note that it's not just extenders that are broken: 
I'm not entirely confident whether the lyrics placement is what it is supposed 
to be, in case there are different rhythms within a container context and 
outside. At least IIUC the searchForVoice and associatedVoice{,Type,Context} 
properties.

As soon as there is an associated voice (e.g., through the searchForVoice 
algorithm), extenders /are/ drawn. The problem with that approach: AFAICS it is 
not possible to restrict the search to a certain context. E.g., for 
ChoirStaves, you'd only want the search to extend to Voices that are 
(currently) printed on some Staff that is part of the ChoirStaff.
For scores that only consist of one ChoirStaff, the workaround I gave in the 
other thread actually works.

IIUC, the melisma translator you are talking about would ensure that moments 
are skipped where all candidate associated voices have melisma_busy? That's 
another useful feature, obviously, but AFAICS the lyric-voice-correspondence 
should be somewhat independent.
Anyway, I'll stop handwaving and speculating here without a good cause. If you 
want me to proceed, you know where to find me...

> Prior to Alexanders bugreport I wasn't even aware that something like 
> \lyricsto ChoirStaff ... could work.
> If we get it to work it might be a good idea to document the feature in the 
> notation manual.

Yes. In fact, Trevor already mentioned that he will at least modify the SATB 
template to use that feature and document it there. But obviously, once 
everything is reliable, NR 2.1.2 "Polyphony with shared lyrics" could be 
simplified drastically, with the current docs merely an emergency or special 
purpose option...

>>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>>> not motivate any supporters yet.
> 
> I verified that the changes made by the autoextender patch are unrelated
> but decided that probably the person who added the feature is the most
> obvious candidate to fix it ;-)

To make sure: this wasn't a complaint about lack of interest from my side. And 
yes, I also double-checked that the auto extenders aren't the culprit...

> Currently I work on  LyricHyphen enhancements. After I know if the 
> autoextender
> patch will be accepted I'll send a patch that will implement the following 
> features: [...]

Whoo! Nice!


Cheers,
Alexander

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


Re: Back in the Pond

2017-01-20 Thread David Kastrup
Knut Petersen  writes:

> Hi everybody!
>
>>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>> Uh, I thought that people replaced extenders right now?
> Well, may I cite the notation manual:
>
> "extender lines cannot be drawn when there is no associated voice."
>
> The autoextender patch only adds extenders at places where extenders
> can be added without it.

That does not sound like we should remove __ from lyrics to me.

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-20 Thread David Kastrup
David Kastrup  writes:

> Alexander Kobel  writes:
>
>> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>> ... } has the potential to be a killer feature w.r.t. usability for
>> choir literature (especially combined with the upcoming automatic
>> extenders). Unfortunately, assignment of lyrics to *container*
>> contexts does not work (at least, not reliably), and extender
>> generation is completely defunct.
>
> Uh, I thought that people replaced extenders right now?
>
>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>> not motivate any supporters yet.
>
> The container context issue would want to be tackled by a melisma
> translator (working both in Midi and PDF since we want the same results
> there).  That work is unfinished and somewhat pervasive.  So it's a bit
> unlikely for 2.20.

I have to grudgingly admit though that picking up the pieces of the
melisma translator would be rather more appropriate for 2.20 (as it
wraps up half-finished functionality already in LilyPond) than working
on arbitrary-precision support.

Well, I'll have to take another look to see what got me stuck last time
around.

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-20 Thread Knut Petersen

Hi everybody!


+1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
... } has the potential to be a killer feature w.r.t. usability for
choir literature (especially combined with the upcoming automatic
extenders). Unfortunately, assignment of lyrics to *container*
contexts does not work (at least, not reliably), and extender
generation is completely defunct.

Uh, I thought that people replaced extenders right now?

Well, may I cite the notation manual:

"extender lines cannot be drawn when there is no associated voice."

The autoextender patch only adds extenders at places where extenders can be 
added without it.

Prior to Alexanders bugreport I wasn't even aware that something like \lyricsto 
ChoirStaff ... could work.
If we get it to work it might be a good idea to document the feature in the 
notation manual.


I reported that in a thread from 2016-12-26 on bug-lilypond, but could
not motivate any supporters yet.


I verified that the changes made by the autoextender patch are unrelated
but decided that probably the person who added the feature is the most
obvious candidate to fix it ;-)

Currently I work on  LyricHyphen enhancements. After I know if the autoextender
patch will be accepted I'll send a patch that will implement the following 
features:

1: use either a rounded box or an arbitrary markup as a hyphen. Solves issue 
#1255.

2: allow to whiteout every hyphen individually instead of the whole set of 
hyphens
 generated for a HyphenEvent (Yes, I know that some people do not like that)

3: allow minimum distance to be automatically set to the with of the hyphen 
stencil.

4: Improved placement of hyphens:
4a: If the spanner starts at the beginning of a system, place the first hyphen
at the start of the system.
4b: If the spanner ends at the end of the system, place the last hyphen at the 
end of
the system
4c: If neither 4a nor 4b apply: In cases where the old code uses n hyphens  use 
n+1
hyphens if enough place between the first/last syllable and the hyphens remain.
'Enough place' might be changed by a property.

Feature 4 gives much better results if there are multiple stanzas.

I think that these proposed changes could also be a something worth to be
integrated in a lilypond 2.20.

Knut

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


Re: Back in the Pond

2017-01-20 Thread David Kastrup
Graham Percival  writes:

> On Thu, Jan 19, 2017 at 02:01:40PM +0100, David Kastrup wrote:
>> "Trevor Daniels"  writes:
>> 
>> > David, you wrote Thursday, January 19, 2017 10:18 AM
>> >
>> >> it would appear that my excursion into a regular workplace ended up
>> >> somewhat shortlived.
>
> Ouch, that sucks.  :(
>
>> Well, the 2.20 release stoppers of course should be tackled.  Step 1
>> IIRC was to contact the persons last having worked on three issues you
>> identified.  Uhm, I'd be glad to leave that in Graham's hand, at least
>> until it's clear that addressing those issues will have to be done by
>> somebody else.
>
> Right, I haven't forgotten, but I likely won't get to this until
> Feb.  I've had a poor (and rare) reaction to some recent
> vaccinations [1], and lost most of 5 days in the past two weeks.

That sucks.  I hope "lost to productive work" rather than "no longer
accessible to my memory": I find the latter ailment more scary though
either is a nuisance.

> I'm not certain how much energy I'll have after catching up on
> work, and getting some work done for a Feb 4 board meeting for an
> (offline) amateur music organization.

Understood.  I'll give it a try then.

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-19 Thread David Kastrup
Alexander Kobel  writes:

> +1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
> ... } has the potential to be a killer feature w.r.t. usability for
> choir literature (especially combined with the upcoming automatic
> extenders). Unfortunately, assignment of lyrics to *container*
> contexts does not work (at least, not reliably), and extender
> generation is completely defunct.

Uh, I thought that people replaced extenders right now?

> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
> not motivate any supporters yet.

The container context issue would want to be tackled by a melisma
translator (working both in Midi and PDF since we want the same results
there).  That work is unfinished and somewhat pervasive.  So it's a bit
unlikely for 2.20.

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-19 Thread Graham Percival
On Thu, Jan 19, 2017 at 02:01:40PM +0100, David Kastrup wrote:
> "Trevor Daniels"  writes:
> 
> > David, you wrote Thursday, January 19, 2017 10:18 AM
> >
> >> it would appear that my excursion into a regular workplace ended up
> >> somewhat shortlived.

Ouch, that sucks.  :(

> Well, the 2.20 release stoppers of course should be tackled.  Step 1
> IIRC was to contact the persons last having worked on three issues you
> identified.  Uhm, I'd be glad to leave that in Graham's hand, at least
> until it's clear that addressing those issues will have to be done by
> somebody else.

Right, I haven't forgotten, but I likely won't get to this until
Feb.  I've had a poor (and rare) reaction to some recent
vaccinations [1], and lost most of 5 days in the past two weeks.
I'm not certain how much energy I'll have after catching up on
work, and getting some work done for a Feb 4 board meeting for an
(offline) amateur music organization.

[1] I don't regret getting the vaccinations, since it's an
important public health issue and most people with whom I go
ballroom dancing are seniors.  For me personally, I'd be willing
to take my chances with the flu or even MMR, but for the elderly
those illnesses could well be fatal.  I just wish that I'd had a
better idea that I'd be one of the unusual people who have bad
side effects.  :(

Cheers,
- Graham

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


Re: Back in the Pond

2017-01-19 Thread Alexander Kobel

Hi David,

On 2017-01-19 12:59, Trevor Daniels wrote:

David, you wrote Thursday, January 19, 2017 10:18 AM


it would appear that my excursion into a regular workplace ended up

somewhat shortlived.

Really sorry to hear that, but it's great to have you back!


Ditto.  I wish that you would have had better luck with that endeavor...


So for the short time range, I am again dependent
on support by other LilyPond lovers.


I'll definitely turn on my financial contribution again.


Ditto, although it's just a drop in a mostly empty bucket...


So what's next on my agenda?
[...]
And, of course, this is an opportunity to try putting out the 2.20
release finally.


Definitely the top priority, IMO.


+1.  A personal wish: I think that \lyricsto ChoirStaff = "ctx" { ... } 
has the potential to be a killer feature w.r.t. usability for choir 
literature (especially combined with the upcoming automatic extenders). 
Unfortunately, assignment of lyrics to *container* contexts does not 
work (at least, not reliably), and extender generation is completely 
defunct. I reported that in a thread from 2016-12-26 on bug-lilypond, 
but could not motivate any supporters yet.


I saw a comment by you that you are aware of the issue; can't remember 
where, it was at some point during my (unsuccessful) debugging streak 
for the problem - might well be a very old comment in the issue tracker 
or a commit message or the like.  May I kindly ask you to have a look 
and think about whether this might be tackleable before 2.20?  I have no 
good intuition for the complexity of this issue; the *specification* 
part should be reasonably simple (which syllable corresponds to which 
note(s)), but I don't know what kind of difficulties the current design 
presents for actually coding it.



Cheers,
Alexander

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


Re: Back in the Pond

2017-01-19 Thread Gianmaria Lari
Trevor wrote:


> I'll definitely turn on my financial contribution again.
>

what's the better way to give a financial contribution?
g.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Back in the Pond

2017-01-19 Thread Simon Albrecht

On 19.01.2017 14:01, David Kastrup wrote:

it is an open question whether it makes sense to admit it
into 2.20.0 (or was the first version 2.20.1)


We had 2.18.0 and 2.18.2.
Best, Simon

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


Re: Back in the Pond

2017-01-19 Thread David Kastrup
"Trevor Daniels"  writes:

> David, you wrote Thursday, January 19, 2017 10:18 AM
>
>> it would appear that my excursion into a regular workplace ended up
>> somewhat shortlived.
>
> Really sorry to hear that, but it's great to have you back!
>
>> So for the short time range, I am again dependent 
>> on support by other LilyPond lovers.
>
> I'll definitely turn on my financial contribution again.

Very much appreciated.

>> So what's next on my agenda?  
>>
>> One somewhat long-standing goal was to remove LilyPond's own
>> implementation of a Rational data type and replace it by one based on
>> Guile's arbitrary-precision arithmetic.
>
> Worthwhile, but best left for 2.21 I think.

Well, the 2.20 release stoppers of course should be tackled.  Step 1
IIRC was to contact the persons last having worked on three issues you
identified.  Uhm, I'd be glad to leave that in Graham's hand, at least
until it's clear that addressing those issues will have to be done by
somebody else.

And the Moment/Rational/Midi-gc stuff is already in reasonable state of
progress in private branches so I don't want to let it get cold.

But of course it is an open question whether it makes sense to admit it
into 2.20.0 (or was the first version 2.20.1).  More likely than not,
not.  So that already gives an incentive for branching off the 2.20
release branch very soon.

>> I am glad that I'll be able to provide technical support and
>> expertise at least for a while and thus hopefully help Graham pick up
>> the reins of the overall project governance a bit better.
>
> Excellent!
>
>> And, of course, this is an opportunity to try putting out the 2.20
>> release finally.
>
> Definitely the top priority, IMO.
>
>> But at any rate, I hope to be on board at least for making LilyPond 2.20
>> a thing.
>
> :)
>
> Trevor

-- 
David Kastrup

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


Re: Back in the Pond

2017-01-19 Thread Trevor Daniels

David, you wrote Thursday, January 19, 2017 10:18 AM

> it would appear that my excursion into a regular workplace ended up
somewhat shortlived.

Really sorry to hear that, but it's great to have you back!

> So for the short time range, I am again dependent 
> on support by other LilyPond lovers.

I'll definitely turn on my financial contribution again.

> So what's next on my agenda?  
>
> One somewhat long-standing goal was to remove LilyPond's own
> implementation of a Rational data type and replace it by one based on
> Guile's arbitrary-precision arithmetic.

Worthwhile, but best left for 2.21 I think.
 
> I am glad that I'll be able to provide technical support and expertise
> at least for a while and thus hopefully help Graham pick up the reins of
> the overall project governance a bit better.

Excellent!

> And, of course, this is an opportunity to try putting out the 2.20
> release finally.  

Definitely the top priority, IMO.

> But at any rate, I hope to be on board at least for making LilyPond 2.20
> a thing.

:)

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


Re: Back in the Pond

2017-01-19 Thread Urs Liska
Hi David,


Am 19.01.2017 um 11:18 schrieb David Kastrup:
> But at any rate, I hope to be on board at least for making LilyPond 2.20
> a thing.

to cut your long story even shorter: sad but glad to read that.
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