Packaging LilyPond after distribution moves to Guile 2 [was Re: intent bug on line start]

[Trevor Daniels]

- Original Message - 
From: "David Kastrup" 

> I had recently upgraded my system to 64bit and now
> have been able to install the default Ubuntu 2.18.2.  I was interested
> to see how they dealt with Guile no longer being in distribution.
> 
> dak@lola:/tmp$ ldd /usr/bin/lilypond
> not a dynamic executable
> dak@lola:/tmp$ file /usr/bin/lilypond
> /usr/bin/lilypond: POSIX shell script, ASCII text executable
> dak@lola:/tmp$ cat /usr/bin/lilypond
> #!/bin/sh
> export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu/lilypond/2.18.2/guile"
> exec "/usr/bin/lilypond.real" "$@"
> 
> O.K.
> 
> Not bad at all.  Maybe we should create some advice for packagers?  This
> here is way better than "muddle through with the current Guile-2.0 state
> and let your users alone with the problems".

That does indeed seem quite elegant, and neatly solves
the problem caused by the move of the distribution to Guile-2.

Could we make a similar change to our own, i.e. LilyPond's, distributions?

Trevor


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

Re: intent bug on line start

[Trevor Daniels]

David Kastrup wrote Friday, August 18, 2017 3:00 PM


> bb  writes:
> 
>> With
>> indent = 0\mm
>> activated the first bar will be wrong, as the first notes of voice one
>> and two align. They should not becauser of r8 (\voiceOne ) and r16
>> (\voiceTwo ) in front.
>> Without, say
>> % indent = 0\mm
>> commented out the layout is correct.
> 
> Cannot see the described effect.  However:

The effect is visible in 2.18.  I can't find any
evidence this bug was reported before, but it is
no longer present in recent releases.

@bb: I suggest you upgrade to the latest 2.19
release.  This bug is fixed there.

Thanks for reporting.

Trevor


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

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
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug

[Trevor Daniels]

Simon Albrecht wrote Wednesday, February 01, 2017 5:49 PM

> On 01.02.2017 18:08, Mike Solomon wrote:
>
>> Yeah, just checked it out, you can remove the spurious if (brain fart).
>> I don’t have time to propose a patch today but I can do that on Monday if no 
>> one else can get around to it (I haven’t set up git-cl yet on this machine).
>> Alternatively, I can just push the change to master if people are OK with 
>> that.
> 
> Shouldn’t at least the normal patch testing be done?

Yes.  This fix isn't urgent, so there's no problem with waiting a few days for
Mike to set up git-cl and to obtain access to the Issue DB at SF.  Mike - 
set up a SF account and post the user name to the Dev list.

And, Mike, we never push to Master - always to Staging, even after testing.

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

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
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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
 
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: barNumberCheck with repeats

[Trevor Daniels]

Robert, you wrote Wednesday, November 09, 2016 9:49 AM

>> \set Score.ignoreBarChecks = ##t
> 
> Ah, great - thanks David!
>
> I guess, a mention of this in the sections "Repeats in MIDI" would be a 
> good idea - I'd be happy to do that, if the Doc-people let me know, how 
> I can do that.

Well, there's the long and the short answer.

The short answer is simply send your proposed plain text to
the bug-list (that's  and someone will
pick it up, vet it, add any necessary formatting and guide 
it through the updating procedure.

The long answer (that's 'long' in the sense of more work for
you, but also more rewarding!) is to read the section on
doc work in the Contributors' Guide:
http://lilypond.org/doc/v2.19/Documentation/contributor/documentation-work
and work from there.  You'll get plenty of help, should you
need it.

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

Re: Font cache issues on Windows 10

[Trevor Daniels]

Carl Sorensen wrote Monday, November 07, 2016 7:04 PM

> On 11/7/16 2:56 AM, "Sirius Barras"  wrote:
> 
>>Ciao Andrew, you wrote:
>>
>>
>>> Where are we at with the font caching issue on Windows 10? There does
>>>not
>>> appear to be much discussion on the bug list presently,
>>>
>>
>>I agree with you, I wonder this annoying issue did not pop up more
>>frequently in the list.
> 
> I suspect it's because few (or perhaps no) developers are using Windows 10.
> That makes it very hard to troubleshoot.

I think it probably affects all versions of Windows.  I'm still
on good old-fashioned Vista and it bit me.  But the solution seems
to be to simply delete the cache, prompting a rebuild, so it's not 
a big deal for most of us.

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

Re: flag and notehead collision with certain chords

[Trevor Daniels]

Gilberto Agostinho wrote Friday, October 14, 2016 7:11 PM

> I think part of the problem is that the amount of collision is not even
> constant for the cases above. Compare the very bottom system on the image I
> posted, note how the flag barely touches the bottom note a' but completely
> collides with the bottom e'. 
> 
>> At least you’d have to give very good evidence and convince a large
>> majority that it would be better to avoid this at the expense of longer
>> stems. 
> 
> Or of shorter flags. Elaine Gould writes on p. 16 of her /Behind Bars/:
> "[s]o that tails do not touch the noteheads of down-stemmed notes, some
> editions shorten the tails while others lengthen the stems."
> 
> You can notice how inconsistent is the distance between noteheads and flags
> in the top system of this example below:
> 
> Producing: 
> 
>  
> 
> I think it's clear that the distance of the flags to the noteheads of notes
> that are normally down stemmed (higher than and including b') is different
> than those that are normally stemmed up (lower than b'). In the bottom
> system, I simply forced the second case to be the same as the first, and the
> consistency and lack of collisions look much better to me.

Before Janek implemented shorter stems outside the staff there was a lot of
discussion about it, including the effect on flags and avoiding collisions with 
note heads.  

You can see much of it here:

http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=flags%2C+beams+and+stem+length=Search%21=lilypond-devel=20=normal=date%3Aearly=0

Janek certainly devised new flags.  But I can't remember whether the revised 
flags were actually implemented.  Maybe they weren't, as the discussion
appears to peter out.

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

Re: \not-part-first-page missing in the manual

[Trevor Daniels]

Trevor Daniels wrote Sunday, September 18, 2016 10:07 AM

> Caio Giovaneti de Barros wrote Sunday, September 18, 2016 3:10 AM
> 
>> In the Notation Manual, section 3.2.2 (Custom titles headers and 
>> footers), subsection "Custom layout for headers and footers", there is a 
>> list of procedures for the \markup block. The procedure 
>> \not-part-first-page exists, but is not listed. In the list, please add:
>> 
>> ---
>> 
>> not-part-first-pagenot first page in the book part?
>> 
>> ---
>> 
>> http://lilypond.org/doc/v2.19/Documentation/notation/custom-titles-headers-and-footers.html#custom-layout-for-headers-and-footers
> 
> Ah yes, this one was added about a month after I wrote that section in the 
> NR.  Thanks for the heads-up - I'll fix it.

Fix pushed to staging ... after checking section still compiles 

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

Re: \not-part-first-page missing in the manual

[Trevor Daniels]

Caio Giovaneti de Barros wrote Sunday, September 18, 2016 3:10 AM


> In the Notation Manual, section 3.2.2 (Custom titles headers and 
> footers), subsection "Custom layout for headers and footers", there is a 
> list of procedures for the \markup block. The procedure 
> \not-part-first-page exists, but is not listed. In the list, please add:
> 
> ---
> 
> not-part-first-pagenot first page in the book part?
> 
> 
> ---
> 
> http://lilypond.org/doc/v2.19/Documentation/notation/custom-titles-headers-and-footers.html#custom-layout-for-headers-and-footers

Ah yes, this one was added about a month after I wrote that section in the NR.  
Thanks for the heads-up - I'll fix it.

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

Fw: Missing warning about clashing note columns in 2.19

[Trevor Daniels]

"Phil Holmes"  wrote in message 
news:no1m38$ha$1...@blaine.gmane.org...
>
>> Von: Malte Meyn 
>>
>> Is this a bug/regression? 2.18.2 warns about clashing note columns, 
>> 2.19.44 does not.
>>
>> \version "2.19.44"
>>
>> <<
>>c''4
>>\\
>>\stemUp a'2
>>  >>
> 
> This changed between 19.12 and 19.14.  It seems to me a retrograde step, 
> since in a complex score it's possible to miss clashing columns.  Does 
> anyone know whether current devel ever outputs this warning?

>From memory, I think Keith O'Hara made this change.  I thought the
warning was still issued if there is an actual clash of notes or stems,
but that doesn't seem to be the case.  This would definitely be wrong
without a warning:

 <<
c''16
\\
{ \stemUp a'8 }
  >>

Trevor

ps pls don't send mail from your newsgroup reader - makes it hard to reply if 
the newsgroup isn't configured.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Laissez viber ties dotted

[Trevor Daniels]

Andrew Bernard wrote Thursday, July 21, 2016 10:55 AM

> On 21 July 2016 at 3:19:49 PM, Malte Meyn  wrote:
>>
>> laissezVibrerTieDotted = \override LaissezVibrerTie.dash-definition = 
>> #'((0 1 0.1 0.75)) 

> Is it only me that finds the IR inadequate? There appears to be no mention 
> of being able to do this for LaissezVibrer ties in the IR. For Tie grobs, 
> this 
> is mentioned in the tie interface page, but there is nothing about this 
> property 
> in the semi-tie interface reference page. Are we supposed to just guess? 

You have identified a defect in the Internals documentation.  This manual is
produced automatically from the source code to ensure it stays in step with
code changes, but in this case (and for PhrasingSlur)  it does not
reference tie-interface where dash-definition is defined.

> That seems to me rather unreliable. Woudl it be reasonable to raise 
> somehwere a request for enhancement for the documentation?

Yes; copying to Buglist.

> Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: git-cl traceback (timeout?)

[Trevor Daniels]

Hi Urs

What did you enter in response to the query?

Trevor

- Original Message - 
From: "Urs Liska" 
To: ; "Phil Holmes" 
Sent: Tuesday, January 19, 2016 9:49 AM
Subject: git-cl traceback (timeout?)


> When uploading a patch git-cl failed with the transcript below:
> 
> I'm not sure if that's caused by git cl (I had just pulled the newest
> version) or if it's a simple time-out on my side, but:
> 
> a)
> If it's a git-cl issue it should be fixed
> b)
> If it's a time-out such an error should be handled by git-cl
> c)
> This left me unclear of whether the issue had been created on Allura
> (I can see that it did through the website but see b) )
> 
> Best
> Urs
> 
> 
> uliska@uliska-lmde-laptop:~/git/lilypond/source$ git cl upload master
> scm/lily.scm | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> Upload server: codereview.appspot.com (change with -s/--server)
> Your browser has been opened to visit:
> 
>https://codereview.appspot.com/get-access-token?port=8001
> 
> If your browser is on a different machine then exit and re-run
> upload.py with the command-line parameter
> 
>  --no_oauth2_webbrowser
> 
> Issue created. URL: http://codereview.appspot.com/286820043
> Uploading base file for scm/lily.scm
> 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):
> Traceback (most recent call last):
>  File "/home/uliska/git/lilypond/git-cl/git-cl", line 628, in 
>sys.exit(main(sys.argv))
>  File "/home/uliska/git/lilypond/git-cl/git-cl", line 622, in main
>return func(argv[2:])
>  File "/home/uliska/git/lilypond/git-cl/git-cl", line 341, in CmdUpload
>issueId = projecthosting_upload.upload(issue, patchset, subject,
> desc, issueId)
>  File "/home/uliska/git/lilypond/git-cl/projecthosting_upload.py", line
> 182, in upload
>status = patchy.upload(issue, patchset, subject, description, issue_id)
>  File "/home/uliska/git/lilypond/git-cl/projecthosting_upload.py", line
> 175, in upload
>issue_id = allura_issues.create_issue(subject, description)
>  File "/home/uliska/git/lilypond/git-cl/allura_issues.py", line 25, in
> create_issue
>allura_result = urllib.urlopen (allura_api + "/new", data_encoded)
>  File "/usr/lib/python2.7/urllib.py", line 89, in urlopen
>return opener.open(url, data)
>  File "/usr/lib/python2.7/urllib.py", line 215, in open
>return getattr(self, name)(url, data)
>  File "/usr/lib/python2.7/urllib.py", line 460, in open_https
>data)
>  File "/usr/lib/python2.7/urllib.py", line 379, in http_error
>result = method(url, fp, errcode, errmsg, headers, data)
>  File "/usr/lib/python2.7/urllib.py", line 641, in http_error_302
>data)
>  File "/usr/lib/python2.7/urllib.py", line 667, in redirect_internal
>return self.open(newurl)
>  File "/usr/lib/python2.7/urllib.py", line 213, in open
>return getattr(self, name)(url)
>  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
>h.endheaders(data)
>  File "/usr/lib/python2.7/httplib.py", line 997, in endheaders
>self._send_output(message_body)
>  File "/usr/lib/python2.7/httplib.py", line 850, in _send_output
>self.send(msg)
>  File "/usr/lib/python2.7/httplib.py", line 812, in send
>self.connect()
>  File "/usr/lib/python2.7/httplib.py", line 1204, in connect
>HTTPConnection.connect(self)
>  File "/usr/lib/python2.7/httplib.py", line 793, in connect
>self.timeout, self.source_address)
>  File "/usr/lib/python2.7/socket.py", line 571, in create_connection
>raise err
> IOError: [Errno socket error] [Errno 110] Connection timed out
> 
> 
> 
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Tidying-up the Issues DB

[Trevor Daniels]

Federico Bruni wrote Friday, January 01, 2016 5:14 PM


> Il giorno lun 28 dic 2015 alle 9:59, David Kastrup  ha 
> scritto:
>> Federico Bruni  writes:
>> 
>>>  Il giorno lun 26 ott 2015 alle 13:07, Werner LEMBERG  ha
>>>  scritto:
 
>   Many of the Issues with Status:Started are no longer active, 
> [...]
 
  Any progress on moving to Savannah?  Is there a TODO list 
 somewhere?
