Re: [testlilyissues:issues] Ticket 3960 discussion

[Trevor Daniels]

James wrote: Wednesday, October 18, 2017 11:54 AM

>- **status**: Started --> Invalid
> - **Patch**: needs_work -->  
> - **Comment**:
> 
> Revisiting this, the example given at the start of this issue
> 
> http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
> 
> has no corresponding entry at all in the 2.19 documentation. In fact the 
> entire NR 4.x section is completely different.
> 
> The example in the 2.18 is for overriding when LilyPond doesn't honour a 
> manual `\break` or `\pagebreak` command by using 
> `NonMusicalPaperColumn.line-break-permission` overrides. The 2.19 doc doesn't 
> mention any example or even snippet. It does have one mention about 
> `line-break-permission` but only in the context of what the setting does and 
> what its defaults are.

This section was changed significantly in Oct 2014when the various 
\auto..breaks.. commands were installed.  See

https://sourceforge.net/p/testlilyissues/issues/4169/
 
> So I wonder now if this tracker is still needed.

so marking this invalid is correct.
 
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: Introduction + how/what to contribute?

[Trevor Daniels]

"Koen Samyn" wrote Thursday, September 28, 2017 9:02 AM

Hi and Welcome!

> I am trying to get started with the lilypond source code and see where I
> can contribute, but the documentation links seem out of order, for example
> the following link:
> 
> /doc/v2.21/Documentation/contributor/summary-for-experienced-developers.htm

2.21 has not yet been released.  Try this one:

http://lilypond.org/doc/v2.19/Documentation/contributor/summary-for-experienced-developers
 
> Any pointers you can give me where extra programming help might be required?

You could browse the Issues DB:

https://sourceforge.net/p/testlilyissues/issues/
 
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: How to locate all layout-property values for a particularLayoutObject in the source files?

[Trevor Daniels]

Simon Albrecht wrote Sunday, September 24, 2017 4:34 PM


> On 24.09.2017 14:30, James wrote:
>> Where would I go to see the 'complete list' of all possible NoteHead.style 
>> values
> 
> 
>  
> – the description of the style property isn’t helpful (since it 
> summarises the use of that property in any grob), but at the top of the 
> page there is a link to all the styles.
> 

This links to Appendix A.9 which seems to be incomplete.
For example, it doesn't contain semipetrucci or blackpetrucci,
which differ from petrucci in the longer note values.  Kievan is
missing too.

So part of James' work might be to extend this table too.

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: PATCHES - Countdown for September 10th

[Trevor Daniels]

James wrote Tuesday, September 12, 2017 9:05 AM


> On Mon, 11 Sep 2017 23:24:31 +0200
> Thomas Morley  wrote:
> 
>> for about a month I'm often surprised about new issues/patches etc.
>> I _am_ subscribed to the lilypond-auto mailing-list which should
>> notify me about stuff from the tracker.
>> 
>> Did I miss a recent change?
>> 
>> Thanks,
>>   Harm
>> 
> 
> If you look here:
> 
> http://lists.gnu.org/archive/html/lilypond-auto/
> 
> It seems that the emails stopped 2nd August.
> 
> I wonder if there is some 'spam' setting that has been triggered on the 
> lilypond-auto list?

I'm pleased to say the lilypond-auto mailing list is operational again, thanks 
to excellent help from the SourceForge team.

The problem stemmed from a privacy change around 2 Aug 2017 which required all 
members of the parent list at SourceForge to resubscribe.  This requirement was 
communicated to all members of all SourceForge lists, but for some reason this 
either was not propagated to our lilypond-auto list at gnu.org or we all missed 
it.  As a result mailings from the SF list to the gnu list stopped.

Getting them working again was tricky.  If you're interested you can see the 
story here:
https://sourceforge.net/p/forge/site-support/15567/

You can, of course, subscribe to the SF list directly, cutting out the (now 
dubious) hop via gnu.org, here:
https://sourceforge.net/p/testlilyissues/mailman/

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: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043by karlinh...@gmail.com)

[Trevor Daniels]

Karlin High Wednesday, September 20, 2017 6:46 PM

> On Wed, Sep 20, 2017 at 12:37 PM,   wrote:
>> This is my first effort at making a patch, so I could be doing things wrong.
> 
> I gather I am supposed to request write access to the issue tracker on
> Sourceforge? Username: karlinhigh

Thanks.  You should be good to go now.

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: PATCHES - Countdown for September 10th

[Trevor Daniels]

James wrote Tuesday, September 12, 2017 9:05 AM

> If you look here:
> 
> http://lists.gnu.org/archive/html/lilypond-auto/
> 
> It seems that the emails stopped 2nd August.
> 
> I wonder if there is some 'spam' setting that has been triggered on the 
> lilypond-auto list?

I can't see anything wrong, but the list admin can't see who's subscribed (!), 
only that there are two subscriptions.  Not sure if this secrecy is a recent 
change.

I've resubscribed lilypond-a...@gnu.org to the SF testlilyissues-auto mailing 
list to see if this fixes it.

I see I'm the only administrator for this SF list, which doesn't seem healthy.  
Phil, should I add you?

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: Propose Commit access for Étienne Beaulé

[Trevor Daniels]

James wrote Thursday, September 07, 2017 4:19 PM

> Étienne has pushed couple of patches now and I wondered if we could
> perhaps give him full commit access to git?

Who now has the authority to do this?  I don't, and I've lost track of who does
now that Han-Wen, Jan and Graham are rarely seen on the lists.

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: Issues write access

[Trevor Daniels]

Étienne Beaulé wrote Thursday, August 10, 2017 2:51 AM


> Hello. May I be granted write access on our issue tracker? My username is
> ebe123. Thank you!

Added.  Welcome!

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: Any objections to branching off a stable branch for 2.20?

[Trevor Daniels]

Phil Holmes wrote Tuesday, July 18, 2017 11:07 AM

> Subject: Any objections to branching off a stable branch for 2.20?

> No objections from me towards aiming for a 2.20 stable release.

None from me either.

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: Releasing 2.20

[Trevor Daniels]

David Kastrup wrote Wednesday, June 07, 2017 9:34 PM

> tomorrow I am leaving for physical therapy.

Hope it all goes well for you.

> So I should be able to do some reasonably straightforward work.

Good, but that should not be your priority ATM.
 
> So how is it going to end up?  Barring objections, I'll probably branch
> off a stable release branch early next week.  I'll have to see what to
> cherry-pick into this branch as fixes proceed, and possibly what to
> revert when it is not clear that functionality provided by recent
> patches/changes can be considered stable in use and interface.

Again, good, but ...
 
> I don't think that we should need much more than the 3-week maturing
> period corresponding to the expected physical therapy duration.

Agreed, there seem to be very few reasons to delay.  Presumably it will
be a .0 release anyway, meaning "use cautiously and look out for bugs."
 
> The alternative of releasing 2.18.3 since 2.18.2 does not even compile
> using gcc-7 anymore is something I want to avoid.

Definitely.  There are so many improvements since 2.18 that a major
release is the sensible choice.

> So I'd rather pitch for a timely release of 2.20.  There have been a few
> critical bugs flagged, however.  I'll take a look at them eventually but
> if someone else has a good idea...

We might need to revisit these to see if they really are critical.

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