>>> 
>>>  No progress, as far as I know.
>>> 
>>>  Nobody is willing to work on maintaining an Allura deployment. 
>>> Josiah
>>>  was the only one who seemed to have the skills and the will to do 
>>> it,
>>>  but he vanished.
>> 
>> This wasn't the situation when we picked Allura as the tracker to use.
> 
> Are you sure? I can't remember anybody offering help on deploying and 
> maintaining an Allura instance.
> 
> I installed Allura once, just to test if the import from Google code 
> worked faster locally than on Sourceforge (which was not the case).  
> Then I tried to install it on the server but gave up once I'd realized 
> that a real deployment was much more complicated than what was shown in 
> the Allura docs back then.

Actually four people expressed an interest in installing Allura on Savannah, 
but all of them found it to be beyond their abilities and gave up.  The problem 
was that they didn't find this out until the middle of July, by which time it 
was really too late to consider an alternative to Allura, any of which would 
doubtless have had problems of its own.

The situation is that no one is currently working on the move to Savannah, and 
no one in our community seems willing and capable of doing so.  I'd be very 
wary now of moving our production Issues DB to Savannah even if someone managed 
to complete the installation and migration, as we would be on our own as far as 
on-going maintenance was concerned, with very little confidence that we would 
be competent at doing that, given the experience so far.

OTOH, using SourceForge seems to be essentially trouble-free.

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

Re: Manual bar breaks autoBeaming

[Trevor Daniels]

Sorry; I retract this email.  It's rubbish!  All that does is invalidate the 
autobeaming.

Trevor

- Original Message - 
From: "Trevor Daniels" <t.dani...@treda.co.uk>
To: "David Kastrup" <d...@gnu.org>; <bug-lilypond@gnu.org>; "Simon Albrecht" 
<simon.albre...@mail.de>
Sent: Monday, December 07, 2015 4:09 PM
Subject: Re: Manual bar breaks autoBeaming


> 
> Simon Albrecht wrote Monday, December 07, 2015 1:32 PM
> 
>>> The report was (supposed to be) about the missing beam over the first 
>>> two quavers, which are not separated by a bar line.
>> 
>> To clarify:
>> 
>> \version "2.19.32"
>> {
>>   \time 3/4
>>   8-"default" 8  16 16 16 16  8 8
>>   8-"with bars" 8 \bar "" 16 16 16 16 \bar "" 8 8
>> }
> 
> This is definitely a bug, and an interesting one!
> If I copy out the 3/4 beam exceptions data structure from
> scm/time-signature-settings.scm and place it in the score:
> 
> {
>   \time 3/4
>  \set Timing.beamExceptions = 
>#'((3 . 4) .
> ((beamExceptions . ((end . ((1/8 . (6))
> (1/12 . (3 3 3
>   8-"default" 8  16 16 16 16  8 8
>   8-"with bars" 8 \bar "" 16 16 16 16 \bar "" 8 8
> }
> 
> then the beams are correct.  So it seems the beam exceptions
> are not being accessed correctly.
> 
> Trevor
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Irregularity in horizontal spacing

[Trevor Daniels]

Urs, you wrote Friday, November 20, 2015 10:19 PM

> What I mean is: These final 16ths look pretty good, but they cause the
> corresponding 8th notes in the top and bottom staff to be spaced pretty
> irregularly. And in effect inacceptably.
> 
> As I have to get that score ready ASAP I can't wait for a proper fix (if
> it should be considered a bug) but need a workaround that works better
> than having to space the notes in all measures manually.

Try:

  \layout {
\context {
  \Score
  \override SpacingSpanner.common-shortest-duration = #(ly:make-moment 16)
}
  }

This will set the score much tighter though, so may not be acceptable.
The actual value seems to be immaterial.

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

Re: Irregularity in horizontal spacing

[Trevor Daniels]

> Urs, you wrote Friday, November 20, 2015 10:19 PM
> 
>> What I mean is: These final 16ths look pretty good, but they cause the
>> corresponding 8th notes in the top and bottom staff to be spaced pretty
>> irregularly. And in effect inacceptably.
>> 
>> As I have to get that score ready ASAP I can't wait for a proper fix (if
>> it should be considered a bug) but need a workaround that works better
>> than having to space the notes in all measures manually.
> 
> Try:
> 
>  \layout {
>\context {
>  \Score
>  \override SpacingSpanner.common-shortest-duration = #(ly:make-moment 16)
>}
>  }
> 
> This will set the score much tighter though, so may not be acceptable.
> The actual value seems to be immaterial.

Actually, this seems better:

  \layout {
\context {
  \Score
  \override SpacingSpanner.uniform-stretching = ##t
}
  }

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

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

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

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


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

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

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

Re: Accidentals tied over a system break

[Trevor Daniels]

Phil Holmes wrote Thursday, October 08, 2015 3:21 PM

> From: "Thomas Morley" 
> To: "Sven" 
> Cc: "lilypond-user" 
> Sent: Thursday, October 08, 2015 3:10 PM
> Subject: Re: Accidentals tied over a system break
> 
> 
>> 2015-10-08 15:40 GMT+02:00 Sven :
>>> Reading my way through Behind Bars by Elaine Gould, I'm trying to 
>>> replicate
>>> some of the examples in LilyPond. One of them contains a tie over a 
>>> system
>>> break:
>>>
>>> \version "2.18.2"
>>>
>>> \relative c'' {
>>>   r2. fis,4~ | \break
>>>   fis8 a16 fis r8 r2 \bar "|."
>>>   }
>>>
>>>
>>> LP puts a sharp in front of the first f# in measure 2 as well as the 
>>> second
>>> one. According to Gould repeating an accidental twice in a bar in close
>>> succession is redundant (and I think I agree with her). To hide the 
>>> second
>>> sharp, I've put \once \override Accidental #'transparent = ##t in front 
>>> of
>>> it. Is this the preferred way of doing hiding that sharp?
>>>
>>> I don't consider this a bug per se, but maybe LP can programmed to avoid
>>> repeating accidentals in close succession in upcoming versions?
>>>
>
> I don't believe the OP is complaining about the sharp after the break: 
> rather the sharp on the last sounded note.  That doesn't appear needed, 
> since we already have a sharp shown on the first note in the bar.

Furthermore, if the tie is removed the sharp on the final fis
is also removed.  The issue is, without the \break the final fis
needs the sharp as the second fis doesn't have one, being tied
to the first fis.  Adding the \break causes the second fis to
need (and get) a sharp, but the sharp on the third fis, which is
now redundant, is not removed.  Seems to be a bug to me.

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

Re: LM Orchestral template

[Trevor Daniels]

Simon Albrecht wrote Wednesday, September 23, 2015 10:08 AM
Subject: Re: LM Orchestral template


> On 23.09.2015 09:53, Phil Holmes wrote:
>>
>>
>> If you use the template locally, the spacings are fine.
> 
> Only if you copy the code displayed. If you click the image in the LM, 
> you get the full code used in producing the example, and compiling that 
> shows the compression.
> 
>>   So it's something to do with the way snippets are compiled: perhaps 
>> a default paper-size setting?
> 
> It’s lilypond-book-preamble.ly which causes the problem, but I don’t 
> understand the mechanism used there. Who would be familiar with this 
> framework, so we may ask him?

This framework was set up years ago, and no one familiar with it is
still active on LP  today.  Graham is probably the best one to ask.  I'll 
copy him in.

@Graham:  The problem is the appearance of this template in the LM,
see:
http://www.lilypond.org/doc/v2.19/Documentation/learning/orchestra-choir-and-piano

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

Re: LM Orchestral template

[Trevor Daniels]

Whoops, used an old email address for Graham.  This is the current one.

Trevor

- Original Message - 
From: "Trevor Daniels" <t.dani...@treda.co.uk>
To: "Phil Holmes" <m...@philholmes.net>; <bug-lilypond@gnu.org>; "Simon 
Albrecht" <simon.albre...@mail.de>
Cc: "Graham Percival" <gper...@gmail.com>
Sent: Wednesday, September 23, 2015 11:34 AM
Subject: Re: LM Orchestral template


> Simon Albrecht wrote Wednesday, September 23, 2015 10:08 AM
> Subject: Re: LM Orchestral template
> 
> 
>> On 23.09.2015 09:53, Phil Holmes wrote:
>>>
>>>
>>> If you use the template locally, the spacings are fine.
>> 
>> Only if you copy the code displayed. If you click the image in the LM, 
>> you get the full code used in producing the example, and compiling that 
>> shows the compression.
>> 
>>>   So it's something to do with the way snippets are compiled: perhaps 
>>> a default paper-size setting?
>> 
>> It’s lilypond-book-preamble.ly which causes the problem, but I don’t 
>> understand the mechanism used there. Who would be familiar with this 
>> framework, so we may ask him?
> 
> This framework was set up years ago, and no one familiar with it is
> still active on LP  today.  Graham is probably the best one to ask.  I'll 
> copy him in.
> 
> @Graham:  The problem is the appearance of this template in the LM,
> see:
> http://www.lilypond.org/doc/v2.19/Documentation/learning/orchestra-choir-and-piano
> 
> Trevor
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: LM Orchestral template

[Trevor Daniels]

Simon Albrecht wrote Tuesday, September 22, 2015 7:35 PM

> I just came across the Orchestral template in LM A.6.I, and noticed two 
> flaws, one minor and one serious:
> – Double basses usually aren’t notated in a \clef "bass_8", but as 
> transposing instruments (originating from the time when they were 
> sharing a staff with the violoncelli). All the scores I have here, from 
> Beethoven through Mendelssohn, Bruckner and Mahler to Hindemith, confirm 
> this. I attach a version of the template where this is changed.

Thanks

> – The image rendition in the docs is extremely compressed, with 
> overlapping stuff, staves touching one another  This is a really bad 
> example and needs to be changed; how is this done? I don’t know the 
> framework in lilypond-book-preamble.ly; certainly there will be someone 
> who can quickly say how to allow the score more space.

I think for this example all that is needed is to reduce the global staff
size, which is set (unusually) in this file to 17.  I can't easily test this as
it is a pain for me to build the docs, but James might be willing to do
some experiments to choose the optimum staff size.

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

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
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Implementing Blocking in Allura

[Trevor Daniels]

One of the features in GC which is not possible to replicate exactly in Allura 
is the tagging of Issues with BlockedOn and Blocking.  I've tried various ways 
of implementing something similar, but the one I prefer is to use the labels: 
field.  Simply add the labels followed by the issue number in plain text to the 
appropriate issue, e.g.

   In Issue 2178 add a label "BlockedOn 2668"
   In Issue 2668 add a label "Blocking 2178"

This blocking detail then shows up in the search results under the Labels field 
and appears in the headings of the two Issues.  It is not possible to simply 
click on the labels field to get to the other issue of the pair; but if either 
issue number is entered in the search box both issues should appear (sometimes 
along with other issues if they satisfy the simple search).

All Blocked and Blocking issues can be found by a search for labels:Block - 
this is perhaps the best search to use when searching for block pairs.

I've made these changes to the two issues above, which I think are the only 
ones currently involved in blocking; see

https://sourceforge.net/p/testlilyissues/issues/search/?q=labels%3ABlock

If you know of any others please tell me.

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

Re: Allura at SF is ready

[Trevor Daniels]

Federico Bruni wrote Wednesday, September 02, 2015 4:29 AM

> Il giorno dom 30 ago 2015 alle 17:57, Trevor Daniels 
> <t.dani...@treda.co.uk> ha scritto:
>> I've not heard anything from Federico or Josiah for over a week, so 
>> I've no idea what state Allura at Savannah is in.  I suggest we wait 
>> a few days for news before inviting devs to join at SF, in case the 
>> Savannah system comes on line soon.
> 
> I gave up with Allura. I started working on it just "by accident". 
> Josiah has the skills to work on it, while I don't.

A pity, but thanks anyway for starting this off.
 
> There's no https connection at the moment but I _think_ that nobody is 
> working on a solution:
> http://bugs.lilypond.org/

Nacho has included bugs.lilypond.gnu.org as an alias on the apache
configuration and he has been asked to set this up as a DNS name.
I've not yet heard back from him, so don't know if this has been done.

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

Re: slurs and articulation

[Trevor Daniels]

Martin Tarenskeen wrote Monday, August 31, 2015 10:50 AM

> Try to compile the following example:
> 
> 
> 
> \version "2.19.25"
> 
> \relative {
>   d''-.( d-. d-. d-.)
>   d-_( d-_ d-_ d-_)
>   d--( d-- d-- d--)
>   d-^( d-^ d-^ d-^)
>   d-+( d-+ d-+ d-+)
>   d-!( d-! d-! d-!)
>   d->( d-> d-> d->)
>   \break
>   \override Slur.outside-staff-priority = #500
>   d-.( d-. d-. d-.)
>   d-_( d-_ d-_ d-_)
>   d--( d-- d-- d--)
>   d-^( d-^ d-^ d-^)
>   d-+( d-+ d-+ d-+)
>   d-!( d-! d-! d-!)
>   d->( d-> d-> d->)
> }
> 
> 
> 
> Why are the articulations in bars 2, 7, 9, 14 treated differently? It 
> seems they are aligned with the slurs instead of the notes. Should I 
> forward this to bug-lilypond?

It does look somewhat inconsistent.

The properties of the various articulations (Script objects)
are defined in scm/script.scm.  Maybe one or two are sub-optimal.

Copying to bug list for further discussion.

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

Re: New bug tracker?

[Trevor Daniels]

Javier Ruiz-Alma wrote Monday, August 31, 2015 4:12 AM

> Is there a new bug tracker for Lilypond?
> LP site still points to the now-read-only tracker:
> http://lilypond.org/bug-reports.html
 
We are currently in transition between bug trackers.  The intention is to 
migrate to a new bug tracker at Savannah, and this is being set up at present.

In the meantime we have an interim bug tracker for use by developers only, so 
we can keep track of changes.  I'd rather not direct users to this temporary 
arrangement to avoid confusion later.

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

Re: Allura at SF is ready

[Trevor Daniels]

James Lowe wrote Monday, August 31, 2015 9:29 AM
 
> @Trevor
> 
> Assuming that you eventually start the migration, I assume you'll tell
> the group and we'd best hold off updating SF until it is completed (so
> that we don't interfere with the migration)?

Yes, that would be sensible.  It should take little more than two days, 
assuming no glitches or gotchas, as only one import should be required (not the 
two needed when migrating from GC).  To be sure of the migration state I would 
disable updating during the migration proper anyway.

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

Re: Allura at SF is ready

[Trevor Daniels]

Colin Campbell wrote Monday, August 31, 2015 1:03 PM


> On 2015-08-31 02:57 AM, Trevor Daniels wrote:
>> James Lowe wrote Monday, August 31, 2015 9:29 AM
>>   
>>> @Trevor
>>>
>>> Assuming that you eventually start the migration, I assume you'll tell
>>> the group and we'd best hold off updating SF until it is completed (so
>>> that we don't interfere with the migration)?
>> Yes, that would be sensible.  It should take little more than two days, 
>> assuming no glitches or gotchas, as only one import should be required (not 
>> the two needed when migrating from GC).  To be sure of the migration state I 
>> would disable updating during the migration proper anyway.
>> ___
> 
> I had started to catch up on verifying issues, as there is a bit of a 
> backlog. Shall I carry on until Trevor starts the final migration, or 
> pause until after the migration is complete?
> BTW, it turns out that SF ID and display name are separate values, so 
> for the record: "John Zebedee" and "Colin Campbell" are the same person.

I'd prefer you to continue.  All your changes should migrate correctly.

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

Learning about Allura

[Trevor Daniels]

@Bug Squad

I've noticed a couple of things about Allura which are
worth mentioning:

a) When you add a new issue or change the status, 
   patch, label, etc, of an existing one, it takes
   some time, i.e. several minutes, before it shows
   up in searches involving the new value.  Allura
   maintains a large inverted index in order to
   reduce the time and resource needed to perform
   complex searches, but the price for this is the
   increased time required to modify that index
   when one of the field values changes.

b) This is a real nuisance.  The body text of issues
   uses markup.  See Formatting Help underneath
   the search buttons.  Some of this is useful, but
   some not.  In particular, a line with # in column
   one means format as a huge header.  So a line
   of Scheme which is not indented appears huge.
   This means that Lily source code should be either
   indented by four spaces or a tab.  Alternatively,
   insert a line containing 4 (or more) tildes before
   and after the Lily code.

   As an example, see https://sourceforge.net/p/testlilyissues/issues/4581/
   before Simon works out how to fix it ;)

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

Re: Glossary index [was: how to get notes without tails?]

[Trevor Daniels]

David Kastrup wrote Sunday, August 30, 2015 10:27 PM

 Trevor Daniels t.dani...@treda.co.uk writes:

 Simon Albrecht wrote Sunday, August 30, 2015 8:58 PM

 Am 30.08.2015 um 21:52 schrieb Trevor Daniels:

 It would be a great help, I think, to add all the non-English terms to the
 Glossary Index.  That would be easy to do, but very laborious and
 time-consuming.  Just needs someone to do it 

 Or someone with the proficiency and time to write a script?

 Actually I don't think that would be very difficult.

 A typical entry header looks like this:

 @node acciaccatura
 @section acciaccatura

 ES: mordente de una nota,
 I: acciaccatura,
 F: acciaccatura, appoggiature brève,
 D: Zusammenschlag,
 NL: samenslag,
 DK: ?,
 S: ?,
 FI: ?.

 The script would need to extract the rest of each line beginning
 @section, ES:, I: etc.  Remove duplicates, remove ?s, and
 for each of the remainder insert a new line containing that extract
 prefixed by @cindex.  Repeat for the next @node.

 It would probably make sense to create separate indices for every
 language.

Yes, that would make sense if all the languages were equally
populated, but many (most?) of the entries are similar to the
one above, with no word for DK, S, and FI.  In this case a
combined entry would have the advantage that a user searching
for a non-existent word might recognise one of the words in
another language, which would appear close to where he was
looking.  Adding the country code in brackets after the entry
would be easy and useful.

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

Re: Allura at SF is ready

[Trevor Daniels]

James wrote Sunday, August 30, 2015 4:22 PM

 I've 'synced' my list of Patches I've been keeping track of manually
 with the issues list now.
 
 Is this set of issues going to be the one we migrate to the 'new' non-SF
 system?
 
 I.e. do we now treat this as a live system?

Yes.  When we migrate to Allura at Savannah I will export from this SF system 
and import to the Savannah system.  I shall not be returning to GoogleCode 
(unless some disaster befalls).

Now you've completed your work I'll invite the Bug Squad to join up so they can 
continue their work in catching new issues.

I've not heard anything from Federico or Josiah for over a week, so I've no 
idea what state Allura at Savannah is in.  I suggest we wait a few days for 
news before inviting devs to join at SF, in case the Savannah system comes on 
line soon.  Are you willing to update the DB with pushes when they occur for a 
few days?

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

Re: Allura at SF is ready

[Trevor Daniels]

James, you wrote Sunday, August 30, 2015 1:47 PM

 Some comments if I may be so bold.

Of course - most welcome!
 
 1. I think it would be useful to have 'Searches' (defined on that left
 hand side panel) for each of the Patch states
 
 New
 Review
 Countdown
 Push

Presumably you'd like these restricted to status:Started?  Otherwise you'll see 
lots of status:Verified, Abandoned, etc.  Anyway, that's what I've done - 
easily changed though.

These are the four Patch( ... ) searches.

Open(Patch) now shows all the Started issues with a non-zero patch field.  
Useful for finding issues with incorrectly set fields.  As a dev you can fix 
these.  It also includes the needs_work, abandoned, and waiting patch states.

 The 'Fixed' search

This shows all the patches waiting to be Verified.  Useful for the bug squad.
 
 2. It seems that the 'Needs' field is mandatory and this is going to be
 misleading I think. For example if you look at the new issue I entered
 manually:
 
 https://sourceforge.net/p/testlilyissues/issues/4576/
 
 This has a 'Needs: design' tag which is inappropriate (and incorrect).

I've defined   as the default for this field; should be OK for new issues 
now.  That also reminded me to define defaults for other fields too.
 
 Otherwise it seems simple enough.

Thanks!

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

Re: [testlilyissues:issues] #4579 NR Changing Defaults: Explain sticky contexts accurately

[Trevor Daniels]

Hi James

The issues and issue numbers you've added don't seem to correspond with those 
Simon posted on the bug list.  For example:

Simon's:
  ID: 4579
  STATUS: New
  SUMMARY: Document tweaking of StaffSymbol and LedgerLineSpanner
  TYPE: Documentation

Yours:
 ** [issues:#4579] NR Changing Defaults: Explain sticky contexts accurately**
 **Status:** Started
 **Created:** Sun Aug 30, 2015 02:54 PM UTC by pkx166h
 **Last Updated:** Sun Aug 30, 2015 02:54 PM UTC
 **Owner:** pkx166h

So it looks like the DB and the bug list are out of sync already.  That was why 
I asked Simon to add his first, as he'd already bagged the next four serial 
numbers.

Ah well - just shows we'd better start using the new Allura DB properly ASAP so 
there is just one authoratative source.  We'll have to ignore Simon's numbers, 
but don't forget to add them!

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

Bug Squad invited to join Allura

[Trevor Daniels]

@Bug Squad

The new Issues DB at SourceForge is live and has been updated by James to 
reflect the current state of patches.  There are a few new issues that are yet 
to be added, in particular the ones Simon raised on the bug list.  These will 
now need to be given new serial numbers as James has bagged the ones Simon 
chose.

So, to enable you to complete the updating and to continue your maintenance of 
the Issues DB I suggest you now go to

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

click on Join at top right and register as a member.  Then send me the 
username you've chosen so I can add you as a developer.  If you are spam-averse 
I suggest you use a disposable email address so you can make a clean break 
after we move to Savannah.

The intention is to migrate the data from SF (not GC) to Savannah, so any work 
you do now will be preserved, DV.

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

Allura at SF is ready

[Trevor Daniels]

The migration of the tracker from GC to Allura at SF has gone well.  
Attachments are present and searches work (in the Allura style, which takes 
some getting used to, but is pretty comprehensive.)  I've set up some common 
searches to make things easier.  You can view it here to inspect and play with 
no need to register or log on:

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

At present just Phil and I are installed as Admins.

We now need to bring the DB up to date with the changes notified on the bug 
list since 24 Aug before they all get forgotten.  I suggest one of the bug 
squad members does this.  Simon would be best, as I think he created most of 
the recent ISSUEs.  Whoever does this needs to register with SF and join the 
LilyIssues (testlilyissues) project as a member.  To do this, go the the url 
above, click on join, and fill in the details.  Make sure you untick the 
Receive newsletter box.  I would recommend using a throw-away email address 
so you can make a clean break later if you are spam-averse.  Then email me the 
username you have chosen so I can give you Dev status.  The new Issues will 
need to be entered (pretty obvious, really) in the correct order, as the number 
cannot be specified.  Then any subsequent comments from the bug list will need 
to be added by proxy, adding the name of the real author in a text comment.

@James: you may like to register in the same way so you can gain some 
familiarity with Allura and bring the Patchy and push details up to date.  You 
may even be able to use it to help with the countdown this weekend.

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

Re: Allura at SF is ready

[Trevor Daniels]

Benkő Pál wrote Friday, August 28, 2015 8:01 PM


 The migration of the tracker from GC to Allura at SF has gone well.  
 Attachments are present and searches work (in the Allura style, which takes 
 some getting used to, but is pretty comprehensive.)  I've set up some common 
 searches to make things easier.  You can view it here to inspect and play 
 with no need to register or log on:

 https://sourceforge.net/p/testlilyissues/issues/
 
 I've taken a look and mostly like it.

Thanks! :)

  my only (not too big) problem
 is that writing comment 38 created back-links in Google Code, but in
 Allura both the link and the comment number is missing.  can it be
 configured somehow to at least number the comments?

The lack of comment numbers is due a a different design:

In GC the comments were strictly linear in time, so a
monotonically increasing comment serial number made sense.

In Allura, comments can be threaded (you can reply to an earlier
comment) and so a monotonically increasing serial number isn't
well-defined, but due to threading, back refs within an issue are
not needed so often.
  
There is a link field available in every comment to cut and 
paste in order to refer to it from elsewhere, including other
issues, when threading doesn't meet the need.

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

Re: New issue submission process?

[Trevor Daniels]

Ralph Palmer wrote Thursday, August 27, 2015 7:27 PM

 Is there a new official submission process and / or location (web site)?

Not yet.  During this hiatus any new bug created or any comment added will have 
to be redone once the new Allura tracker is available, if they are to be 
integrated into the tracker database. 

 If a new site is on the horizon, but not yet here, is there a projected
 timeline?

The interim Allura site at SourceForge should be available this weekend.  That 
will enable the bug squad and James to bring the tracker up to date and 
maintain it by entering the backlog by interrogating the mailing lists or their 
own records.  I've asked developers to go easy on changes which affect the 
tracker as this will be quite onerous.  I'll send out details for doing this as 
soon as its available.

Most developers and users will not need write access to this interim 
implementation at SourceForge as the intention is to quickly move the tracker 
to its permanent home at Savannah.  Unfortunately this is not yet ready.  It's 
difficult to guess how long this will take, but if it's more than a week we'll 
need to rethink whether to ask all developers to use the SF implementation.  
Maintaining it by proxy cannot go on for long.

 Does anyone besides myself need some explanation / explication?

I've sent a few mails to the dev list.  Apologies for not copying the bug list.
 
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: PATCHES: Countdown for August 26th 2015 - IMPORTANT UPDATE TO PATCHREVIEW PROCESS - PLEASE READ

[Trevor Daniels]

James Lowe wrote Sunday, August 23, 2015 5:58 PM

 Google Tracker will be 'read-only' on the 25th August. At the moment,
 as I understand it we are still 'transitioning' to a new tracker
 system for issues but Rietveld is still working as normal.

Preparations for using Allura are looking up.  Here's the timescale
for transitioning as far as can be determined ATM.

One of the problems which caused many of my imports to SF to fail
has been identified by Dave Brondsema as an incorrect permissions
setting, so now that is corrected I'm hopeful that imports will be
much more successful.

Our VM system at Savannah has also progressed.  Allura is now
installed.  Some problems remain: the certificate doesn't work
with the VM url so https access fails, and the verification
email doesn't appear to be sent.  No doubt there will be more
issues to resolve, but it looks much more promising than it did
last week.

I'll start to export the Issues DB from GC on Wed 26 Aug 2015,
so avoiding any problems on Tuesday while Google are fiddling
with the permissions.  This will take c. 35 hours.  I then need
to edit the Author field locally and re-import, which will take
another c. 35 hours.  To do this, I'll use the VM at Savannah if
it is ready; otherwise I'll use the system at SF.

So the earliest date at which we can hope to move all issue
activity to Allura is next week-end, 29/30 Aug.  If there are
further glitches or gotchas it will be later.

Trevor

 

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

Re: autoBeaming and \set measurePosition

[Trevor Daniels]

Simon Albrecht wrote Thursday, August 20, 2015 1:11 AM

 I don’t quite know what I’m supposed to think of this: With 3/4, there 
 is no beam between the third and fourth quavers. It doesn’t happen with 
 -1/4, 0, 1/4, or 2/4. Doesn’t seem like this is going to appear in any 
 realistic scenario. Just ignore it?

Automatic beams which are created using beamExceptions are
triggered when the beam end points are passed.  Skipping the
end point like this means beam creation is not triggered.

I think just ignore it.  If anyone wants to do this it's easy to add a manual
beam.

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

Re: Possible bug with new \partial

[Trevor Daniels]

Mats Bengtsson, you wrote Sunday, August 16, 2015 9:55 PM
Subject: Re: Possible bug with new \partial


 My apologies for spamming the mailing list. After some more trials, I 
 realize that the problem remains even if I write \partial after \time. 
 Still, the problem only appears with multimeasure rests, as the two 
 following examples illustrate:
 
 \version 2.19.25
 % Working example
 \relative c'{
 \time 2/4
 \partial 4
 c4 |
 d8 e f g |
 f4
 \bar ||
 \time 3/4
 \partial 4*0
 %R2.*3 |
 f4 ( a f ) |
 f2.
 }
 
 % Failing example
 \relative c'{
 \time 2/4
 \partial 4
 c4 |
 d8 e f g |
 f4
 \bar ||
 \time 3/4
 \partial 4*0
 R2.*3 |
 f4 ( a f ) |
 f2.
 }