[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: Merge Rests Engraver

[Trevor Daniels]

Jay Anderson wrote Wednesday, May 17, 2017 7:31 AM

> Thanks. When I ran `git cl upload origin/master` it wasn't able to associate 
> the patch with an issue:

> We were not able to associate this patch with a tracker issue.
> Please enter a valid tracker issue number
> (or enter nothing to create a new issue): 1228
> Problem setting patch status for Allura issue

Did you register git-cl in your account at SourceForge and obtain a bearer 
token?
See "Authorizing git-cl for the LilyPond issue tracker" as the next step in 
configuring git-cl 
in http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

If this is not the problem we'll need Phil to take a look.

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: Calling in for sickness

[Trevor Daniels]

David, you wrote Monday, May 15, 2017 5:42 PM

> had a sort of apoplexy and will not be able to do anything while
> recovering.  I am hospitalized at the moment, CRT and MRT did not show
> any specific anomalies but my right side is hampered and I cannot yet
> swallow or cough which is sort of inconvenient.

Please take things easy for a while and make sure you are fully better
before starting work on LP again.  Your health is more important!

But do keep us informed about your progress back to health.

With my best wishes for a speedy 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: Merge Rests Engraver

[Trevor Daniels]

Hi Jay, you wrote Sunday, May 14, 2017 5:15 AM

> When running git-cl it failed to create a new ticket number to track the
> issue (the instructions say I need to request access:
> http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl#configuring-git_002dcl).
> There is an existing issue (
> https://sourceforge.net/p/testlilyissues/issues/1228/). Let me know what
> more I need to do there. Thanks.

You need to create an account at SourceForge
https://sourceforge.net/user/registration
if you don't already have one, and post your username 
to this list.  We'll then register you as a developer
on the Lily Issues DB, which will permit you to modify
existing and create new Issues.

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: 2.19.59: Bad horizontal spacing when \override LyricText #'X-offset

[Trevor Daniels]

Dmytro O. Redchuk wrote Friday, April 28, 2017 9:10 AM

> please take a look at this MWE:
>
% --- 8< 
\version "2.19.59"

{ r4 a a2 a4 a2 }
\addlyrics {
  \override LyricText #'X-offset = #0
  "Блаженні голодні й спрагнені правди, бо вони на" -- си -- тять -- ся.
}
% --- 8< 
>
> I've attached images for 2.18.2, 2.19.59 and 2.19.59 with no \override.
>
> If I missed something and that spacing should be treated in some
> special way for such rather extreme cases in 2.19?
>
> Or is there any issue/regression?

This seems to be a bug so copying to the bug list.  I don't think this has
been reported before.

The output is correct in 2.18.2 and up to 2.19.9, but wrong from 2.19.10.

The changes in 2.19.10 include Janek's:

   Issue 2462  ab6842155a003ba7d9243507594e3e973ebbb3e4

which directly affects lyrics, but there are several other commits which 
affect horizontal alignment generally.

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: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David Kastrup wrote Sunday, April 09, 2017 5:14 PM
> 
> Harm brought a few points, one concerning different warning/error
> behavior (and with regard to the _text_ of the existing warning, I will
> cede the point thought there isn't yet a proposal for \voices as far as
> I can see).  He also pointed out that this calls for changing more of
> the preexisting documentation.  Again, I'll cede that this would make
> sense but I consider it separate work where I'd be glad that someone
> else would tackle it.

I'm sure someone will pick this up.
 
> So how to proceed?  Formally this patch went through countdown, but for
> one thing I stated that I was going to do a rename anyway, and for
> another, there were several points raised.  I'm just very ambiguous on
> addressing them.  For most of the bike-shedding I lean towards just
> canning it for now since I prefer the current proposal.  For some
> improvement suggestions I'd appreciate more concrete proposals fitting
> with \voices.
> 
> I think I'll upload the current, renamed patch and then wait to see what
> other feedback I feel I can sensibly incorporate.

Sounds good to me.

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: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David Kastrup wrote Friday, April 07, 2017 9:07 PM


> "Trevor Daniels" <t.dani...@treda.co.uk> writes:
> 
>> David, you wrote Thursday, April 06, 2017 4:54 PM
>>
>>> You could try separate commands \voicifyUp and \voicifyDown .  I am not
>>> sure whether or not \voicify should not be \voices or \voicing or
>>> \voicings instead, possibly making for nicer compounds like that.
>>> 
>>> I mean, something like
>>> 
>>> \voices 1,3,4 ...
>>
>> Although you later argued cogently against compounds like \voicesUp I
>> think \voices is a better choice than \voicify anyway, simply because
>> it expresses its operation more clearly (not sure what meaning the word
>> "voicify" would trigger in the mind - in Google it enables voice dictation;
>> in Twitter it applies a filter, for example).  
>>
>> In other words \voices stands better than \voicify on its own merits.
> 
> I'll not stop the countdown for now but am going to commit with this
> change unless we get a conflicting view in which case it would make
> sense to stop the countdown and gather more opinions, possibly from the
> user list.

OK.  Happy to wait to see what others think, or, if there's no further
input, to defer to your preference.
 
> Not sure what to name input/regression/voicify.ly instead, though.
> "voicify.ly" is clearly referring to the command, "voices.ly" is much
> more ambiguous.  But at least it is not taken yet.

Well, lots of the regression tests have compound names.
"reordering-voices-in-parallel-construct.ly or something
similarly descriptive would be fine.

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: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David, you wrote Thursday, April 06, 2017 4:54 PM

> You could try separate commands \voicifyUp and \voicifyDown .  I am not
> sure whether or not \voicify should not be \voices or \voicing or
> \voicings instead, possibly making for nicer compounds like that.
> 
> I mean, something like
> 
> \voices 1,3,4 ...

Although you later argued cogently against compounds like \voicesUp I
think \voices is a better choice than \voicify anyway, simply because
it expresses its operation more clearly (not sure what meaning the word
"voicify" would trigger in the mind - in Google it enables voice dictation;
in Twitter it applies a filter, for example).  

In other words \voices stands better than \voicify on its own merits.

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: Lily version operators documentation

[Trevor Daniels]

Urs Liska wrote Wednesday, February 15, 2017 8:04 AM

> Am 14.02.2017 um 18:27 schrieb Trevor Daniels:
>
>> As these functions are not intended for the usual LilyPond user I
>> don't think the NR is suitable, other than to have them listed in A22.
>> Similarly, they will also be listed in the IR under Scheme functions.
> 
> Are they listed there really?
> I was of the impression that the ly:something functions defined in
> Scheme are *not* documented anywhere.

You're right.  I was misled by the title of A.22 - "Scheme functions".
Having explored how this is generated it seems these are actually
scheme-callable functions written in C++, if I understand it correctly.

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

Re: Lily version operators documentation

[Trevor Daniels]

Urs Liska wrote Tuesday, February 14, 2017 9:23 AM

> my patch https://sourceforge.net/p/testlilyissues/issues/5067/
> http://codereview.appspot.com/317270043 is currently on countdown. It
> introduces the procedures
> 
> - lilypond>?
> - lilypond>=?
> - lilypond - lilypond<=?
> - lilypond=?
> 
> comparing a given version to the one currently compiling the document.
> This makes it possible to write library code supporting multiple
> LilyPond versions across syntax changes.
> 
> My question is: Where can I add documentation for this? Browsing through
> Extending and IR doesn't seem to indicate a suitable place. It *might*
> be fitting somewhere in the "General input and output" of the NR, but
> I'm way from being sure about that either.

As these functions are not intended for the usual LilyPond user I
don't think the NR is suitable, other than to have them listed in A22.
Similarly, they will also be listed in the IR under Scheme functions.

Perhaps the best place to add a description is in Section 2 of the
Usage Manual where convert-ly is discussed?  A new subsection 
2.2 Testing the version (displacing the existing sections down 1)
could be added.  But I concede mixing with convert-ly is hardly ideal.

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

Re: request for LilyPond issue tracker user account

[Trevor Daniels]

Flaming Hakama by Elaine wrote Wednesday, February 08, 2017 9:12 PM


>I endeavored to start contributing to lilypond development.

Great!

> I've been following the steps in the contributor docs, and on the git-cl
> page instructs me:
> 
> http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl
> For the LilyPond issue tracker, please request a user account by sending an
> email to the LilyPond Developer’s mailing list (lilypond-devel@gnu.org),
> preferably using the same email address that you want to use for your user
> login.
> 
> So, I'd like to get a LilyPond issue tracker user account for my email
> ela...@flaminghakama.com

Certainly possible, but that particular instruction is wrong, or at least
incomplete.  What you actually need to do is go to SourceForge:

https://sourceforge.net/p/testlilyissues/issues/

and obtain a user account (unless you already have one) and send me
or post on the Dev list your Username there.  It's the Username I need,
not your email address.

Note: need to correct that para in the CG.

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

Re: Issue 3830: Document \offset command (issue 319150043 bydavid.nales...@gmail.com)

[Trevor Daniels]

david.nales...@gmail.com wrote Tuesday, January 24, 2017 10:57 PM

> Question:
> 
> How do I get a backslash in @subsubsubheading{} ?
> 
> The literal symbol doesn't show up, and @backslashchar{} displays
> @backslashchar{}

>From memory it's @bs{}.

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

Re: Back in the Pond

[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: How to adjust space between ChordNames and Staff?

[Trevor Daniels]

Thomas Morley wrote Friday, January 13, 2017 9:05 PM


> 2017-01-13 17:05 GMT+01:00 Trevor Daniels <t.dani...@treda.co.uk>:
>>
>> Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM
>>
>>> On 13 January 2017 at 01:20, Trevor Daniels <t.dani...@treda.co.uk> wrote:
>>>
>>>> Interesting.  Does that mean the ChordNames and Lyrics contexts behave
>>>> differently wrt the vertical spacing controls when these are placed within 
>>>> a
>>>> \with { } block, since Lyrics can be spaced out that way?
>>>>
>>>> If so, is this intended for some reason ... or a bug?
>>>
>>> Thanks Harm. That did the trick. However, I concur with Trevor about the
>>> confusing difference compared to Lyrics. I assumed that they'd work the
>>> same way so I did not occur to me to try the \layout block. If it /is/ an
>>> intended behaviour, there should probably be a note that the settings
>>> won't work with \with { }.
>>
>> Exactly, but I think we need to understand exactly what the problem is before
>> we can decide (a) whether this _is_ a bug and if so (b) whether it is a 
>> coding or
>> a documentation problem.
>>
>> Copying to bug list so this doesn't get forgotten.
>
> No bug.
> It's \chords vs \chordmode.
>
> \chords (as a shortcut) already created a ChordNames-context, see:
>
> chordStuff = \chords { c1 d:m }
> \void \displayLilyMusic \chordStuff
>
> So if you really want to use \chords you need to put overrides, etc
> into \layout or use
> \chords \with { ... }
> at least with newer devel-versions.
>
> If you use \chordmode you can do
> \new ChordNames \with { ... } \chordmode

Excellent explanation!  Many thanks!

So no bug, but we should add a paragraph somewhere in the NR to make this
clear.  I'll start on that in a day or two.

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

Re: How to adjust space between ChordNames and Staff?

[Trevor Daniels]

Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM

> On 13 January 2017 at 01:20, Trevor Daniels <t.dani...@treda.co.uk> wrote:
>
>> Thomas Morley wrote Thursday, January 12, 2017 10:26 PM
>>
>>> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi <risva...@gmail.com>:
>>>
>>>> The spacing between ChordNames and Staff seems a bit tight by default. I've
>>>> been trying to adjust it but I haven't figured out the right magic words
>>>
>>> Do it in \layout
>>>
>>> chordStuff = \chords { c1 d:m }
>>> melody = \relative c'' { c4 c c c | d d d d }
>>> \score {
>>>  <<
>>>\new ChordNames  { \chordStuff }
>>>\new Staff { \melody }
>>>  >>
>>>  \layout {
>>>  \context {
>>>\ChordNames
>>>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = 
>>> #10
>>>  }
>>>  }
>>> }
>>
>> Interesting.  Does that mean the ChordNames and Lyrics contexts behave
>> differently wrt the vertical spacing controls when these are placed within a
>> \with { } block, since Lyrics can be spaced out that way?
>>
>> If so, is this intended for some reason ... or a bug?
>
> Thanks Harm. That did the trick. However, I concur with Trevor about the 
> confusing difference compared to Lyrics. I assumed that they'd work the 
> same way so I did not occur to me to try the \layout block. If it /is/ an 
> intended behaviour, there should probably be a note that the settings 
> won't work with \with { }.

Exactly, but I think we need to understand exactly what the problem is before
we can decide (a) whether this _is_ a bug and if so (b) whether it is a coding 
or
a documentation problem.

Copying to bug list so this doesn't get forgotten.

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

Re: How to adjust space between ChordNames and Staff?

[Trevor Daniels]

Thomas Morley wrote Thursday, January 12, 2017 10:26 PM


> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi :
>
>> The spacing between ChordNames and Staff seems a bit tight by default. I've
>> been trying to adjust it but I haven't figured out the right magic words
>
> Do it in \layout
> 
> chordStuff = \chords { c1 d:m }
> 
> melody = \relative c'' { c4 c c c | d d d d }
> 
> \score {
>  <<
>\new ChordNames  { \chordStuff }
>\new Staff { \melody }
>  >>
>  \layout {
>  \context {
>\ChordNames
>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #10
>  }
>  }
> }

Interesting.  Does that mean the ChordNames and Lyrics contexts behave 
differently wrt the vertical spacing controls when these are placed within a 
\with { } block, since Lyrics can be spaced out that way? 
 
If so, is this intended for some reason ... or a bug? 

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[Trevor Daniels]

David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM


> Ok, so I will probably do
> 
> git revert HEAD
> 
> in my staging branch
> 
> and push it to origin/staging.
> 
> ---
> 
> I won't attempt to clear the LSR queue in preparation for my patch
> update (as I did) by running makelsr.py again.
> 
> When I update my issue, I'll simply add my snippet to snippets/new,
> and leave updating the LSR to the future (when the frenched-score
> snippet and my proposed snippet and whatever else appears will be
> integrated)

Sorry my recipe caused a problem in this case.  Normally clearing
the old LSR queue first with makelsr.py would be fine.  But what
you suggest is also OK, as long as someone fixes the problem and
runs makelsr.py reasonably soon - before the next new snippet is
added (I can't run it myself - on my Windows Vista it always tries 
to change all the \ to / or vice versa.)

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

Re: adding a snippet to a patch

[Trevor Daniels]

David Nalesnik wrote Monday, January 09, 2017 9:51 PM


> On Mon, Jan 9, 2017 at 2:00 PM, David Nalesnik  
> wrote:
>
>> I'm adding a snippet to a patch dealing with hairpins, and I'm not
>> sure what I need to do.
>>
>> I've added the snippet to Documentation/snippets/new.
>>
>> Do I then need to run scripts/auxiliar/makelsr.py and add the
>> resulting files to my patch for upload to Rietveld?
>>
>> The reason I ask is that there is a snippet not my own which is
>> getting written to Documentation/snippets/ when I run the script:
>> using-marklines-in-a-frenched-score.ly.  This leads to changes in
>> Documentation/snippets/staff-notation.snippet-list as well.
>>
>> I don't want these changes jumbled in with my patch.
> 
> Looking over several older patches affecting snippets, I see that I
> should run the makelsr script and add the resulting files.
> 
> This, however, was not done in the last patch adding a snippet:
> 
> commit 5944d20489bb5b8e4c4907fa3b3bcae9ec275ccb
> Author: Mark Knoop 
> Date:   Thu Sep 8 18:56:16 2016 +0100
> 
> I'm at a loss what to do.   Should I just add the files relevant to my
> patch, and ignore those produced by Mark's?

The normal practice is to include the makelsr.py changes with
your patch on Reitveld, but as two separate commits, so the
makelsr.py changes are in a commit on their own.

In this case, as there are some other changes involved, I
suggest running makelsr.py first, before applying your patch,
and push to staging.  No need for a prior review.  Then your 
patch, including a second makelsr.py in a separate commit,
can be uploaded to Reitveld cleanly.

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

Re: 5027: NR example with bad engraving practice

[Trevor Daniels]

Simon Albrecht wrote Thursday, January 05, 2017 10:16 PM


>>> On 04.01.2017 15:01, Hans Åberg wrote:
 This is just a quirk of the 4/4 [meter], also mentioned in Hindemith, 
 "Elementary Training", p. 30. In other words, the note should not cross 
 the 2nd and 4th metric accents, but it can cross the [3rd].
> 
> I’ve never heard of that and would assume it is a peculiarity in 
> Hindemith. Can anyone cite Gould or similar on the topic?

Well, Elaine Gould has several pages on the topic - 166-169.
That section starts:

"Note-values sustained across a beat or half-bar must expose
the beat structure of the bar:

[examples picked out are all in 4/4 time]

   8 4.~ 8 4 8 and not 8 2 4 8
   8 8 8 8~ 4. 8 and not 8 8 8 2 8

"Only very straightforward rhythms may be written across the beat
or half-bar:   4 2.  or   2 32  [are OK]"

"As the division of a bar becomes more complex, it is essential to
reveal more of the beats."

"When the rhythms are not part of a regular pattern, the long duration
may be divided to expose the beats or half-bar, to make the rhythm
easier to count.  In 4/4 it is the third (not the fourth) beat that should 
be exposed:

   2~ 4... 32  or even   2~ 4~ 8.. 32  "

So her essential message is reveal as many beats with ties as is
necessary to make the required rhythm clear.  There is no definite
rule.

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

Re: LilyPond 2.20 release process

[Trevor Daniels]

Phil Holmes wrote Saturday, December 31, 2016 11:03 AM


>I think there are a few bugs that need attention prior to stable release. 
> https://sourceforge.net/p/testlilyissues/issues/4975/ is one I'm aware of, 
> and there are a number of ones marked as critical.

There are four bugs marked as critical regressions, see:

https://sourceforge.net/p/testlilyissues/issues/search/?q=%28_type%3ACritical+OR+labels%3ARegression%29+AND+%28status%3ANew+OR+status%3AAccepted+OR+status%3AStarted%29

It seems the sources of these bugs have been traced to patches submitted by 
devs who are no longer active:

https://sourceforge.net/p/testlilyissues/issues/4807/

Keith O'Hara

https://sourceforge.net/p/testlilyissues/issues/4751/

John Gourlay

https://sourceforge.net/p/testlilyissues/issues/4182/

Janek Warchol

https://sourceforge.net/p/testlilyissues/issues/3778/

Mike Solomon

The patches are all large and quite far-reaching, so reversion is not an 
option.  Debugging has been attempted and (so far) abandoned.  So it is not 
clear what should be done.

Discuss.

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

Re: Delete new LSR-snippet?

[Trevor Daniels]

Knut Petersen wrote Friday, December 23, 2016 11:53 PM

Harm, would this be a better snippet for the LSR?

>> I seem to remember a post or maybe an LSR entry for placing
>> divisi arrows at the end of a staff.  Maybe this could be
>> adapted to achieve the same effect more reliably?
>>
>> Found it  - LSR 650.  It modifies the barline stencil.
> 
> Something like the following code  could be a base:
> 
> \version "2.19.53"
> 
> mpBarLine = {
>   \once \override Staff.BarLine #'stencil =
> #(lambda (grob) (ly:stencil-combine-at-edge (ly:bar-line::print grob) X 
> RIGHT
> (grob-interpret-markup grob mpBarLineMarkup) 0))
>   \break
> }
> 
> mpBarLineMarkup = \markup \with-dimensions #'(0 . 0) #'(0 . 0) {
>   \line {\hspace #3 \override #'(line-width . 20)
>  \justify{This is a marginal note}
>   }
> }
> 
> \paper {
>   left-margin = 2\cm
>   line-width = 14\cm
>   indent = 0\cm
>   ragged-right = ##f
> }
> 
> {
>   \repeat unfold 16 { c'' 4 } \break
>   \repeat unfold 16 { c'' 4 } \mpBarLine
>   \repeat unfold 16 { c'' 4 } \bar "|."
> }
> 
> \layout {}

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

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Trevor Daniels]

Alexander Kobel wrote Monday, December 26, 2016 1:00 AM


> Oh well, it's late. I didn't spot measure 7, with the 8( 8) in alto. 
> Same there.
> And, of course, you should have an extender there in the second verse, 
> and you should have extenders in measure 1 (was/was/shall) an measure 9 
> (shall/shall/was); but that's a limitation of the satb-template (or, 
> rather, a lack of voice assignment) that's beyond this patch to correct.

Well spotted!  In fact there are several other places where the lyric
alignment was wrong.  At the time I posted it it was a work-in-progress
(for Christmas 2017, in fact), but thank you for helping with the final
tweaks :)  For interest, I attach the latest version, hopefully now almost
correct, albeit several messy tweaks!  Can you spot any other improvements?
It will make a useful test as the various improvements to LP which you 
outline below take effect.  One day maybe all the tweaks can be removed.
 
> In fact, to solve this, one would need a simultaneous assignment of the 
> lyrics to all four voices they apply to. Basically, a \addlyrics 
> \lyricsto ChoirStaff.

That would indeed be a great improvement - once it can be made to work!

> (Note 1 to whom it may concern, including myself: once this works, the 
> satb and ssaattbb templates should be changed to associate the Verse* 
> lyrics with the entire ChoirStaff, and *Lyrics with the corresponding 
> Staff per default.)

I'd be happy to make this change as soon it it becomes available.
 
> (Note 2 to whom it may concern, including myself: we should have auto 
> extender regtests for \lyricsto ctx = name, for at least ctx = Voice, 
> Staff, ChoirStaff.)

Yes.

Trevor
\version "2.19.52"

#(set-global-staff-size 17)

\header {
  title = "As Joseph was A-Walking"
  subtitle = ""
  subsubtitle = ""
  composer = "Trad."
  arranger = "arr. R.R.Terry"
  poet = ""
  revisionDate = \markup {
%"4 Dec 2016"  % first draft
"27 Dec 2016"  % tweaks to lyrics alignments
  }
}

TwoVoicesPerStaff = ##t

SopranoMidiInstrument = "voice oohs"
AltoMidiInstrument = "voice oohs"
TenorMidiInstrument = "choir aahs"
BassMidiInstrument = "choir aahs"

sd = \once \slurDashed
td = \once \tieDashed
la = \once \override LyricText.self-alignment-X = #LEFT
nudgeR =
#(define-music-function (alignment) (number?)
#{ \once \override LyricText.parent-alignment-X = #alignment #})

Time = {
  \set melismaBusyProperties = #'()
  \numericTimeSignature
  \time 6/8
  \key ees \major
  \tempo "Andante" 4. = 56
  \repeat volta 2 {
\partial 8
s8 |
s2.*7 |
s4. s4
  }
  \break
  \repeat volta 2 {
s8 |
s2.*7 |
s4. s4
  }
}

SopranoMusic = \relative {
  ees'8 |
  g4 bes8 c4 d8 |
  \sd ees4\=1(\=2( bes8\=1) g4\=2) bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4

  ees8 |
  g4 bes8 c4 d8 |
  \sd ees4( bes8) g4 bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4
}

AltoMusic = \relative {
  bes8 |
  ees4 8 4 f8 |
  \sd g4\=1(\=2( f8\=1) ees4\=2) 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)

  bes8 |
  ees4 8 4 f8 |
  \sd g4( f8) ees4 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)
}

TenorMusic = \relative {
  g8 |
  bes4 8 aes 4 8 |
  \td \sd bes4~( 8 4) g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)

  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)
}

BassMusic = \relative {
  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4\=1(\=2( d8\=1) ees4\=2) 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)

  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)
}

VerseOne = \lyricmode {
  \set stanza = "1."
  As \la Jo -- seph \la "was __" a -- walk -- _ ing,
  He heard an an -- gel sing, __ _
  This _ __ night __ _ shall _ be born __ _ _
  Our hea -- _ ven -- \la ly __ _ \nudgeR #-3 King. __ _

  \set stanza = "4."
  He \la nei -- ther \la shall __ be ro -- _ cked
  In sil -- ver or in gold, __ _
  But _ in a woo -- _ den cra -- _ dle
  That rocks __ _ _ \la "on___" the \nudgeR #-3 mould. __ _
}

VerseTwo = \lyricmode {
  

Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

[Trevor Daniels]

Alexander Kobel wrote Sunday, December 25, 2016 2:19 PM

> But: I cannot imagine a situation where I would not use automatic 
> extenders, so I'm a really bad person to judge the need and requirements 
> for a manual mode.

One obvious and fairly common situation is when there are several
verses set beneath a melody line, but with different melismata.  In
this situation is is far easier to disable the automatic detection
of melismata and indicate them in the lyrics with "_".  That will
still work fine, AFAIUI, but equally the extender lines will differ
between the verses and will also need to be indicated manually.  Or
have I misunderstood something?

I attach a recent example - very Christmassy!

How would this be coded in future?

Trevor
 \version "2.19.52"

#(set-global-staff-size 17)

\header {
  title = "As Joseph was A-Walking"
  subtitle = ""
  subsubtitle = ""
  composer = "Trad."
  arranger = "arr. R.R.Terry"
  poet = ""
  revisionDate = \markup {
"4 Dec 2016"  % first draft
  }
}

TwoVoicesPerStaff = ##t

SopranoMidiInstrument = "voice oohs"
AltoMidiInstrument = "voice oohs"
TenorMidiInstrument = "choir aahs"
BassMidiInstrument = "choir aahs"

sd = \once \slurDashed
td = \once \tieDashed

Time = {
  \set melismaBusyProperties = #'()  % turn off auto-melismata
  \time 6/8
  \key ees \major
  \tempo "Andante" 4. = 56
  \repeat volta 2 {
\partial 8
s8 |
s2.*7 |
s4. s4
  }
  \break
  \repeat volta 2 {
s8 |
s2.*7 |
s4. s4
  }
}

SopranoMusic = \relative {
  ees'8 |
  g4 bes8 c4 d8 |
  \sd ees4\=1(\=2( bes8\=1) g4\=2) bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4

  ees8 |
  g4 bes8 c4 d8 |
  \sd ees4( bes8) g4 bes8 |
  c4 ees8 d4 c8 |
  bes4.~ 4 c16( d) |
  \sd ees4( d8) c( d) ees |
  \sd bes4\=1(\=2( g8\=1) ees4\=2) f8 |
  \sd g8\=1(\=2( f\=1) ees\=2) \sd bes'4( g8) |
  ees4.~ 4
}

AltoMusic = \relative {
  bes8 |
  ees4 8 4 f8 |
  \sd g4\=1(\=2( f8\=1) ees4\=2) 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)

  bes8 |
  ees4 8 4 f8 |
  \sd g4( f8) ees4 8 |
  ees4 8 aes4 8 |
  aes4.( g4) ees8 |
  \td ees4~ 8 ees( f) g |
  \sd f4\=1(\=2( d8\=1) ees4\=2) 8 |
  \td ees4~ 8 \sd d\=1(\=2( c\=1) d\=2) |
  ees4( c8 bes4)
}

TenorMusic = \relative {
  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)

  g8 |
  bes4 8 aes 4 8 |
  \td bes4~ 8 4 g8 |
  aes4 g8 aes4 c8 |
  f8.( d16 bes8 ees4) c8 |
  \td bes4~ 8 aes4 bes8 |
  \sd \td bes4~( 8 g4) c8 |
  \sd bes4( g8) \sd aes4( bes8) |
  g4( aes8 g4)
}

BassMusic = \relative {
  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)

  ees8 |
  ees8.( f16) g8 aes8.( g16) f8 |
  \sd ees4( d8) ees4 8 |
  aes,4 c8 f4 ees8 |
  d4.( ees4) aes8 |
  \td g4~ 8 aes4 ees8 |
  \sd d4\=1(\=2( bes8\=2) c4\=1) aes8 |
  \sd bes4( c8) \td bes4~ 8 |
  c8.( bes16 aes8 ees'4)
}

VerseOne = \lyricmode {
  \set stanza = "1."
  As Jo -- seph was a -- walk -- _ ing,
  He heard an an -- gel sing, __ _
  This _ __ night __ _ shall _ be born __ _ _
  Our hea -- _ ven -- ly __ _ King. __ _

  \set stanza = "4."
  He nei -- ther shall be ro -- _ cked
  In sil -- ver or in gold, __ _
  But _ in a woo -- _ den cra -- _ dle
  That rocks __ _ _ on the mould. __ _
}

VerseTwo = \lyricmode {
  \set stanza = "2."
  He nei -- ther shall be born __ _ _
  In hous -- sen nor in hall, __ _
  Nor _ in the place _ of Pa -- ra -- dise,
  But in __ _ an ox 's stall. __ _

  \set stanza = "5."
  He nei -- ther shall be chri -- sten -- ed
  In white wine or in red, __ _
  But _ in the fair __ _ spring wa -- _ ter
  As we __ _ were chri -- sten -- ed. __ _

}

VerseThree = \lyricmode {
  \set stanza = "3."
  He nei -- ther shall be clo -- _ thed
  In pur -- ple nor in pall, __ _
  But _ all __ _ in __ _ fair li -- _ nen
  As wear __ _ _ ba -- bies all. __ _

  \set stanza = "(1."
  As Jo -- seph was a -- walk -- _ ing,
  He heard an an -- gel sing, __ _
  This _ __ night __ _ shall _ be born __ _ _
  Our hea -- _ ven -- ly __ _ King.) __ _
}


\paper {
  indent = 0
  top-margin = 10
  bottom-margin = 5
  left-margin = 25
  right-margin = 15
  ragged-bottom  = ##f
  ragged-last-bottom = ##f
  print-page-number = ##t
  top-markup-spacing.basic-distance = 10
  markup-system-spacing.basic-distance = 15
  system-system-spacing.basic-distance = 22
  top-system-spacing.basic-distance = 15
  last-bottom-spacing.basic-distance = 25
}

\include "satb.ly"


As Joseph was A-Walking.pdf
Description: Adobe PDF document

Re: Delete new LSR-snippet?

[Trevor Daniels]

Thomas Morley wrote Friday, December 23, 2016 11:42 AM

> with
> http://lsr.di.unimi.it/LSR/Item?u=1=1049
> a new snippet arrived.
> Though, it only demonstrates how to use 'extra-offset, imho.
> I tend to delete it, otoh I don't want to scare away a possible new
> contributor...
> 
> Opinions?

Not sure how else one would place text to the right of a staff,
but this doesn't seem to be a very reliable method.  So I'd
also recommend deleting it.

I seem to remember a post or maybe an LSR entry for placing
divisi arrows at the end of a staff.  Maybe this could be 
adapted to achieve the same effect more reliably?

Found it  - LSR 650.  It modifies the barline stencil.

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

Re: [PATCH] Automatic lyric extenders

[Trevor Daniels]

Knut Petersen wrote Thursday, December 22, 2016 12:33 AM

> Attached find a new version of the patch.
> Please test. Read the updated manuals.
> 
> Feel free to provide corrections and translations!

Looks promising.  I have several comments to make, but it will be
much easier to do that when the patch has reached Review stage
on Rietveld.

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