Thanks Mats.  Nice to see you're still in the pond!

https://code.google.com/p/lilypond/issues/detail?id=4567

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

Re: Possible bug with new \partial

[Trevor Daniels]

Mats,

Here's a workaround, although I bet you already have one:

\relative c'{
\time 2/4
\partial 4
c4 |
d8 e f g |
f4*2
\bar ||
\time 3/4
R2.*3 |
f4 ( a f ) |
f2.
}

Trevor


 
 My apologies for spamming the mailing list. After some more trials, I 
 realize that the problem remains even if I write \partial after \time. 
 Still, the problem only appears with multimeasure rests, as the two 
 following examples illustrate:
 
 \version 2.19.25
 % Working example
 \relative c'{
 \time 2/4
 \partial 4
 c4 |
 d8 e f g |
 f4
 \bar ||
 \time 3/4
 \partial 4*0
 %R2.*3 |
 f4 ( a f ) |
 f2.
 }
 
 % Failing example
 \relative c'{
 \time 2/4
 \partial 4
 c4 |
 d8 e f g |
 f4
 \bar ||
 \time 3/4
 \partial 4*0
 R2.*3 |
 f4 ( a f ) |
 f2.
 }
 
 
/Mats
 
 
 
 
 
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: modern-cautionary accidentals

[Trevor Daniels]

Patrick Karl , you wrote Sunday, June 07, 2015 10:27 PM

 The discussion of Automatic Accidentals in the Chapter 1 of the Notation 
 Manual says:

 modern-cautionary
 This rule is similar to modern, but the ‘extra’ accidentals (the ones not 
 typeset
 by default) are typeset as cautionary accidentals. They are by default printed
 with parentheses, but they can also be printed in reduced size by defining the
 cautionary-style property of AccidentalSuggestion.

This looks to be an oversight. The cautionary-style property was deprecated
in Release 2.11.5 but it seems the manual was not updated.  Thanks for pointing
this out.

The correct override is

\version 2.19.20

{ 
  \relative c'' {
  \accidentalStyle neo-modern-cautionary
  \override AccidentalCautionary #'font-size = #-2
  
  cis16 cis d ciscis cis d dd d d d cis c c c
   }
 }

 Also, the neo-modern-cautionary discussion does not mention the possibility 
 of reduced size accidentals; wouldn’t the info under modern-cautionary also 
 apply to neo-modern-cautionary.

Yes, the example above shows this.

Copying to bug-list ...

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

Re: Learning Manual – simplify piano centered lyrics example?!

[Trevor Daniels]

Noeck wrote Saturday, April 25, 2015 7:01 PM

 GrandStaff is used deliberately here to avoid the bar lines extending 
 between the two staves, potentially crossing lyric syllables - except that 
 I've just discovered the bar lines _do_ extend between the two staves, even 
 when GrandStaff is used!  That needs more investigation.
 
 Yes, that’s weird, indeed!
 
 A GrandStaff is connecting the bar lines on purpose (like for a string
 ensemble). You probably think of a ChoirStaff here which does not
 connect bar lines in favour of the lyrics (as in a choir score).

You're right, I was too hasty and jumped to the wrong conclusion (I actually 
wrote the refs you gave!).  The only difference between PianoStaff and 
GrandStaff is that the staves of PianoStaff are only removed together.  So I've 
no idea now why GrandStaff was used in this example.  Its origin was earlier 
than 2008 and predates its appearance in git, so no clues there.  Whatever; 
clearly it should be PianoStaff now - lyrics do not, in fact, collide with the 
span bars.
 
Trevor

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

Re: Learning Manual – simplify piano centered lyrics example?!

[Trevor Daniels]

pls wrote Saturday, April 25, 2015 11:31 AM

 yesterday I stumbled across this example in the Learning Manual:  
 http://lilypond.org/doc/v2.19/Documentation/learning/piano-centered-lyrics. 
 In my opinion it can and should be simplified.  Obviously there’s no need 
 anymore for a GrandStaff to accept Lyrics. \consists “Bar_engraver” has also 
 become unnecessary, here. To make the example more consistent with the text 
 I’d use a PianoStaff instead of a GrandStaff like so:

GrandStaff is used deliberately here to avoid the bar lines extending between 
the two staves, potentially crossing lyric syllables - except that I've just 
discovered the bar lines _do_ extend between the two staves, even when 
GrandStaff is used!  That needs more investigation.

Your other two points are valid, however.

As this template is obtained from the LSR you may provide a change there 
yourself and it will make its way into the docs automatically.  Go to
http://lsr.di.unimi.it/LSR/Search?q=piano+template+lyrics+centered
and click on Contributing.

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

Re: Subdivided beams

[Trevor Daniels]

Urs Liska wrote Thursday, April 23, 2015 5:06 PM


I had the opportunity to have a look in the German translation of 
 Behind Bars (which is BTW an exceptionally good translation. Usually I 
 prefer reading this kind of books in the original language, but here I 
 don't see any problems reading the translation).
 
 There I found a rule where LilyPond's behaviour differs. The rule makes 
 perfect sense to me, and the (very few) examples I could immediately 
 find confirm it.
 
 Consider the following example of beam subdivision
 http://lilypond.org/doc/v2.19/Documentation/notation/beams.html#Selected-Snippets-12
 
 According to Gould (sorry, I don't own the book, so no page number 
 available) the rhythmical organization is indicated by the number of 
 remaining beams in the subdivisions. Depending on the length of the 
 following group there should remain one or more beams.
 
 In the example in the docs the third beat is correctly divided in two 
 groups of a quaver's length, thus having a single beam in the middle. 
 But in the fourth beat the first and the third subdivision should have 
 *two* beams, indicating that they separate groups of a sixteenth note 
 length each.
 
 From the description it seems that LilyPond doesn't do that and can't 
 easily be talked into doing it, so this seems an embarrassing bug.

This was recently discussed on the user list.  See

http://lists.gnu.org/archive/html/lilypond-user/2015-03/msg00365.html

and surrounding emails.

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

Re: Octavecheck?

[Trevor Daniels]

Noeck wrote Wednesday, March 25, 2015 6:48 PM

 Here is a guess what happens (even if that contradicts the docs):
 The following pitches are perhaps not relative to the octave check but
 to the previous pitch corrected by the octave check.

That would be my explanation too.

 This would explain it, but the docs would have to be corrected.

Yes, it's a doc issue.  But is it really useful in this form?
Does anyone use it?

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

Re: The built-in template satb.ly fails in 2.19.16

[Trevor Daniels]

David Kastrup wrote Saturday, March 14, 2015 7:28 AM


 Trevor Daniels t.dani...@treda.co.uk writes:
 
 I've just noticed that the examples of using the built-in template, satb.ly, 
 in the Learning Manual, see
 http://www.lilypond.org/doc/v2.19/Documentation/learning/built_002din-templates
 are not correct in 2.19.16.
 Does anyone recognise any changes in 2.19.16 which might have affected this 
 macro?
 (There have been minor changes to this in current master, but both fail the 
 same way.)
 
 Pretty likely issue 2010
 URL:https://code.google.com/p/lilypond/issues/detail?id=2010.
 
 I think it requires associated voices to either be in the same  
 block as their lyrics.  Or something like that (if they are not
 accompanied by any non-associated context in the   I think that's
 also ok).

That seems to be it, sort of.  Below I've simulated the
rather bizarre structure the satb.ly template generates.
This causes the last three notes of the Soprano line and
all the lyrics to vanish, although no error is generated.
If the \dynamicUp command is removed or the double nesting
is removed (the latter by commenting the two lines
indicated) it works correctly.

\version 2.19.16

\score {
  \new ChoirStaff 
{ 
  \new Staff = Descant {
\new Voice = Descant 
  \dynamicUp % remove to fix

  }
  \new Lyrics \lyricsto Descant { }
 } % remove to fix
{   % remove to fix
  \new Staff = Soprano {
\new Voice = Soprano \relative { a' a a a }
  }
  \new Lyrics \lyricsto Soprano { A B C D }
 }   
  
}

I'm not sure I'd call this a bug, the structure required
to expose it being so bizarre.  As I'm currently looking
into reworking this template completely I hope a simplified
structure will bypass the problem.

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

Re: The built-in template satb.ly fails in 2.19.16

[Trevor Daniels]

David Kastrup wrote Saturday, March 14, 2015 1:25 PM
Subject: Re: The built-in template satb.ly fails in 2.19.16


 Trevor Daniels t.dani...@treda.co.uk writes:

 That seems to be it, sort of.  Below I've simulated the
 rather bizarre structure the satb.ly template generates.
 This causes the last three notes of the Soprano line and
 all the lyrics to vanish, although no error is generated.
 
 Well, the solution to issue 2010 kills off associated lyrics contexts
 when they become (rather than already are) the only thing left in a
 ... construct.  But in this case, the controlling context is
 actually outside.  The problem of 2010 was that if the controlling
 context in a ... construct dies, the associated lyrics have to quit
 at the same timestep rather than wait for another timestep, or the
 ... construct will throw the whole timing of LilyPond off.

Yes, 2010 may still be involved, but the problem arises 
in this particular case when the Descant music is empty, 
and there is nothing else to keep the context alive.
 
 I'm not sure there is a sane way within the current design (which uses
 the run_always flag for associated lyrics) to make this work in
 arbitrary complex ... constructs.

It's a bit hackish, but maybe determine the longest music
in the ChoirStaff and ensure all the contexts are that
long by adding spacer rests in parallel to that length.
 
 Maybe there is a better solution for issue 2010 but I've spent a _lot_
 of time playing around with that one.

Please don't spend longer on 2010.  At least not until
I've explored all options for fixing satb.ly.  There are
far more important things for you to do.

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

The built-in template satb.ly fails in 2.19.16

[Trevor Daniels]

I've just noticed that the examples of using the built-in template, satb.ly, in 
the Learning Manual, see
http://www.lilypond.org/doc/v2.19/Documentation/learning/built_002din-templates
are not correct in 2.19.16.  They were (and still are) fine when using 2.19.15 
with the same template.

The problem may be associated with one of the macros:

#(defmacro lyrics-if-defined (name voice . optionals)
  (let ((above (if (pair? optionals) (car optionals) #f)))
(if (defined? name)
  `(make-music 'ContextSpeccedMusic
  'create-new #t
  'context-type 'Lyrics
  'property-operations ',(if above `((assign alignAboveContext ,above)) '())
  'element (make-music 'LyricCombineMusic
 'associated-context ,voice
 'element ,name))
  #{#})))

Does anyone recognise any changes in 2.19.16 which might have affected this 
macro?
(There have been minor changes to this in current master, but both fail the 
same way.)

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

Re: 2 questions re this file

[Trevor Daniels]

Peter Teeson wrote Saturday, February 28, 2015 6:59 PM

 I removed the bar checks in the lyrics and all is OK.
 (I put them in because Learning suggested it…)

Yes, sorry about that.  If that section in the
Learning Manual is to be retained I think it needs to
have an explanation and a warning added, saying that
the check for the occurrence of a barline is made at
the start of the syllable _following_ the barcheck.  
So if a bar starts with a rest the first syllable in 
that bar does not immediately follow the barline, 
and a barcheck should not be placed before it, as 
there is no barline there.

I'll see if I can draft an amendment ...

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

Re: time-signature-single-digit.ly andtime-signature-single-digit.ly don't have \version

[Trevor Daniels]

Masamichi HOSODA wrote Sunday, February 22, 2015 2:59 AM

 I've fixed the issues I found.
 
 Therefore, in this branch,
 https://github.com/trueroad/gub/tree/gcc-4.9
 I've succeed GUB's ``make lilypond''.
 All lilypond installers have been built by gcc-4.9.2.

 In darwin-x86 (Intel Mac), mingw (Windows), linux-64, linux-x86, linux-ppc, 
 freebsd-64, freebsd-x86):
 I've tested lilypond installer and lilypond - they work fine.
 Correct PDF is generated.

I've just had a look at your branch on:
https://github.com/trueroad/gub/network

That's an impressive set of patches over six months of hard work.

Congratulations!  And many thanks for moving this on!

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

Re: node conflict in LM and NR

[Trevor Daniels]

Trevor Daniels wrote Thursday, December 25, 2014 11:19 PM

 Federico Bruni wrote Thursday, December 25, 2014 8:59 PM
 
 There are two identical nodes in LM and NR:
 
 $ cd Documentation
 $ git grep '@node The tweak command'
 learning/tweaks.itely:@node The tweak command
 notation/changing-defaults.itely:@node The tweak command
 
 Due to issue #2266 translated manuals will have a broken link.
 Can you change one of the two?
 
 Will do.

Actually there are masses of duplicate node names across two manuals.
For example, compare LM 1 with NR 1  2.  You'll find the
following are node names in both:

Pitches
Accidentals
Clef
Clefs
Tuplets
Ties
Rests
Time Signature
Bar lines
Grace notes
...
with lots more elsewhere.

Do all these cause problems for the translations?  I really do not want
to try to invent discrete names for all these nodes, especially if the real
problem for the translations lies elsewhere.  So for the time being I shall
withdraw my will do.

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

Re: run make doc without regtest? (issue 4180)

[Trevor Daniels]

Federico Bruni wrote Friday, December 26, 2014 10:01 PM

I cannot compile 'make doc' because of issue 4180.
 IIUC the regtests are run automatically before compiling the 
 documentation? How can I avoid that?

This regtest , time-signature-single-digit.ly, was added as part of commit
586a6d331e22d0e1a255068f07c534d219c7c902
(see Issue 4176.)

It causes LilyPond 2.19.15 to crash in Frescobaldi:

Starting lilypond-windows.exe 2.19.15 [time-signature-single-digit.ly]...
Processing 
`c:/users/trevor/appdata/local/temp/frescobaldi-i1jfd6/tmpskecnk/time-signature-single-digit.ly'
Parsing...
Renaming input to: `time-signature-single-digit.ly'
Interpreting music...
Exited with return code -1073741571.

Was this regtest never executed before being committed?!

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

Re: run make doc without regtest? (issue 4180)

[Trevor Daniels]

Federico,

You could revert commit 586a6d331e22d0e1a255068f07c534d219c7c902 locally or 
temporarily remove that regtest from your local repository while you run your 
make doc tests.

Trevor
  - Original Message - 
  From: Federico Bruni 
  To: Trevor Daniels 
  Cc: Lilypond bug 
  Sent: Friday, December 26, 2014 10:47 PM
  Subject: Re: run make doc without regtest? (issue 4180)


  Il giorno ven 26 dic 2014 alle 23:32, Trevor Daniels t.dani...@treda.co.uk 
ha scritto:

This regtest , time-signature-single-digit.ly, was added as part of commit 
586a6d331e22d0e1a255068f07c534d219c7c902 (see Issue 4176.) It causes LilyPond 
2.19.15 to crash in Frescobaldi: [...] Was this regtest never executed before 
being committed?!


  Well, at least by the automatic doc build:
  https://code.google.com/p/lilypond/issues/detail?id=4176#c2


  It seems that it doesn't occur in any situation:
  http://lists.gnu.org/archive/html/bug-lilypond/2014-10/msg00071.html


  For me it's very annoying because I need to run 'make doc' to check a lot of 
translation updates which I'd like to commit in the next days.


  If anyone knows how to avoid regtests in 'make doc' it would help a lot.


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

Re: node conflict in LM and NR

[Trevor Daniels]

Federico Bruni wrote Thursday, December 25, 2014 8:59 PM

 There are two identical nodes in LM and NR:
 
 $ cd Documentation
 $ git grep '@node The tweak command'
 learning/tweaks.itely:@node The tweak command
 notation/changing-defaults.itely:@node The tweak command
 
 Due to issue #2266 translated manuals will have a broken link.
 Can you change one of the two?

Will do.

The nodes became identical on 10 Oct 2013 when I changed all
the nodes from (for example) @node The \tweak command to
@node The tweak command.  Before that change the two nodes
were distinct, as one had a backslash and the other did not.  See
ff7d82711b47d3d31f26e1e6fc012c4055a20059

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

Re: Place objects by hand

[Trevor Daniels]

David Nalesnik wrote Sunday, November 02, 2014 1:08 PM

 Yes, I would say it's definitely a bug.  This is a bit of misuse of 
 self-alignment-X, but the same happens with this line:

  \once \override DynamicText.self-alignment-X = #5

 So, possibly it's a problem with the Dynamics context?

After a little more experimentation, it turns out it's the way the Dynamics 
context works.  I'm guessing from experimenting, rather than reading code, but 
it seems just the notes above and below all the dynamics in a system are 
selected and a line is centered between the lowest of the notes above a dynamic 
mark and the highest of the notes below a dynamic mark.  All the dynamics are 
then placed along this line and the distance between the staves is adjusted so 
there is (just) no overlap.  Notes without dynamics are permitted to 'poke 
through' the dynamics line.  This rather clumsy example illustrates it. 

\new PianoStaff 
  \new Staff { e' d, d e' e' d e' e' }
  \new Dynamics { s\f s s s\p s s\f s s }
  \new Staff { a'' a'' a'' e''' a a'' e''' a'' }


So if a dynamics mark is moved far enough horizontally so 'its' notes are no 
longer considered we get the effect observed.

After all this I found issues 1127 and 3299!  Should have looked first.

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

Re: suprising touch of rest with accidentals

[Trevor Daniels]

Werner LEMBERG wrote Sunday, November 02, 2014 7:03 AM

 [release/2.19.15-1-13-gdd5a6e7]
 
 with this input
 
  \relative c' {
gis' cis e8[ r fis gis dis' e gis cis]
  }
 
 I would expect that there is at least a tiny distance between the rest
 and the sharp, but it seems that they directly touch – is this
 expected?  Having such a dense setting for a situation where lilypond
 isn't forced to squeeze at all is bad IMHO.

I'd call this a bug.  The manual beam over the rest is necessary to provoke it.
The bug was introduced during the 2.15 develoment cycle - in 2.14.2 it
displays nicely, but compresses in 2.15.95.

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

Re: Pitched rest bug [was: A pause in 3/4 measure]

[Trevor Daniels]

David Kastrup wrote Sunday, November 02, 2014 7:38 AM


 Trevor Daniels t.dani...@treda.co.uk writes:

 Urs Liska wrote Saturday, November 01, 2014 9:06 PM

 Am 1. November 2014 21:55:01 MEZ, schrieb Trevor Daniels 
 t.dani...@treda.co.uk:

Thomas Morley wrote Saturday, November 01, 2014 12:05 PM

 Using d1*3/4\rest has a draw-back:
 The rest will change it's position, if \transpose is used.

 Copying to bug list.  This seems like a bug to me.  Do others agree?  I
 can't see a relevant issue in the tracker.

 Is it not desired behaviour that a pitched rest is affected by 
 transposition? 
 I find thst very plausible. 

 This is the sort of problem I had in mind:

 { b'1 b'1\rest
   \transpose d c { 
 b'1 b'1\rest
   }
 }
   
 I suppose that is partly my fault.  In the discussion with pitches rests
 in irregularly lined staves, Pál went out of his way to snap to the next
 line, and I voted for just taking the user at his word.  In the context
 of transpositions by an even-called interval in a regular staff, well...

 So we probably need some minimal snapping after all.  Or the snapping is
 triggered by the transposition, but I don't think that would be a good
 idea since transpose can work even inside of chords and overrides don't
 belong there.  Or we need at least one manually settable property that
 will cause snapping.

Ah, yes.  That discussion's documented in Issue 2249.  So there is a
relevant issue already in the tracker - marked Needs-evidence.  I
think we have it now.

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

Re: Place objects by hand

[Trevor Daniels]

Noeck wrote Sunday, November 02, 2014 12:46 AM


 That would be nice, but your example puts the f on the left of the upper
 note and not centralized between the staves (I am using 2.19.15).

You're right, Joram, \offset is not a solution.  In fact, it seems to point to
another problem with \offset.  In this example it prevents the dynamic
text being centered between the staves.  I don't understand why it should
have this effect.

\version 2.18.2

\new PianoStaff 
  \new Staff { g-_ g c' }
  \new Dynamics {
\once \offset X-offset -3 DynamicText 
s\f s s\p
  }
  \new Staff { \clef bass g'-_ g' g' }


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

Re: Place objects by hand

[Trevor Daniels]

David, you wrote Sunday, November 02, 2014 12:44 PM

 No, it's not a problem with \offset.

 Substitute this for the call to \offset, and you'll see that it's actually an 
 issue with X-offset here:

  \once \override DynamicText.X-offset = #-3

Ah, sorry to cast invalid aspersions on \offset, David.  Still looks like a bug 
though.  Another example bites the dust.

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

Pitched rest bug [was: A pause in 3/4 measure]

[Trevor Daniels]

Thomas Morley wrote Saturday, November 01, 2014 12:05 PM

 Using d1*3/4\rest has a draw-back:
 The rest will change it's position, if \transpose is used.

Copying to bug list.  This seems like a bug to me.  Do others agree?  I can't 
see a relevant issue in the tracker.

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

Bug in \offset with Fingering.font-size?

[Trevor Daniels]

Should \offset work with the font-size of fingering?  It doesn't seem to.  The 
default value is -5, so offsetting by -2 should give -7, with a size as shown 
by the \override and \tweak, but both forms of \offset give 0.

{
  \set fingeringOrientations = #'(left)
  a'-24
  \override Fingering.font-size = #-7
  a'-2
  \once \offset font-size #-2 Fingering
  a'-2
  a'-\tweak font-size #-7 -2
  a'-\offset font-size #-2 -2
}

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

Re: Pitched rest bug [was: A pause in 3/4 measure]

[Trevor Daniels]

Urs Liska wrote Saturday, November 01, 2014 9:06 PM

 Am 1. November 2014 21:55:01 MEZ, schrieb Trevor Daniels 
 t.dani...@treda.co.uk:

Thomas Morley wrote Saturday, November 01, 2014 12:05 PM

 Using d1*3/4\rest has a draw-back:
 The rest will change it's position, if \transpose is used.

Copying to bug list.  This seems like a bug to me.  Do others agree?  I
can't see a relevant issue in the tracker.
 
 Is it not desired behaviour that a pitched rest is affected by transposition? 
 I find thst very plausible. 

This is the sort of problem I had in mind:

{ b'1 b'1\rest
  \transpose d c { 
b'1 b'1\rest
  }
}
  
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug in \offset with Fingering.font-size?

[Trevor Daniels]

David Nalesnik wrote Saturday, November 01, 2014 9:46 PM

 On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels t.dani...@treda.co.uk wrote:

 Should \offset work with the font-size of fingering?  It doesn't seem to.  
 The default value is -5, so offsetting by -2 should give -7, with a size as 
 shown by the \override and \tweak, but both forms of \offset give 0.

 You're seeing this behavior with \offset because 'font-size can't be set to a 
 callback, which \offset does.

 Enhancing 'font-size to process callbacks would be a useful feature, I think.

Thanks, I see.  I agree, although a warning might be a pro tem stand-in.

There goes my first example of its use for the docs :(

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

Re: Bug in \offset with Fingering.font-size?

[Trevor Daniels]

 David Nalesnik wrote Saturday, November 01, 2014 9:46 PM

 On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels t.dani...@treda.co.uk wrote:

 Should \offset work with the font-size of fingering?  It doesn't seem to.  
 The default value is -5, so offsetting by -2 should give -7, with a size as 
 shown by the \override and \tweak, but both forms of \offset give 0.

 You're seeing this behavior with \offset because 'font-size can't be set to 
 a 
 callback, which \offset does.

 Enhancing 'font-size to process callbacks would be a useful feature, I think.
 
 Thanks, I see.  I agree, although a warning might be a pro tem stand-in.
 
 There goes my first example of its use for the docs :(

It also fails to work on Script.padding, although it's fine for 
DynamicLineSpanner.padding.
{
c'4\fermata
\override Script.padding = 3
c'4\fermata
\offset padding 3 Script 
c'4\fermata
}

Is this a similar problem?

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

Re: Bug in \offset with Fingering.font-size?

[Trevor Daniels]

David Nalesnik wrote Saturday, November 01, 2014 10:40 PM

 Oh!  You're tackling the documentation?  I'm so glad to hear that :) :)

 I might have an example or two from when I was trying (unsuccessfully of 
 course) to write something up.  I think I may have been fooling with 
 Beam.positions.

 Have you seen the regtest offsets.ly?  Maybe one of those examples is 
 workable. 

Yes, I have it in front of me.  Actually, what I was doing was going through
the LM looking for existing examples where \offset might be useful.  It has
to be something where a displacement makes more sense than an absolute
value.  I found two, moving a fermata up a bit with padding and changing the
font size of fingering, but sods' law, neither of these work.  We don't cover
DynamicLineSpanners there, so that's not a possibility, and for most other
objects we have extra-offset, which is covered in the LM and does more or
less what \offset does re moving objects.

So I'm rethinking.  There are too many places where it goes wrong to 
explain in the LM - the concepts of callbacks and define-grobs.scm are
too advanced - and the inverted syntax of the \override form similarly is
potentially confusing in the LM, where users are just beginning to grasp
the \override syntax.  So maybe it is better to document it just in the NR, 
where all this complication can simply be stated, and any property can
be chosen to offset.

I'll abandon my patch to the LM and see what I can do for the NR.

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

Re: Bug in \offset with Fingering.font-size?

[Trevor Daniels]

David Nalesnik wrote Saturday, November 01, 2014 10:53 PM

 On Sat, Nov 1, 2014 at 5:29 PM, Trevor Daniels t.dani...@treda.co.uk wrote:

 It also fails to work on Script.padding, although it's fine for 
 DynamicLineSpanner.padding.

Is this a similar problem?

 Actually, no.  To work, \offset needs access to a default value--a number, 
 number-pair, or list of number-pairs--or a default procedure to calculate 
 these values with.  If you don't find an entry in define-grobs.scm, it will 
 have nothing to work with.

 DynamicLineSpanner.padding works because it's set by default to 0.6.

Hm.  I wonder if it would go badly wrong if it simply assumed 0 in
such cases? Or #'(0 . 0) - whatever it was expecting.  You'd have to assume
the form given in the passed offset value was correct, I suppose.  In
other words, work as if it were \override or \tweak.

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

Re: Bug in \offset with Fingering.font-size?

[Trevor Daniels]

David Nalesnik wrote Saturday, November 01, 2014 11:53 PM

 On Sat, Nov 1, 2014 at 6:21 PM, Trevor Daniels t.dani...@treda.co.uk wrote:

 David Nalesnik wrote Saturday, November 01, 2014 10:53 PM

To work, \offset needs access to a default value--a number,
 number-pair, or list of number-pairs--or a default procedure to calculate
 these values with.  If you don't find an entry in define-grobs.scm, it will
 have nothing to work with.

 DynamicLineSpanner.padding works because it's set by default to 0.6.

 Hm.  I wonder if it would go badly wrong if it simply assumed 0 in
 such cases? Or #'(0 . 0) - whatever it was expecting.  You'd have to assume
the form given in the passed offset value was correct, I suppose.  In
 other words, work as if it were \override or \tweak.

 Wouldn't it just be duplicating the effect of an ordinary override of the 
 property?

Well, yes.  But the point of \offset is that the user doesn't know and doesn't
need to know what the default value is or whether it has a default value or
not.  He or she just wants to shift it a little from where it currently is.

 Would this be a better behavior than what happens currently--maybe 
 give a warning no default found, using 0.0 and at least do something nice?

I don't think a warning would be necessary (assuming you find it works
well).  It would do exactly what the user was expecting.

 Actually, it might not be hard to enhance \offset to deal with Script.  
 The defaults aren't stored in define-grobs, rather they're in script.scm. 
 I'll look into that.

Great!  I've just found two good examples serendipitously with layout
queries from Noeck.  So I'll work with them.  Tomorrow.  It's late.

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

Re: Center whole note chords

[Trevor Daniels]

Dan Eble wrote Wednesday, October 29, 2014 1:15 AM
Subject: Center whole note chords


 I'm not top posting
 % I don't have an engraving reference to consult (yet), but I have a
 % hymnal here with some measures that look better than Lilypond's
 % default.  I hope the experts will weigh in on whether there is
 % material here for a ticket or two.
 %
 % 1. All voices have a fermata to be semantically correct.
 % In a real score, I would have used partcombine but I've left
 % it out for simplicity.  Regardless, the voices in unison in
 % the top staff would not be combined.  Should Lilypond notice
 % this situation and combine and center one fermata over them?

Elaine Gould in Behind Bars, p188, shows some examples of
fermate for unison and adjacent notes.  The fermata always
centres on the note that is on the 'correct' side of the stem (for
adjacent notes) or on the first one (unison).  Two fermate seem
to be shown only if there are two stems.  But I think this should
be left to the engraver to code, rather than expecting LP to
remove a coded fermata.

 %
 % 2. The notes in the lower staff are centered with respect
 % to the notes in the upper staff.

She seems silent on this point, AFAICS.

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

Re: LilyPond - Can't get convert-ly to work

[Trevor Daniels]

Hi Tony

You copied my instructions incorrectly, missing out LilyPond in the path to 
convert-ly in all these examples.

Try again!  It works here.

Trevor

- Original Message - 
From: Tony Warren warr...@talktalk.net
To: Trevor Daniels t.dani...@treda.co.uk
Sent: Sunday, October 12, 2014 12:37 AM
Subject: Re: LilyPond - Can't get convert-ly to work


 Hi Trevor
 
 Won't be around on Sunday morning. Here are some results, still with 
 path entries for Python34 removed:
 
 
 C:\Users\Tony WarrenC:/Program Files/LilyPond/usr/bin/python.exe 
 C:/Program
 Files/usr/bin/convert-ly.py -h
 C:/Program Files/LilyPond/usr/bin/python.exe: can't open file 
 'C:/Program Files/
 usr/bin/convert-ly.py': [Errno 2] No such file or directory
 
 C:\Users\Tony WarrenC:/Program Files/LilyPond/usr/bin/python.exe 
 C:/Program
 Files/usr/bin/convert-ly -h
 C:/Program Files/LilyPond/usr/bin/python.exe: can't open file 
 'C:/Program Files/
 usr/bin/convert-ly': [Errno 2] No such file or directory
 
 C:\Users\Tony WarrenC:/Program Files/LilyPond/usr/bin/python.exe 
 C:/Pr
 ogram Files/usr/bin/convert-ly.py -h
 C:/Program Files/LilyPond/usr/bin/python.exe: can't open file 
 'C:/Program': [Er
 rno 22] Invalid argument
 
 C:\Users\Tony WarrenC:/Program Files/LilyPond/usr/bin/python.exe 
 C:/Pr
 ogram Files/usr/bin/convert-ly.py
 C:/Program Files/LilyPond/usr/bin/python.exe: can't open file 
 'C:/Program': [Er
 rno 22] Invalid argument
 
 C:\Users\Tony Warren
 
 Regret still no go. [The triple inverted commas are suggested in 
 LilyPond 2.18.2 Usage.pdf]
 
 Tony
 
 
 Before getting your going to bed e-mail I took my 'new Python' entries 
 out of the path variable. Still no go.
 
 C:\Program Files\LilyPond\usr\binconvert-ly -h
 Traceback (most recent call last):
   File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in 
 module
 import lilylib as ly
   File C:\Program 
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py,
  line 238
 print log[0]
 ^
 SyntaxError: invalid syntax
 
 C:\Program Files\LilyPond\usr\binpath
 PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program 
 Files\Co
 mmon Files\Roxio Shared\DLLShared\;C:\Program Files\Common Files\Roxio 
 Shared\DL
 LShared\;C:\Program Files\Common Files\Roxio 
 Shared\9.0\DLLShared\;C:\Windows\Sy
 stem32\WindowsPowerShell\v1.0\;C:\Program 
 Files\LilyPond\usr\bin;C:\Program File
 s\LilyPond\usr\share\lilypond\current\python
 
 C:\Program Files\LilyPond\usr\bin
 
 On 12/10/2014 00:01, Trevor Daniels wrote:
 Hi Tony

 Sorry, it's difficult to test here as I don't have a more recent python 
 installed.  But it seems like you'll have to specify complete paths to the 
 python interpreter and convert-ly, like this (all one command):

 C:\Users\TrevorC:/Program Files/LilyPond/usr/bin/python.exe C:/Program 
 Files/LilyPond/usr/bin/convert-ly.py -h

 If this works at least you can execute it in the directory containing the 
 LilyPond source code.

 As it's midnight I'm closing down for tonight.  I'll check again tomorrow.

 Trevor

 - Original Message -
 From: Tony Warren warr...@talktalk.net
 To: Trevor Daniels t.dani...@treda.co.uk
 Sent: Saturday, October 11, 2014 11:44 PM
 Subject: Re: LilyPond - Can't get convert-ly to work


 Trevor

 No go:

 C:\Program Files\LilyPond\usr\binconvert-ly -e C:\0\Psalm136.ly
 Traceback (most recent call last):
File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in
 module
  import lilylib as ly
File C:\Program
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py
   line 238
  print log[0]
  ^
 SyntaxError: invalid syntax

 C:\Program Files\LilyPond\usr\binconvert-ly
 Traceback (most recent call last):
File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in
 module
  import lilylib as ly
File C:\Program
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py
   line 238
  print log[0]
  ^
 SyntaxError: invalid syntax

 C:\Program Files\LilyPond\usr\bin

 Won't I still be picking up the newer Python?

 C:\Program Files\LilyPond\usr\binpath
 PATH=C:\Python34\;C:\Python34\Scripts;C:\Python34\Lib\idlelib;C:\Windows\system3
 2;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\Common
 Files\Roxio Shared
 \DLLShared\;C:\Program Files\Common Files\Roxio
 Shared\DLLShared\;C:\Program Fil
 es\Common Files\Roxio
 Shared\9.0\DLLShared\;C:\Windows\System32\WindowsPowerShel
 l\v1.0\;C:\Program Files\LilyPond\usr\bin;C:\Program
 Files\LilyPond\usr\share\li
 lypond\current\python

 C:\Program Files\LilyPond\usr\bin

 [I installed Python myself, intending to start learning - but have been
 too busy]

 Tony

 On 11/10/2014 23:28, Trevor Daniels wrote:
 Tony

 OK, thanks.  It seems you have a more recent version of the python 
 interpreter installed on your system than the one used by and distributed 
 with LilyPond, and this is taking precedence.  This might have been 
 installed by some other application.

 So

Re: LilyPond - Can't get convert-ly to work

[Trevor Daniels]

Hi Tony

Could you please say which version of LilyPond you are using, so we can be sure 
we're looking at the right code.

And then please enter the command python (without the quotes of course) at 
the Command Prompt and say what the output is.  You can then enter CTRL-Z  
Enter  to get your usual command prompt back.

Trevor

- Original Message - 
From: Tony Warren warr...@talktalk.net
To: bug-lilypond@gnu.org
Sent: Saturday, October 11, 2014 10:13 PM
Subject: LilyPond - Can't get convert-ly to work


 I'm not top posting.
 
 % I know nothing of Python. Help please. See below:
 
 %{
 
 Microsoft Windows [Version 6.0.6002]
 Copyright (c) 2006 Microsoft Corporation.  All rights reserved.
 
 C:\Users\Tony Warrenconvert-ly -h
 Traceback (most recent call last):
  File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in module
import lilylib as ly
  File C:\Program 
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py,
 line 238
print log[0]
^
 SyntaxError: invalid syntax
 
 %}
 %{
 Always get this message, administrator or not, command line options or not,
 supplying file for conversion or not. Help a newbie, please.
 %}
 
 
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fw: LilyPond - Can't get convert-ly to work

[Trevor Daniels]

Missed copying this to bug-lilypond ...

- Original Message - 
From: Trevor Daniels t.dani...@treda.co.uk
To: warr...@talktalk.net
Sent: Saturday, October 11, 2014 11:28 PM
Subject: Re: LilyPond - Can't get convert-ly to work


 Tony
 
 OK, thanks.  It seems you have a more recent version of the python 
 interpreter installed on your system than the one used by and distributed 
 with LilyPond, and this is taking precedence.  This might have been installed 
 by some other application.
 
 So you will need to run convert-ly by passing it to the python interpreter 
 distributed with LilyPond.  To do this, instead of just entering 
 convert-ly, you'll need first to enter
 
 cd C:/Program Files/LilyPond/usr/bin  (in this case, with the quotes)
 
 then you should find that convert-ly works.  You'll need to specify full 
 paths to the LilyPond code you need to convert, unfortunately.
 
 Trevor
 
 
 - Original Message - 
 From: Tony Warren warr...@talktalk.net
 To: Trevor Daniels t.dani...@treda.co.uk
 Sent: Saturday, October 11, 2014 11:06 PM
 Subject: Re: LilyPond - Can't get convert-ly to work
 
 
 Hello Trevor
 
 Lilypond is 2.18.2
 
 Microsoft Windows [Version 6.0.6002]
 Copyright (c) 2006 Microsoft Corporation.  All rights reserved.
 
 C:\Users\Tony Warrenpython
 Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 
 bit (I
 tel)] on win32
 Type help, copyright, credits or license for more information.
 
 
 Thanks for your help
 
 Tony
 
 
 On 11/10/2014 22:56, Trevor Daniels wrote:
 Hi Tony

 Could you please say which version of LilyPond you are using, so we can be 
 sure we're looking at the right code.

 And then please enter the command python (without the quotes of course) 
 at the Command Prompt and say what the output is.  You can then enter 
 CTRL-Z  Enter  to get your usual command prompt back.

 Trevor

 - Original Message -
 From: Tony Warren warr...@talktalk.net
 To: bug-lilypond@gnu.org
 Sent: Saturday, October 11, 2014 10:13 PM
 Subject: LilyPond - Can't get convert-ly to work


 I'm not top posting.
 % I know nothing of Python. Help please. See below:

 %{

 Microsoft Windows [Version 6.0.6002]
 Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

 C:\Users\Tony Warrenconvert-ly -h
 Traceback (most recent call last):
   File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in 
 module
 import lilylib as ly
   File C:\Program 
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py,
 line 238
 print log[0]
 ^
 SyntaxError: invalid syntax

 %}
 %{
 Always get this message, administrator or not, command line options or not,
 supplying file for conversion or not. Help a newbie, please.
 %}


 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
 
 -- 
 AR Warren
 34 Rosehill
 BILLINGSHURST
 West Sussex
 RH14 9QN
 
 t: +44 (0) 1403 783496
 

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

Re: LilyPond - Can't get convert-ly to work

[Trevor Daniels]

Hi Tony

Sorry, it's difficult to test here as I don't have a more recent python 
installed.  But it seems like you'll have to specify complete paths to the 
python interpreter and convert-ly, like this (all one command):

C:\Users\TrevorC:/Program Files/LilyPond/usr/bin/python.exe C:/Program 
Files/LilyPond/usr/bin/convert-ly.py -h

If this works at least you can execute it in the directory containing the 
LilyPond source code.

As it's midnight I'm closing down for tonight.  I'll check again tomorrow.

Trevor

- Original Message - 
From: Tony Warren warr...@talktalk.net
To: Trevor Daniels t.dani...@treda.co.uk
Sent: Saturday, October 11, 2014 11:44 PM
Subject: Re: LilyPond - Can't get convert-ly to work


 Trevor
 
 No go:
 
 C:\Program Files\LilyPond\usr\binconvert-ly -e C:\0\Psalm136.ly
 Traceback (most recent call last):
   File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in 
 module
 import lilylib as ly
   File C:\Program 
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py
  line 238
 print log[0]
 ^
 SyntaxError: invalid syntax
 
 C:\Program Files\LilyPond\usr\binconvert-ly
 Traceback (most recent call last):
   File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in 
 module
 import lilylib as ly
   File C:\Program 
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py
  line 238
 print log[0]
 ^
 SyntaxError: invalid syntax
 
 C:\Program Files\LilyPond\usr\bin
 
 Won't I still be picking up the newer Python?
 
 C:\Program Files\LilyPond\usr\binpath
 PATH=C:\Python34\;C:\Python34\Scripts;C:\Python34\Lib\idlelib;C:\Windows\system3
 2;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\Common 
 Files\Roxio Shared
 \DLLShared\;C:\Program Files\Common Files\Roxio 
 Shared\DLLShared\;C:\Program Fil
 es\Common Files\Roxio 
 Shared\9.0\DLLShared\;C:\Windows\System32\WindowsPowerShel
 l\v1.0\;C:\Program Files\LilyPond\usr\bin;C:\Program 
 Files\LilyPond\usr\share\li
 lypond\current\python
 
 C:\Program Files\LilyPond\usr\bin
 
 [I installed Python myself, intending to start learning - but have been 
 too busy]
 
 Tony
 
 On 11/10/2014 23:28, Trevor Daniels wrote:
 Tony

 OK, thanks.  It seems you have a more recent version of the python 
 interpreter installed on your system than the one used by and distributed 
 with LilyPond, and this is taking precedence.  This might have been 
 installed by some other application.

 So you will need to run convert-ly by passing it to the python interpreter 
 distributed with LilyPond.  To do this, instead of just entering 
 convert-ly, you'll need first to enter

 cd C:/Program Files/LilyPond/usr/bin  (in this case, with the quotes)

 then you should find that convert-ly works.  You'll need to specify full 
 paths to the LilyPond code you need to convert, unfortunately.

 Trevor


 - Original Message -
 From: Tony Warren warr...@talktalk.net
 To: Trevor Daniels t.dani...@treda.co.uk
 Sent: Saturday, October 11, 2014 11:06 PM
 Subject: Re: LilyPond - Can't get convert-ly to work


 Hello Trevor

 Lilypond is 2.18.2

 Microsoft Windows [Version 6.0.6002]
 Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

 C:\Users\Tony Warrenpython
 Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32
 bit (I
 tel)] on win32
 Type help, copyright, credits or license for more information.
 Thanks for your help

 Tony


 On 11/10/2014 22:56, Trevor Daniels wrote:
 Hi Tony

 Could you please say which version of LilyPond you are using, so we can be 
 sure we're looking at the right code.

 And then please enter the command python (without the quotes of course) 
 at the Command Prompt and say what the output is.  You can then enter 
 CTRL-Z  Enter  to get your usual command prompt back.

 Trevor

 - Original Message -
 From: Tony Warren warr...@talktalk.net
 To: bug-lilypond@gnu.org
 Sent: Saturday, October 11, 2014 10:13 PM
 Subject: LilyPond - Can't get convert-ly to work


 I'm not top posting.
 % I know nothing of Python. Help please. See below:

 %{

 Microsoft Windows [Version 6.0.6002]
 Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

 C:\Users\Tony Warrenconvert-ly -h
 Traceback (most recent call last):
File C:\Program Files\LilyPond\usr\bin\convert-ly.py, line 52, in 
 module
  import lilylib as ly
File C:\Program 
 Files\LilyPond\usr\share\lilypond\current\python\lilylib.py,
 line 238
  print log[0]
  ^
 SyntaxError: invalid syntax

 %}
 %{
 Always get this message, administrator or not, command line options or 
 not,
 supplying file for conversion or not. Help a newbie, please.
 %}


 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
 -- 
 AR Warren
 34 Rosehill
 BILLINGSHURST
 West Sussex
 RH14 9QN

 t: +44 (0) 1403 783496

 
 
 -- 
 AR Warren
 34 Rosehill
 BILLINGSHURST
 West Sussex
 RH14 9QN
 
 t

Re: Mistake in addInstrument example

[Trevor Daniels]

Timothy Lanfear wrote Sunday, August 24, 2014 8:06 PM

 Notation reference section 2.1.6. The example illustrating the use of
 addInstrumentDefinition sets instrumentTransposition context properties
 incorrectly. The midi output for Kaspar is an octave too low. The
 transposition for Melchior is harmless but unnecessary.

You're right, Timothy.  The notes for both Kaspar and Melchior are
entered at the correct sounding pitch, so no transposition is required
for either of them.  I'll raise a bug report to fix it.

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

Re: self-alignment-X has negligible effects on dynamics

[Trevor Daniels]

Janek Warchoł wrote Monday, July 28, 2014 10:12 PM


 2014-07-28 22:51 GMT+02:00 David Nalesnik david.nales...@gmail.com:

 I think that this should be made clear in the documentation, if you haven't
 already done this!
 
 Yes, i should do this (or maybe some doc editor would like to help me?
 I would prefer to focus on making further changes in the code).

If your code changes necessitate a change to the documentation and you
haven't done this yourself, please add an issue to the tracker explaining
what changes and/or additions need to be made to the documentation at
the time the code change is pushed.  Remember at the time you push
your changes it is likely that you are the only one who understands what
the implications are re the documentation.  It is unlikely any doc editor
will pick this up otherwise.

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

Re: Shifted notehead won't merge with same pitch from other voice

[Trevor Daniels]

Simon Albrecht wrote Thursday, May 29, 2014 11:43 AM

 http://www.lilypond.org/doc/v2.18/Documentation/learning/real-music-example

 Rereading this, I notice that the Moderato marking in the example would 
 probably be more accurately and straightforwardly coded as

 \tempo Moderato
 bes2.

 than as

 bes2.^\markup { \bold Moderato } .

 Accordingly, the second sentence in the paragraph after the fourth music 
 example 
 should be changed from The tutorial showed how to add bold text with the 
 \markup command, so adding Moderato in bold is easy. to The tutorial
 showed how to add a tempo indication with the \tempo command, so adding 
 Moderato is easy.

 I'm not familiar with the patching process etc. so, if there are no 
 objections to this, 
 could someone apply the change, please?

Seems like an improvement.  I'll have a look.  Thanks.

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

Re: Shifted notehead won't merge with same pitch from other voice

[Trevor Daniels]

Trevor Daniels wrote Thursday, May 29, 2014 4:50 PM
 
 Simon Albrecht wrote Thursday, May 29, 2014 11:43 AM
 
 http://www.lilypond.org/doc/v2.18/Documentation/learning/real-music-example

 Rereading this, I notice that the Moderato marking in the example would 
 probably be more accurately and straightforwardly coded as

 \tempo Moderato
 bes2.

 than as

 bes2.^\markup { \bold Moderato } .

 Accordingly, the second sentence in the paragraph after the fourth music 
 example 
 should be changed from The tutorial showed how to add bold text with the 
 \markup command, so adding Moderato in bold is easy. to The tutorial
 showed how to add a tempo indication with the \tempo command, so adding 
 Moderato is easy.

 I'm not familiar with the patching process etc. so, if there are no 
 objections to this, 
 could someone apply the change, please?
 
 Seems like an improvement.  I'll have a look.  Thanks.

Done

See https://code.google.com/p/lilypond/issues/detail?id=3933

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

Re: Add Extending a TrillSpann in the doc.

[Trevor Daniels]

Pierre Perol-Schneider wrote Tuesday, April 08, 2014 8:45 PM

 After a discussion on the french forum I've added this snippet to the LSR:
 http://lsr.di.unimi.it/LSR/Item?u=1id=912
 
 I think it would be helpfull to add it in the doc :
 http://lilypond.org/doc/v2.18/Documentation/notation/spanners
 
 with beams and glissandi.

The need to use both these properties for glissandi and beams is already 
clearly shown in the section you reference.  What does this example add to what 
is already shown, other than showing they are also both needed for 
TrillSpanner?  I think two examples are sufficient, considering the length of 
the NR.  That said, I'd be happy to see a simple list added giving _all_ the 
spanners for which springs-and-rods has to be set to permit minimum-length to 
become effective.

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

Re: Docs: example for line-break-permission and page-break-permission

[Trevor Daniels]

Paul Morris wrote Tuesday, February 25, 2014 7:44 PM

 That means that this statement is potentially misleading:
 
 Lily sometimes rejects explicit \break and \pageBreak commands. There are
 two commands to override this behavior:

Well, Lily does sometimes reject explicit breaks, for example when they
are placed in the middle of an incomplete bar:

  { a4 a8 a4 a \break a a a a a8 \break a4 a a a }

but the following commands do not override this behaviour.  So in this
respect the two statements are misleading.  But are there other circumstances 
where both sentences as written are correct?  I can't think of any.
 
 So I like James' suggestion for a more thorough explanation that would
 remove this ambiguity.

Indeed.  I think we need a tracker to record this discussion and the
eventual conclusion.  Bug Squad: could you please set one up?

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

Re: Docs: example for line-break-permission and page-break-permission

[Trevor Daniels]

James wrote Tuesday, February 25, 2014 5:58 AM

 On 24/02/14 21:18, Paul Morris wrote:
 The example given here:
 http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
 
 While not addressing your suggestion directly, but being one of the few 
 doc editors I am not sure this part of the Notation Reference has been 
 'touched' for a while - certainly since I started helping (back in 2011) 
 and when we have since had many spacing/break code improvement changes - 
 I seem to recall that we were on 2.12 back then.

Probably not; I've never edited this section AFAIR.
 
 This whole document section doesn't follow standard policy; again, not 
 that that casts any aspersions on your email but just using the term 
 'Lily' instead of LilyPond, and seeing no useful TexInfo references to 
 other, related the parts of the documentation (this is more of a 
 editorial discussion than anything for me).

If you're thinking of working on this page it would be good to tidy it
up a little (as a separate commit of course).

However, I'm not sure that the change proposed by Paul is correct.
I think the current wording is correct.

Try this, and you'll see the long line runs off the right side of the page.
No line break is inserted to prevent it; only the manual ones are actioned.

\paper {
  indent = #0
  ragged-right = ##t
  ragged-bottom = ##t
}

music = \relative c'' { c8 c c c }

\score {
  \new Staff {
\repeat unfold 4 { \music } \break
\repeat unfold 20 { \music } \break
\repeat unfold 4 { \music } \break
  }
  \layout {
\context {
  \Score
  \override NonMusicalPaperColumn.line-break-permission = ##f
  \override NonMusicalPaperColumn.page-break-permission = ##f
}
  }
}

 
 While examples are helpful of course I am wondering if we could better 
 explain some of these functions/commands than having to 'waste' pages of 
 webspace and documentation with literal (and verbatim) \pageBreak examples?
 
 Trevor do you see what I mean?

Yes.  I'd remove the pagebreak from this example (since its effect is not
clear in the docs anyway); use a smaller example showing a line break being
inserted and being suppressed; and simply say page-break-permission
works the same way.  I'd also give the music variable a full bar of notes
rather than half a bar so the repeat counts correspond with the number
of bars in the lines.

I've not really looked at the other examples, but if you want to propose
changes please do it one example at a time.

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

Re: redundant entries in the indexes are confusing and lesseningthe clarity

[Trevor Daniels]

James wrote Saturday, February 01, 2014 10:51 AM


 On 01/02/14 10:14, Eluze wrote:

 add \single, \temporary \undo and  more to the index - is that worth an
 entry in the tracker!?

 A tracker? I'd just create a patch and submit it (and create the tracker 
 with git-cl for that patch). Otherwise you are going to have to say 
 where you want the @cindex's specifically. Seems as you know how to make 
 a patch that you might as well do them and submit them yourself. I don't 
 think it is ever a bad idea to have index entries.

I agree.

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

Re: Fw: Error in documentation

[Trevor Daniels]

David Kastrup wrote Thursday, January 16, 2014 5:47 AM

 Just pushed a fix for the parenthesis engraver to staging.  The chord
 bracket stuff was already fixed shortly before:
 
 commit 4bdb9204b1b682b38bd76afc03e5d629621428f1

 Should cherry-pick into translation, I think, so that this moves into
 2.18.1 as well.

Thanks David.  No need for a tracker then.

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

Re: Error in documentation

[Trevor Daniels]

This has been fixed already.

Trevor

Phil Holmes wrote Thursday, January 16, 2014 3:25 PM


 Copying to -bugs for an issue.

  - Original Message - 
  From: Peter Crighton 
  To: LilyPond Mailing List 
  Sent: Wednesday, January 15, 2014 10:27 PM
  Subject: Error in documentation


  Hello all,
  in the documentation about percussion notation it is said that you need to 
include the Parenthesis_engraver in order to use \parenthesize – 
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-percussion.html#ghost-notes
 This is not true, you do not have to include anything. Also, you do not have 
to add chord brackets.
  Maybe this could be updated?

  --
  Peter Crighton | Musician  Music Engraver based in Mainz/Wiesbaden, Germany
  http://www.petercrighton.de


--


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






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

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

Fw: Error in documentation

[Trevor Daniels]

Forwarding to bug list ...

- Original Message - 
From: Peter Crighton petecrigh...@gmail.com
To: LilyPond Mailing List lilypond-u...@gnu.org
Sent: Wednesday, January 15, 2014 10:27 PM
Subject: Error in documentation


Hello all,
in the documentation about percussion notation it is said that you need to
include the Parenthesis_engraver in order to use \parenthesize –
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-percussion.html#ghost-notes
This
is not true, you do not have to include anything. Also, you do not have to
add chord brackets.
Maybe this could be updated?

--
Peter Crighton | Musician  Music Engraver based in Mainz/Wiesbaden, Germany
http://www.petercrighton.de






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

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

Re: \defineBarLine is confusing

[Trevor Daniels]

Keith OHara wrote Tuesday, December 31, 2013 6:14 AM


 Trevor Daniels t.daniels at treda.co.uk writes:
 
 The description of \defineBarLine in NR 1.2.5 does
 not make it clear that the parameter called bartype
 doubles as both the name of the barline being defined
 and the definition of the bar line to be used in
 the middle of the line (i.e. not at the beginning or
 the end.)  
 
 Why not \defineBarLine normal end start span?
 
 I agree that the simple list of four arguments would be better.
 
 I traced the history to find the discussion at the point where the
 grouping was introduced:
 http://lists.gnu.org/archive/html/lilypond-devel/2012-09/msg01031.html

Hm, there was very little discussion of this point in a very long
thread.  Only David expressed an opinion AFAICS.  I think I
must have stopped following it at the time due to the length of the
thread.

I came across this when trying to document \inStaffSegno better,
and had to use the new \defineBarLine documentation in the NR.
I couldn't understand it without referring to the Scheme implementation
which used a simple list of four arguments and was perfectly clear.
So either the user interface or the documentation (or probably both)
should be improved.

 I think there might be consensus to reverse that decision.
 (I would raise a tracker issue, but maybe better to give it a day 
 on the mailing list in case there is other input.)

OK.  No one else has chimed in yet.  Maybe no one else has
tried to understand \defineBarLine from scratch :)

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