Re: music function to be included somewhere in scm/*

[Trevor Daniels]

Noeck wrote Friday, December 16, 2016 9:08 PM

> Am 16.12.2016 um 17:38 schrieb Alexander Kobel:
>> [2] Side Note: other proposed names for minimum-length so far:
>> 
>> (1) minimum-space
>> (2) show-length
>> (3) hide-below-length
>> (4) hide-if-shorter-than
>> (5) minimum-visibility
>> (6) visibility-threshold
>> (7) printing-threshold
>> (8) extender-threshold
> 
> At a first glance, the property is still the same, just the behaviour
> for shorter extenders changed:
> 
> before: shorter extenders are prolonged
> after:  shorter extenders are not visible
> 
> But at a second glance, the minimum-length for LilyPond grobs usually
> means that the object is visible and the length is at least
> minimum-length (for glissandi, etc.). Using it to hide a shorter object
> feels inconsistent, IMHO. So I agree with Werner. But I have no
> favourite naming, all of them sound wrong to me - a slight preference
> for (6).

Definitely not "minimum-length" which means "Try to make a spanner at
least this long." 

How about "collapse-length", which would be analogous to "collapse-height"?
This exists already and means "Minimum height of system start delimiter. 
If equal or smaller, the bracket/brace/line is removed."

"remove-threshold" is another possibility.

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

Re: music function to be included somewhere in scm/*

[Trevor Daniels]

Knut Petersen wrote Thursday, December 15, 2016 6:08 PM

>> Another common use case occurs when the lyrics in several verses have
>> melismata in different places.  This is usually indicated with dashed slurs,
>> occasionally even with two such slurs starting on the same note.  When
>> there are many of these the easiest way is simply to turn off auto-melismata
>> with   \set melismaBusyProperties = #'() and indicate them with __ and _
>> manually in the lyrics.  Presumably this behaviour will not change with your
>> proposed patch?
> 
> You would leave out the "__" part everywhere.
> 
> Have a look at lyrextest.ly and lyrextest.pdf I sent to the list a few hours 
> ago.
> That should answer most of your questions.
> 
> The "__" is still understood, but it is not needed.

Great!  I'm looking forward to a much easier time setting choral pieces for my 
choir!

Many thanks to you and Alexander for all your work and the prompt replies!

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

Re: music function to be included somewhere in scm/*

[Trevor Daniels]

Alexander Kobel and Knut Petersen wrote Thursday, December 15, 2016 4:45 PM

OK, thanks for your explanations.  Clearly the patch is an improvement for this
use case:

> On 2016-12-15 17:19, Trevor Daniels wrote:
>
> Currently, I set minimum-length = 0 in all Lyric contexts so that I
> can place identical lyrics in several voices, all with extenders, but
> the extenders appear in the score only when they correspond to melismata.
> In other words the extender is permitted to reduce in size to 0, which
> seems pretty well what "minimum-length" means.

Another common use case occurs when the lyrics in several verses have
melismata in different places.  This is usually indicated with dashed slurs,
occasionally even with two such slurs starting on the same note.  When
there are many of these the easiest way is simply to turn off auto-melismata
with   \set melismaBusyProperties = #'() and indicate them with __ and _
manually in the lyrics.  Presumably this behaviour will not change with your
proposed patch?

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

Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)

[Trevor Daniels]

Alexander, you wrote Thursday, December 15, 2016 3:51 PM

> On 2016-12-15 13:34, Trevor Daniels wrote:
>
>> Adding you to the dev list is very little work, but you do have to
>> get a SourceForge id and tell me what it is for me to do that.
>>
>> James probably is willing to undertake the work of creating an
>> issue and servicing it on your behalf, but if you yourself are not
>> known to Allura you will not be able to contribute to any discussion
>> on _any_ issue - including those James has created on your behalf.
> 
> Okay, makes sense. In this case, I guess it's reasonable to add me no 
> matter how much (or little) I will participate. I created an SF account 
> with username akobel.

Added, giving you Developer status.  Now you can update and create issues
as well as read them.

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

Re: music function to be included somewhere in scm/*

[Trevor Daniels]

Knut Petersen wrote Thursday, December 15, 2016 1:55 PM

> minimum-length in my patch means:
> - Don't generated automatic extenders if it's impossible to give them 
> minimum-length.
> - Use minimum-length for forced extenders at unusual places (single note) if 
> possible.
> 
> I think the most reasonable way is to keep that traditional name.

I don't understand what you mean for the proposed behaviour.

Currently, I set minimum-length = 0 in all Lyric contexts so that I 
can place identical lyrics in several voices, all with extenders, but 
the extenders appear in the score only when they correspond to melismata.
In other words the extender is permitted to reduce in size to 0, which
seems pretty well what "minimum-length" means.

Will this behaviour change with your proposed patch?

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

Re: add choral and choral-cautionary accidental style (issue311430043by perpeduumimmob...@gmail.com)

[Trevor Daniels]

Alexander, you wrote Wednesday, December 14, 2016 11:49 PM

> yes, I guess I never asked to be on that list. My last commit was 
> pre-Rietveld and pre-Allura, I think; and it's unlikely that 
> contributions from my side will come more often in the foreseeable 
> future (except for one more patch "in the pipeline", waiting for a 
> cleanup and documentation).
> So I guess it's not really worth to give me any other status than other 
> occasional users. On the other hand, do whatever is the most convenient 
> for you - handling a lonesome patch every other year manually or adding me.

Adding you to the dev list is very little work, but you do have to
get a SourceForge id and tell me what it is for me to do that.

James probably is willing to undertake the work of creating an
issue and servicing it on your behalf, but if you yourself are not 
known to Allura you will not be able to contribute to any discussion 
on _any_ issue - including those James has created on your behalf.

Trevor


> On 2016-12-14 16:28, Trevor Daniels wrote:
>>
>> Alexander, you wrote Wednesday, December 14, 2016 12:32 PM
>>
>>> On 2016-12-14 13:15, James wrote:
>>>
>>>> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
>>>>> Reviewers: ,
>>>>>
>>>>> Message:
>>>>> add choral and choral-cautionary accidental style
>>>> ...
>>>>>
>>>>> Please review this at https://codereview.appspot.com/311430043/
>>>>>
>>>>> Affected files (+151, -1 lines):
>>>>>   M Documentation/notation/pitches.itely
>>>>>   M ly/engraver-init.ly
>>>>>   M scm/music-functions.scm
>>>>>
>>>>> ___
>>>>
>>>> Does this have an associated tracker item or do we need to create one
>>>> for you?
>>>>
>>>> https://sourceforge.net/p/testlilyissues/issues/?source=navbar
>>>
>>> I don't think git-cl created one; I received some error message but I
>>> thought it related to the known and documented "no automatic
>>> notification" after patch upload. But obviously, I mis-configured
>>> git-cl's Allura bearer token...
>>> Please create one if you don't mind; I will have a look at the
>>> configuration for my next upload.
>>
>> AFAICS you don't have developer status at SourceForge.  Have you
>> ever asked to be added as a developer?  That would explain
>> the failure.
>>
>> To fix it please send me (or post to the list) your SourceForge
>> identifier and I'll add you.
>>
>> Trevor
>>
> 
> ___
> 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: add choral and choral-cautionary accidental style (issue311430043 by perpeduumimmob...@gmail.com)

[Trevor Daniels]

Alexander, you wrote Wednesday, December 14, 2016 12:32 PM

> On 2016-12-14 13:15, James wrote:
>
>> On 13/12/16 20:10, perpeduumimmob...@gmail.com wrote:
>>> Reviewers: ,
>>>
>>> Message:
>>> add choral and choral-cautionary accidental style
>> ...
>>>
>>> Please review this at https://codereview.appspot.com/311430043/
>>>
>>> Affected files (+151, -1 lines):
>>>   M Documentation/notation/pitches.itely
>>>   M ly/engraver-init.ly
>>>   M scm/music-functions.scm
>>>
>>> ___
>>
>> Does this have an associated tracker item or do we need to create one
>> for you?
>>
>> https://sourceforge.net/p/testlilyissues/issues/?source=navbar
> 
> I don't think git-cl created one; I received some error message but I 
> thought it related to the known and documented "no automatic 
> notification" after patch upload. But obviously, I mis-configured 
> git-cl's Allura bearer token...
> Please create one if you don't mind; I will have a look at the 
> configuration for my next upload.

AFAICS you don't have developer status at SourceForge.  Have you
ever asked to be added as a developer?  That would explain
the failure.

To fix it please send me (or post to the list) your SourceForge
identifier and I'll add you.

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

Re: Stepping down and moving on

[Trevor Daniels]

David, you wrote Wednesday, November 09, 2016 5:09 PM

> I have accepted a full-time development (and team management) position
> with another company.  Due to their project and team expansion plans,
> I will be starting already in December.

I sincerely hope you're finding your new job engaging and enjoyable,
and a satisfying match to your talents!
 
> This employment is in another city.  I'll be travelling back and forth
> weekly for the foreseeable future.  While I might be working on some
> LilyPond side projects interesting to me occasionally, I will not be
> able to do any serious amound of coordination or other activity
> involving me with LilyPond's community.
...
> There are also several half-completed features that are a nuisance.
> I do not expect to be able to to a significant amount of work on them in
> the foreseeable future.

As the end of the year is approaching I'm planning to do some tidying
of the SF Issues DB.  Should I return all the unfinished issues signed 
out to you in a state of "needs work" to unassigned?  Or are there some
you wish to retain?

> I'll try seeing through the release of 2.20 in the little time remaining
> to me both before and after starting my job.  

That would be most welcome, even if we end up with a couple of unfixed
regressions.  There are so many wonderful new features in 2.19 (most
of them crafted by you!) we really should now get them into a stable
release.

Trevor


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

Re: Lilypond python upgrade

[Trevor Daniels]

Andrew Bernard wrote Thursday, December 08, 2016 1:28 AM

> Moving a thread across from the user list, I just wanted to let people know
> that I will be starting on the work of upgrading lilypond to use Python 3 -
> yes, with all the complexity that entails. I am happy to have  a serious
> shot at this task.

Excellent news, Andrew!  Keep the list informed about progress: work on
LilyPond is full of traps and gotchas, but many of them can be sidestepped
or overcome with advice from the old-hands (literally in many cases!)

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

Re: bypassing the patch countdown

[Trevor Daniels]

Graham Percival wrote Wednesday, December 07, 2016 10:34 PM

> We instituted the policy of patch countdowns and Patchy after the
> lengthy wait for 2.14.0, which was due to a large number of
> regression bugs due to patches which either broke the compile, or
> broke previously-working output.
> 
> However, even after that, I still pushed some commits directly to
> staging, bypassing the countdown.  Obviously I did this for
> updating the VERSION when making a release, but I also did it for
> a few typo fixes as well.
> 
> Is this still an accepted practice?

It is.  But as a minimum it must have been tested locally with
a build or (partial) doc build, or passed the automated tests 
before pushing to staging.  Of course significant changes still
need to go through countdown.

Trevor

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

Re: Stepping up, contributor mentoring

[Trevor Daniels]

- Original Message - 
From: "Trevor Daniels" <t.dani...@treda.co.uk>
To: "Graham Percival" <gra...@percival-music.ca>
Cc: <lilypond-devel@gnu.org>
Sent: Friday, December 02, 2016 7:59 PM
Subject: Re: Stepping up, contributor mentoring


> 
> Graham you wrote Friday, December 02, 2016 6:34 PM
> 
> 
>> On Tue, Nov 29, 2016 at 11:37:04PM -, Trevor Daniels wrote:
>>> 
>>> Graham Percival wrote Tuesday, November 29, 2016 11:11 PM
>>> 
>>> > So, are there any vacancies on the Bug Squad?  I've signed up for
>>> > sourceforge (username: gperciva).  
>>> 
>>> I've added you to SF as a Developer (gives you Read, Create, Update
>>> permissions for the LP Issues at 
>>> https://sourceforge.net/p/testlilyissues/issues/ ).
>> 
>> Hmm.  Sourceforge seems to have forgotten my account -- I couldn't
>> log in, and the recovery emails didn't work.  So I tried to create
>> a new account with the same username, and it appeared to work.
>> This is not encouraging.  :(
>> 
>> It could simply be that I used to have an account there, and it
>> got confused because I created an account with the same name as a
>> deleted account.
>> 
>> Could you please try adding "gperciva" to the SF Developer list  
>> again?  If my suspicions are correct, this account will also
>> disappear, in which case I'll choose a different username.
> 
> Hhm.  There seemed to be no problem when I added gperciva the
> first time - it filled in the field correctly with your name.
> However, when I returned to SF just now you were no longer in
> the Developer list.  So I added gperciva again, and again it's
> filled in your name correctly.  All looks normal...
> 
> See if you can update one of the issues now.

Ah - I've just looked in the audit log, extracted below.  My
previous attempt to add you was removed because your account
had been deleted.

SF runs lots of things asynchronously - the deletion occurred
almost 24 hours after I added it.

2016-12-02 19:54:09 tdanielsmusic 
  /p/testlilyissues/admin/groups/add_user
  add user gperciva to Developer
2016-11-30 22:14:03 sf-robot
  Removed user from role: Developer because the associated account has been 
deleted.
2016-11-29 23:26:37 tdanielsmusic 
  /p/testlilyissues/admin/groups/add_user
  add user  to Developer

Let's see what happens tomorrow ...

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

Re: Stepping up, contributor mentoring

[Trevor Daniels]

Graham you wrote Friday, December 02, 2016 6:34 PM


> On Tue, Nov 29, 2016 at 11:37:04PM -0000, Trevor Daniels wrote:
>> 
>> Graham Percival wrote Tuesday, November 29, 2016 11:11 PM
>> 
>> > So, are there any vacancies on the Bug Squad?  I've signed up for
>> > sourceforge (username: gperciva).  
>> 
>> I've added you to SF as a Developer (gives you Read, Create, Update
>> permissions for the LP Issues at 
>> https://sourceforge.net/p/testlilyissues/issues/ ).
> 
> Hmm.  Sourceforge seems to have forgotten my account -- I couldn't
> log in, and the recovery emails didn't work.  So I tried to create
> a new account with the same username, and it appeared to work.
> This is not encouraging.  :(
> 
> It could simply be that I used to have an account there, and it
> got confused because I created an account with the same name as a
> deleted account.
> 
> Could you please try adding "gperciva" to the SF Developer list
> again?  If my suspicions are correct, this account will also
> disappear, in which case I'll choose a different username.

Hhm.  There seemed to be no problem when I added gperciva the
first time - it filled in the field correctly with your name.
However, when I returned to SF just now you were no longer in
the Developer list.  So I added gperciva again, and again it's
filled in your name correctly.  All looks normal...

See if you can update one of the issues now.

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

Re: Stepping up, contributor mentoring

[Trevor Daniels]

Graham Percival wrote Tuesday, November 29, 2016 11:11 PM


> Hi all, I'm back.

Great!  Welcome back!  We've missed you!

> So, are there any vacancies on the Bug Squad?  I've signed up for
> sourceforge (username: gperciva).  

I've added you to SF as a Developer (gives you Read, Create, Update
permissions for the LP Issues at 
https://sourceforge.net/p/testlilyissues/issues/ ).

> Other than that, my primary
> interest remains in organization / mentoring new contributors.
> Has anything changed in regards to that in the past four years?
> Or shall I jump straight in?  I see that "Contributor 1.4 Mentors"
> hasn't changed.

Not a lot has changed.  Most of the usual suspects are still here,
although many (including me) are often in lurking mode.

> Anything else I should know?  I've skimmed the past month of this
> mailing list.

Other than maintenance the docs have not moved forward much :(

> (I was planning on waiting until the new year, but David's news
> made me re-evaluate my health now, and I think I have the energy
> to take on more stuff.  To make a long story short: depression,
> burnout, quit academia, moved back to Vancouver, recovery.  Also,
> started ballroom and swing dancing!  Great fun, absolutely
> recommended, *especially* for other shy, socially anxious computer
> geeks.  Despite that help, I'm still not 100% recovered, but I'm
> content with my progress, and I think that doing more volunteer
> work will help.)

I'm sure it will.  I found singing in fully staged musicals and 
opera was both enjoyable and very therapeutic for overcoming shyness
and lack of confidence in company.  Everyone else is so extrovert it
was catching!

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

Re: Stepping down and moving on

[Trevor Daniels]

Hi David

The first thing to do is to sincerely thank you for your extreme dedication, 
skill and energy in developing our favourite program over recent years.  Even 
that seems a weak effort at expressing the gratitude and admiration I feel.  We 
owe you a great deal.  But eventually we all have to move on.

It goes without saying, although I shall say it, that whatever continuing 
involvement you feel able to provide will continue to be widely welcomed by all 
users and developers.  Please don't leave us entirely!

Finally, I do hope your involvement with our community has been mutually 
beneficial.  I believe it has.

Sincerely, Trevor


- Original Message - 
From: "David Kastrup" 
To: 
Cc: 
Sent: Wednesday, November 09, 2016 5:09 PM
Subject: Stepping down and moving on



Hi folks and team,

while I haven't really occupied an official function in LilyPond
development, it's hard to deny that I have effectively functioned as
acting chief architect and vetter (with a rather mottled performance).

Partly in connection with a drop of my productivity particularly this
year, the amount of financial support for my work from members of the
LilyPond community went down from overall survivable to disastrous.  Of
course this is bitter for those of you that did contribute in
significant amounts to my subsistence but I have to be moving on.

I have accepted a full-time development (and team management) position
with another company.  Due to their project and team expansion plans,
I will be starting already in December.

This employment is in another city.  I'll be travelling back and forth
weekly for the foreseeable future.  While I might be working on some
LilyPond side projects interesting to me occasionally, I will not be
able to do any serious amound of coordination or other activity
involving me with LilyPond's community.

As my communication style has proven to be a somewhat mixed blessing for
the purpose of attracting long-term developers, I expect that this may
help in the long run for finding a different balance of areas LilyPond
is getting worked on.

During his tenure as LilyPond leader, Graham has demonstrated that even
without a central technical lead there is a lot of potential to focus
the resources of people willing to work on and expand LilyPond and we
have been continuing to reap the results of his talent for organizing
people into useful teams even though I have not really figured out how
to fill gaps in the various teams and tools managing LilyPond's
infrastructure to offset the "natural" amounts of fluctuation.

I'll try seeing through the release of 2.20 in the little time remaining
to me both before and after starting my job.  My main worry is the
current comparative amount of instability with regard to font handling,
and my main bad taste is that 2.20.1 will not be able to support
Guile 2: there is no way that anything deserving the label of "stable"
and including Guile 2 will come about in the rest of my tenure.

There are also several half-completed features that are a nuisance.
I do not expect to be able to to a significant amount of work on them in
the foreseeable future.

Once consequence, of course, is that my requirement for funding is over.
I am greatly thankful to the people who have enabled me to keep working
on LilyPond as long as I did, but what remains in my bank account, in
spite of being quite less than what I started with when working on
LilyPond, is sufficient to tide me over the time to my first paycheck.

So I would ask you to cancel any regular bank payments you might still
have in place as of December: I don't see that I will have a reasonable
chance at returning a tangible value for them.

Thanks for making me stay in the pond as long as I did!

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

Re: issue tracker access

[Trevor Daniels]

Hi Janek

> can you give me write access to the sourceforge issue tracker? My
> sourceforge username is janek-warchol.

Done.  Added as Developer (Read/Create/Update Issues).  

Welcome back!

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

Re: change title of doc-tagged lsr-snippet 586

[Trevor Daniels]

Thomas Morley wrote Sunday, October 09, 2016 11:20 PM


>2016-10-10 0:07 GMT+02:00 Trevor Daniels <t.dani...@treda.co.uk>:
>>
>> Thomas Morley wrote Sunday, October 09, 2016 8:46 PM
>>
>>> in /Documentation/snippets we have markup-lines.ly coming from LSR.
>>> http://lsr.di.unimi.it/LSR/Item?id=586
>>>
>>> Although the code correctly uses \markuplist the description says:
>>> "Text that can spread over pages is entered with the
>>> \markuplines command."
>>>
>>> I'd like to change the description and the somehow misleading title.
>>>
>>> Any problem with our docs while changing the title in lsr?
>>
>> Only if the snippet is referenced by name, which appears not to be the 
>> case for this snippet.  Running auxiliar/makelsr.py should be sufficient.  
>> However, the same title appears in the texidoc string in a couple of 
>> regression tests, so you might want to look at these too.
>
> Are you sure?

Well, not absolutely, since I've never actually tried it, but I'm fairly 
confident.

> I've found Documentation/snippets/table-of-contents.ly worth fixing,

No - that's updated automatically when you run makelsr.py

> but nothing in the reg-tests.

I was thinking of 

  input/regression/markup-lines.ly
  input/regression/markup-lines-identifier.ly

which use similar words.  If you thought these words "misleading" maybe
they should be changed too.

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

Re: Help with Scheme engraver please

[Trevor Daniels]

Trevor Daniels wrote Saturday, September 17, 2016 9:57 PM

> Thomas Morley wrote Friday, September 09, 2016 11:31 PM
> 
>> 2016-09-08 0:07 GMT+02:00 Trevor Daniels <t.dani...@treda.co.uk>:
>>>
>>>  But I don't understand why you
>>> used a rather complicated procedure to obtain durations.  Could you
>>> not simply extract the durations from note events?
>> 
>> In my opinion the historic lute tablatures were written disregarding
>> any polyphony as far as rhythmy are concerned, yes.
>> But this polyphony was always _meant_ and the player should respect it.
>>
>> For our coding this means an example like
>> 
>> upper = { d'2 d' }
>> middle = { \override Rest.staff-position = #-1.5 r8 f r8 f r8 f r8 f }
>> lower = { a,4\rest d a,4\rest d }
>> 
>> \score {
>>  <<
>>   \new Staff << \clef "G_8" \upper \\ \lower \\ \middle >>
>> 
>>   \new TabStaff
>>   << \clef "G_8" \upper \\ \lower \\ \middle >>
>>  >>
>>  \layout {
>>\context {
>>\TabStaff
>>  stringTunings = \stringTuning <a, d f a d' f'>
>>}
>>  }
>> }
>> 
>> should return proper polyphonic in Staff, and in TabStaff only a
>> single 8th indication for the overall rhythm should be printed.
>> This can be achieved with my proposal and would warrant the principle
>> of one source-code for Staff _and_ TabStaff.
>> I didn't found a method to do so with simple durations.
> 
> OK, I see now why you need to extract the interval between a note and the
> subsequent note even when they are split between several voices.  
> This interval then should be displayed as the "duration" of the first of the 
> pair
> (unless it is unchanged from the previous one, of course)
> 
> I agree this can't be done by looking solely at the duration of individual
> notes.
> 
> However, your code doesn't quite work in all situations.  If you replace the
> first f in the middle voice with a rest we should have a duration of 4 
> followed
> by one of 8, but the 8 is missing.
> 
>> You seems to be of different opinion, for some cases you let
>> explicitely print the warning:
>> "Polyphony is not supported in lute tab"
> 
> Well, I meant it wasn't supported in my simple implementation, not
> that it shouldn't be.
> 
> I need now to study your approach to polyphony in greater detail to understand
> the logic.

Having thought about polyphony in tab a little more I realise now there is a 
fundamental difficulty: it is quite possible to have an interval in time 
between two adjacent notes that cannot be represented as a single duration.  In 
staff representation ties would be used to do this, but I don't think ties were 
used in baroque tab, were they?  Even if they were, implementing them at this 
early stage would be a step too far, at least for me.  So I plan to sidestep 
polyphony at present and concentrate on implementing lute tab from a single 
voice.  There's plenty to do yet to achieve that in a form suitable for a LP 
patch.

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

Re: Help with Scheme engraver please

[Trevor Daniels]

Thomas Morley wrote Friday, September 09, 2016 11:31 PM

Hi Harm

back now from my week away ...


> 2016-09-08 0:07 GMT+02:00 Trevor Daniels <t.dani...@treda.co.uk>:
>>
>>  But I don't understand why you
>> used a rather complicated procedure to obtain durations.  Could you
>> not simply extract the durations from note events?
> 
> In my opinion the historic lute tablatures were written disregarding
> any polyphony as far as rhythmy are concerned, yes.
> But this polyphony was always _meant_ and the player should respect it.
>
> For our coding this means an example like
> 
> upper = { d'2 d' }
> middle = { \override Rest.staff-position = #-1.5 r8 f r8 f r8 f r8 f }
> lower = { a,4\rest d a,4\rest d }
> 
> \score {
>  <<
>   \new Staff << \clef "G_8" \upper \\ \lower \\ \middle >>
> 
>   \new TabStaff
>   << \clef "G_8" \upper \\ \lower \\ \middle >>
>  >>
>  \layout {
>\context {
>\TabStaff
>  stringTunings = \stringTuning <a, d f a d' f'>
>}
>  }
> }
> 
> should return proper polyphonic in Staff, and in TabStaff only a
> single 8th indication for the overall rhythm should be printed.
> This can be achieved with my proposal and would warrant the principle
> of one source-code for Staff _and_ TabStaff.
> I didn't found a method to do so with simple durations.

OK, I see now why you need to extract the interval between a note and the
subsequent note even when they are split between several voices.  
This interval then should be displayed as the "duration" of the first of the 
pair
(unless it is unchanged from the previous one, of course)

I agree this can't be done by looking solely at the duration of individual
notes.

However, your code doesn't quite work in all situations.  If you replace the
first f in the middle voice with a rest we should have a duration of 4 followed
by one of 8, but the 8 is missing.
 
> You seems to be of different opinion, for some cases you let
> explicitely print the warning:
> "Polyphony is not supported in lute tab"

Well, I meant it wasn't supported in my simple implementation, not
that it shouldn't be.

> Always printing the duration at the start of every bar even if
> unchanged happens sometimes, but sometimes not, Maybe let it depend on
> a context-property?

Yes, a sensible later step.
 
> For the bass courses.
> I didn't understand this point in your former mails. Now with your
> code its clearer to me.
> But why you do it this way? Isn't my implementation of
> https://sourceforge.net/p/testlilyissues/issues/4768/
> sufficient?

Well, to be honest I'd forgotten about this.  But unfortunately it is 
incompatible
with the nice fret number glyphs from Fronimo as that font doesn't include
a '/'.  However, as we can't adopt the Fronimo fonts anyway I'll revert to using
your implementation in any future work.

I need now to study your approach to polyphony in greater detail to understand
the logic.

Trevor

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

Re: Help with Scheme engraver please

[Trevor Daniels]

- Original Message - 
From: "Thomas Morley" <thomasmorle...@gmail.com>
To: "Trevor Daniels" <t.dani...@treda.co.uk>
Cc: "Lily-Devel List" <lilypond-devel@gnu.org>
Sent: Sunday, September 04, 2016 7:28 AM
Subject: Re: Help with Scheme engraver please


> 2016-09-03 19:29 GMT+02:00 Thomas Morley <thomasmorle...@gmail.com>:
> 
>> I've put some work on it. See attached duration-as-markup-5b-harm.ly
>> The general work should be clear from comments and descriptions.
>> There's some ugly code in it, although it works so far, wide room for
>> improvements still there.
>> Nevertheless it works now even in polyphonic.
> 
> Please replace the coding in `stop-translation-timestep' with:
> 
[snip]
>
> This will cure a bug with last notes starting at some moment, but with
> different durations.

Thanks  Harm, for this and the preceding mail.  I've found them very
helpful.  In particular, a simpler way to set stringTuning and how to set
persistent variables within engravers.  But I don't understand why you
used a rather complicated procedure to obtain durations.  Could you
not simply extract the durations from note events?

Actually I'd got quite a bit further than the simple example I posted,
and my current state is attached, extracting durations and pitches
from note-events, and detecting the start of bars by acknowledging
barline grobs.  This version draws duration grobs whenever the
duration changes, and at the start of every bar, bass course
grobs below the tab, adds fingering and laissez vibrer slurs (I think
that's what they are used for.)

There's quite a lot still wrong with this example, although it works in
simple cases.  You can see these problems listed in the TODOs.
And the code needs some tidying up too as bits of it are rather
messy (to say the least!).  And it would probably be better to separate
the generation of the two types of grobs into two engravers.

You'll see I use the Fronimo glyphs for the bass course indications,
and mensural flags for the durations.  These are just for demonstration: 
we'd need a set of lute tab glyphs of our own to be defined at some stage.

But this is now pretty close to Phase I which I defined in the note 
dated 22 Nov 2009, in this thread:
http://lilypond-s-support-for-tablatures.3383434.n2.nabble.com/Baroque-lute-tablature-td4008032.html

I probably will be somewhat unresponsive for 10 days or so, as we
are away on a belated summer break next week.

Trevor
\version "2.19.46"

% Example of using Scheme engravers to add markup based on
% note duration and pitch

% Avoids repeated durations on both chords and consecutive notes
% Always prints duration at start of bar
% Adds dots
% Adds string indication in bar 3
% Adds stroke finger indications
% Makes dots height not vary with duration
% Adds glyphs for minims and semibreves
% Fixes error message with avoid-slur
% Adds string finger indications
% Adds glissando to show repeated finger
% (not good - each has to be positioned)
% Removes debugging printouts in Lute_tab_duration_engraver
% Uses note names in stringTuning (thanks Harm)
% Places persistent variables inside engraver (thanks Harm)
% Adds bass courses


%{
TODO
  Error when finger is specified with slur
  Warning when bass course pitch is specified
  Handle notes with different durations at one musical moment better
  Need better way of linking notes with repeated right finger
could this be detected and added automatically?
  Bass course pitches should not be hard-coded
%}

#(define (t->m t)
   "Return the current moment of translator object @var{t}."
   (ly:context-current-moment (ly:translator-context t)))

#(define
  (duration-markup duration)
"Returns flags corresponding to duration as markup,
 avoiding repeated symbol if duration has not changed."
  (define flag-glyph "")
  (define dots-glyph "")
  (let ((duration-log
 (ly:duration-log duration))
(duration-dots
 (ly:duration-dot-count duration)))
; obtain flag glyph
(case duration-log
  ; TODO: replace with more suitable glyphs
  ((0) (set! flag-glyph (markup #:note "1" UP)))
  ((1) (set! flag-glyph (markup #:note "2" UP)))
  ((2) (set! flag-glyph (markup #:musicglyph "rests.M2mensural")))
  ((3) (set! flag-glyph (markup #:musicglyph "flags.mensuralu03")))
  ((4) (set! flag-glyph (markup #:musicglyph "flags.mensuralu04")))
  ((5) (set! flag-glyph (markup #:musicglyph "flags.mensuralu05")))
  ((6) (set! flag-glyph (markup #:musicglyph "flags.mensuralu06")))
  (else
   (begin
(ly:warning "Duration glyph not available for duration-log of ~a" duration-log)
(set! flag-glyph " "
; obtain dots glyp

Re: Help with Scheme engraver please

[Trevor Daniels]

Thomas Morley wrote Friday, September 02, 2016 8:22 PM


> 2016-09-02 13:05 GMT+02:00 Trevor Daniels <t.dani...@treda.co.uk>:
>>
>> There already is a helpful working example in the code base.  See
>>
>> input/regression/scheme-engraver.ly
>>
>> This doesn't go as far as creating new grobs, so I've attached a
>> simple example that does.  This is a bit of a hack, used as part of
>> a learning process, and a bit messy as it evolved from an earlier
>> attempt, but it illustrates one way.
>>
>> Actually, comments from the experts on this would be very helpful.
>
> I stumbled across you're printing a rest-glyph for a quarter-note.
> 
> Eventually I might have some ideas, but there are a plethora of
> variants for historic tablaures. Which glyphs do you want to be
> printed above the TabStaff for the code below. Only flags, flags with
> stems, stems only for quarters, what to do for notes longer than a
> quarter?
> 
> m = { \compressFullBarRests c'\maxima \longa \breve 1 2 4 8 16 32 }
> 
> <<
>  \new MensuralVoice \m
>  \new TabStaff \with { \revert TextScript.stencil }
>  \new TabVoice
>\with {
>  \consists \Lute_tab_duration_engraver
>} \m

I really know very little about lute tablature, but I believe there are many
different styles.  Should this ever get close to operational we'd need
to discuss which styles to support and what glyphs would be needed.
But I fear that's some way in the future.  The mensural (and rest) glyphs
I used in this little example are just markers really, while I explore how to
deal with other aspects - fingering, bass courses, articulations, etc.

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

Re: Help with Scheme engraver please

[Trevor Daniels]

Simon, you wrote Friday, September 02, 2016 1:34 AM

Hi Simon,

>On 24.08.2016 11:51, Trevor Daniels wrote:
>> David Kastrup wrote Wednesday, August 24, 2016 7:48 AM
>>> "Trevor Daniels"<t.dani...@treda.co.uk>  writes:
>>>> Prompted by the recent discussion on lute tablature, I tried coding a
>>>> Scheme engraver to create the duration grobs but quickly ran into a
>>>> problem.  I need to collect information from both a Listener and an
>>>> Acknowledger so the obvious place to build the grob is in
>>>> stop-translator-timestep,
>>> No, no, no.  stop-translator-timestep really is only for cleanup work.
>>> Stuff is no longer in working order then.  You want process-acknowledged
>>> here I think.
>>>
>>> There will always be a call to process-acknowledged whenever grobs have
>>> been created, and_reading_  stuff from grobs should be delayed until
>>> then since other acknowledgers might_write_  stuff into a grob even
>>> after your personal acknowledger has been called.  So the basic workflow
>>> is to use the various acknowledgers to_record_  the grobs you are
>>> interested in and_write_  stuff into them (or do read/write stuff that
>>> more or less is accumulative and/or really unrelated to other
>>> engravers), and then use the process-acknowledged hook for processing
>>> (including_reading_) the grobs you had recorded.
>>>
>>> You can create new grobs in process-acknowledged.  That will lead to a
>>> new cycle of acknowledger calls followed by process-acknowledged.  Only
>>> when all those cycles are over is stop-translator-timestep called, and
>>> then creating grobs is no longer an option.
>>
>> Thanks David.  That's beautifully clear.
>
> I just caught up with all the mailing lists, being back from holiday, 
> and I’d be interested in a working example for this solution. Would you 
> mind sharing it?

There already is a helpful working example in the code base.  See

input/regression/scheme-engraver.ly

This doesn't go as far as creating new grobs, so I've attached a
simple example that does.  This is a bit of a hack, used as part of
a learning process, and a bit messy as it evolved from an earlier
attempt, but it illustrates one way.

Actually, comments from the experts on this would be very helpful.

Trevor
\version "2.19.40"

% Example of using Scheme engraver to add markup based on note duration

% Avoids repeated durations on both chords and consecutive notes

%{
TODO
  Handle notes with different durations at one musical moment better
  Add dots
  Add bass courses
%}

#(define (t->m t)
   "Return the current moment of translator object @var{t}."
   (ly:context-current-moment (ly:translator-context t)))

% persistent variables for Lute_tab_duration_engraver
#(define previous-duration-log #f)	% to supress repeated durations
#(define ev #f)		% event
#(define en #f)		% engraver

Lute_tab_duration_engraver =
#(make-engraver
   ((initialize translator)
(format 1 "\n\n~16a: (initialize)\n" (t->m translator)))
   ((start-translation-timestep translator)
(set! ev #f)
(set! en #f)
(format 1 "~16a: (start-translation-timestep)\n" (t->m translator)))
   (listeners
 ((note-event engraver event)
  ; Save just the last event at each timestep
  ;TODO save shortest duration event?
  (set! ev event)
  (set! en engraver)
  (format 1 "~16a: detected this note event: ~a\n "
(t->m engraver) event)))
   (acknowledgers
 ((note-head-interface engraver grob source-engraver)
  (format 1 "~16a: saw ~a coming from ~a\n"
  (t->m engraver) grob source-engraver)))
   (end-acknowledgers
 ((beam-interface engraver grob source-engraver)
  (format 1 "~16a: saw end of ~a coming from ~a\n"
  (t->m engraver) grob source-engraver)))
   ((process-music translator)
(format 1 "~16a: (process-music)\n" (t->m translator))
(if ev
  (let ((duration-log
 (ly:duration-log (ly:event-property ev 'duration
(display duration-log)
(if (not (equal? duration-log previous-duration-log))
(let ((grob (ly:engraver-make-grob en 'TextScript ev)))
  (set! previous-duration-log duration-log)
  (ly:grob-set-property! grob 'direction UP)
  (ly:grob-set-property! grob 'text
(case duration-log
  ((2) (markup (#:musicglyph "rests.M2mensural")))
  ((3) (markup (#:musicglyph "flags.mensuralu03")))
  ((4) (markup (#:musicglyph "flags.mensuralu04")))
  ((5) (markup (#:musicglyph "flags

Re: Help with Scheme engraver please

[Trevor Daniels]

David Kastrup wrote Wednesday, August 24, 2016 7:48 AM


> "Trevor Daniels" <t.dani...@treda.co.uk> writes:
> 
>> Prompted by the recent discussion on lute tablature, I tried coding a
>> Scheme engraver to create the duration grobs but quickly ran into a
>> problem.  I need to collect information from both a Listener and an
>> Acknowledger so the obvious place to build the grob is in
>> stop-translator-timestep,
> 
> No, no, no.  stop-translator-timestep really is only for cleanup work.
> Stuff is no longer in working order then.  You want process-acknowledged
> here I think.
> 
> There will always be a call to process-acknowledged whenever grobs have
> been created, and _reading_ stuff from grobs should be delayed until
> then since other acknowledgers might _write_ stuff into a grob even
> after your personal acknowledger has been called.  So the basic workflow
> is to use the various acknowledgers to _record_ the grobs you are
> interested in and _write_ stuff into them (or do read/write stuff that
> more or less is accumulative and/or really unrelated to other
> engravers), and then use the process-acknowledged hook for processing
> (including _reading_) the grobs you had recorded.
> 
> You can create new grobs in process-acknowledged.  That will lead to a
> new cycle of acknowledger calls followed by process-acknowledged.  Only
> when all those cycles are over is stop-translator-timestep called, and
> then creating grobs is no longer an option.

Thanks David.  That's beautifully clear, and much better than the rather
terse sentence in the CG which misled me:

"If useful things are to be done to the acknowledged grobs, this should be 
deferred until all the acknowledging has finished, i.e., store the acknowledged 
grobs and process the information in a process-acknowledged () or 
stop-translation-timestep () function."

I took what appeared to be the stop-translation-timestep option.

I'll take a time-out and prepare a patch for the CG based on your mail.

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

Help with Scheme engraver please

[Trevor Daniels]

Prompted by the recent discussion on lute tablature, I tried coding a Scheme 
engraver to create the duration grobs but quickly ran into a problem.  I need 
to collect information from both a Listener and an Acknowledger so the obvious 
place to build the grob is in stop-translator-timestep, but my attempts all 
result in a LilyPond crash.  I'm on Windows Vista, so the crash code is not 
very helpful - 1073741819.

Minimal examples below.  The first creates a grob from the Listener and works 
fine.  The second tries to create a grob from stop-translator-timestep and 
fails.

What am I doing wrong?

This works:

\version "2.19.46"

engraver_demo =
#(make-engraver
   (listeners
 ((note-event engraver event)
  (let ((grob (ly:engraver-make-grob engraver 'TextScript event)))
(ly:grob-set-property! grob 'text "hi")

\layout {
  \context {
\Voice
\consists
\engraver_demo
  }
}

\relative {
  c'8
}

This fails:

\version "2.19.46"

#(define ev #f)

engraver_demo =
#(make-engraver
   (listeners
 ((note-event engraver event)
  (set! ev event)))
   ((stop-translation-timestep engraver)
  (let ((grob (ly:engraver-make-grob engraver 'TextScript ev)))
(ly:grob-set-property! grob 'text "hi"

\layout {
  \context {
\Voice
\consists
\engraver_demo
  }
}

\relative {
  c'8
}

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

Re: repeating bar numbers and rehearsal marks in frenched score

[Trevor Daniels]

Mark, you wrote Monday, August 01, 2016 6:03 PM


> At 14:21 on 01 Aug 2016, Phil Holmes wrote:
>
>>If you create an account on SourceForge and let us have the details,
>>I'll add you to the tracker users.
> 
> username: mkdev
> email: m...@opus11.net

You're now a developer AFA SourceForge is concerned, which means you can add 
Issues.  There are a few more hoops to jump through before you can submit 
patches.  Details are in 

http://lilypond.org/doc/v2.19/Documentation/contributor/summary-for-experienced-developers

and

http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

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

Re: GSoC spanners review/update

[Trevor Daniels]

Nathan, you wrote Tuesday, July 19, 2016 10:03 PM

> Can you please add my account starrynte (email address is 
> starry...@gmail.com)?

You're now a developer AFA SourceForge is concerned, which means you can add 
Issues.  There are a few more hoops to jump through before you can submit 
patches.  Details are in 

http://lilypond.org/doc/v2.19/Documentation/contributor/summary-for-experienced-developers

and

http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

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

Re: GSoC spanners review/update

[Trevor Daniels]

Nathan Chou wrote Tuesday, July 19, 2016 10:26 AM

> I have (except for one question below) finished adapting
> Dynamic_engraver and Dynamic_align_engraver to work cross-voice. I
> plan to continue with other spanners (perhaps slurs next), but I want
> to make sure I am on the right track. I organized my current progress
> in the gsoc-2016-spanners branch on my GitHub fork (
> https://github.com/starrynte/lilypond/compare/master...gsoc-2016-spanners
> ); any feedback would be welcome.

Congratulations and thanks for all the work you've done so far!
 
> Should I create an issue and upload
> what I currently have (working cross-voice support for dynamics) to
> Rietveld for code review? Or should I leave that for the end when the
> project is completed?

Create an issue and upload what you have done so far as soon as it is
operational.  That way it will receive a review and, once installed in
a development release, attract user comments which will help you in
your further work.

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

Re: Patch

[Trevor Daniels]

Steven, you wrote Friday, May 27, 2016 9:22 PM

>>Thomas Morley wrote Friday, May 27, 2016 3:07 PM
>>
>>> 2016-05-27 6:11 GMT+02:00 Steven Weber :

 Since I don't have an official mentor and the recommendation is that you
 send your first couple of patches to your mentor first, I thought I'd send
 it to the list and see if someone can take a look.

 Any feedback or next steps I should take?
>>>
>>> please ask Trevor or Phil for developer-status at source-forge. (cc-ing 
>>> both)
>>> Once this is done use git-cl to upload your patch. More in CG.
>>> An issue at sourceforge will be opened automatically and the patch
>>> itself will be put up on Rietveld.
>>> Then the usual patch-review-circle will start.
>>
>>Happy to do this.  Just let me have your username at SourceForge if you
>>have one already, or go to 
>>
>>https://sourceforge.net/p/testlilyissues/issues/
>>
>>click "Join" in the top right and create a username to send to me.
> 
> My SF user name is steven-weber.

Thanks.  You're added as a developer as far as SourceForge is concerned.
That means you can read, create and update issues there.

However, to use git-cl you also need to have an account at Rietveld, and have
a SF bearer token.  How to do this is described under configuring git-cl here:

http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

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

Re: Patch

[Trevor Daniels]

Hi Steven

Thomas Morley wrote Friday, May 27, 2016 3:07 PM


> 2016-05-27 6:11 GMT+02:00 Steven Weber :
>>
>> Since I don't have an official mentor and the recommendation is that you
>> send your first couple of patches to your mentor first, I thought I'd send
>> it to the list and see if someone can take a look.
>>
>> Any feedback or next steps I should take?
>
> please ask Trevor or Phil for developer-status at source-forge. (cc-ing both)
> Once this is done use git-cl to upload your patch. More in CG.
> An issue at sourceforge will be opened automatically and the patch
> itself will be put up on Rietveld.
> Then the usual patch-review-circle will start.

Happy to do this.  Just let me have your username at SourceForge if you
have one already, or go to 

https://sourceforge.net/p/testlilyissues/issues/

click "Join" in the top right and create a username to send to me.

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

Re: No countdown today

[Trevor Daniels]

David Kastrup wrote Saturday, May 14, 2016 9:19 AM

> James  writes:
> 
>> It seems that there is some intermittent issue at Savannah.gnu.org
>> that is stopping me from pulling or fetching (I am getting either
>> 'SSH-message' errors or 'fatal read' errors.
>>
> I got it mostly under control by reducing my MTU to 1400 from its
> default of 1500 on my wireless interface.  It would appear that
> something was not dealing gracefully with packet fragmentation and/or
> size.  While I consider it most likely to have been a problem at my end,
> it is at least conceivable that it might be a problem with the FSF's
> network connections.  Though I think that Savannah is on quite a
> different net than most of the gnu.org stuff, so that's a bit unlikely.
> 
> At any rate, just wanted to throw this out for people who might want to
> try whether fiddling with the MTU might make any difference with their
> setup.

I had a similar problem 6 years ago which was resolved by
changing the MTU value.  The details are recorded here:

http://lists.gnu.org/archive/html/lilypond-devel/2010-02/msg00400.html

Just in case these problems are something similar ...

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

Re: Rewriting the Translator definition framework

[Trevor Daniels]

David Kastrup wrote Friday, April 22, 2016 1:07 PM

> I am currently doing pitch 2 at first-class Scheme engravers and am
> sorely tempted to scratch the whole macro-based mess and do it via
> inheritance and templates.
> 
> Now the sore point is that the basic type for which Scheme functions are
> defined is that of a Translator.  And Engravers and Performers are
> inherited from Translators, and it is only when inheriting from
> Engravers/Performers that it is clear where the documentation is coming
> from: static and specific to some Translator type, or dynamic and
> defined per Engraver (as with Scheme engravers).  Similar for some
> dispatch tables.
> 
> So the salient point would be to use virtual inheritance for access to
> the translator documentation.  We don't use virtual inheritance
> elsewhere yet but, well, it's not like it hasn't been around a long time
> now (basically since times before there even was a C++ standard other
> than the ARM).  So it's not a particularly new challenge for the
> compiler, and its use would also be quite straightforward.  I don't see
> a comparably straightforward way to introduce documentation via a side
> path, and it would also open up the path for having other translator
> types (unspecific translators like the Timing_translator or even
> performers) created dynamically by Scheme later on without having to
> extend the macro mess.
> 
> I think that would be considerably cleaner than dragging a number of
> unused static components around for dynamically defined types.
> 
> Any principal objections?

Not really an objection; just a thought.  I can't comment on the
technicalities, and I've every confidence you can carry this through,
but I wonder about the position of existing compositions that include 
custom C++ engravers in the old (i.e. current) style.  I guess there
will be very few of these, but it would be a shame if they were to be
limited to 2.18 stable without a rewrite.

Might it be better to move forward to 2.20 before doing this so they 
could take advantage of all the 2.19 improvements in a stable release?

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

Re: Lilypond issue tracker account request

[Trevor Daniels]

Karl O. Pinc wrote Tuesday, March 22, 2016 2:32 PM

> On Tue, 22 Mar 2016 12:14:37 -
>
> "Trevor Daniels" <t.dani...@treda.co.uk> wrote:
> 
>> Karl O. Pinc wrote Tuesday, March 22, 2016 3:47 AM
> 
>> > I'd like an account in the lilypond issue tracker.  
>> 
>> Happy to add you to the Issue Tracker as a Member.
>> That allows you to comment on Issues without moderation.
>> That's the way to start.
>> 
>> You'll need to post or send me your SourceForge Username
>> so I can set that up.
> 
> I am "kpinc" at sourceforge.

Thanks.  You're added to the Issue Tracker as a Member.
That means you can freely comment on Issues.

https://sourceforge.net/p/testlilyissues/issues/

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

Re: Lilypond issue tracker account request

[Trevor Daniels]

Karl O. Pinc wrote Tuesday, March 22, 2016 3:47 AM

Hi Karl

> I'd like an account in the lilypond issue tracker.

Happy to add you to the Issue Tracker as a Member.
That allows you to comment on Issues without moderation.
That's the way to start.

You'll need to post or send me your SourceForge Username
so I can set that up.
 
> I'm thinking about someday contributing to lilypond
> in the area of harp related notation.  I'd probably
> start with the fingering notation.

Great!  The first step is to post specific issues that
you have identified to the bug list:
http://lists.gnu.org/archive/html/bug-lilypond/
for discussion and to have an Issue created.

Or to comment on existing issues.

> [snip]
>
> I've no idea if I'll every get around to contributing
> but am reading through the developer docs and it
> can't hurt to get setup for it.  FWIW I've done
> FOSS development work with FOSS tools.

When you are ready to contribute to a specific Issue,
post a patch to the bug list.

The first few patches are usually sheparded through the
system by one of the Devs before you are elevated to
Developer status.

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

Re: What to do with snippet "Centering markup on note headsautomatically"?

[Trevor Daniels]

Thomas Morley wrote Saturday, March 12, 2016 12:20 PM

> http://lists.gnu.org/archive/html/lilypond-user/2016-03/msg00302.html
> states correctly that the LSR-snippet "Centering markup on note heads
> automatically"
> http://lsr.di.unimi.it/LSR/Item?id=637
> doesn't work in 2.19.x anymore.
> It's tagged doc, so it appears in snippets.
> 
> It turns out that the custom-engraver, setting TextScript-parent to
> NoteColumn, is unnecessary in 2.19. (NoteColumn is already x-parent)
> 
> Sufficient would be to do (deleting the engraver and other settings):
> 
> \layout {
>  \context {
>\Voice
>\override TextScript.self-alignment-X = #CENTER
>\override TextScript.parent-alignment-X = #CENTER
>  }
> }
> 
> 
> Though, what to do?
> Creating a snippet in snippets/new
> or
> simply remove the doc-tag in LSR?
> 
> Opinions?

Remove the doc-tag.

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

Re: Unable to use git-cl

[Trevor Daniels]

Carl, you wrote Tuesday, March 08, 2016 6:54 PM
> 
> I can upload patches to Rietveld, as you can see at
> 
> https://codereview.appspot.com/283550043
> 
> but the links to the issue tracker never get made.
> 
> As far as I can see, we have a custom git-cl, so I can't get general help
> anywhere but on the devel list.
> 
> I would appreciate anybody who can point me in a direction that I can
> troubleshoot my problem.

The SSL error you're seeing has been reported when users upgraded to python 
2.7.9.  Have you perhaps got this or a later version of python installed?  I 
still have 2.4.5, as distributed with Lily, and it seems to work OK.

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

Re: Verifying issues

[Trevor Daniels]

Simon Albrecht wrote Wednesday, March 02, 2016 10:52 PM

> I noticed that there have been many ‘Issues to verify’ around, so I 
> started to catch up with these. Now the question is: Shouldn’t we only 
> mark issues as verified, when the change is already included in an 
> official release?

Yes, that is correct.  See Regular Maintenance under
http://www.lilypond.org/doc/v2.19/Documentation/contributor/bug-squad-checklists

Verified fixes should be in an available release.

> For curiosity, following the CG instruction I took the committish from 
>  – claimed to be 
> ‘Fixed_2_19_38’ – and fed it into , 
> and it worked. So according to the instruction, I should mark the issue 
> verified, although the change is not contained in the most recent 
> release, 2.19.37.

Which instruction is this?  I think Phil's tool finds any commit that is in
the git master, not just those in built releases.

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

Re: Commit access

[Trevor Daniels]

Paul Morris wrote Monday, February 29, 2016 1:57 AM


> In issue 4776 James wrote:
> 
>> @Paul, you may want to apply for commit access yourself if you like as I 
>> think you've done enough work for the 'cause' to
> 
> So I’d like to request commit access.  Among other things this will save 
> James the extra work of committing patches for me.

Who has the authority to action this request now?  It seems a perfectly 
reasonable one.

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

Re: Allura account

[Trevor Daniels]

Hi Valentin

Nice to have you back!  

I've added your username as a Developer,  so you should now be able to Read, 
Create and Update Issues.

Trevor
  
- Original Message 
From: "Valentin Villenave" <valen...@villenave.net>
To: "Trevor Daniels" <t.dani...@treda.co.uk>
Cc: "Carl Sorensen" <c_soren...@byu.edu>; "Phil Holmes" <m...@philholmes.net>; 
"Carl Sorensen" <carl.d.soren...@gmail.com>; "Lily-Devel List" 
<lilypond-devel@gnu.org>
Sent: Monday, February 22, 2016 7:36 PM
Subject: Re: Allura account


On Tue, Feb 16, 2016 at 2:42 PM, Trevor Daniels <t.dani...@treda.co.uk> wrote:
> I see you're already registered as a Developer on Allura.  Maybe Phil just 
> beat me to it.

Greetings Trevor,
could you add me as well? (On the off chance I’m able to contribute a
bit more to LilyPond in weeks to come...)

My SF usename is v_villenave (it has been inactive for nearly eight
years but I’ve just unearthed it).

Cheers!

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

Re: Allura account

[Trevor Daniels]

Hi Carl

> My user name is cds4byu

I see you're already registered as a Developer on Allura.  Maybe Phil just beat 
me to it.

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

Re: text-replacements: add and the like (issue 281470043 bysimon.albre...@mail.de)

[Trevor Daniels]

Simon Albrecht wrote Monday, January 25, 2016 8:03 PM
 
> How should I (and James) interpret the silence here? Any more opinions?

If a user has requested additional characters which have an html character
(non-numeric) definition and a developer is willing to do the work I see no 
reason why they should not be added.

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

Re: Add RemoveEmptyStavesAll command (issue 283050043 bysimon.albre...@mail.de)

[Trevor Daniels]

Simon Albrecht wrote Thursday, January 14, 2016 3:34 PM


> On 14.01.2016 16:20, d...@gnu.org wrote:
>> The name is rather clumsy (and it does not help that the issue report
>> talks about "\RemoveEmptyStavesFirst" while the actual patch and the
>> Rietveld review has "\RemoveEmptyStavesAll").
>>
>> How about "\RemoveAllEmptyStaves" ?
> 
> Vote taken – what do others think?

Definitely better.  With this I don't think we need \RemoveEmptyStavesFirst.
Is there a musical need to remove empty staves from only the first system?

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

Re: Request for developer status on the issue tracker

[Trevor Daniels]

Heikki Tauriainen wrote Friday, January 08, 2016 1:04 PM

> I understand that running git-cl to create new issues requires
> developer status on the issue tracker at Sourceforge. I've just
> created a SourceForge account, and would kindly request developer
> access to the issue tracker (if possible). My username at SourceForge
> is "htlily".

Hi Heikki

Added to Devs as requested.  You'll be known in issues as "H T LilyPond".

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

Re: Request for developer status on the issue tracker

[Trevor Daniels]

Heikki, you wrote Friday, January 08, 2016 4:18 PM

> I still managed (like I always seem to do when I run git-cl with
> several months having passed since the last time...) to fail to submit
> a patch with git-cl fully successfully (*), so I had to create a new
> issue for the tracker (https://sourceforge.net/p/testlilyissues/issues/
> 4730/) manually. I'm sorry if I didn't get the values of all metadata
> fields right when creating the issue - I'd be grateful for any help
> whether something still needs to be fixed there.

Only the Owner field was missing, so I added your username,
and Accepted the Issue.
 
> (*) Failing with git-cl was simply my own fault, as I didn't anticipate
> (remember) that git-cl would need to open a web browser in the middle
> of the patch submission procedure - this didn't work well as I wasn't
> logged on in a GUI session, and had to abort the script.

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

Re: Error in git-cl creating a new issue

[Trevor Daniels]

John Gourlay, you wrote Wednesday, January 06, 2016 3:07 AM


>I just submitted a small change to the Contributors Guide using git-cl. The 
>patch got into codereview.appspot.com, but not into 
>sourceforge.net/p/testlilyissues/issues/. I let git-cl create a new issue for 
>the patch, but it produced a bunch of error messages. Does anyone have an idea 
>about why? How do I proceed now? The error messages were:

It was because you had Member rather than Developer status at SourceForge.  
I've upgraded you now.  Please try again.

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

Re: Error in git-cl creating a new issue

[Trevor Daniels]

Simon Albrecht, you wrote Wednesday, January 06, 2016 1:14 PM

> On 06.01.2016 13:26, Trevor Daniels wrote:
>> John Gourlay, you wrote Wednesday, January 06, 2016 3:07 AM
>>
>>
>>> I just submitted a small change to the Contributors Guide using git-cl. The 
>>> patch got into codereview.appspot.com, but not into 
>>> sourceforge.net/p/testlilyissues/issues/. I let git-cl create a new issue 
>>> for the patch, but it produced a bunch of error messages. Does anyone have 
>>> an idea about why? How do I proceed now? The error messages were:
>> It was because you had Member rather than Developer status at SourceForge.  
>> I've upgraded you now.  Please try again.
> 
> Ah, interesting. Would that be the same for me? I had the same problem.

No, you've always had Dev status.  In fact you were the second one after James 
to be added.  Must be something else in your case.  Has git-cl never worked for 
you?

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

Re: Error in git-cl creating a new issue

[Trevor Daniels]

Simon, you wrote Wednesday, January 06, 2016 4:05 PM

> The rietveld part is fine. Only the Allura part reliably fails, with the 
> same kind of messages that John reported.
> I’ve just been creating issues manually.

Well, a 403 HTTP error means the server received and understood
the request but decided the request was forbidden.

Assuming you have a valid bearer token, see
 https://sourceforge.net/auth/oauth/, 

and have set up the full url to the correct page:
 https://sourceforge.net/p/testlilyissues/issues/

I don't know what else might be wrong.

If neither of these are the reason we'll have to wait until 
Phil can take a look.

Trevor


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

Re: lilypond-auto doesn't work correctly

[Trevor Daniels]

Werner, you wrote Tuesday, December 22, 2015 4:11 AM

> Is it possible to resurrect correct functionality of the
> `lilypond-auto' list?  Currently, no mails from allura are sent to
> it, which makes it sort of useless...

There is a comparable list, Testlilyissues-auto, at SourceForge.
I've added lilypond-a...@gnu.org to it.

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

Re: Musicians prefer LilyPond scores, study finds

[Trevor Daniels]

Francisco Vila wrote Thursday, December 17, 2015 4:53 PM

> I just gained my PhD. My humble thesis tells the design and results of
> an experiment with a number of musicians, comparing lilypond scores
> with the originals which those scores were copied from.

Congratulations Dr Vila!

As your thesis concerns LilyPond I think many of us would be interested to see 
a translation of the abstract to English, if that is possible.

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

Re: On issues that are marked as 'Patch_Abandoned'

[Trevor Daniels]

I think the end-point of this discussion looks like consensus, and that's 
pretty well what I've been doing to tidy up some inactive issues.  Let's see 
how it looks as a patch to the CG.

Trevor

- Original Message - 
From: "James Lowe" <p...@gnu.org>
To: "lilypond-devel" <lilypond-devel@gnu.org>
Cc: "Trevor Daniels" <t.dani...@treda.co.uk>; "David Kastrup" <d...@gnu.org>; 
"simon Albrecht" <simon.albre...@mail.de>
Sent: Saturday, November 21, 2015 7:14 PM
Subject: On issues that are marked as 'Patch_Abandoned'


> Hello,
> 
> 
> 
> Trying to collate all the that David, Simon and Trevor kindly came up
> with (although may end up repeating myself, so my apologies in advance).
> I collated the main points from each of the three and have responded,
> inline, to those points.
> 
> I hope this isn't 'bad form' but the thread was so interlaced with
> comments and comments of comments, I wanted to make sure that I didn't
> misrepresent or misunderstand anyone.
> 
> ***
> 
> [David K]
> A whole bunch of the issues you have below are for Duplicate, Invalid,
> or independently Fixed issues. An abandoned patch is natural to go with
> that and should not require any additional action. It's only for open
> issues that an abandoned patch might form a point of reference.
> 
> [JAMES]
> What I would like to perhaps suggest here is that those that are
> Duplicate, Invalid or Independently fix (i.e. also technically a
> duplicate I suppose) can keep those 'Status' entries but the 'Patch'
> entry can be moved to 'blank'.
> 
> [David K]
> The only suspicious combination is an abandoned patch for a Started
> issue where the issue owner is the same person responsible for the
> patch. That's likely an oversight (or the owner tried to work on a
> different patch and lost track at some point of time).
> 
> [JAMES]
> Which sounds reasonable. Hence the point about removing the Patch entry
> (i.e. setting it to blank) and making sure the Status field is set
> accordingly (Invalid or Duplicate).
> 
> [David K]
> I don't think abandoned patches require any action of their own.
> "Started" issues may independently be considered as not being worked on
> after a considerable amount of time.
> 
> [JAMES]
> Would 9 months be acceptable as a 'considerable amount of time'? I can
> then start on trying to make sure that I go back as far as necessary
> (i.e. everything before April/May of this year) and then try to keep on
> top of it each month thereafter; trying to make sure that issues marked
> 'abandoned' are never older than 6 months.
> 
> [David K]
> In that case, it might get disowned, reset to "Accepted" (when it's
> still relevant) and _possibly_ any existing patch may be marked
> "abandoned" in that process.
> 
> [JAMES]
> Certainly it should get set to 'blank' owner I think (and put back to
> 'Accepted'). Anything younger than 9 months (see my last comment above)
> would still be marked as 'abandoned' (if not already). If the previous
> owner disagrees or still wants to 'own' the issue (whatever that may
> mean for them) then they can always update the ticket accordingly. This
> would have two effects; first the issue would be 'updated' in terms of
> its 'last edited' date (so to speak) bringing it forward from any
> 6-month-or-older filter, and secondly the Issue would have an entry -
> either just the Owner and Status change and/or a 'I am still working on
> this' entry in the thread. This puts the onus back on the developer and
> if they choose to do nothing, then that can be assumed to remove doubt
> on the state of the issue for others who may want to work it or who may
> be ignoring it, thinking that the other developer is still doing
> something (Graham P's universal 'Law of the 'Hot Potato'!)
> 
> [David K]
> But I don't think that any patch already marked "abandoned" necessitates
> any further action on its own.
> 
> [JAMES]
> Well I think that 'depends' (see my previous replies above for my
> reasoning).
> 
> ***
> 
> [Simon A]
> One can see immediately that a patch has already been prepared for this
> issue, which may serve as a starting point for future work. True,
> anybody to pick up such an issue would have to read through the entire
> discussion anyway, but I’d rather ask the other way round:
> What’s the benefit of deleting the Patch label, or the harm that a
> Patch:abandoned does?
> 
> [JAMES]
> My further thoughts on what I said before were if a patch was only
> abandoned because a developer gave up or ran out of time (or something
> similar to that) other than the fact it was 'Invalid' or 'Duplicate';
> the

Re: SubdivideBeam gives undesired result when beaming over more thana quarter note

[Trevor Daniels]

Urs Liska wrote Thursday, November 19, 2015 11:20 PM

> However, I have a question: Where are the CLI messages defined that are
> used in the git-cl process? This is still talking about Google issue
> tracker items.

Good point.  That was why I thought you might not have updated git-cl.

Copying to Phil, as he is the expert on the new git-cl.

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

Re: Allura account

[Trevor Daniels]

Hi Urs

This isn't documented as the expectation was that this was a brief temporary 
home for the issues DB while a new permanent home at Savannah was brought into 
service.  But it seems that has stalled, so maybe we ought to rethink this and 
document the present position.

Anyway, all you need to do is visit

http://sourceforge.net/p/testlilyissues/issues/

click on Join at top right, enter the details, and let me know the Username you 
have selected.  I can then give you Developer status, and the instructions from 
James will then work.  None of the permissions at GoogleCode were transferred 
as some objected to using SourceForge, so people are being re-registered only 
on request.

Trevor

- Original Message - 
From: "Urs Liska" 
To: ; 
Sent: Thursday, November 19, 2015 2:22 PM
Subject: Allura account


> Hi Trevor and Phil,
> 
> I just tried to upload my first patch after the move to Allura.
> Uploading to Rietveld *did* work, but now it seems I need an account at
> the Allura server.
> 
> Would one of you mind creating one for me?
> 
> I'm not sure about the email addresses, though.
> So far I used lilyli...@googlemail.com as I think the Google tracker
> required this. Consequently I'm also registered to Rietveld with that
> address. But I think this is obsolete now
> 
> So I would actually prefer using g...@ursliska.de if possible. I just
> checked: My commits to LilyPond's source are assigned both that one and
> u...@openlilylib.org.
> 
> I'm slightly confused, sorry ...
> 
> Thanks
> Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allura account

[Trevor Daniels]

Oh, and you also need to pull the latest version of git-cl.

Trevor

- Original Message - 
From: "Trevor Daniels" <t.dani...@treda.co.uk>
To: "Urs Liska" <u...@openlilylib.org>
Cc: "Lily-Devel List" <lilypond-devel@gnu.org>
Sent: Thursday, November 19, 2015 3:18 PM
Subject: Re: Allura account


> Hi Urs
> 
> This isn't documented as the expectation was that this was a brief temporary 
> home for the issues DB while a new permanent home at Savannah was brought 
> into service.  But it seems that has stalled, so maybe we ought to rethink 
> this and document the present position.
> 
> Anyway, all you need to do is visit
> 
> http://sourceforge.net/p/testlilyissues/issues/
> 
> click on Join at top right, enter the details, and let me know the Username 
> you have selected.  I can then give you Developer status, and the 
> instructions from James will then work.  None of the permissions at 
> GoogleCode were transferred as some objected to using SourceForge, so people 
> are being re-registered only on request.
> 
> Trevor
> 
> - Original Message - 
> From: "Urs Liska" <u...@openlilylib.org>
> To: <t.dani...@treda.co.uk>; <m...@philholmes.net>
> Sent: Thursday, November 19, 2015 2:22 PM
> Subject: Allura account
> 
> 
>> Hi Trevor and Phil,
>> 
>> I just tried to upload my first patch after the move to Allura.
>> Uploading to Rietveld *did* work, but now it seems I need an account at
>> the Allura server.
>> 
>> Would one of you mind creating one for me?
>> 
>> I'm not sure about the email addresses, though.
>> So far I used lilyli...@googlemail.com as I think the Google tracker
>> required this. Consequently I'm also registered to Rietveld with that
>> address. But I think this is obsolete now
>> 
>> So I would actually prefer using g...@ursliska.de if possible. I just
>> checked: My commits to LilyPond's source are assigned both that one and
>> u...@openlilylib.org.
>> 
>> I'm slightly confused, sorry ...
>> 
>> Thanks
>> Urs
> ___
> 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

Keeping the list of issues in active development current

[Trevor Daniels]

Devs and Bug Squad

The list of issues obtained by clicking Open (Begun) in Allura now contains 
just those issues that were Started within the last 6 months or have a 
currently active Owner.

Those that don't have a currently active Owner should be reverted to 
Status:Accepted when they have been moribund for more than 6 months.  Those 
that do have a currently active Owner should be so reverted by the Owner 
themselves if or as soon as they have ceased working on them.  In that way the 
Open (Begun) list should eventually contain just those issues with patches that 
are in active development.

Trevor

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

Tidying-up the Issues DB

[Trevor Daniels]

Devs, Bug Squad:

Many of the Issues with Status:Started are no longer active, with many not 
seeing any change for several years.  Following the move of the Issues DB from 
GC to SF many of the original owners of these Started Issues have not 
re-registered at SF; indeed many are no longer active on the devel list, and it 
seems inconsistent for these issues to have a status of Started when they have 
no Owner.  I'd like to tidy up this situation by reverting these issues to 
Status:Accepted so they become more obviously available for someone else to 
select for further work by appearing in the Open (Accepted) list.

To this end I've already reassigned those not seeing any action for over 3 
years.  Unless I hear objections I'll continue reassigning more recently 
moribund issues until the Open (Begun) and Open (Patch) lists reflect more 
closely the issues actually under active consideration.

Comments?

Trevor


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

Re: Allure and git-cl troubleshooting

[Trevor Daniels]

Hi Paul

Looking at the error again it seems to be a problem with authenticating at 
GoogleCode rather than Allura at SourceForge.

Trevor

- Original Message - 
From: "Paul Morris" <p...@paulwmorris.com>
To: "James" <p...@gnu.org>
Cc: "Phil Holmes" <m...@philholmes.net>; "Trevor Daniels" 
<t.dani...@treda.co.uk>; "lilypond-devel" <lilypond-devel@gnu.org>
Sent: Monday, October 26, 2015 6:15 PM
Subject: Re: Allure and git-cl troubleshooting


Thanks Trevor, Phil, and James.  I believe I have everything configured 
correctly.  (I removed my bearer token below, but I just double checked and 
it’s correct.)

[lilypond-git (whiteout-style)]$ git cl config
Rietveld server (host[:port]) [codereview.appspot.com]: 
Allura server [https://sourceforge.net/p/testlilyissues/issues/]: 
Allura bearer token (see https://sourceforge.net/auth/oauth/) [***REMOVED***]: 
CC list ("x" to clear) [lilypond-devel@gnu.org]: 

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

Re: Tidying-up the Issues DB

[Trevor Daniels]

James wrote Monday, October 26, 2015 11:54 AM

> On 26/10/15 11:29, Trevor Daniels wrote:
>> Devs, Bug Squad:
>>
>> Many of the Issues with Status:Started are no longer active, with many not 
>> seeing any change for several years.  Following the move of the Issues DB 
>> from GC to SF many of the original owners of these Started Issues have not 
>> re-registered at SF; indeed many are no longer active on the devel list, and 
>> it seems inconsistent for these issues to have a status of Started when they 
>> have no Owner.  I'd like to tidy up this situation by reverting these issues 
>> to Status:Accepted so they become more obviously available for someone else 
>> to select for further work by appearing in the Open (Accepted) list.
>>
>> To this end I've already reassigned those not seeing any action for over 3 
>> years.  Unless I hear objections I'll continue reassigning more recently 
>> moribund issues until the Open (Begun) and Open (Patch) lists reflect more 
>> closely the issues actually under active consideration.
>>
>> Comments?
> 
> I think you should also be setting the 'owner' if it has any to 'blank'
> (if that wasn't already implied) for issues that are 'Started' and have
> an 'owner' but have had no activity for a similar amount of time.

I shall, although the Owner field is almost always blank anyway for these 
moribund issues.  During the migration it was filled in only for those Devs who 
were already registered at SF.

> I think this may overlap the 'patch-abandoned' discussion - which i
> still need to go back a review as part of my Patch Meister duties.

I don't think what I said conflicts with anything we discussed then - I'm just 
getting on  with doing it.  Usually I shall leave the patch status unchanged, 
unless on inspection I think it looks wrong, in which case I shall add a 
comment explaining any change I make.

Trevor

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

Re: Allure and git-cl troubleshooting

[Trevor Daniels]

Paul Morris wrote Sunday, October 25, 2015 9:33 PM


> I gave git-cl another try and got the same error from my previous message, 
> ending in:
>
> File "/usr/lib/python2.7/urllib2.py", line 558, in http_error_default
>  raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
> urllib2.HTTPError: HTTP Error 404: Not Found

Hhm, assuming you've got a bearer token from
https://sourceforge.net/auth/oauth/, 
and have set up the full url to the correct page:
https://sourceforge.net/p/testlilyissues/issues/
I don't know what else might be wrong.

We'll have to let Phil have a look.

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

Re: Allure and git-cl troubleshooting

[Trevor Daniels]

Paul Morris wrote Sunday, October 25, 2015 7:48 PM

> Below is an error I got trying to upload with git-cl, the new Allura version 
> that’s in LilyDev4.  I followed James and Phil’s recent email exchange about 
> how to do config with Allura server url, source forge account, bearer token, 
> etc.  
> 
> Any ideas on why it’s not working?  Do I need to be an authorized user on the 
> Allura tracker, perhaps?

Maybe not the cause of this particular problem, but only authenticated 
developers are permitted to edit tickets, which is what git-cl needs to do.  
Anyone submitting a patch is de facto a developer, so all you need to do is 
Join (see the Join button top right on the Issues page) the TestLilyIssues 
project and announce on the devel list what username you have chosen and we'll 
authorise you as a Developer.

Trevor

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

Re: Allure and git-cl troubleshooting

[Trevor Daniels]

Paul, you wrote Sunday, October 25, 2015 8:45 PM


>> On Oct 25, 2015, at 4:32 PM, Trevor Daniels <t.dani...@treda.co.uk> wrote:
>> 
>> Maybe not the cause of this particular problem, but only authenticated 
>> developers are permitted to edit tickets, which is what git-cl needs to do.  
>> Anyone submitting a patch is de facto a developer, so all you need to do is 
>> Join (see the Join button top right on the Issues page) the TestLilyIssues 
>> project and announce on the devel list what username you have chosen and 
>> we'll authorise you as a Developer.
> 
> Ok, my username on sourceforge is paulwmorris.

Thanks Paul - should be good to go now.

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

Re: StaffPad

[Trevor Daniels]

Urs Liska wrote Thursday, October 08, 2015 10:34 AM

> Am 08.10.2015 um 11:32 schrieb Werner LEMBERG:
>
>> I was quite impressed seeing the following video.
>>
>>   https://www.facebook.com/verge/videos/975966512439692/
>>
>> If writing music like this *really* works, I could imagine that even I
>> would use a computer instead of writing on paper...
> 
> I think even more relevant to us is: is it ever possible to make that
> work for entering music into LilyPond?

It's pretty clear from the videos and the StaffPad blog

http://blog.staffpad.net/

that the main attraction of this is as a composing tool
(assuming it works well, of course), something that 
LilyPond is not designed to do.  MusicXML provides the 
link between the two, again assuming that it works well,
but at present that would be one-way only.

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

Fw: [forge:site-support] #11271 Discussion posts vanish if a ticket's title is edited

[Trevor Daniels]

Hi, devs and bug squad members using Allura

I'm told (see below) that the bug which made discussion posts vanish after 
editing the description has been fixed.  Please let me know if you come across 
any counter-examples.

Trevor

- Original Message - 
From: "John Barrett" <jwb1...@users.sf.net>
To: "[forge:site-support] " <11...@site-support.forge.p.re.sf.net>
Sent: Tuesday, September 29, 2015 7:44 PM
Subject: [forge:site-support] #11271 Discussion posts vanish if a ticket's 
title is edited


>- **status**: assigned --> fixed
> - **Comment**:
> 
> Greetings,
> Our engineering team has indicated this issue has been resovled.
> Thanks
> SourceForge Support
> 
> 
> 
> ---
> 
> ** [site-support:#11271] Discussion posts vanish if a ticket's title is 
> edited**
> 
> **Status:** fixed
> **Labels:** engr nf-10570 
> **Created:** Sat Sep 19, 2015 03:44 PM UTC by Trevor Daniels
> **Last Updated:** Mon Sep 21, 2015 10:00 PM UTC
> **Owner:** nobody
> 
> 
> The discussion posts of a ticket sometimes vanish if the ticket title or 
> custom fields or description are edited.  They are not deleted, as they 
> reappear if the ticket is simply edited again and saved without change.  
> While normally this is not serious, it can be if a bulk edit is done on a 
> large number of tickets, as the original selection of tickets cannot be 
> recreated after the bulk edit is done.
> 
> The url shown is left in a state with the discussion posts not visible.
> 
> 
> ---
> 
> Sent from sourceforge.net because you indicated interest in 
> <https://sourceforge.net/p/forge/site-support/11271/>
> 
> 
> 
> To unsubscribe from further messages, please visit 
> <https://sourceforge.net/auth/subscriptions/>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Google-to-Allura port adds brackets around rests

[Trevor Daniels]

- Original Message - 
From: "Trevor Daniels" <tr...@treda.co.uk>
To: "Trevor Daniels" <t.dani...@treda.co.uk>; "Lily-Devel List" 
<lilypond-devel@gnu.org>; "Simon Albrecht" <simon.albre...@mail.de>
Sent: Tuesday, September 08, 2015 11:04 PM
Subject: Re: Google-to-Allura port adds brackets around rests


> 
> Trevor Daniels wrote Tuesday, September 08, 2015 12:37 PM
>> 
>> Simon Albrecht wrote Monday, September 07, 2015 11:28 PM
>>>
>>>> Am 08.09.2015 um 00:23 schrieb Trevor Daniels:
>>>> Simon Albrecht wrote Monday, September 07, 2015 7:16 PM
>>>>> Am 07.09.2015 um 20:09 schrieb Dan Eble:
>>>>>> Compare
>>>>>>
>>>>>> https://code.google.com/p/lilypond/issues/detail?id=1677
>>>>>> https://sourceforge.net/p/testlilyissues/issues/1677/ 
>>>>>> <https://sourceforge.net/p/testlilyissues/issues/1677/>
>>>>>>
>>>>>> The latter has square brackets around rests, e.g. “[r4]” instead of “r4”.
>>>>>
> 
> Further to this, there are over 300 issues containing rests in square
> brackets, of which 77 are still active (i.e. they have a Status of Accepted
> Started or New.)  So we really ought to fix those if it is at all possible.

With help from Simon the square brackets around rests in those 77 issues
have now all been fixed by hand.  I'm afraid the remainder, none of which are
still active, will have to remain wrong, unless someone else wants to
practice editing Allura issues.

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

Re: Allura task list

[Trevor Daniels]

Trevor Daniels wrote Friday, September 18, 2015 9:14 PM
> 
> Dan Eble wrote Tuesday, September 15, 2015 2:08 AM
> 
>> It would be convenient to have a search button that finds issues assigned to 
>> the logged-in developer which are not yet fixed.  Is that possible?
>
> I can't see a way to do this with a single button, but you can do it already 
> with just a couple of clicks:
> 
> Hit Open(All), then click on Owner and select "eble".  This will bring up the 
> five open issues currently owned by you.

I've found a way (I think).  Try clicking on My Open Issues.

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

Re: Allura task list

[Trevor Daniels]

Dan Eble wrote Monday, September 28, 2015 10:37 PM


> On Sep 28, 2015, at 11:27 , Trevor Daniels <t.dani...@treda.co.uk> wrote:
>> 
>> Trevor Daniels wrote Friday, September 18, 2015 9:14 PM
>> 
>>> Dan Eble wrote Tuesday, September 15, 2015 2:08 AM
>> 
>> I've found a way (I think).  Try clicking on My Open Issues.
>> 
> Three cheers for Trevor!

Thanks.  Of course it only works for issues added after you registered with SF, 
unless you go back and edit the Owner field of the older issues.

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

Re: List of Issues with 'patch_abandoned' assigned to them - as ofSeptember 2015

[Trevor Daniels]

David Kastrup wrote Sunday, September 20, 2015 11:34 PM

> James Lowe  writes:
> 
>> On 20/09/15 22:52, Simon Albrecht wrote:
>>> On 20.09.2015 23:10, James Lowe wrote:

 My thinking is like this; I pick an issue to work on, I do some stuff,
 make a patch, have a discussion, then get bored and go silent.

 The issue is now patch_abandoned.

 What is the benefit of leaving this label (or even having it in the
 first place)
>>> 
>>> One can see immediately that a patch has already been prepared for this
>>> issue, which may serve as a starting point for future work. True,
>>> anybody to pick up such an issue would have to read through the entire
>>> discussion anyway, but I’d rather ask the other way round:
>>> What’s the benefit of deleting the Patch label, or the harm that a
>>> Patch:abandoned does?
>>
>> Extra cruft that serves no purpose as I can see.
>>
>> We have waiting/needs_work already.
> 
> Both of those indicate that the Patch is not (yet?) abandoned.

The key difference is one of ownership.  The LP developers have
a tradition of not interfering (other than by commenting) on the development
of a patch to an issue already "owned" by someone else.  Patch 
waiting/needs_work means the current owner is still planning to do more 
work, so other devs let it ride.  Patch abandoned means the previous 
dev has given up, so anyone else is free to take it up and change the 
ownership.  Well, at least that's my understanding.

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

Tracking Issue activity on Allura at SF

[Trevor Daniels]

Devs and Bug Squad:

If you haven't yet signed up to Allura at SourceForge you may be missing 
discussions on Issues and finding it difficult to keep up with changes to the 
Issues DB (there are already around 40 new issues and many more comments and 
changes since we moved from GC a month ago).  As an alternative you can track 
changes to the Issues DB on this (advert-free!) page: 
https://sourceforge.net/p/testlilyissues/activity
without needing to create an account and without needing to sign up for emails. 
 By clicking on "Comment" you can go straight to the referenced comment or by 
clicking on the Ticket number you can see all the discussion posts.

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