Re: Spacing/collision behaviour of NullVoice

[Trevor Daniels]

Urs Liska wrote Tuesday, December 17, 2013 9:01 AM

 However I noticed a behaviour I wouldn't have expected:
 
 Try out the following snippet:
 
 soprano = \relative c' { c e g c }
 verse = \lyricmode { This is my song }
 
 \score {
   \new Staff 
  %\soprano
  { \oneVoice r4. r4 r4. }
 \new NullVoice = aligner \soprano
 \new Lyrics \lyricsto aligner \verse
   
   \layout {}
 }
 
 The rests are placed wrongly, obviously avoiding _something_.

NullVoice has had a checkered history, and has never worked
perfectly in all situations.  The current implementation is the best
so far, but still has a restriction which I quote from the NR:

The NullVoice context must be inside a Staff context, and should 
only contain notes that are already being displayed in that staff, and 
in the same octave. Otherwise the NullVoice may interact with the 
printed voices in unexpected ways. For example, arbitrary notes in 
the NullVoice may cause accidentals to appear (or disappear) on the 
staff.

and implied, I think, at the same musical moment.

See 
http://www.lilypond.org/doc/v2.17/Documentation/notation/techniques-specific-to-lyrics#index-NullVoice

It looks like you have found a further restriction relating to rests.

Trevor


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

Re: Usage 3.1: \verb+lilypond-book+

[Trevor Daniels]

Federico Bruni wrote Sunday, December 15, 2013 10:45 AM


 http://lilypond.org/doc/v2.17/Documentation/usage/an-example-of-a-musicological-document.html
 
 Below the Input section there is:
 
 Documents for \verb+lilypond-book+ may freely mix music and text.
 
 \verb+ is intended? It's inside a verbatim block...

I'm not familiar with LaTeX, but this looks like valid input.
It produces the output lower down.

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

Re: Missing notes after lyrics end: bug?

[Trevor Daniels]

Arjen Bax wrote Sunday, December 15, 2013 2:48 PM

 Complete minimal working example, omitting the lower staff:
 
  \version 2.16.2
 
  sopTxt = \new Lyrics = sopL \with { alignAboveContext = upper }
\lyricsto sop \lyricmode { A C }
 
  sopV = \relative c'' {  { c2 c } { \sopTxt }  c4 c c c }
  altV = \relative c'  { c4 c c c c c c c }
 
  \score {
\new ChoirStaff 
  \new Staff = upper 
 \new Voice = sop { \voiceOne \sopV }
 \new Voice = alt { \voiceTwo \altV }
  
  \new Lyrics \lyricsto alt { A B C D E F G H }

  }
 
 Where are the four c4 notes of the soprano?

This may be a bug.  Copying to the bug list.

Removing \lyricsto restores the missing notes, so as a work-around,
given you have just one bar, remove \lyricsto and enter the duration
of each syllable explicitly.

Trevor

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

Re: [Lilypond] Incorrectly print notes with length 16*7 and 16*5

[Trevor Daniels]

 Neither am I :)

This output looks correct to me.  In the first example you're asking for a
g16 to be displayed but for its duration to be 7/16 long followed by a fis16 
with duration 5/16, so filling the bar.  See 
http://www.lilypond.org/doc/v2.17/Documentation/notation/writing-rhythms#scaling-durations

Did you intend to produce 7 g16s followed by 5 fis16s?  If so, this is the
way to do it:

\repeat unfold 7 g16
\repeat unfold 5 fis16

See
http://www.lilypond.org/doc/v2.17/Documentation/notation/repeats

Trevor
 
Jimmie Felidae wrote Monday, October 28, 2013 1:15 PM

 I'm not top posting.
 
 Tested on Lilypond 2.17.29 and latest release of 2.16.
 
 Example 1:
 % Wrong output in bar 1
 \version 2.14.0
 
 \relative c {
  \key d \major
  \time 6/8
  g16*7 fis16*5
  |
  d2.
  |
 }
 
 Example 2:
 % Wrong output in bar 1
 \version 2.14.0
 
 \relative c {
  \key f \major
  \time 4/4
  \tempo 4 = 126
  c4 g16*5 r16*7
  |
  f8 d16 d8. g8 f4 d8 c
  |
  d1
  |
 
 }
 
 
 
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: strange automatic line breaking after full measure rests andbefore small durations

[Trevor Daniels]

pls wrote Friday, October 11, 2013 4:26 PM

Hm, but why are there line breaks after every R1? e.g.:

R1*12
r2 r4 r8 r16 r32 r64 r128 r128

It's due to the artificial nature of this example.  LP tries to estimate a 
suitable spacing for the section of music presented, based on the shortest 
duration found.  The 128th notes lead her to believe long measures will be 
needed to accommodate all these short notes.  Try removing the shortest notes 
progrssively and you'll see the changes.  Maybe a better algorithm would 
actually count how many short notes are present, but that would need to be 
implemented as an enhancement, and it is rare that difficulties arise for 
'real' music, even with this simple estimation.

As Eluze said:
 you can correct it with a more appropriate value, eg.
 
 \set Score.proportionalNotationDuration = #(ly:make-moment 1 12)

This can be used to override Lily's estimation by setting a more suitable value 
if only a small number of short notes are present.

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

Re: LM 4.5: dead link

[Trevor Daniels]

Federico Bruni wrote Sunday, September 29, 2013 3:33 PM

 2013/9/29 David Kastrup d...@gnu.org
 
 Federico Bruni fedel...@gmail.com writes:

  for the record, I've solved by adding a double backslash in the italian
  file, as suggested here:
  http://lists.gnu.org/archive/html/lilypond-devel/2008-08/msg00206.html

 That sounds like an unrobust solution as it depends on a particular
 erroneous behavior.  It's quite likely that this will not work
 identically across several versions of Texinfo (Texinfo 5.0 may be
 different) and across different backends.

 it's just a temporary solution until the node name in the english file is
 fixed.
 I hope someone can deal with this, I don't know the doc policy

It seems a backslash in a node name causes no problems for
references within the same manual, but cross-references across
manuals fail.  The correct way of dealing with this is to drop the
backslash from the node name and encode it using the bs{}
macro in the heading.  Here's an example from changing-defaults.itely:

@node The set command
@subsection The @code{@bs{}set} command

I see there are several node names in the documentation that include
native backslashes, but only the one noted above is used in a 
reference across manuals.  I'll fix ref_check.py to check for backslash
in note names to give a warning, and amend all the instances in the
documentation.  Oh, and add a note to the CG.

@bug Squad: could you please raise an issue to track this

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

Fw: film score example

[Trevor Daniels]

The message below, posted on the user list, contains a useful list of problems 
encountered 
while learning and using LilyPond for a significant project.  Some suggest 
improvements to the
documentation are needed; others could be turned into requests for 
enhancements.  I wonder
if the bug squad would like to trawl this for new tracker items?

Trevor

- Original Message - 
From: Curt accou...@museworld.com
To: Lilypond-User List lilypond-u...@gnu.org
Sent: Friday, September 13, 2013 4:54 AM
Subject: film score example


 Hi all - 
 
 About a year ago, several of you answered questions of mine about notating a 
 film score.  I reached a stopping point with the first cue and learned a bit 
 more about git, so I have the first film cue from the score up on github now:
 
 https://github.com/tunesmith/TheForgivingSea
 
 (pdf of score at: 
 https://github.com/tunesmith/TheForgivingSea/blob/master/1M2/pdf/1M2.pdf )
 
 The score was originally prepared (in Sibelius) a few years ago, under the 
 tutelage of a professional hollywood film composer, Hummie Mann, and was 
 performed/recorded by a volunteer orchestra, so it's been through several 
 revisions to tighten it up.  This project was to re-notate it in lilypond.  
 It's also a simple, short score, so it might be useful for various learning 
 purposes.  I'm also more than happy to receive any suggestions or pull 
 requests on how to improve the score or simplify the lilypond coding.
 
 Appended below is part of one of the README's - the unexpected difficulties 
 I had with lilypond, as in the areas that didn't seem to work easily right 
 away.  (Note that I started this re-notation project as a complete lilypond 
 beginner.)  A big one here is giant time signatures, which are common in 
 film scores but don't seem to have a graceful solution in lilypond.  Please 
 note that these are just the (minor) complaints, and that overall I was 
 *extremely* happy with the experience and output.  I did this all in eclipse 
 (elysium) on a 15  MacBook Pro and loved the coding experience.
 
 Thanks for all your help, I hope someone finds this useful!
 
 Curt
 
 ~^~^~^~^
 
 Unexpectedly hard parts of creating this score (all specific to v2.16):
 
 - General spacing and staff sizes.  I believe Lilypond by default puts 
 everything 
 too close together for music that is read by instrumentalists, particularly
 sight-readers.  The spacing commands are easy to use, but difficult to find
 and look up if you don't already know them.
 
 - I make liberal use of tagging for part extraction.  It appears this is 
 the best
 way to handle minor differences between parts and full scores.
 
 - Hairpins are surprisingly difficult.  Most instruments do not have a natural
 decay, so hairpins don't necessarily start or end right at the note
 boundaries.  It's necessary to use fake voices in these cases.  Even
 with this, it didn't support having a decrescendo end at the Fine bar - 
 I had to make it end at a note value before the Fine bar.  And
 if you have ties over these fake voices, you have to know about
 \set tieWaitForNote = ##t
 
 - Header text elements are a bit bearish to configure.  Our instructions were 
 to
 put the instrument name in the upper left of each part; I ended up using
 the out of the box poet slot, and then later reconfigured all of 
 bookTitleMarkup to reposition instrument when it became clear I'd need 
 the instrument slot for later pages.  It also could be easier to put a 
 simple newline in, for longer instrument names.
 
 - The alignment of the flat sign in text markup like Clarinet in Bb is 
 difficult.
 I gave up on this one because the approach to make it look right felt too
 hard-coded.
 
 - The \sustainOff right-alignment looks bad to me.  It should end at the 
 barline
 or at the rest you stop pedaling; not right afterward.  Pedaling usually 
 implies
 you pedal for the duration of the note, but not longer.
 
 - It was difficult to figure out how to create a percussion staff where 
 someone
 switched from a pitched instrument to a rhythm instrument.  Also, I'm not 
 quite convinced on the choice for a percussive half note- I've seen open-heads
 in these situations before, but I found it impossible to override the notehead
 in \drummode.
 
 - It was extremely hard to specify a subito dynamic right after a hairpin.  
 This
 is a relatively common use-case, but I had to pull in a pretty complicated
 scheme function, and modify it, to make it work as expected.  This one 
 requirement
 probably took around six hours.
 
 - Making courtesy/cautionary accidentals show up in just the parts was a more 
 verbose process than it needed to be, it seemed.  I wasn't able to do this
 reliably unless I tagged the entire measure.  The programmer in me wanted
 to just tag the cautionary accidental alone.
 
 - Fermatas were often misaligned, too close to or colliding with slurs.  
 Manual
 padding was necessary.
 
 - In film scoring, it's common to include the 

Fw: whiteout bug

[Trevor Daniels]

Phil Holmes m...@philholmes.net wrote in message 
news:kt58ju$3le$1...@ger.gmane.org...

 For one or two of the builds, it appears that the tail is placed 
 in front of the whiteout box, for reasons I don't understand, although I do 
 remember Keith saying that the order of placing whiteout and other grobs is 
 not determinate and has led to odd regression test results.

The order in which grobs _in the same layer_ are placed is indeterminate,
but this can be controlled by setting the 'layer property.  See

http://www.lilypond.org/doc/v2.17/Documentation/notation/visibility-of-objects#index-layers

for details.

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

Re: Fw: whiteout bug

[Trevor Daniels]

Eluze wrote Monday, July 29, 2013 12:42 PM

 Trevor Daniels wrote

 The order in which grobs _in the same layer_ are placed is indeterminate,
 but this can be controlled by setting the 'layer property.  See
 
 http://www.lilypond.org/doc/v2.17/Documentation/notation/visibility-of-objects#index-layers
 
 for details.
 
 thanks for pointing us to this - so the correct workaround (if one insists
 on sky-lines) is:
 
  \layout {
\context {
  \Staff
  \override TextScript.whiteout = ##t
  \override TextScript.layer = #0
}
  }
 
 the odd thing is you have to find a fitting integer.
 
 in our case only the value #0 is satisfying.
 
 #1   leads to the cropping behavior 
 #-1 has the bar line drawn through the text

Yes, although sometimes you might have to change the 'layer for other
grobs to 'make room', as Lily uses only 0 and 1 by default and
only integral values are accepted for 'layer.  So if you want something
to appear reliably above the staff lines but below the bar lines you'd
need to change the 'layer for StaffSymbol to some negative integer,
say -2, and use -1 for the grob you want to insert.

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

Re: ly:grob-system not working as expected

[Trevor Daniels]

Mark Polesky wrote Thursday, July 11, 2013 5:35 AM

 Actually, I would say the vast majority of scheme functions
 in that list ought to have clearer docstrings:
 http://lilypond.org/doc/v2.17/Documentation/internals/scheme-functions
 
 Again, what's the protocol here, should I wait for someone
 on the bug squad to add a tracker issue, or should I add it
 myself?

Add it yourself.  The bug squad's responsibility is to make sure reported
bugs don't get ignored by adding trackers if no developer has done so.  
They and developers together raise tracker issues.

 - Mark
Trevor

(Nice to see you back, Mark!)


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

Re: Bug in

[Trevor Daniels]

Peter Toye wrote Monday, May 13, 2013 9:37 AM

 Lilypond crashes out when I use the %e format in a header 
 (I'm allergic to
 leading zeroes). This is under Windows 7 Home Premium. Postings on the
 Lilypond mailing list indicate that 
 this is specific to Windows - and it
 works OK on Linux. I'm not in a position to test this.
 
 Example:
 
 \version 2.16.2
 
 \header {
  tagline = \markup {
Engraved
\simple #(strftime %d %e %Y (localtime (current-time)))
  }
 }
 
 {
  c d e f
 }
 
 Lilypond log:
 
 Starting lilypond-windows.exe 2.16.2 [Bridge6(strftime).ly]...
 Processing
 `c:/users/peter_2/appdata/local/temp/
 frescobaldi-y9etc5/tmpurt867/Bridge6(strftime).ly'
 Parsing...FATAL: memory error in realloc
 Exited with return code 3.

Under Windows Vista Home Premium and LilyPond 2.17.17 this gives:

 Processing `test.ly'
 Parsing...
 This application has requested the Runtime to terminate it in an unusual way.
 Please contact the application's support team for more information.

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