Re: New breathing mark

[Carl Sorensen]

On Sat, Nov 12, 2022 at 10:00 AM  wrote:

From: samarutuk 
> To: bug-lilypond 
> Cc:
> Bcc:
> Date: Sat, 12 Nov 2022 10:10:35 +0100
> Subject: Breath mark style in LilyPond 2.23.80
> Dear all,
> when I tried version 2.23.80 for the first time yesterday, I was
> absolutely shocked to see the new, very mundane comma as a breath mark
> when rendering. I know that other notation programs also use the comma,
> but for me the more caesura-like character used before was always a
> reason to use Emmentaler/Feta, also and especially in MuseScore. The
> normal text style comma, with its delicate tadpole continuation, goes
> down much more easily in an opulent score with lyrics, staccato dots,
> and other expressive marks. It's a misstep aesthetically and for
> readability reasons, in my humble opinion. As a brass player, breath
> marks are very important and actually occur in large numbers, so this
> comma will really haunt me constantly.
> However, since I don't expect you to undo it, then I do ask that you
> still preserve the old style so that each Lilypondian can decide for
> themselves whether to use the snappy comma or the Emmental original
> breath mark (tm). If MuseScore (which I still use) adopts the modified
> font, I may add the old breath mark there as well.
> Sorry for the long text... and yes, I'm still shocked (and sticking with
> older versions for now).
> Kind regards
> Andreas
>
>
Andreas,

This was an intentional change, implemented in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1576

At least two developers prefer the new breath mark.

Perhaps you could request that the old mark be added back to Feta, and that
code allowing one to use the old mark be developed.

Since this was an intentional change, it's not a bug, so bug-lilypond is
not the best place to discuss it.  Either lilypond-user or lilypond-devel
would be a better place.

Sincerely,

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

Re: LilyPond on macOS (was: \repeat unfold has problems inside \repeat volta)

[Carl Sorensen]

On Sat, Jul 2, 2022 at 10:23 AM Jean Abou Samra  wrote:

> Le 02/07/2022 à 18:14, Carl Sorensen a écrit :
>
> > I can't currently run 2.23.10 on my Mac, so I can't try it,
>
>
> What is the problem you are encountering? I think that normally, it
> should work on all 64-bit-capable Macs.


I don't run LilyPond at the command line, but I use Frescobalidi.

When I extract the files from lilypond-2.23.10-darwin-x86_64.tar.gz and
place it in my Applications folder, then point Frescobald to lilypond in
bin/ , I get the following error:

Traceback (most recent call last):

File
"/Applications/Frescobaldi.app/Contents/Resources/lib/python3.5/frescobaldi_app/lilypondinfo.py",
line 224, in done

AttributeError: 'Process' object has no attribute 'process'


I assume I am mangling things by my usage, and I haven't had the time to
try to figure the problem out.


I'd welcome any insights on how to take that downloaded binary and put it
somewhere on my system so I can use it with Frescobaldi.


Thanks,


Carl





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

Re: What is the point of bug-lilypond?

[Carl Sorensen]

On 10/16/21, 4:55 AM, "lilypond-devel on behalf of Jean Abou Samra" 
 wrote:



A factor to consider is that, as far as I can read
http://lilypond.org/bug-reports.html (but I can't
remember how it worked for myself), posting to
bug-lilypond requires being subscribed to the list,
thus receiving all subsequent bug reports, which is
not what a user wants. On GitLab, just turn on
notifications for an issue if you are interested
in it. This is turned on by default if you are
the author of the report.

When I started with bug-lilypond, posting did not require subscribing.  Now, 
apparently, it does, probably to avoid spam (we had a problem with spam on 
bug-lilypond for a while).

However, one can subscribe to the list and turn off all emails.

It's also a question of communication. With bug-lilypond,
a bug report is supposedd not to immediately interface with
developers (for some definition of this term). A drawback
of GitLab issues is that everyone there receives notification
for all reports including those that are not actually
valid. I would actually turn this to an advantage:
it's often interesting to see common failure patterns
(leading to better interfaces and/or better documentation).

I have turned off GitLab issues, because I don’t want to be swamped with the 
updates.  I am, however, subscribed to bug-lilypond so I can see what problems 
come up and will respond to those that I feel a need to.

I would be really disappointed if we replaced bug-lilypond with GitLab issues.  
GitLab issues give you the whole history.  bug-lilypond just gives you the 
report and the issue number for the created issue (if I want more information).

I would stop interacting with bug reports entirely if bug-lilypond is replace 
with direct submission to GitLab issues.

Thanks,

Carl
 

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

Re: A suggestion for Dynamic staves

[Carl Sorensen]

On 9/30/21, 10:32 AM, "Peter Toye"  wrote:

Oddly, Frescobaldi doesn't recognise \magnifyMusiceither wher I've put it 
or within the brackets.

You haven't matched the required structure for the file.  Our parser is 
flexible to allow different kinds of music functions, so sometimes the error 
messages are less than helpful.

Here's code that works (note the extra set of braces to put all the \
magnifyMusic and the music argument all within the Dynamics context.

\version "2.22.1"
\language "english"
\score {
  <<
\new Staff {
  \relative {
a'4\f 4 4\> 4
4 4 4 4\!
  }
}
\new Staff \with {
  \magnifyStaff #5/7
}
{ \relative {
  a'4\f 4 4\> 4
  4 4 4 4\!
  }
}
\new Dynamics {
\magnifyMusic #5/7
{
%  \override DynamicText.font-size = #-3
  s4\f 4 4\> 4
  4 4 4 4\!
}
}
  >>
}

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

Re: Changing volta number text

[Carl Sorensen]

On 5/18/21, 2:11 PM, "Jean Abou Samra"  wrote:


It is worth noting that the \volta command added by Dan Eble in the 2.23 
development series does exactly the job requested here, if I understood 
correctly.

Perfect!

Thanks,

Carl



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

Re: Changing volta number text

[Carl Sorensen]

On 5/18/21, 1:46 PM, "lilypond-user on behalf of Kieren MacMillan" 
 wrote:

Hi Ralph,

> I have to admit, after learning from you that the documentation is 
accurate, and spending some time examining the various examples in the 
documentation, I think I could achieve what I want. It takes some real effort, 
and I think it would be difficult for someone who has little experience with 
LilyPond. And isn't that the point of the documentation?

Absolutely. My comment was meant as a [gentle] criticism of the 
documentation, not of you or other users. Even if it explicitly pointed out 
that one needs to *not use* the \repeat volta command, that would be [more] 
helpful!

> I think it would be helpful to include an appropriate example in the 
manual repeat marks section of the documentation.

Given that the combination of the first three examples at 

 is sufficient to solve your example, and the fourth example is almost exactly 
what you needed, what would a more appropriate example look like? Would that be 
in addition to the existing examples, or as a replacement to one of them?

The sheer size of the Lilypond docs is already pretty overwhelming; just 
adding more examples won’t necessarily make it easier for users.

> I guess I'll make a note of the solution!

Some syntactic sugar might be nice… I could imagine a function that took a 
list of string+moment pairs and “unfolded” a volta automagically. If my life 
ever calms down, maybe I’ll give that a try.

It seems to me that, for right now, Aaron's changeVoltaText function is the 
preferred way to do it, as it preserves the \unfoldRepeats behavior (albeit 
with warnings).

I'd be in favor of Aaron's snippet being added to the Docs.

Carl
 

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

Re: 64 bit MacOS version + Apple Silicon version

[Carl Sorensen]

From: Marnen Laibow-Koser 
Date: Thursday, April 22, 2021 at 1:26 PM
To: Carl Sorensen 
Cc: Bart Kummel , David Kastrup , Karlin High 
, Kenneth Wolcott , 
"bug-lilypond@gnu.org" 
Subject: Re: 64 bit MacOS version + Apple Silicon version
[..]
Do you have any suggestions about how I could “help out with the Mac build 
scripts”?  I’ve been to that site, and I’m not sure what I could best do to 
help out.
Try using the Makefile that’s there to build a newer version of LilyPond.  See 
what breaks.  Submit a merge request (or at least an issue) so we know we need 
to fix it.

Alternatively, you may want to help out on the automated build pipeline (which 
only barely exists right now).

If documentation is a problem, *definitely* raise an issue on the GitLab 
project.  I want this to be as approachable as such a complex project can be.

OK.  These are great suggestions.

It may be two weeks or so before I can jump into this.  I’m swamped with the 
end of semester challenges.

I’ll give it a go as soon as I can.

Thanks,

Carl

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

Re: 64 bit MacOS version + Apple Silicon version

[Carl Sorensen]

From: Marnen Laibow-Koser 
Date: Thursday, April 22, 2021 at 12:59 PM
To: Carl Sorensen 
Cc: Bart Kummel , David Kastrup , Karlin High 
, Kenneth Wolcott , 
"bug-lilypond@gnu.org" 
Subject: Re: 64 bit MacOS version + Apple Silicon version



On Thu, Apr 22, 2021 at 2:54 PM Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:
The problem is that there is not an .app bundle for 2.22.0.  The latest is 
2.20.0.  It would be nice to have .app bundles available for every release.  
And I don’t know how to make that happen.  That’s why I’m asking questions.

Please help out with the Mac build scripts, then!  Until the LilyPond 
maintainers choose to take them, they’re in a separate project at
https://gitlab.com/marnen/lilypond-mac-builder .  Contributions would be *most* 
welcome there (and if the LilyPond project wants to take over that repo, that 
would also be welcome; I’m doing this mostly because no one else was, not 
because I particularly want to run the Mac build effort).

Do you have any suggestions about how I could “help out with the Mac build 
scripts”?  I’ve been to that site, and I’m not sure what I could best do to 
help out.

Thanks,

Carl

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

Re: 64 bit MacOS version + Apple Silicon version

[Carl Sorensen]

From: Marnen Laibow-Koser 
Date: Thursday, April 22, 2021 at 12:48 PM
To: Bart Kummel 
Cc: Karlin High , Carl Sorensen , 
Kenneth Wolcott , David Kastrup , 
"bug-lilypond@gnu.org" 
Subject: Re: 64 bit MacOS version + Apple Silicon version


On Thu, Apr 22, 2021 at 2:24 PM Bart Kummel 
mailto:b...@kummelweb.nl>> wrote:
Jean,

The first thing I do is checking the website, in this case 
lilypond.org<http://lilypond.org>. There is a section about reporting a bug. It 
says to check the bug list and if your bug isn't there, report it. That's what 
I did. It didn't say "search through years of mail archives". And, let's be 
honest, it is HARD to come to conclusions from a mail archive, especially when 
you weren't part of the discussion.

That discussion aside, it seems the Homebrew formula found here 
https://github.com/nwhetsell/homebrew-lilypond does work. It's fairly simple, 
but takes a while to run.

My suggestion would be to update the MacOS download page, and add Homebrew and 
Macports as preferred installation methods. I'd be happy to help updating that 
page, if someone can tell me where to start.

Macports should *not* be the preferred method of installing LilyPond on Mac OS; 
I believe most Mac users these days stay far away from it (I know I do).  I 
like Homebrew for some things, but I've generally found it awkward for 
installing things like LilyPond, which is why I created the downloadable .app 
bundles.

Is there a problem with the .app bundles?  Why are we having this discussion 
right now?  I think I'm missing some context.

The problem is that there is not an .app bundle for 2.22.0.  The latest is 
2.20.0.  It would be nice to have .app bundles available for every release.  
And I don’t know how to make that happen.  That’s why I’m asking questions.

Thanks,

Carl

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

Re: 64 bit MacOS version + Apple Silicon version

[Carl Sorensen]

On 4/22/21, 9:49 AM, "Bart Kummel"  wrote:

I think you should re-consider this comment: "The other option is ditching
LilyPad and doing a Darwin-only version of LilyPond, assuming that we can
do this with suitably free components.", by David Kastrup. I don't think
many people are using the limited editor LilyPad. There are a lot of better
tools available (Frescobaldi). I'd rather have a native LilyPond without
the *Pad, than having to compile it myself or rely on a Docker solution.

This implies that the only reason we need Apple's SDK is for compiling the 
LilyPad editor.  Is that true?

Is it possible to create a Mac app bundle without the SDK?

We currently have a MacPorts way to install LilyPond on 64-bit MacOS systems, a 
Homebrew way to install LilyPond on 64-bit MacOS systems, and Marnen's work on 
a 64-bit .app bundle for MacOS systems.

I really prefer the .app bundle, because it is path-independent and it makes it 
easy for me to have multiple versions installed.  As far as I know, only the 
.app version can be delivered as a binary and installed any place I'd like to 
put it.

If it were possible to have a MacOs .app bundle that could be created on 
non-Apple hardware, even if all the app did was open the .ly file in TextEdit, 
I'd be all over that.  And I think I have some time this summer to try to make 
it work.  But I don't know enough about developing on the Mac to know if this 
is possible.  Does anybody else?

Thanks,

Carl


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

Re: Lilypond 2.23.0 crashes on layout

[Carl Sorensen]

On 2/17/21, 12:21 PM, "Arusekk"  wrote:

> This statement seems a little bit strange to me.  I didn't think we had a
> lilypond editing app on Linux -- only on Windows and MacOS.  How are you
> using lilypond when it is "not told to lay out"?  Are you using
> Frescobaldi?  Are you using Denemo?  Are you using Emacs?  I would be
> surprised if Frescobaldi or Emacs had anything to do with the issue,
> because both just call the lilypond executable.  But I think it's good to
> understand your use case completely.

I use vim or kate, and I meant omitting \layout{} from the .ly script, 
sorry 
for confusing wordings. I am not a native English speaker, and I sometimes 
over-complicate by mistake, especially when it comes to words related to 
music.

Thank you.  That is now clear.

The English I would use would be "when there is no layout block".

Fortunately, Jonas figured out the error very quickly and has already posted a 
patch for review.

Carl


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

Re: Lilypond 2.23.0 crashes on layout

[Carl Sorensen]

On 2/16/21, 4:00 PM, "Arusekk"  wrote:

On my box lilypond crashes every single time I command it to produce 
PDFs (never does if not told to lay out), so I think I can provide much 
help, maybe core files, or recorded execution from GDB (never tried to 
do it before, though).

This statement seems a little bit strange to me.  I didn't think we had a 
lilypond editing app on Linux -- only on Windows and MacOS.  How are you using 
lilypond when it is "not told to lay out"?  Are you using Frescobaldi?  Are you 
using Denemo?  Are you using Emacs?  I would be surprised if Frescobaldi or 
Emacs had anything to do with the issue, because both just call the lilypond 
executable.  But I think it's good to understand your use case completely.

Thanks,

Carl
 

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

Re: wrong text font

[Carl Sorensen]

This is a known issue that was resolved back in 2016.  It has to do with some 
font configurations.

See here for more info:

http://lilypond.1069038.n5.nabble.com/Problem-with-Fonts-too-big-td196510.html

HTH,

Carl
  

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

Re: Fonts on Arch Linux

[Carl Sorensen]

I checked on Wikipedia.

The Libertine website has been archived in the Wayback Machine.

You can also get a forked continuation of the now non-developed Linux Libertine 
fonts as  Libertinus, which has Serif, Sans, and Mono variants.

https://www.tug.org/TUGboat/tb37-1/tb115hosny.pdf

https://github.com/alif-type/libertinus

You may wish to investigate thin font with ongoing development.

Carl


On 6/28/20, 6:09 AM, "Andrew Bernard"  wrote:

Thanks Aaron. I didn't give an MWE as it was a preliminary probe to
see if this is a known issue.

Here's the code in question:

  #(define fonts
 (set-global-fonts
  #:roman "Linux Libertine O"
  #:sans "Linux Biolinum O"
  #:typewriter "Linux Libertine Mono O"
  #:factor (/ staff-height pt 20)
  ))

However, I have only recently moved to Arch, so I am setting up all
anew. After a) going nuts and b) exploring everything there is to be
known about fontconfig, I tried deleting all files in ~/.cache, which
includes a lot of fontconfig cache data. Now the issue has gone away.
I suspect, but I can't be sure that this is a subtle issue - the Linux
Libertine and Biolinum original font site seems to have been defunct
for a long time, and while setting up my new system I had to source
the fonts from a whole lot of dubious free font download sites, and
the all seem to be different all in different ways. I think I just had
a bad set of font data cached. Possibly. but clearing the cache solved
this.

I do not know what happened to the original source of these fonts.
They are veyr fine,. and Biolinum is a very good stand in for Optima.

Andrew



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

Re: Dead link in documentation

[Carl Sorensen]

On 6/5/20, 12:43 AM, "Dave Atkinson"  wrote:

> Dear Lilypond Devs,
>
> I'm reading Lilypond - Extending, and trying to learn a bit of Scheme to 
> achieve my aims. At the bottom of the page
>
> https://lilypond.org/doc/v2.19/Documentation/extending/scheme-simple-data-types
>
> there is the following sentence:
> 
> There are additional Scheme data types that are not discussed here. For 
> a complete listing see the Guile reference guide, 
> http://www.gnu.org/software/guile/manual/html_node/Simple-Data-Types.html.
> 
> The link appears to be dead and takes me to a 404 - Page Not Found 
> landing page at gnu.org.
> 
> Cheers,
> 
> Dave


The current link is here:

https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Simple-Data-Types.html#Simple-Data-Types

Carl


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

Re: Keys won't display as text in saxophone diagram

[Carl Sorensen]

Here’s a version of display-woodwind-diagrams.scm that I think will work, but I 
don’t know enough about saxophone diagrams to say. Please give it a try.

It would be nice if you could create a regression test that tests all of the 
desired behavior of saxophone diagrams in both text mode and graphical mode.  
Then we would have some way of ensuring things work properly.

With this code

\version "2.20.0"

fingering = \markup \override  #'(graphical . #f)
{
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two three five))
  (lh . ( T bes))
  (rh . ()))
}
}

fingeringGraph = \markup %\override  #'(graphical . #f)
{
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two three five))
  (lh . (T bes ))
  (rh . ()))
}
}

\score {
{
   ^\fingering
  r r
   ^\fingeringGraph
}
}

I got what appears to match your desired output in Text mode, as well as the 
proper output in graphical mode (I think).

Carl


From: Antonio Ortega Brook 
Date: Thursday, May 21, 2020 at 9:18 PM
To: Carl Sorensen 
Cc: "bug-lilypond@gnu.org" , Valentin Villenave 
, Valentin Villenave 
Subject: Re: Keys won't display as text in saxophone diagram

This would be the desired output

On Thu, 21 May 2020 at 22:46, Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:
What is the desired output?

Carl

From: Antonio Ortega Brook 
mailto:antonioortegabr...@gmail.com>>
Date: Thursday, May 21, 2020 at 7:13 PM
To: Carl Sorensen mailto:c_soren...@byu.edu>>
Cc: "bug-lilypond@gnu.org<mailto:bug-lilypond@gnu.org>" 
mailto:bug-lilypond@gnu.org>>, Valentin Villenave 
mailto:valen...@villenave.net>>, Valentin Villenave 
mailto:v.villen...@gmail.com>>
Subject: Re: Keys won't display as text in saxophone diagram

Oh, don't worry, I've already edited the file (just took a look at Valentin's 
merge request to see what was changed).
After fixing this a new issue came up: in text mode, the octave key is 
displayed as a misaligned circle, instead of a T letter.
I paste the code below an attach the output.
Cheers

\version "2.20.0"

fingering = \markup \override #'(graphical . #f) {
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two three five))
  (lh . (T bes))
  (rh . ()))
}
}

\score {
 ^\fingering
}

On Thu, 21 May 2020 at 20:46, Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:
Valentin,

Thanks for the quick fix.  I was trying to fix it, but I'm not as fast as you.

If you attach the proper copy of scm/display-woodwind-diagrams.scm to an email, 
 I can give Antonio instructions about how to get the file into the proper 
place on his MacOS.

The instructions:

Browse (using finder) to the folder containing LilyPond.app
Right-click (or control-click) on LilyPond.app, and select "Show Contents"
Click on Resources
Click on Share
Click on lilypond
Click on 2.20.0
Click on scm
Drag the proper copy of display-woodwind-diagrams.scm into the scm/ folder.

This procedure is necessary because I don't think we've ever had a version 
without this typo.

HTH,

Carl



On 5/20/20, 5:42 PM, "Antonio Ortega Brook" 
mailto:antonioortegabr...@gmail.com>> wrote:

Hello everyone. First of all I think maybe I misunderstood the instructions
for bug reporting and I've opened an issue in GitLab before posting to this
list and now I think that I might not be supposed to do that. I'm very
sorry for the inconvenience.
Anyway, I get the following error when trying to display key names in a
saxophone diagram:

/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/display-woodwind-diagrams.scm:1773:55:
Wrong type argument in position 2 (expecting list): #f
Exited with return code 1.

Example:

\version "2.20.0"

fingering = \markup \override #'(graphical . #f) {
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two four five six))
  (lh . (b))
  (rh . (ees)))
}
}

\score {
 ^\fingering
}

Attached is the expected result.
Best regards
--
Antonio


--
Antonio Ortega Brook


--
Antonio Ortega Brook


display-woodwind-diagrams.scm
Description: display-woodwind-diagrams.scm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Keys won't display as text in saxophone diagram

[Carl Sorensen]

What is the desired output?

Carl

From: Antonio Ortega Brook 
Date: Thursday, May 21, 2020 at 7:13 PM
To: Carl Sorensen 
Cc: "bug-lilypond@gnu.org" , Valentin Villenave 
, Valentin Villenave 
Subject: Re: Keys won't display as text in saxophone diagram

Oh, don't worry, I've already edited the file (just took a look at Valentin's 
merge request to see what was changed).
After fixing this a new issue came up: in text mode, the octave key is 
displayed as a misaligned circle, instead of a T letter.
I paste the code below an attach the output.
Cheers

\version "2.20.0"

fingering = \markup \override #'(graphical . #f) {
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two three five))
  (lh . (T bes))
  (rh . ()))
}
}

\score {
 ^\fingering
}

On Thu, 21 May 2020 at 20:46, Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:
Valentin,

Thanks for the quick fix.  I was trying to fix it, but I'm not as fast as you.

If you attach the proper copy of scm/display-woodwind-diagrams.scm to an email, 
 I can give Antonio instructions about how to get the file into the proper 
place on his MacOS.

The instructions:

Browse (using finder) to the folder containing LilyPond.app
Right-click (or control-click) on LilyPond.app, and select "Show Contents"
Click on Resources
Click on Share
Click on lilypond
Click on 2.20.0
Click on scm
Drag the proper copy of display-woodwind-diagrams.scm into the scm/ folder.

This procedure is necessary because I don't think we've ever had a version 
without this typo.

HTH,

Carl



On 5/20/20, 5:42 PM, "Antonio Ortega Brook" 
mailto:antonioortegabr...@gmail.com>> wrote:

Hello everyone. First of all I think maybe I misunderstood the instructions
for bug reporting and I've opened an issue in GitLab before posting to this
list and now I think that I might not be supposed to do that. I'm very
sorry for the inconvenience.
Anyway, I get the following error when trying to display key names in a
saxophone diagram:

/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/display-woodwind-diagrams.scm:1773:55:
Wrong type argument in position 2 (expecting list): #f
Exited with return code 1.

Example:

\version "2.20.0"

fingering = \markup \override #'(graphical . #f) {
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two four five six))
  (lh . (b))
  (rh . (ees)))
}
}

\score {
 ^\fingering
}

Attached is the expected result.
Best regards
--
Antonio


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

Re: Keys won't display as text in saxophone diagram

[Carl Sorensen]

Valentin,

Thanks for the quick fix.  I was trying to fix it, but I'm not as fast as you.

If you attach the proper copy of scm/display-woodwind-diagrams.scm to an email, 
 I can give Antonio instructions about how to get the file into the proper 
place on his MacOS.

The instructions:

Browse (using finder) to the folder containing LilyPond.app
Right-click (or control-click) on LilyPond.app, and select "Show Contents"
Click on Resources
Click on Share
Click on lilypond
Click on 2.20.0
Click on scm
Drag the proper copy of display-woodwind-diagrams.scm into the scm/ folder.

This procedure is necessary because I don't think we've ever had a version 
without this typo.

HTH,

Carl



On 5/20/20, 5:42 PM, "Antonio Ortega Brook"  
wrote:

Hello everyone. First of all I think maybe I misunderstood the instructions
for bug reporting and I've opened an issue in GitLab before posting to this
list and now I think that I might not be supposed to do that. I'm very
sorry for the inconvenience.
Anyway, I get the following error when trying to display key names in a
saxophone diagram:

/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/display-woodwind-diagrams.scm:1773:55:
Wrong type argument in position 2 (expecting list): #f
Exited with return code 1.

Example:

\version "2.20.0"

fingering = \markup \override #'(graphical . #f) {
\center-column {
\woodwind-diagram
#'saxophone
#'((cc . (one two four five six))
  (lh . (b))
  (rh . (ees)))
}
}

\score {
 ^\fingering
}

Attached is the expected result.
Best regards
-- 
Antonio

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

Re: Bar number with chord name

[Carl Sorensen]

On 4/19/20, 9:07 AM, "Aidan O Connor"  wrote:

Hi,

Thanks for that info. The workaround makes sense.
But the behavior seems a little inconsistent. If the cord names are removed the 
bar numbers appear above the staff, but below the fret diagram. Is the fret 
diagram not considered part of the score system?


CDS-> The fret diagrams are markups attached to chords in the staff, so they 
are part of the staff.  If you had used a FretBoards context as well as a 
ChordNames context, you would have found the bar numbers above the fret 
diagrams.

HTH,

Carl
I am using a brain-dead Mac version of Microsoft Outlook that does not allow 
proper internet-style quoting for inline replies.
So you can see that my contributions begin with CDS->



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

Re: Possible documentation error in 2.7.2

[Carl Sorensen]

On 2/29/20, 1:46 AM, "Ben Eichler"  wrote:

HI there,


I read at "2.7.2 Displaying Chords" in the docs: "*Chord names can be
displayed only at the start of lines and when the chord changes.*"

This is a little bit misleading. By default, each chord in the content is
printed by Lilypond. The documentation is trying to point out that this
behaviour can be overridden, but this is not apparent to new readers of the
documentation.

Could this sentence in the documentation be clarified to something like
this: *"By default, each chord in the content is printed. This behaviour
can be overridden using the chordChanges setting, as shown below."*

The original sentence is in a selected snippet.  ALL of the selected snippets 
are used to show overrides, because we try to avoid overrides in the main body 
of the text.

The second sentence of your proposal goes against the documentation policy.  We 
don't talk through the code.  We consciously and deliberately make these 
descriptions as short as possible.

Something like "The ChordNames context can be set to display chord names only 
at the start of lines and when the chord changes." would be more consistent 
with our policy, although listing the context name is suspect.  How would you 
feel about that sentence?

Thanks,

Carl


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

Re: Documentation suggestions.

[Carl Sorensen]

On 12/30/19, 11:58 AM, "Peter Toye"  wrote:

Monday, December 30, 2019, 6:39:39 PM, David Kastrup wrote:

> Peter Toye  writes:

>> As an occasional and fairly new Lilypond user I've found that the
>> documentation is occasionally obscure or misleading. I've made a few
>> suggestions below.

 
>> 2. Neither LM nor NR mention that the default language for entering
>> pitches is English. This might be confusing to non-English newbie
>> engravers. I suggest adding to LM Section 1.2.1 'Pitches' something
>> like:

> It isn't.  The default is "nederlands", very much different from
> English.

Sorry - I only tried English and Deutsch. In any case, it needs a mention.

It's mentioned in the Notation Reference, Section 1.1.1 Accidentals, which also 
has a link to Note Names in other languages.

>> 'By default, note names are written using English notation. You can
>> change this using the \language command. See [add reference to NR
>> 1.1.1 "Note names in other languages"]'

A statement very similar to this is in LM 2.1.2 Accidentals

>> 3. In NR 1.2.5 'Bar and bar number checks' I suggest adding a
>> paragraph at the bottom of the section:

>> 'Note that if MIDI output is selected and volta repeats are in place,
>> the bar number check will fail. It is best to suppress MIDI output
>> whle checking bar numbers.'

> Is this a feature of Midi or rather of repeat expansion?

It seems to be an interaction. Midi doesn't handle repeats (except 
unfolded) and it seems to mess up the bar number checks if you include Midi 
output with repeats. Scared me because I thought I couldn't count

I think that this behavior has been fixed in master: 
https://sourceforge.net/p/testlilyissues/issues/5624/

So we don't need to add this to the documentation. 


>> 4. The characters allowed in variable names are only briefly touched
>> upon: in LR 2.4.1 the use of only alphabetic characters is mentioned
>> as a convention, while NR 3.1.5 states this as a requirement. In a
>> LilyPond-user email David Kastrup said "It's alphabetic characters in
>> the ASCII set plus all non-ASCII characters, potentially interspersed
>> with isolated single underlines or dashes." From other hints and
>> experiments it appears that any characters are allowed if the name is
>> enclosed in double quotation marks. I suggest in NR 3.1.5 'File
>> Structure' in the bullet point 'A variable...' the last sentence is
>> replaced by:

>> 'By convention, the name of a variable consists of upper- and
>> lower-case alphabetic characters only. In addition, non-ASCII
>> characters and non-adjacent single underscores and dashes are also
>> allowed. Any combination of characters is allowed if the variable name
>> is enclosed in double quotation marks.'

> Inside of double quotation marks, backslashes
> and double quotation marks
> need to be escaped with backslashes.

Fine - I'd not tried that, but it's fairly obvious now I think about it 
that some sort of escape is needed. I suggest adding your sentence to the end 
of mine.

>> I've changed David's wording slightly to be marginally more accurate
>> (IMO). This may need to be checked for accuracy.

> I think we need to differentiate between what
> currently works and what
> we want to _promote_ as a convention.

To an extent, yes, but a _reference_ manual should be complete, unless 
there's a positive movement towards changing it in the near future. My 
suggested text points out the convention, as does LM.

I think we need to be careful about what we write here.  I think in the NR we 
should have only the recommended usage for variable names in the body text, and 
put the "Do anything you want with quotes" in the Known Issues section.  That 
way it will be there, but clearly listed as an exception.

>> 5. The context of the various \tag commands is not described. I had
>> assumed that they were lexical items, similar to many directives for
>> conditional compilation; this was not correct! I suggest adding the
>> following text to NR 3.3.2 'Using Tags', but I'm not sure of the best
>> placement. Either close to the top of the section, before the
>> examples, or at the very end, before "see also":

>> 'Note that \keepWithTag and \removeWithTag are themselves music
>> expressions and so must appear within a \score block.'

> Music expressions don't need to appear in a \score block.  They can
> appear at top level, in a \book, in assignments and other places.

OK. I was wrong in detail. Sorry. 

But my basic point is that this isn't mentioned in the documentation as far 
as I can see. Thomas says that \keepWithTag etc. are music functions, 
presumably as opposed to commands. I was unaware of this; it 

Re: Midi block gives errors with bar number checks

[Carl Sorensen]

From: Peter Toye 
Reply-To: Peter Toye 
Date: Tuesday, November 26, 2019 at 11:43 AM
To: Carl Sorensen , "bug-lilypond@gnu.org" 

Subject: Re: Midi block gives errors with bar number checks

Carl,

I've just found the MIDI "beat clock" - 24 per crotchet. Still no bar numbers 
though!

Hmm, I’ve been using MIDI on a MacBook using GarageBand.  Apparently Apple has 
added a framework called Core MIDI that adds the concepts of Bars, Beats, and 
SubBeats to the MIDI time stream.  So I always have Bars in mm work.

I suppose that one could make the midi performer ignore \barNumberCheck.  The 
only time I can imagine that would be problematic is if one were only  using 
LilyPond to create a midi file.   And I suppose that as long as it were 
properly documented, users would not expect it to work.

Thanks,

Carl

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

Re: Midi block gives errors with bar number checks

[Carl Sorensen]

On 11/26/19, 9:24 AM, "Peter Toye"  wrote:

The following MWE gives bar number check errors. If you comment out the 
midi block they go away. Bizarre, but a definite bug IMHO.

I don't think it's a bug at all.  Midi files require ascending bar numbers, 
IIUC.  You can't have two measure #2 in a midi file.

So you can label the bar with whatever bar number you want.  But when you run 
the midi, you'll just get incremented bar numbers.

Hence, the midi sees the fourth bar as bar 4, regardless of whether it is in an 
alternative or not.

If you put \barNumberCheck on your bars 1 and 2 and then unfold the repeats in 
your midi, you'll see errors on each bar number check.

\version "2.19.52"

\language "english"

music = {
\new Staff {
\repeat volta 2 {
  \barNumberCheck 1 c''1 \barNumberCheck 2 1
}
\alternative {
  { \barNumberCheck #3 d''1  }
  { \barNumberCheck #3 e''1 }

}
{ \barNumberCheck #4 f''1 | }
}

}

\score {
  \music
  \layout {
\set Score.alternativeNumberingStyle = #'numbers
\override Score.BarNumber.break-visibility = ##(#t #t #t)
  }
}

%
% comment out the midi block to remove errors
\score {
  \unfoldRepeats
  \music
  \midi { }

}


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

Re: [musicxml2ly] handling empty staffs

[Carl Sorensen]

On 6/14/19, 9:35 AM, "Florian"  wrote:

Hi again,

    
Carl Sorensen-3 wrote
> I believe that this is less a bug in musicxml2ly and more a limitation of
> musicxm2ly.  MusicXML and Lilypond have fundamentally different concepts
> of the structure of music.  These differences lead to inability to exactly
> render the MusicXML in LilyPond for complicated structures.

Hmm - I'm not so deep into MusicXML and Lilypond - I would really appreciate
it if you could elaborate a bit more on that? It is always good to
understand the limitations :)

I don't know enough to do so.


Carl Sorensen-3 wrote
> In this case, the note of musicXML is correctly rendered -- that is, the
> note is put in the correct voice and the correct staff.However, the
> musicXML structure is different from the LilyPond structure, so there is
> not a one-to-one correspondence.

I see - since MusicXML does not have a kind of grouping per voice or staff
like Lilypond-> just a simple list of pitches (which can be assigned to any
voice and staff) it might be not so easy to (automatically) decide what to
do in musicxml2ly: like adding an { s1*2 } to keep the context alive or
adding some more \change Staff="2" or whatever… 

But still -  if this kind of limitation is known, does it mean that
musicxml2ly can’t provide a sane default if there’s any? 

I can contribute a fix if there’s such a default and somebody explains it to
me… 

I don't think it is as simple as having a sane default.  I think it will mean 
changing the way musicxml2ly makes its fundamental score layout.  To solve this 
particular problem as a special case we would need to somehow track which 
contexts are missing content and then add spacer rests.  This would require 
parsing the whole lilypond music tree, I think, and is not really a simple 
problem.

On the other hand, one could put a generic fix in place by finding the length 
of the music (still not a trivial problem, I think) and then automatically 
putting a spacer part of the same length in parallel with each of the staff 
contexts (or maybe with each of the voice contexts instead).  This would create 
unnecessary elements in the .ly score, but would solve the problem.

IMO, the best solution is just to hand manipulate the .ly score to make it a 
good score.  But I wouldn't be opposed to you developing a solution to solve 
the problem and avoid the hand manipulation.

Thanks,

Carl


 

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

Re: [musicxml2ly] handling empty staffs

[Carl Sorensen]

On 6/10/19, 12:00 PM, "Florian"  wrote:

Hi Aaron, 


Aaron Hill wrote
> Seems to be a case of the first context not being alive by the time the 
> other notes come along.  If you manually added some spacer rests of 
> suitable length to the upper Staff...
> 
> 
>  \context Staff = "1" <<
>\mergeDifferentlyDottedOn \mergeDifferentlyHeadedOn
>{ s1*2 } %% Keeping context alive.
>  >>
> 
> 
> ...then the output appears correct.

When adding the spacer rests the output contains now two staffs as expected
but they have different time signatures (C vs. 4/4) which is not correct
either. So I guess more manual work is required here which brings me back to
the initial request to classify this as a musicml2ly bug :)  
I hope we can avoid any manual post processing - that's why I'm using
lilipond... 

I believe that this is less a bug in musicxml2ly and more a limitation of 
musicxm2ly.  MusicXML and Lilypond have fundamentally different concepts of the 
structure of music.  These differences lead to inability to exactly render the 
MusicXML in LilyPond for complicated structures.

In this case, the note of musicXML is correctly rendered -- that is, the note 
is put in the correct voice and the correct staff.However, the musicXML 
structure is different from the LilyPond structure, so there is not a 
one-to-one correspondence.

IMO, when there is not perfect correspondence between structural 
representations, expecting a converter to handle all possible outcomes is 
unreasonable.If the information in the musicXML is all captured (and it 
appears to be so for this case), then the converter has done its job.

I'm certainly not opposing raising an issue for this, but fixing it would be 
very low priority for me.

Thanks,

Carl
 

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

Re: modern-straight and flat- flags too thick and too spaced apart

[Carl Sorensen]

On 2/17/19, 7:52 PM, "edes"  wrote:


el 2019-02-17 a las 21:41 Thomas Morley escribió:

> I'm currently working on it.

Thank you!


> Though, there is a design-decision we need to do.

Indeed...

In general terms, I stand by my original opinion that both flat *and*
modern-straight flags should behave like beams (but I might be missing
something, of course...).

But the Stockhausen examples you show don't behave like *traditional* beams.  
The Stockhausen examples show the flags all coming from the stem at the same 
point relative to the staff lines.  Traditional beams vary where they are 
relative to the staff lines (lower ones rest, middle ones straddle, higher ones 
hang, IIRC).  Since the Stockhausen beams don't live on the staff, they don't 
have to be concerned about the staff lines, and I suspect they are just one 
staff-space apart, although I haven't measured carefully.

In the Crumb piece, we can't tell what's happening with the flat flags/beams; 
they aren't on the staff lines.  But I suspect that they are exactly one 
staff-space apart, so they don't behave like traditional beams either.

I think this discussion belongs on the -user list, not the bug list, as we're 
now talking about aesthetics, so I've copied it over there.

Thanks,

Carl

 

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

Re: modern-straight and flat- flags too thick and too spaced apart

[Carl Sorensen]

On 2/16/19, 7:22 PM, "edes"  wrote:


Hello, list.

Some time ago I reported a bug with modern-straight and flat flags, and it
was accepted as issue 5412:

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

I only have a very basic knowledge of lilypond, but I assume that this
problem happens at the font level, and that there is no way to improve the
output by tweaking the lilypond code?

It turns out that the straight family of  flags is actually implemented in 
scheme.

The file is scm/flag-styles.scm

The thicknesses are hard-coded at lines 111 (modern-straight-flag), 117 
(old-straight-flag), and 122 (flat-flag).

The names of the variables (which show up only as numbers in these calls) are 
found at line 60.

Unfortunately, at this point there does not appear to be any grob property for  
the thickness, so there is not a straightforward override.  You'll need to edit 
the scheme file.  Or, you could define your own straight flag style by copying 
(and altering) one of the flag definitions.

If you get some better numbers, and especially if you have some evidence from 
nicely-engraved scores, it's likely that we would replace the defaults.

Thanks,

Carl


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

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

[Carl Sorensen]

On 1/14/19, 11:11 AM, "samaru...@aim.com"  wrote:

PS Windows+Mac: StemUp/Downs appear everywhere after the import, this 
was not the case with older LilyPond versions, e.g. 2.19.31, which I 
still use on my Windows system because of the errors listed above (I 
know that would probably be another separate issue).

   
Further searching for philomelos (which was a fork of musicxml2ly that was 
apparently reintegrated into lilypond in the commit I referenced earlier) led 
to the following:

https://github.com/Philomelos/lilypond-musicxml2ly-dev

which contains the following in its release notes:

v0.1.13:

added the command line options --nsd / --no-stem-directions to ignore stem 
direction indications given in MusicXML, and use lilypond's automatic stemming 
instead.

You might try using the command option --no-stem-directions or --nsd and see if 
that eliminates the spurious stem direction commands.

HTH,

Carl



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

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

[Carl Sorensen]

On 1/14/19, 9:32 PM, "Carl Sorensen"  wrote:



On 1/14/19, 11:11 AM, "samaru...@aim.com"  wrote:

PS Windows+Mac: StemUp/Downs appear everywhere after the import, this 
was not the case with older LilyPond versions, e.g. 2.19.31, which I 
still use on my Windows system because of the errors listed above (I 
know that would probably be another separate issue).

   
Further searching for philomelos (which was a fork of musicxml2ly that was 
apparently reintegrated into lilypond in the commit I referenced earlier) led 
to the following:

https://github.com/Philomelos/lilypond-musicxml2ly-dev

which contains the following in its release notes:

v0.1.13:

added the command line options --nsd / --no-stem-directions to ignore stem 
direction indications given in MusicXML, and use lilypond's automatic stemming 
instead.

You might try using the command option --no-stem-directions or --nsd and 
see if that eliminates the spurious stem direction commands.

HTH,

Carl


And LilyPond issue #4751 
(https://sourceforge.net/p/testlilyissues/issues/4751/?page=1) confirms that 
the stem directions and the new command-line option were added as part of 
2.19.44

HTH,

Carl




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

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

[Carl Sorensen]

On 1/14/19, 11:11 AM, "samaru...@aim.com"  wrote:

PS Windows+Mac: StemUp/Downs appear everywhere after the import, this 
was not the case with older LilyPond versions, e.g. 2.19.31, which I 
still use on my Windows system because of the errors listed above (I 
know that would probably be another separate issue).

Having only briefly looked at it, it appears that a new dictionary that uses 
\stemUp, \stemDown, and \stemNeutral was added to xml2ly in commit

author  John Gourlay  2016-02-18 21:47:49 -0500
committer   John Gourlay  2016-02-18 21:47:49 
-0500
commit  2ab5d80245dcab194daea64ec83ded3ec8252e51 (patch)

I have not checked whether this commit is the source of the spurious stemXXX 
commands.  But I do note that it comes after 2.19.31.

I don't do any musicXML import, so I'm a poor person to check this out further, 
but I thought I could at least point you in this promising direction.

HTH,

Carl


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

Re: Notes in the measure following a cadenza do not automatically get accidentals if they had accidentals in the cadenza

[Carl Sorensen]

On 11/28/18, 2:50 AM, "David Kastrup"  wrote:

Arcus Impetus  writes:

> %The measure following a cadenza
> %does not properly automatically
> %place accidentals. Lilypond seems to consider
> %the meaning of the accidentals in the cadenza
> %to carry forward to the notes in the next measure
>
> \version "2.18.2"
> {
>  \cadenzaOn cis' \cadenzaOff \bar "|" cis'
> }

Here's a workaround:

\version "2.18.2"
{
  \cadenzaOn cis' \cadenzaOff 
  \partial 128 s128  cis'4
  
} 

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

Re: Disappearing dynamics

[Carl Sorensen]

Have you tried changing the lilypond call in Frescobaldi to a gdb lilypond 
call, so that you can pause the execution of lilypond and give Frescobaldi time 
to do whatever it might do -- and then continue lilypond from the debugger?

Have you tried changing the Frescobaldi options for displaying the pdf to get 
to a minimal Frescobaldi run that doesn't do much but generate the pdf?

This sounds like a truly bizarre bug.

Carl

On 11/12/18, 4:46 PM, "Andrew Bernard"  wrote:

Hi k\Kevin and All,

It ranks as one of the most bizarre bugs I have ever seen (and I speak as a
software developer of many decades). It's only with Frescobaldi. Command
line compilation is fine. It's only dynamic markings, which is puzzling -
whatever is going on? Running sync of course I tried, thinking the same as
you. but to no effect. Once the dynamics appear, then they continue to
appear.

A mystery of the cosmos. Perhaps dynamic markings have become shy or
recalcitrant. It's difficult to know how to debug this. Same behaviour in
printing Debian 9.6 and Ubuntu 18.10.

Andrew


On Tue, 13 Nov 2018 at 09:37, Kevin Barry  wrote:

>
> How bizarre. I wonder what difference there could possibly be that
> would make files appear to have different content. Does this issue
> occur in Frescobaldi if opening after a successful (i.e. dynamics
> appear correctly) compile from the cli and without making any edits?
> Does running sync before compilation make any difference? Do dynamics
> ever disappear after they have successfully appeared once?
>
>



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

Re: no solution found for Bezier intersection

[Carl Sorensen]

On 7/2/18, 6:32 AM, "David Kastrup"  wrote:


I'll take a thorough look at this code.  Looks like it could benefit
from a more graphic approach to intersections than converting everything
into zero-based polynomials and then doing root finding.


I probably have a link to some good, robust Bezier intersection finding 
algorithms if you are interested.

Carl
 

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

Re: lilypond not working when compiled against guile-2.2

[Carl Sorensen]

On 6/5/18, 2:45 AM, "Thomas Morley"  wrote:

2018-06-05 4:14 GMT+02:00 Carl Sorensen :
>
>
> On 6/4/18, 6:13 PM, "Thomas Morley"  wrote:
>
>
> That said, in our git we have a 'guile-v2-work'-branch, but it's not
> up to date...
>
> @David
> I think about updating this branch, it would be far easier to point
> interested people to this branch.
> Needed would be a rebase, probably with the need to solve
> merge-conflicts and I'd like to add some new patches of my own.
> What would be the git-syntax for it?
>
> First cut:
>
> git checkout guile-v2-work
> git rebase master
>
> Solve any merge conflicts.
>
Hi Carl,

if I understand correctly, the above will work on my local copy of
said branch, to get it public, the updates should be pushed to the
public branch.

For pushing usual patches to staging from a local branch I use:
git push origin HEAD:staging


git push origin HEAD:guile-v2-work

HTH,

Carl



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

Re: lilypond not working when compiled against guile-2.2

[Carl Sorensen]

On 6/4/18, 6:13 PM, "Thomas Morley"  wrote:


That said, in our git we have a 'guile-v2-work'-branch, but it's not
up to date...

@David
I think about updating this branch, it would be far easier to point
interested people to this branch.
Needed would be a rebase, probably with the need to solve
merge-conflicts and I'd like to add some new patches of my own.
What would be the git-syntax for it?

First cut:

git checkout guile-v2-work
git rebase master

Solve any merge conflicts.

Add in any patches you want to add in.

Then you're all up to date.

HTH,

Carl


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

Re: Slur collision detection and resolution works for sharp symbol but fails for flat symbol

[Carl Sorensen]

On 5/27/18, 9:52 AM, "Aaron Hill"  wrote:

On 2018-05-27 06:29, Jürgen Reuter wrote:
> Looks like slur collision detection and resolution (the slur is moved
> upwards) works fine for sharp accidentals, but is ignored for flat
> accidentals.

Slur collision is not ignored.  There are a number of different parameters 
governing the goodness of slurs.  The goodness of each factor is calculated and 
summed to give the overall goodness (actually, badness) of the slur.  A number 
of slurs are tried, and the slur with the lowest badness is used.

The parameters that can be adjusted to get a particular outcome are found in 
the Slur.details property, and are listed, along with their default values, in 
the Notation reference:
http://lilypond.org/doc/v2.19/Documentation/internals/slur

In this particular case, increasing the accidental-collision penalty will cause 
the slur to avoid the accidental.

   \version "2.18.2"
   {
 \override Slur.direction = #UP
\override Slur.details.accidental-collision = #20 % the default is 3; a 
higher value will make it more likely the accidental is avoided
 \override Slur.height-limit = #10
 a'( ges'') a'( gis'') % Collision with both accidentals.
 \override Stem.direction = #UP
 a'( ges'') a'( gis'') % Collision with flat only.
   }


This is not a bug, but just a hard slur to engrave, so the default values of 
the details may not be optimal.

HTH,

Carl


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

Re: Key cancellation, position bug

[Carl Sorensen]

On 4/23/18, 1:30 PM, "Torsten Hämmerle"  wrote:

But why \once?
If generally all cancellations collide, you may well use a general
\override.

Because all cancellations don't collide; only the cancellations of flats 
collide.

Carl



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

Re: DOC: Correcting spelling of Harmonia Sacra in NR 1.1.4 Shape note heads

[Carl Sorensen]

On 9/30/17 4:46 PM, "David Kastrup"  wrote:

>Karlin High  writes:
>
>> This is a nitpick. The places in the documentation that reference the
>> "Harmonia Sacra" songbook by Joseph Funk have the spelling Harmonica
>> Sacra. Harmonia does not have a "c" here. A few references are below.
>> There are enough of them that a Google search for "Joseph Funk
>> Harmonica Sacra" gets auto-corrected.
>>
>> http://harmoniasacra.org/index.html
>> http://gameo.org/index.php?title=Harmonia_Sacra
>> https://www.amazon.com/Harmonia-Sacra-Joseph-Funk/dp/1932676155
>>
>> The attached patch has proposed corrections. Translated docs would be
>> affected; I do not know the process for that. Possible actions:
>>
>> * Forget it. Anyone who would be bothered by this is probably beyond
>>help.
>> * Fix directly in git like other typos
>> * Go through review and tracker like other patches
>
>I'd use option 2 here (of course, push to staging rather than master)
>after carefully reading the diff and making sure that no chapter/node
>names are affected (which would constitute a structural change and thus
>should be checked doing "make doc" before possibly inconveniencing
>others by a broken staging, either by checking yourself or creating an
>issue after all).
>
>We have had a fair share of "this could not possibly break compilation"
>kind of changes breaking compilation.
>
>Also any possibility for contention is worth a review.  This here seems
>solid enough to me.

I agree with David.

Thanks,

Carl


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

Re: Better discoverability for thin-variant Aiken heads: add to snippets, docs, or features?

[Carl Sorensen]

On 9/8/17 12:47 PM, "lilypond-devel on behalf of Karlin High"
 wrote:

>
>a snippet for the LSR,
>a reference in the documentation, perhaps under NR 1.1.4 Shape note heads,
>adding a feature to LilyPond, the command \aikenHeadsThin
>
>Any preference from the developers? I've read some of the contributor's
>guide, and doing the work looks like a fun challenge.

As much as I hate to have commands expand, I think given all of the other
shape note commands, we should probably go ahead and add a command
\aikenThinHeads  (rather than \aikenHeadsThin -- all of the others end
with Heads) and \aikenThinHeadsMinor.

Thanks,

Carl


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

Re: NR 4.2.2, table column should be called "glyph name"?

[Carl Sorensen]

On 6/12/17 4:06 AM, "Federico Bruni" <f...@inventati.org> wrote:

>
>
>Il giorno sab 10 giu 2017 alle 2:54, Carl Sorensen <c_soren...@byu.edu>
>ha scritto:
>> On 6/8/17 10:26 AM, "Federico Bruni" <f...@inventati.org> wrote:
>> 
>>> 
>>>http://lilypond.org/doc/v2.19/Documentation/notation/setting-the-staff-s
>>>iz
>>> e.html
>>> 
>>> """
>>> Automatic font weight at different sizes
>>> 
>>> The Emmentaler font provides the set of Feta musical glyphs in eight
>>> different sizes; each one tuned for a different staff size. The
>>> smaller
>>> the glyph size, the ³heavier² it becomes, so as to match the
>>> relatively thicker staff lines. Recommended glyphs sizes are listed
>>> in
>>> the following table:
>>> 
>>> font name   staff height (pt)   staff height (mm)   use
>>> feta11  11.22   3.9 pocket scores
>>> feta13  12.60   4.4
>>> [...]
>>> """
>>> 
>>> Should "font name" be replaced with "glyph name"?
>> 
>> Not in my opinion.  The font is feta11 (the font family is feta).  The
>> staff height is 11.22 pt.  The staff height is 3.9 mm.
>> 
>> 
>
>Hi Carl, are you sure?
>The context of my report was:
>
>commit 18d03fa6a724b0102ccc47d194209802cea02f2e
>Author: James Lowe
>Date: Sun Mar 5 16:34:39 2017 +
>
>Doc - NR + CG: Clarify Emmentaler is the 'font' and Feta/Parmesan
>are glyphs
>
>Issue 4966
>
>Distinguish between Emmentaler
>the 'font' and Feta/Parmesan
>glyphs that make up the
>Emmentaler font family.

In this context, I guess that the proper word is 'subfont' rather than
'glyph'.  The emmentaler font is made up of several subfonts, according to
the files in the out/mf directory.  In the case of emmentaler-11 (which is
the font), the subfonts include
feta11
feta-noteheads11
feta-flags11
parmesan11
parmesan-noteheads11
feta-alphabet11 

Each of these subfonts is a collection of glyphs.  And the glyphs have
individual names.

If I were to try to fix the problem you have identified, I would probably
change the contents of the first column from 'fetaxx' to 'emmentaler-xx'.
I believe that when one sets the font-size in general, it applies to
Emmentaler, not to Feta.  The only place I have found in the documentation
that uses anything other than the whole font is in NR 1.8.3, where some
font-encodings are used.  But I cannot find any documentation that
describes which glyphs are in which encodings, so I don't know how to use
this in general.

So, in looking at all of this, my recommendation is not to change the
heading of the table, but to change the contents of the first column.

Thanks,

Carl


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

Re: NR 4.2.2, table column should be called "glyph name"?

[Carl Sorensen]

On 6/8/17 10:26 AM, "Federico Bruni"  wrote:

>http://lilypond.org/doc/v2.19/Documentation/notation/setting-the-staff-siz
>e.html
>
>"""
>Automatic font weight at different sizes
>
>The Emmentaler font provides the set of Feta musical glyphs in eight
>different sizes; each one tuned for a different staff size. The smaller
>the glyph size, the ³heavier² it becomes, so as to match the
>relatively thicker staff lines. Recommended glyphs sizes are listed in
>the following table:
>
>font name  staff height (pt)   staff height (mm)   use
>feta11 11.22   3.9 pocket scores
>feta13 12.60   4.4
>[...]
>"""
>
>Should "font name" be replaced with "glyph name"?

Not in my opinion.  The font is feta11 (the font family is feta).  The
staff height is 11.22 pt.  The staff height is 3.9 mm.

Thanks,

Carl


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

Re: Font cache issues on Windows 10

[Carl Sorensen]

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.

Thanks,

Carl


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

Re: Manual page breaking causing assertion failure

[Carl Sorensen]

On 7/21/16 11:41 AM, "Chris Yate"  wrote:

>Hey Abraham / BugsList people,
>
>I'm guessing nobody had a chance to look at this problem. I'm experiencing
>it again, and it's really slowing me down.
>
>Is there anything else I can do to help debug / isolate the issue? It's
>still there in 2.19.45 but I guess we'd expect that anyway.
>
>Chris
>
>On Sat, 9 Jan 2016 at 09:55 Chris Yate  wrote:
>
>> So, it turns out this was easy to minimise the code. File is attached.
>> It's still ~70 bars but only one voice, which is the dynamics staff of a
>> piano score (without anything else), so it's only silent music.
>>
>> "AutoPageBreaksOff" in the score block causes the exception failure.
>>
>> I note some "insane spring distance" warnings.These don't happen in the
>> real thing.

I suspect you have not yet created a LilyPond "Tiny Example".

http://lilypond.org/tiny-examples.html

While you have greatly reduced the file from the original size, there's
still a lot of stuff in there that I doubt is necessary to trigger the
assertion failure.

For example, the piece starts with a \partial.  Does the error still occur
without the \partial?  If so, take it out.

Similarly, there are lots of dynamic indications in the part.  Can any of
them be removed and still have the assertion failure?  if so, take them
out.

It would be much nicer if you could write the code something like

\repeat unfold 20 s2.
\crescTextCresc s8\cresc s4\! s4. |
\repeat unfold 50 s2.

so that we would know the following:

a) What minimum set of dynamics causes the assertion failure
b) How many bars are necessary to cause the assertion failure

Because few of the developers work in Windows, it will be difficult for
them to debug this problem.  So anything you can do to narrow it down will
increase the likelihood that the problem will be solved.

Thanks,

Carl


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

Re: tuplets and accidentals collision

[Carl Sorensen]

On 7/6/16 5:07 AM, "Gilberto Agostinho"  wrote:

>
>Is this a known bug? The only similar bug I found in the tracker is  this
>one here   , but it
>seems to be a bit different than what I am reporting here.
>
>Cheers,
>Gilberto
>

Why do you think issue 3766 is different from your observation?  Both are
a collision between the tuplet bracket and the accidentals.  It seems to
me they are the same thing (although the patch for issue 3766 was never
applied, as it didn't yet meet LilyPond coding standards).

Thanks,

Carl


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

Re: patch labels in CG manual

[Carl Sorensen]

James,

On 5/20/16 10:15 AM, "James"  wrote:

>
>
>One thing to realise and I think people have forgotten is that the
>Patchy-testing scripts (rather than Patchy-merge scripts) no longer work
>as they were written to scrape the old Google tracker and don't work
>with Allura.
>
>So Patch testing is 100% manually done - i.e. lots of clicking and
>typing commands - and that includes me having to download the raw *diff
>file from Rietveld via my browser and then running the commands, albeit
>serially, in a CMD window completely unscripted. Then making sure I
>manually clean my out of tree build and the tree in its current state
>after a patch test.

I certainly had forgotten this.  I'm amazed that you've continued this
long with manual patch application.  You're an all-star!

I will commit to helping get the Patchy-testing scripts working, so this
manual procedure is no longer needed, or is at least simplified.

I've found the Patchy scripts at github as shown in the CG.  Are changes
made by sending a pull request to Graham?  Or do we have push permission
on the Patchy repo?

Thanks,

Carl


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

Re: PianoStaff vertical spacing messed up by tuplet

[Carl Sorensen]

On 5/10/16 3:09 PM, "Rutger Hofman"  wrote:

>Hello bug list,
>
>I think I encountered a bug that is triggered under very specific
>circumstances. The lilypond program is included below. It sets the same
>line two times twice. The first time is OK. The second time, after the
>\break, makes the distance between the Staffs of the PianoStaff much too
>large. The second page repeats the same 2 lines, and the distance bug
>after the pageBreak is already triggered. This page shows that the
>spacing between PianoStaffs is unaware of the increased distance between
>the Staffs: unreadable because the PianoStaffs overlap.
>
>Things to note:
>- the first incantation works fine
>- if the slur is removed, everything works fine
>- if the tuplet is replaced with straight 8th notes, idem

I believe this is a problem with cross-staff unbeamed tuplets.  Change the
final e,4 to e,8 e and all works well.  But if we add \autoBeamOff, the
same behavior is observed.

\version "2.19.39"

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

rondoPiSU = \relative c'' {
 \time 2/4
 \autoBeamOff

 % c2 |
 \change Staff = ST f,4( \tuplet 3/2 { e8) \change Staff = SU e,8 e }
| %599
}


\score {
 \new PianoStaff = PI <<
 \new Staff = ST {
 \rondoPiSU
 \break
 \rondoPiSU
 \pageBreak
 \rondoPiSU
 \break
 \rondoPiSU
 }
 \new Staff = SU {
 \clef bass
 s2*4 |
 }
 >>
}


Thus,  I would make sure the issue title includes "cross-staff unbeamed
tuplets".


Thanks,

Carl


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

Re: \omit dynamic occupies space

[Carl Sorensen]

On 4/27/16 7:09 AM, "Graham King"  wrote:

>meanwhile, Harm has kindly shown me a work-round.  It is in the first
>two bars of this example, which also serves to illustrate the partial
>effect of \omit.

I haven't looked at the code, but it appears to me that without the
dynamics, the hairpin is bound from the left edge of the first note column
to the right edge of the last note column.

With the omitted dynamics, the hairpin appears to be bound to the right
edge of the first note column and the left edge of the last note column.

Hazarding a guess that the dynamic text is bound to the note column, and
thus the hairpin moves out of the columns into the inter-column space.
And if the dynamic text overflows the column, the hairpin is shortened.
When the text is omitted, the hairpin can only move to the edge of the
column.

Carl


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

Re: fondu fails on newer OS X versions

[Carl Sorensen]

On 4/3/16 4:15 PM, "Andrew Bernard"  wrote:

>Hi Thomas et al.,
>
>
>While I was helping Mats look into this I noticed the same point. The
>defect means you can¹t even use a basic system font like Times in a font
>name override in markup on the Mac.

Can you use LaTeX fonts on El Capitan?

>
>
>Given that fondu is moribund, does this topic need to go the development
>list for discussion? Are there other tools that can be used instead of
>fondu that are currently maintained? Basing lilypond core code on
>unmaintained libraries for such important
> functionality such as font rendering in this type of use case does not
>seem robust.

I think you are right.  We need to discuss this on the developer list.  It
seems we have a few options:

1) Get George Williams to fix fondu
2) Get somebody on the LilyPond team to take over maintenance of fondu
3) Put a fork of fondu into the lilypond source tree and take over
maintenance of the fork
4) Find an alternative utility that provides us the same functionality
5) Write our own utility to get the same functionality

It seems like we almost have a patch prepared, thanks to Mats's work.  So
we could probably fork it if need be.  But I'd sure rather have George
apply all the pending patches plus ours, and just release a new version.


>What to do? In any case, a bug should be raised for lilypond don¹t you
>think, even though this is an external program? If nothing else, others
>who encounter it will be able to search for it.

I agree.  We need a bug posted.


Thanks,

Carl


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

Re: Noteheads slightly too large

[Carl Sorensen]

Paul Morris wrote
>> On Feb 14, 2016, at 10:11 AM, David Kastrup 

> dak@

>  wrote:
>> 
>> Your image only shows notes between staff lines.  However, a reduction
>> in notehead size will mainly make notes _on_ staff lines look too small
>> and/or unsymmetric so the image is not really useful for judging
>> potential _downsides_ of that change.  Can you do a more complete image,
>> including ledger lines and larger note values (half, semibreve, breve,
>> longa)?
> 
> Maybe also include an example with some note heads that are colored so you
> can see better how they overlap with the staff lines?  i.e. with 
> 
> \override NoteHead.color = #blue

I've attached an image with green noteheads that shows spaces, staff lines,
and ledger lines (all at a setting of Overdone_heads = -0.2, which reduces
the metafont notehead size by 20% of the staff line thickness).

 

Here are three images  that come from a test with various durations.

 

 

 

I believe the changes are so minute that they cannot be seen when the note
is on a staff line.  The symmetry of the note is unchanged; only its height
is adjusted.

pdf files with three different settings for overdone_heads and the noteheads
in green are available on the tracker issue: 
https://sourceforge.net/p/testlilyissues/issues/4693/
  

Thanks,

Carl





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659p187226.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Noteheads slightly too large

[Carl Sorensen]

The feta font files specify the notehead height to be exactly staff_space +
staff_line_thickness.  I am assuming that in the conversion from ps to type1
font with hinting, the notehead gets just a bit larger.

I have rebuilt the feta font with a notehead height of staff_space + 0.8 *
staff_line_thickness. It seems to avoid the overlap problem, but still
appears to be full width.

If this is acceptable, I will prepare a patch.

Thanks,

Carl
 



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659p187152.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: Review of chapter 4 of NR (spacing.itely)

[Carl Sorensen]

Very nice work, Federico.


On 12/18/15 10:57 AM, "Federico Bruni"  wrote:

>
>b) 4.3.1 Line breaking
>"Note that manually forced line breaks have to be added in parallel
>with the music:"
>What means "in parallel" here? The example following this sentence does
>not show "parallel breaks", there's only one \break in one voice.
>If the purpose is suggesting the use of \break in each voice, the
>example
>does not match this purpose.
>
>What I'm getting wrong?

 I think that the example is demonstrating that you can add breaks in a
music expression that contains only breaks and spacing information, as
long as that expression is in parallel with the music.

I use this feature often in my scores; I create a spacing variable and
actually add it in a parallel context in a Staff.

I agree that it is poorly worded and needs to be fixed.

Thanks,

Carl


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

Re: Aw: Re: Several notation errors in bagpipe.ly

[Carl Sorensen]

-- Messaggio inoltrato --

Da: Oliver Briede o.bri...@web.de
Oggetto: Aw: Re: Several notation errors in bagpipe.ly
Data: Sun, 7 Jun 2015 10:20:31 +0200
A: Federico Bruni f...@inventati.org
Cc: Julia Meihöfer j.meihoe...@googlemail.com

Hello Federico,

we attached the corrected bagpipe.ly version 2.19. All changes are
commented with the introdutction @JO.


Thank you for your careful work.

It's very convenient for review to have the old lines commented out and
the new lines added, along with a comment of why it's that way.

In terms of us modifying the version in the lilypond distribution, it
would be much easier to just have the file as it should be, with all of
the wrong items eliminated and the right items included.

Could you please prepare a copy of the file in that format?

Thanks,

Carl


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

Re: Aw: Re: Several notation errors in bagpipe.ly

[Carl Sorensen]

On 6/7/15 9:45 AM, Federico Bruni f...@inventati.org wrote:

Thanks Oliver

The correct email address is bug-lilypond@gnu.org
The normal procedure is that the Bug Squad will open a new issue in the
tracker if the errors are confirmed.
I cannot comment on the changes proposed, sine I don't know anything
about bagpipe music. I hope others will.

I cannot comment on the changes either, but it seems like we have an
expert opinion that the changes are correct.


If you know the basics of Git, you may provide a patch against master,
so that developers can easily see what you want to change (the attached
file may be ignored...). You find the information here:
http://www.lilypond.org/doc/v2.19/Documentation/contributor/commits-and-pa
tches

I will be happy to submit a patch, so Oliver and Julia do not have to, if
they would rather not.
Please let me know.

Thanks,

Carl


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

Re: manuals page [WAS Re: teaching a university module on engraving with lilypond]

[Carl Sorensen]

On 4/27/15 10:47 AM, Federico Bruni fedel...@gmail.com wrote:

2015-04-27 17:25 GMT+02:00 Kevin Barry barr...@gmail.com:

- I'd rather use a conversational approach instead of unordered lists:
Please be aware that LilyPond is a text-based(link) music engraver and
read the FAQ(link) before You can see LilyPond in action in the
following video tutorials made by Ben Lemon... (a small iframe of youtube
video would be great). Then explain that the first manual to be read
should be Learning and Usage, followed by Notation.

I think that such an approach could be helpful.

But Notation shouldn't be read.  It should only be referenced.  And I
think we should make that clear whenever we talk about it.

Thanks,

Carl


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

Re: Subdivided beams

[Carl Sorensen]

On 4/23/15 10:49 AM, Trevor Daniels t.dani...@treda.co.uk wrote:


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


 
 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.


A new issue, number 4355, has been created for this bug.

http://code.google.com/p/lilypond/issues/detail?id=4355


Thanks,

Carl


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

Re: Roman Numeral placement

[Carl Sorensen]

On 4/21/15 10:34 AM, SonusProj . sonusproject...@gmail.com wrote:

I want to add below the chord, treble clef, the associated Roman numeral
description of each chord.


I.E. on the C Major I would have I, the Dm7 would have ii7 with the 7 in
superscript, the Em7 would have iii7 with the 7 in superscript, etc.


I see several avenues for this but I don't see an avenue where I can
write the code once and use many times. I want the Roman numerals to
appear for all keys and don't want an overly clutter code.

It seems that what is really wanted here (although not currently available
in LilyPond as far as I know) is a scale-degree chord namer.  This would
be a reasonable feature request.  I'll copy to bug-lilypond so the bug
squad can do their magic.

Thanks,

Carl


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

What should be the default B7 chord?

[Carl Sorensen]

There has been a difference of opinion on why the default B7 guitar chord
shape should be.  I'm making a poll to determine what the users would
prefer.

Would you like the first chord in the attachment (barred on fret 2) or the
second chord (open chord in first position)?

Thanks,

Carl

attachment: b7-test.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: turkish accidental eksik bakiye missing in emmentaler font

[Carl Sorensen]

On 11/26/13 8:37 PM, Keith OHara k-ohara5...@oco.net wrote:

Philippe Ploquin philippeploquin at neuf.fr writes:


 The accidental called eksik bakiye is missing in lilypond.

Can anyone give a link to a reference image showing this accidental in
use?  

http://upload.wikimedia.org/wikipedia/en/e/e5/Turkish_Note_Names.jpg




___
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

[Carl Sorensen]

On 10/28/13 7:15 AM, Jimmie Felidae evolution.ji...@gmail.com wrote:

 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.
  |
}

I believe this does exactly what is supposed to do: print a sixteenth note
that takes up the duration of 7 sixteenth notes, followed by a sixteenth
note that takes up the duration of 5  sixteenth notes for a total of 12/16
or 6/8, thus filling the bar.

What do you believe it should do?

Thanks,

Carl


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

Re: Cppcheck reports patch for 2546

[Carl Sorensen]

On May 20, 2012, at 1:16 PM, Graham Percival gra...@percival-music.ca wrote:

 On Sat, May 19, 2012 at 08:30:50AM +0200, Julien Nabet wrote:
 Since I don't have a Google account to sign in to
 http://codereview.appspot.com/, I attached the patch for 2546.
 Don't hesitate to tell me if it's ok or not. (I attached a link to
 why prefix is better).
 
 Unfortunately we do not accept patches outside of the process
 discussed here:
 http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers
 
 Hopefully somebody will offer to shepherd your patch through the
 process.

I have offered to shepherd his patch, but have been busy with family 
emergencies.  I should get to it tomorrow. 

Thanks,

Carl
 

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

Re: Cppcheck reports

[Carl Sorensen]

On 5/18/12 1:42 PM, Marek Klein ma...@gregoriana.sk wrote:




Hello

2012/5/17 Julien Nabet serval2...@yahoo.fr


 I'm not top posting.
Hello,

I just git clone Lilypond project and launched cppcheck (git updated
today).
I thought it could interest you, here are some examples :
[lily/tuplet-bracket.cc:594] - [lily/tuplet-bracket.cc:594]: (style) Same
expression on both sides of '-'
   592   if (!follow_beam)
   593 {
   594   points.push_back (Offset (x0 - x0, staff[dir]));
   595   points.push_back (Offset (x1 - x0, staff[dir]));
   596 }

[lily/tie-engraver.cc:240]: (performance) Prefer prefix ++/-- operators
for
non-primitive types
 240   for (; it  heads_to_tie_.end (); it++)
 241 report_unterminated_tie (*it);
(+ it's safer to use it != heads_to_tie_.end ())

[lily/paper-book.cc:346]: (performance) Possible inefficient checking for
'cols'
emptiness
   346   if (cols.size ())
   347 {
   348   Paper_column *col = dynamic_castPaper_column *
(cols.back ());
   349   col-set_property (symbol, permission);
   350   col-find_prebroken_piece (LEFT)-set_property (symbol,
permission);
   351 }

If you're interested, I can send you the full report (since there's no
possibility of attachment), just tell me where I can send it.

Julien.



This need some discussion before tracking an issue, I think - therefore
cc-ing devel...

I think that it would be worth creating an issue, and attaching the output
file from cppcheck, as long as the file is not too long.

At any rate, I'd like to see the output file.

Thanks,

Carl


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

Re: Cppcheck reports

[Carl Sorensen]

Thanks for the file, Julien.  I have split the warnings into various
issues.

See issues 2545, 2546, and 2548 through 2554 on the issue tracker.

http://code.google.com/p/lilypond/issues/detail?id=2545colspec=ID%20Type%2
0Status%20Stars%20Owner%20Patch%20Needs%20Summary

http://code.google.com/p/lilypond/issues/detail?id=2546colspec=ID%20Type%2
0Status%20Stars%20Owner%20Patch%20Needs%20Summary

etc.

Julien, if you want to fix any of these, I'd be happy to help you get
patches reviewed and pushed.

Here's instructions on uploading a patch for review:

http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches
#uploading-a-patch-for-review



Thanks,

Carl


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

Re: tupletSpannerDuration and percent repeat conflict

[Carl Sorensen]

On 3/26/12 12:49 PM, Lenore Horner lenorehor...@sbcglobal.net wrote:

 I'm not top posting.

\version 2.14.2
\paper{ ragged-right=##t }
\relative c'' {
   \set tupletSpannerDuration = #(ly:make-moment 1 4) \times 2/3 {
   \repeat percent 2 {g8 f g  f g f   g f g  f g f }
   } \unset tupletSpannerDuration
}

Produces correct pdf output but also the following string of error
messages 
(the full piece of music showed similar inconvenient lack of line numbers
with the errors).

A simple change prevents the errors:

\version 2.14.2
\paper{ ragged-right=##t }
\relative c'' {
\set tupletSpannerDuration = #(ly:make-moment 1 4)
% \times 2/3 {  % NOTE -- move the \times 2/3 *inside* the
repeat percent
\repeat percent 2 \times 2/3 {g8 f g  f g f   g f g  f g f }
%}
\unset tupletSpannerDuration
}

HTH,

Carl




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

Re: NR 1.2.4 - Not working snippet

[Carl Sorensen]

On 3/14/12 5:19 PM, Thomas Morley thomasmorle...@googlemail.com wrote:

Hi,

due to the changes in 3/4-time snippet lily-baa9b310-1.ly in NR 1.2.4
doesn't work any more (and the description above is wrong)
At least in the german translation.

This is correct.  The german translation has not been updated.

When the translation is updated, the snippet should also be fixed, I think.

Thanks,

Carl


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

Re: complex-beam

[Carl Sorensen]

On 2/26/12 2:10 AM, David Bobroff bobr...@centrum.is wrote:

I'm looking for a way to achieve this beaming pattern:

http://notendur.centrum.is/~bobroff/lily/complex-beam.png

Can LilyPond do this?  I suspect I'll have to use a combination of
subdivideBeams and stemRightBeamCount/stemLeftBeamCount.  Is there a
known solution?

Thanks,

David




Lilypond does not currently do second-level beam subdivisions.

Please add this as a feature request.  I have been looking for a good
example of what it means to have multiple subdivision.

I believe this can be achieved; I will try to get to it in the next couple
of weeks.

I believe this beaming could be expressed as something like:

(subdivide . ((1 . 8) . (1 1 1))
 ((1 . 16) . (1 1 1 1 1 1)))

although I am not proposing this as the syntax.

It might be better to change subdivideBeams from a boolean to a list,
where each element of the list would be a beat length at which to
subdivide.  If that were the case we would achieve the beaming in the
sample by

\set subdivideBeams = #'((1 . 8) (1 . 16))

Or perhaps

\set subdivideBeams = #'((ly:make-moment 1 8)
 (ly:make-moment 1 16))

Or perhaps even (with David K's new syntax, where we can have duration
elements)

\set subdivideBeams = #'( 8 16 )

I'll put this in the hopper and think about it.

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/19/12 6:07 AM, Martin Straeten martin.strae...@gmail.com wrote:

Your idea regarding a no beamlet sticking out property seems to be a
practicable solution; the workaround described in the issue is fine for
the simple example, but is quite inconvenient in real life.

The current patch on issue 2228 restores the previous behavior, with the
option to use strict beat beaming by setting a context property.

Hopefully this will be part of 2.15.27.  If you can build your own source,
it's available now from Rietveld.

Thanks,

Carl


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

Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat

[Carl Sorensen]

On 1/19/12 10:05 AM, Graham Percival gra...@percival-music.ca wrote:

On Thu, Jan 19, 2012 at 03:55:26PM +, lilyp...@googlecode.com wrote:
 New patch set after:
 
 scripts/auxiliar/makeslr.py
 git add Documentation/snippets/new/strict-beat-beaming.ly
 git commit Documentation/snippets/new/strict-beat-beaming.ly
 git reset --hard HEAD
 
 This properly updated strict-beat-beaming.ly, but avoids showing all
 of the other snippets changed by convert-ly.  Maybe we should add
 this to the CG.

The proper thing is to:
- make a branch
- do a local lsr update
- make your code and doc change
- do a local lsr update
- review, then merge with staging as a single commit or a special
  merge commit which git-rebase will handly properly; consult
  David about what that means in exact git terms.

I personally would just squash the branch into a single commit,
but a separate branch merge would be more appropriate for larger
changes.

Why is this the proper thing to do?

The objective is to get the new snippet into the tree.  The way to get the
new snippet into the tree is to add it to D/s/n and do a makelsr.py.  But
this also updates a bunch of other files.  Why is not preferable to throw
away all the rest of the changes, which will be redone as part of a
release?

Unless we are going to expect *every* user to do a local makelsr.py for
*every* branch they create, it seems unreasonable to ask them to do it in
advance for some branches.

I'm positive that the commits obtained will be exactly the same.  In fact,
I'll go ahead and demonstrate it.

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/17/12 3:33 AM, Martin Straeten martin.strae...@gmail.com wrote:

here two examples:
BWV 544:
http://216.129.110.22/files/imglnks/usimg/4/4a/IMSLP01329-BWV0544.pdf
old Edition of  Bach Gesellschaft

This example shows examples of beaming the 3/8 unit it both two and three.
 In measures 3-6, the pedal is beamed in three (as LilyPond currently does
it), then in measure 7 the pedal is beamed in two (as you have requested),
presumably to show the pedal rhythm being different from the manual rhythm
(which is in three).  In measure 8, it's back to three, then in measure 9,
back to two.

In measure 13, the manual is beamed in two.  In measure 14, the pedal is
beamed in three.

In measures 29 and 30, both the pedal and the manual are beamed in three.

On the top of page 203 (I lost count of the measures), the manual is
beamed in three.

I have been unable to determine any rule for when it should be beamed in
two and when it should be beamed in three. I think that for this piece,
the old rule of minimize the number of beamlets sticking out would give
the beaming in these editions.

So perhaps we should add a property to turn on and off the no beamlets
sticking out rule.  Then it would be under user control.

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/15/12 6:04 PM, Carl Sorensen c_soren...@byu.edu wrote:

On 1/15/12 3:06 PM, Janek Warchoł janek.lilyp...@gmail.com wrote:

2012/1/15 Martin Straeten martin.strae...@gmail.com:
 I'm not top posting.
 in 6/8 an 3/4 measure the beamlet of the last/first semiwaver
 points to the dotted quaver.

 semiquavers should be beamed together

I may be wrong, but i don't agree.  Beaming them together would be
against the rhythmical subdivision in 6/8 and 3/4 meters.


I agree with Martin. One of the important things to recognize (which
LilyPond doesn't do yet in the beaming pattern) is that complex meters
(like 3/4 and 6/8) have a fundamental beat unit of 3, and so the beaming
that is chosen is wrong.

The fundamental unit of 6/8 is not 1/8, but 3/8.  6/8 is two groups of
3/8.  The division at half of the 3/8 group is a more important division
than the division at 1/3 of the 3/8 group, so the beaming should reflect
that division.

In the old code, this was handled by trying to avoid sticking out flags.
 That was tossed in order to recognize beat divisions, and the beat
divisions work properly in simple meter, but not it complex meter.

Please make this a regression, with a title that says Beamlet orientation
is wrong in complex meters.

Thanks,

Carl

Having not checked Gould before responding, I used the wrong terms.

S/complex/compound/

I meant compound meters, not complex meters.

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/15/12 2:50 PM, Martin Straeten martin.strae...@gmail.com wrote:

 I'm not top posting.
in 6/8 an 3/4 measure the beamlet of the last/first semiwaver
points to the dotted quaver.

semiquavers should be beamed together like in 2.14.2

%-sample--
\version 2.15.24
\score {
\relative c'{
   \time 6/8 
   c16 d e f8.  c8. d16 e f
   \time 3/4 
   c16 d e f8.  c8. d16 e f
}}

Having reviewed Gould on beaming, I don't believe that the 3/4 time
measure in this example shows a valid problem.

The rhythm in the 3/4 measure is an invalid measure.  The three beats in
the measure are combined in such a way that the beats are obscured,
falling in the middle of the two dotted quavers. (Did I use that term
correctly?)

To be a valid 3/4 rhythm, at least two out of the three beats should be
shown, according to Gould (page 168, top of page).  This rhythm shows only
one beat, the first.

Thus, the 3/4 rhythm could be

c16 d e f~f8 c8. d16 e f

Which shows beats one and two, or

c16 d e f8.c8~ c16 d e f

Which shows beats one and three.  Personally, I think the best is

c16 d e f~ f8 c~ c16 d e f

Which shows all three beats.  The beaming is appropriate for this rhythm.

I guess that beaming the three semiquavers together is the most attractive
option for the first two cases above.  But that implies a 6/8 accent
structure, rather than a 3/4 accent structure, so I think it's incorrect.

So at the moment, I believe the 6/8 beaming is a bug.  I believe the 3/4
beaming is more a misuse of lilypond, and there is no *right* beaming.

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/15/12 2:50 PM, Martin Straeten martin.strae...@gmail.com wrote:

 I'm not top posting.
in 6/8 an 3/4 measure the beamlet of the last/first semiwaver
points to the dotted quaver.

semiquavers should be beamed together like in 2.14.2

%-sample--
\version 2.15.24
\score {
\relative c'{
   \time 6/8 
   c16 d e f8.  c8. d16 e f
   \time 3/4 
   c16 d e f8.  c8. d16 e f
}}

This has been added as issue 2228:

http://code.google.com/p/lilypond/issues/detail?id=2228

A patch is up for review:
http://codereview.appspot.com/5545067

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/16/12 3:41 PM, Janek Warchoł janek.lilyp...@gmail.com wrote:

Carl,

Thanks for your research.
I agree that there must be tied notes if one wants this melody to be
in 3/4 meter.
However, i'm not sure about 6/8.  My pure reasoning is that a
measure in 6/8 meter divides like this:

4. + 4.
8+8+8  +  8+8+8
(16+16)+(16+16)+(16+16)+(16+16)+(16+16)+(16+16)

This argument is hinted at on page 87 of Read.  It is also expressed
explicitly in Gould, page 157, where it indicates that reversing the
fractional beam indicates 6/16 (or 12/16) instead of 6/8, just as you
indicate below.


If one wants to have
16+16+16  +  16+16+16  +  16+16+16  +  16+16+16
grouping, shouldn't 12/16 meter be used?

However, in the literature, there is talk of a beat.  So Gould (p. 155)
says Beams join notes within a beat, never across a beat.  In simple
time a beat is the denominator of the time signature.  In compound time, a
beat is three times the denominator of the time signature.  So a beat in
6/8 is *not* 1/8, but rather 3/8, as shown on p. 155 of Gould.

And there are cases in compound meters where we want to beat 3 against 2,
in which case the beaming that Martin asked for would be correct.

So maybe there should be a setting that allows one to choose which beaming
to use.

The rule that used to apply in 2.14 did not take into account beats at all
if there were fractional beams -- it just tried to avoid sticking-out
beamlets.  Sometimes it got it right, and sometimes it got it wrong.

Looking at Gould now, I think that you are correct, and 2.15.24 had it
right.

Maybe we should ask on -user?

Thanks,

Carl

P.S.  We can set context properties to get the desired behavior with
manual beaming:

\version 2.15.24
\score {
  \relative c'{
\time 6/8
c16 d e f8.  c8. d16 e f
\set Timing.baseMoment = #(ly:make-moment 1 16)
\set Timing.beatStructure = #'(3 3 3 3)
c16[ d e f8.]  c8.[ d16 e f]
  }
}





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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

After a thorough review of the literature, I'm pretty satisfied that the
beaming in 2.14 was wrong.  The beaming in 2.15.24 is correct.

If the 2.14 beaming is desired, a workaround is shown on lilypond issue
2228:

http://code.google.com/p/lilypond/issues/detail?id=2228


I've marked that issue invalid.  Martin, if you'd like to make an argument
that I was wrong in doing so, I'm willing to listen.  It would be best if
you can show some well-engraved music that shows the beaming you were
after.

Thanks,

Carl


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

Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers

[Carl Sorensen]

On 1/15/12 3:06 PM, Janek Warchoł janek.lilyp...@gmail.com wrote:

2012/1/15 Martin Straeten martin.strae...@gmail.com:
 I'm not top posting.
 in 6/8 an 3/4 measure the beamlet of the last/first semiwaver
 points to the dotted quaver.

 semiquavers should be beamed together

I may be wrong, but i don't agree.  Beaming them together would be
against the rhythmical subdivision in 6/8 and 3/4 meters.


I agree with Martin. One of the important things to recognize (which
LilyPond doesn't do yet in the beaming pattern) is that complex meters
(like 3/4 and 6/8) have a fundamental beat unit of 3, and so the beaming
that is chosen is wrong.

The fundamental unit of 6/8 is not 1/8, but 3/8.  6/8 is two groups of
3/8.  The division at half of the 3/8 group is a more important division
than the division at 1/3 of the 3/8 group, so the beaming should reflect
that division.

In the old code, this was handled by trying to avoid sticking out flags.
 That was tossed in order to recognize beat divisions, and the beat
divisions work properly in simple meter, but not it complex meter.

Please make this a regression, with a title that says Beamlet orientation
is wrong in complex meters.

Thanks,

Carl


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

Re: Chord names collide with notes (vertical space missing on second line staff)

[Carl Sorensen]

On 1/10/12 10:03 AM, Jean-Alexis Montignies ja...@montignies.info
wrote:


% no problem without mark alignment to the left or lyrics
% third staff line is to show that there's no problem after second line

\score {

\new ChordNames = chords  \chordmode { \repeat unfold 6 {g1 c:m
} }
   \new Voice = theme{
 \repeat unfold 3 {
 \once \override Score.RehearsalMark #'self-alignment-X = #LEFT
 \mark mark
 \repeat unfold 2 {g''4 b'8 g'  c'' b' g'4 |  d''8 g' c'' g' b'
a' r4 }
 }
   }
   \new Lyrics \lyricsto theme \lyricmode { \repeat unfold 72 ba }

}


Here's another example.

When using -ddebug-skylines, and setting the nonstaff-relatedstaff-spacing
#'padding = #0,  one can see that the chordnames on the second line are
*not* being spaced relative to the notes and the staff, but somehow to
notes only.  Very strange.

\version 2.15.24

\score {
  
\new ChordNames = chords {
  \override VerticalAxisGroup #'nonstaff-relatedstaff-spacing
#'padding = #0
  \chordmode {\repeat unfold 3 { g1 } }
}
\new Voice = theme {
  \repeat unfold 3 {
\once \override Score.RehearsalMark #'self-alignment-X = #LEFT
\mark markb'4 g'8 b' g' b' g' b'  \break
  }
}
\new Lyrics \lyricsto theme \lyricmode { \repeat unfold 21 A}
  
}


Thanks,

Carl



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

RE: error: auto beaming in tuplets after dotted semiquaver

[Carl Sorensen]

 From: Martin Straeten [martin.strae...@gmail.com]
 Sent: Friday, December 30, 2011 12:47 PM
 To: bug-lilypond@gnu.org
 Subject: error: auto beaming in tuplets after dotted semiquaver

 I'm not top posting.

 Autobeaming dotted semiquaver with 64th in tuplet is incorrect for 2.15.23.
 Beams of first 64th points to the left instead of beeing connected to the 
 beams
 of the 2nd and 3rd 64th.

This is issue 2113, and has been fixed in 2.15.24.

Thanks for the report.

Carl

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

Re: Issue 1781 in lilypond: Mac OS X 10.7 (Lion) cannot run LilyPond

[Carl Sorensen]

On 12/30/11 6:49 PM, lilyp...@googlecode.com lilyp...@googlecode.com
wrote:


Comment #18 on issue 1781 by dzhan...@gmail.com: Mac OS X 10.7 (Lion)
cannot run LilyPond
http://code.google.com/p/lilypond/issues/detail?id=1781

When will lilypond work on Lion? (Mac OS X 10.7+)
I would love to use it... but this is stopping me. :(


It is reported that 2.15.23 works on Lion, using some work provided by a
user.

Please see http://code.google.com/p/lilypond/issues/detail?id=1943

If this doesn't work for you, you can always install ubuntu on a
virtualBox and run lilypond in Ubuntu (or some other linux).

I wish I had better news for you than this.  We are short on developers
for OSX.

Thanks,

Carl






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

Re: Bug with (banjo) tablature rendering (workaround possible)

[Carl Sorensen]

On 12/29/11 11:42 AM, Dirk De Wachter que...@belgacom.net wrote:

 I'm not top posting.
The script should explain it all.
It is written for the latest stable lilypond.

This another manifestation of issue 34.

This can be avoided by using \with when defining the TabStaff:

context TabStaff \with {
  tablatureFormat = #fret-number-tablature-format-banjo
  stringTunings = #banjo-open-g-tuning
} 
  \relative c' {
\normalmusic
  }


This insures that the context properties for the TabStaff are set at the
time the TabStaff is created (which, if there are grace notes in the
regular staff, happens before the first music in the TabStaff).

HTH,

Carl


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

Re: Beam subdivision bug in 2.15.22

[Carl Sorensen]

On 12/16/11 12:12 PM, Xavier Scheuer x.sche...@gmail.com wrote:

On 16 December 2011 19:48, Thomas Scharkowski t.scharkow...@t-online.de
wrote:
 \times 2/3 { b16 b b } b8 b4 b b

 2.15.22 produces a (wrong) beam subdivison.
 2.14.2 output is correct.
 See attachments.

Result is fine with 2.15.20.
I did not make a git-bisect but I suspect Carl's fix for issue #11
to be the cause of this.
http://code.google.com/p/lilypond/issues/detail?id=11

I am quite sure that this is the case.


I'm not a git expert but it seems Carl's commit was pushed a few hours
after 2.15.20 release, so issue #11 should have been tagged as
fixed_2_15_21, isn't it?

That is probably correct.


A better wording for this issue report would be something like
unexpected beamlet in tuplet sixteenth.  But maybe it is better to
reopen issue #11.

No, do not reopen issue #11.  This is *not* issue 11.  It is a separate
issue caused by the fix to issue #11.

We should *never* reopen fixed issues unless we see that the issue was in
fact, not fixed.

The regtest for issue 11 shows that issue 11 has been solved.  That fix
introduced a regression that was not tested by the existing regression
tests.  We now have a new problem, and a new potential regression test.
When I've fixed the new problem, the regtests will show that 11 is *still*
fixed.

So a new issue should be added for this bug.

Thanks,

Carl


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

Re: Issue 2059 in lilypond: Bar numbering of alternatives

[Carl Sorensen]

On 12/6/11 3:26 PM, lilyp...@googlecode.com lilyp...@googlecode.com
wrote:


Comment #14 on issue 2059 by x.sche...@gmail.com: Bar numbering of
alternatives
http://code.google.com/p/lilypond/issues/detail?id=2059

The use of this

   \set Score.alternativeNumberingStyle = #'number

or

   \set Score.alternativeNumberingStyle = #'numbers-with-letters

deserves an explanation (as a snippet) in the notation reference,
NR 1.4.1 Long repeats  and maybe a cross-reference in  NR 1.2.5 Bars 
Bar numbers

and this new feature deserves an entry in 'Documentation/changes.tely'
IMHO

Thank you!

Xavier


This should become a new issue, type Documentation.

Thanks,

Carl


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

Re: Issue 1356 in lilypond: LilyPond-style comments embedded inaScheme expression can't include special characters

[Carl Sorensen]

On 11/29/11 7:28 AM, Phil Holmes m...@philholmes.net wrote:

Graham Percival gra...@percival-music.ca wrote in message
news:2029015547.GA2763@chikara...
 On Mon, Nov 28, 2011 at 06:05:35PM -0700, Colin Campbell wrote:
 On 11-11-28 11:39 AM, Phil Holmes wrote:
 This presumes that the Bug squad can and do run Git, which is a
 false presumption.

 +1

 More specifically, I believe it requires a Linux build environment,
 to be truly effective.

 If you want to test that the patch actually does what it claims to
 do, then yes.  If you just want to check if the patch exists in
 master, then of course it's not necessary.

 OTOH, with the lilybuntu VM and lily-git.tcl, doing
 Update source, drop to a shell, cd ~/lilypond-git/build and
 running make, should be within reach for most of the sort of folk
 who want to be bug squadders.

 I honestly believe that less than 50% of bug squad volunteers are
 actively working after 4 weeks.  Am I incorrect as a matter of
 fact?

I don't know the history.  I believe the current squad, as shown on the
CG, 
has 100% active members.

 Assuming that I'm not factually incorrect here, we should not make
 it harder for bug squad volunteers to get started.  Once we hit
 80% retention of volunteers after 4 weeks, I'm open to increasing
 the difficulty.  I would hope that this goal is easy -- as long as
 we're up front about what's required, maintain an encouraging
 environment where questions are welcome (within the bug squad, and
 I'm not claiming to be interested in taking part in that), and
 ruthlessly update the CG section on Issues -- but it *does*
 require skilled developers mentoring new volunteers.

 Short term: sure, let's make verify a patch only a task for the
 bug meister.  The bug meister can either check patches in master
 via git, or else just mark any Patch issue as verified without
 checking anything.


Whoa.  I've just trained the new squadders to do this based on what was
_agreed_ wrt checking the patch was pushed to staging.  With the volume
of 
patches we have, this is one of the larger jobs to do, and so it really
does 
waste my time.  Unless there is clear agreement to change what we
currently 
do (and I only see one person dissenting) then we go with the current
status 
quo, as documented in the current CG in GIT.

I think that Graham meant verify a patch that doesn't have an obvious
change to verify, i.e., patches whose only verification is verify that
the patch was applied.

Those that can be verified through changed documentation or fixed regtests
could easily keep going as they have historically.

Thanks,

Carl




-- 
Phil Holmes
Bug Squad






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

Re: New read/eval Scheme syntax inconsistent in handling existing code

[Carl Sorensen]

On 11/21/11 1:35 PM, David Kastrup d...@gnu.org wrote:
I don't throw out functionality as a rule.  ly:export was an exception
to that rule because its presence was fundamentally incompatible with
maintaining predictable timing for #.  But I backed up this step with a
set of convert-ly rules of rather high quality and coverage (including
the entire Lilypond code base).
 
Let me take the time (much belated) to thank you for that set of
convert-ly rules.  I disagree that they are of rather high quality and
coverage; I believe they are of extremely high quality and coverage.

Thanks,

Carl


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

Re: Using Unicode symbols for accidentals

[Carl Sorensen]

On 11/12/11 6:29 AM, Hans Aberg haber...@telia.com wrote:

On 11 Nov 2011, at 23:04, Pavel Roskin wrote:

 It's not exactly a bug, more like a feature request :)
 
 I have noticed that convert-ly removes the \encoding and converts
 everything to UTF-8.

I hacked together some code, scm/define-note-names.scm, with a language
unicode added.

Another concern about having unicode as the default language -- when I
opened the file in my default editor (TextEdit), none of the unicode
characters appeared.  Readability was definitely not higher in this case.

Thanks,

Carl


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

Re: Problem with music function in 2.15.18

[Carl Sorensen]

On 11/12/11 2:17 PM, Nick Payne nick.pa...@internode.on.net wrote:

There's a music function I use in virtually every guitar score I've done
with Lilypond, to move glissandi that I use to indicate that a finger
should be kept on a string when moving frets. I just downloaded and
installed 2.15.18 (Linux amd64 version running on Ubuntu 10.04), and the
parameters to the function no longer seem to be being recognised as the
correct type. The short example below shows the problem.

\version 2.15.18

\language english

guide = #(define-music-function (parser location padleft padright shift
missacc) (number? number? pair? boolean?) #{
 \once \override Glissando #'bound-details #'left #'padding =
#$padleft
 \once \override Glissando #'bound-details #'right #'padding =
#$padright

I believe you now use just $padright instead of #$padright

HTH,

Carl



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

Re: Using Unicode symbols for accidentals

[Carl Sorensen]

On 11/11/11 4:49 PM, Pavel Roskin pro...@gnu.org wrote:

On Fri, 11 Nov 2011 23:21:42 +0100 (CET)
Werner LEMBERG w...@gnu.org wrote:

 
  f♯ is shorter and more readable than fsharp, let alone fis.
 
 In Germany and Austria, f♯ is *never* used.  Only fis and nothing
 else.

I'm sure the signs for accidentals are used in the musical scores, even
in Germany :)

I think the point Werner was making is that accidentals are used on a
staff.  The graphical representation of f sharp is a notehead on the f
line or space (depending on which staff, and which octave) with a sharp
symbol either before the note (an accidental) or in the key signature.

The text representation of f sharp in germany and austria is fis.  When
you want to describe a note in text, that's how you do it.  In english, we
write f sharp; in german, they write fis.


Using those signs in a text file would be a new thing.  Maybe
accidentals should be written before the notes, as in the score (♯f),
but that could complicate parsing and conversion to the new format.  On
the other hand, it would be better to make a choice that's more natural
for musicians, not for programmers.

For german musicians, fis is more natural.

Personally, I would *hate* having to type unicode symbols for sharp and
flat. It's much easier to learn that is means sharp and es means flat,
than it is to learn (and remember) how to get unicode characters in my
text file.  I can type text at 70 words per minute.  I can type unicode at
about 0.2 words per minute.

If learning that is means sharp and es means flat is going to stop
someone from using LilyPond, I have no confidence that they will ever use
it anyway.  They should probably use some GUI point-and-click tool, rather
than LilyPond.

I believe that someone who wanted to (including you) could define a
language, e.g. unicode, that used unicode symbols for entry of
alterations.  It should be relatively straightforward, by adding entries
to the file scm/define-note-names.scm.  If you'd like to try it, I'd
certainly be willing to help you through rough spots that you hit.  And if
you have a unicode language, then we can have the discussion about making
it the default language for LilyPond, although I doubt there is any chance
of moving it to the default.

One of the nice things about LilyPond is that if you want a feature, you
can implement it.  So let me encourage you to give it a try!

Thanks,

Carl



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

Re: MIDI dynamics doesn't apply to multi-voice measures

[Carl Sorensen]

On 10/29/11 8:09 AM, Pavel Roskin pro...@gnu.org wrote:

Quoting Keith OHara k-ohara5...@oco.net:

 Pavel Roskin proski at gnu.org writes:

 I'm trying to change relative loudness on the melody and the
 accompaniment, by it turn out the MIDI dynamics doesn't apply to the
 measures that have multiple voices.

 You now need to put some dynamic mark at the start of every voice,
 not just the start of every staff.

I tried adding dynamic marks in the first multi-voice measures for the
left and the right hand, but it's not enough.  I'm afraid I'll need
them in every measure.  Also, I'll need to make them transparent, or
the score would be hard to read.  It's easier for me to edit the
resulting MIDI-file.

You're probably using the  \\  construct.  This creates temporary
voices.

Please try with explicitly instantiated voices, as shown in section 3.2.2
of the Notation Reference:

http://lilypond.org/doc/v2.15/Documentation/learning/explicitly-instantiati
ng-voices


HTH,

Carl



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

Re: Issue 1859 in lilypond: let \contextStringTunings affect only current context.

[Carl Sorensen]

On 9/4/11 9:04 AM, David Kastrup d...@gnu.org wrote:

 lilyp...@googlecode.com writes:
 
 Comment #3 on issue 1859 by reinhold...@gmail.com: let
 \contextStringTunings affect only current context.
 http://code.google.com/p/lilypond/issues/detail?id=1859
 
 Good, so this bug seems really fixed.
 
 The way the code had been written originally, I suspect that it was
 written with a particular use case in mind.  My guess would be that the
 side-effects were worse than the cure, but until we get an explicit
 report of the purported problem, I would prefer to have the code stick
 with the straightforward version that corresponds with both function
 name as well as documentation.

The use case was wanting to make sure that the TabStaff and the FretBoards
both used the same tuning to avoid the possibility of an error.

The current version is clearly better.  No need to go back to try to
implement the old use case.
 
 Actually, I don't like the entire approach all too much, so I am
 currently working on making a define-scheme-function thingy that can
 take Lilypond arguments like define-music-function but produces not a
 music but a Scheme expression.

That would be much nicer than the current usage.

IMO, the best practice would be to do a \makeStringTuning, at the top of the
file, then as needed instantiate your TabStaff and FretBoards contexts with
the named string tuning.

Thanks,

Carl



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

FW: Custom Tuning creating space beneath the first system

[Carl Sorensen]

Peter,

I've forwarded this to bug-lilypond, because it is a bug.
\contextStringTuning sets a context property for the FretBoards context.
This creates a FretBoards context if one doesn't exist.

I'll investigate possible fixes.

In the meantime, since you're not using FretBoards in this layout, put the
following in your file before the score:

contextStringTuning =
#(define-music-function (parser location tuning chord)
   (symbol? ly:music?)
   (_ Convert @{chord} to a string tuning stored in @code{tuning},
and set @code{stringTunings} of the current context to the
newly-defined tuning.
@{chord} must be in absolute pitches and should have the highest
string number (generally the lowest pitch) first.  @code{tuning}
should be a string that will be converted to a symbol.)
   (begin
 (chord-tuning parser tuning chord)
 #{
\set TabStaff.stringTunings = $(ly:parser-lookup parser tuning)
 #}))

HTH,

Carl


-- Forwarded Message
From: Peter Crighton petecrigh...@googlemail.com
Date: Fri, 19 Aug 2011 06:58:05 -0600
To: LilyPond Mailing List lilypond-u...@gnu.org
Conversation: Custom Tuning creating space beneath the first system
Subject: Custom Tuning creating space beneath the first system

Hi everybody.

When I create a custom tuning via \contextStringTuning there is some
extra vertical space (only) beneath the first system. When creating it
via \set TabStaff.stringTunings everything's perfect.
Is this a bug? Can it be fixed? I'd like to use \contextStringTuning,
because it's more compact.

--
Peter Crighton | (mainly) Progressive Rock musician based in
Mainz/Wiesbaden, Germany
http://www.petercrighton.de

-- End of Forwarded Message



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

Re: Issue 1663 in lilypond: Images missing on web site

[Carl Sorensen]

On 7/30/11 3:07 AM, Phil Holmes m...@philholmes.net wrote:

 Colin Campbell c...@shaw.ca wrote in message
 news:4e334502.6070...@shaw.ca...
 
 Will this mean that we won't have to use the separate
 
 scripts/auxiliar/cg-section.sh SECTION as in CG 5.6, Phil?
 
 Colin
 
 
 Almost certainly not.  TBH I've not looked into why that's separate, but I'd
 be staggered if anything I've done will change that.

Phil's answer is correct.

The reason we have cg-section.sh different from doc-section.sh is that the
CG has a different file layout than the rest of the docs.

These *.sh scripts are minimal scripts to process the individual doc
sections quickly, and are not compatible with the full doc process.  But
they do test the texinfo in the relevant section.

Thanks,

Carl


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

Re: Issue 1752 in lilypond: redesigning G clef in our Feta font

[Carl Sorensen]

On 7/24/11 2:19 PM, lilyp...@googlecode.com lilyp...@googlecode.com
wrote:

 
 
 Comment #25 on issue 1752 by percival.music.ca: redesigning G clef in our
 Feta font
 http://code.google.com/p/lilypond/issues/detail?id=1752
 
 The critical regression thing was a complete brain fart from me and
 should be scornfully ignored.  I also now agree that the idea of an
 \override for this specific glyph should be dropped.
 
 However, I am aghast that the font switching architecture is going
 nowhere.  As far as I understand it,
1. we can switch to a different OTF font.  (aka gonville)

2. we *CANNOT* switch to a different metafont font ?


Not quite.  We can only switch to gonville through an ugly hack.  There is
no difference between switching to gonville and switching to a different
metafont font.

Thanks,

Carl


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

Re: Issue 1752 in lilypond: redesigning G clef in our Feta font

[Carl Sorensen]

On 7/24/11 5:43 PM, lilyp...@googlecode.com lilyp...@googlecode.com
wrote:

 
 
 Comment #26 on issue 1752 by lemniska...@gmail.com: redesigning G clef in
 our Feta font
 http://code.google.com/p/lilypond/issues/detail?id=1752
 

 
 In order to address the difference of opinion, we have two proposals.  The
 first is to allow an override to switch the glyphs.  Trevor is strongly
 against it; it would lead to a multiplicity of overrides.  The second is
 to
 create a new font with the new glyph.
 
 Is it worth it?  I mean, that would be the biggest code duplication i've
 ever imagined - to have two fonts that differ with one glyph only!
 

Well, actually, I wouldn't have it be a new font.  I'd have it be a
different version of the Feta font.  AFAICS, the majority has signed off on
this change to the font.  For those who don't want to use the new version of
the font, they can use the old version of the font.

 Absent the new architecture, my recommendation is to wait on this patch
 until 2.16 is out, and then apply the patch *without* the override
 capability to 2.17.
 
 (obviously) I don't like this solution because it makes my work lie on a
 shelf for a few months and do nothing but collect dust.

This proposal was based on Graham's assertion that 2.16 is 10 days away from
release, so your new clef would be 10 days away from being in 2.17.  If this
doesn't happen, I might change my mind.

And I'll take a look at the font switching capability.

 
 Can we accept the style override as a temporary solution?  Sooner or later
 we'll implement font changing architecture and we'll then move to the more
 elegant solution.  We can set ourselves a deadline: with 2.18 the Clef
 #'style = #old override will be dropped regardless of whether we'll have
 font changing architecture or not.  How do you like it?


In the past, I would have been in favor.  Having seen what happened with
\chordGlissando, I am not in favor.

When you add the #'style =  #'old to the syntax, you'll have to remove it
shortly thereafter.  It makes a horrendous mess for convert-ly.

I'm pretty much solidly in favor of doing it right, rather than doing it
quickly.

If we need a shorter-term solution, and having had Graham take back his
Critical Regression brain fart, I'd say we go ahead and push the changes,
and then James will either have to use the current version, or maintain a
patch to the font.

Thanks,

Carl 


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

Re: Issue 1733 in lilypond: \displayLilyMusic ignores \tweak

[Carl Sorensen]

On 7/24/11 4:12 AM, -Eluze elu...@gmail.com wrote:
 
 If I run the command above with 2.15.5, I get the output at the bottom.
 I'm not convinced that's correct.
 
 Unbound variable: t
  \tweak #'transparent ##unspecified c e 
 
 an old question: should it be ##t or just #t?
 
 a small example to illustrate the dilemma (from the NR) - emphasized by me:
 
 Controlling tuplet bracket visibility
 The default behavior of tuplet-bracket visibility is to print a bracket
 unless there is a beam
 of the same length as the tuplet. To control the visibility of tuplet
 brackets, set the property
 'bracket-visibility to either #t (always print a bracket), #f (never print a
 bracket) or
 #'if-no-beam (only print a bracket if there is no beam).

IMO, we should probably not list these in the text, but rather just show
examples.

But if we do list them, they should be #t, #f, 'if-no-beam.

#'if-no-beam is the only value in that section that has the # used to
introduce a scheme variable.




 music = \relative c'' {
 \times 2/3 { c16[ d e } f8]
 \times 2/3 { c8 d e }
 \times 2/3 { c4 d e }
 }
 \new Voice {
 \relative c' {
  \music s4^default 
 \override TupletBracket #'bracket-visibility = #'if-no-beam
  \music s4^'if-no-beam 
 \override TupletBracket #'bracket-visibility = ##t
  \music s4^#t 
 \override TupletBracket #'bracket-visibility = ##f
  \music s4^#f 
 }
 }


The example is correct.

Thanks,

Carl


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

Re: 2.14.2

[Carl Sorensen]

On 7/14/11 6:23 AM, Urs Liska lilyli...@googlemail.com wrote:

 Hi guys,
 
 as you may have noticed I gained some activity again lately.

Glad to have you back!

 I think I have to apologize that I faded out of my Bug Squad duty
 silently half a year ago.

Apology accepted.

 
 This as a general remark, now to my current question:
 When do you expect 2.14.2 to be released?

I think it's ready when Graham gets to it.  I expect it soon.

 ATM there are many issues to verify that are marked as fixed_2_14_2. So
 before this version is released the issues can't be verified.

I think that in the past we have marked it as verified when fixed in the
development version, and not waited for the backported version to be
released.  But I think the policy you are proposing is better.

Perhaps when it's verified in one of the versions, a tag indicating that
should be added:  verified_2_15_5.  Then when it's been verified in both
versions, the verified_2_15_5 tag is removed, and status is set to Verified.

Thanks,

Carl


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

Re: how to change gap between beams?

[Carl Sorensen]

On 7/13/11 6:48 AM, Janek Warchoł lemniskata.bernoull...@gmail.com
wrote:

 2011/7/13 m...@apollinemike.com m...@apollinemike.com
 
 On Jul 13, 2011, at 1:48 PM, Janek Warchoł wrote:
 
 Is it possible to change gap between beams (i.e. the distance between the
 lines) painlessly?
 \override Beam #'gap = #2 doesn't work, i don't find anything in LSR nor
 Internals...
 
 cheers,
 Janek
 
 You have to override the Beam #'length-fraction property.
 
 It works, thanks!
 Interestignly, it isn't listed in Internals - a bug?\

IR 3.12.2 beam-interface, user-settable properties.

HTH,

Carl



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

Re: Diatonic Instruments (Mountain Dulcimer)

[Carl Sorensen]

On 7/8/11 1:51 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote:

 Hi Blake,
 
 unfortunately the only thing we can do now is to add this to our issue
 tracker.
 Dear Bugsquad, should this be added as a comment to
 http://code.google.com/p/lilypond/issues/detail?id=703
 or as a new issue?
 Carl, i dare to cc you because you are knowledgeable on Frets (and
 also the issue mentioned is yours).

This should be a new issue.  Issue 703 is about dealing with string pitches;
this issue is dealing with frets that are not a semitone.

Thanks,

Carl


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

Re: Backporting for 2.14.2

[Carl Sorensen]

=On 6/28/11 12:30 PM, Federico Bruni fedel...@gmail.com wrote:

 Il giorno lun, 27/06/2011 alle 13.13 -0600, Carl Sorensen ha scritto:
 I'm trying to get ready for release 2.14.2.  In general, I'd like
 bugfixes
 from 2.15.x to show up in 2.14.2.
 
 Carl,
 
 when v2.14.2 will be released? (more or less)
 Please consider that I'm going to prepare a patch for italian doc which
 should be cherry-picked to 2.14.
 
 Now I'm stuck because I'm not sure about how to translate the snippets
 in LM.  Francisco usually replies very quickly, so I'm afraid he could
 be on vacation.

Francisco is on vacation for a week.

I expect to have 2.14.2 released on July 9.

Thanks,

Carl

 
 My question is here:
 http://lilypond-translations.3384276.n2.nabble.com/snippets-in-LM-td6518251.ht
 ml

Documentation/snippets come from the LSR (snippets in the LSR with a docs
tag).

Documentation/snippets/new contains snippets that are changed from those in
the LSR.

Somehow makelsr.py ties the things all together (I'm not sure I understand
the exact details) to give us a set of snippets for the documentation.

I'm not very strong on my knowledge of the translation work, but IIUC,
snippets are automatically translated using the .po files, rather than being
individually translated by translators.

You should have time to resolve this issue after Francisco returns and
before 2.14.2 is released.

Thanks,

Carl


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

FW: how to create baroque ornaments

[Carl Sorensen]

-- Forwarded Message
From: Giso Grimm gg3...@vegri.net
Date: Mon, 27 Jun 2011 13:23:54 -0600
To: lilypond-u...@gnu.org
Conversation: how to create baroque ornaments
Subject: how to create baroque ornaments

How can I create ornaments like those in the attached example?

I tried \markup with creating a path, however, this is always placed
outside the staff. The desired ornament should always appear at a fixed
distance to the note head (similar to accidentials, but after the note
head).

Best regards,

Giso

-- End of Forwarded Message


The most straightforward way to do this will be to add the ornaments to the
font and to make them articulations.  Then the properties can be
appropriately set.  This would require changes to the font, so it's not
trivial.  That's why I've forwarded this request to bug-lilypond, where it
can become an enhancement request.

It looks like the current script interface is pretty hard-coded around
getting glyphs from the feta font.

You may be able to adjust the position of a markup to get what you want, but
I think it will be quite difficult.

I'd be happy to give you some advice about adding the glyphs to the feta
font if you're interested in doing it.

HTH,

Carl



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

Re: Bugs in Debian

[Carl Sorensen]

On 6/7/11 5:42 AM, Carlo Stemberger carlo.stember...@gmail.com wrote:

 The Debian Bug Tracking System contains some bug reports concerning LilyPond,
 with short examples.
 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=lilypond;dist=unstable
 
 Could you verify them and in case add them to your track, please?
 
 Thank you!

Carlo,

143709 is invalid.
153782 is invalid.
153784 is invalid.
437267 has been fixed in 2.14.
607431 is accepted as lilypond issue 1683.
139577 has been fixed.
335828 is a Debian bug, not a LilyPond bug.
98659 has been fixed.

Hope this helps.

Carl


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

Re: Attachments on the tracker

[Carl Sorensen]

On 5/29/11 4:29 AM, Phil Holmes m...@philholmes.net wrote:

 Phil Holmes m...@philholmes.net wrote in message
 news:irt6lm$brs$1...@dough.gmane.org...
 We're now using 33.4 MB (66% of total attachment quota) on the bug tracker
 for attachments.  At some point we will (I assume) need to prune some of
 the attachments to avoid running out of space.  I think it would make
 sense to delete some of the attachments on
 http://code.google.com/p/lilypond/issues/detail?id=1562 since these are
 quite large and have done their job.  Does it make sense to start pruning
 now?
 
 --
 Phil Holmes
 Bug Squad
 
 http://code.google.com/p/lilypond/issues/detail?id=1060 is another
 candidate.

One single attachment on 1060 is 1.7 MB, and could certainly be pruned.  But
I don't see any way for me to prune attachments, or I'd have already done
this for issue 1060.

Thanks,

Carl


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

Re: Cross-staff beaming

[Carl Sorensen]

On 5/29/11 5:42 AM, Hilary Snaden h...@newearth.demon.co.uk wrote:

 Phil Holmes wrote:
 Hilary Snaden h...@newearth.demon.co.uk wrote in message
 news:4de210b3.80...@newearth.demon.co.uk...
 Manual beamings of cross-staff note groups are mangled, but
 inconsistently. The beaming in this extract works for the first 6 bars,
 then fails on beats 1 and 3 on the following bars. (Beamings on beats 2
 and 4 are as they were.) Versions 2.12.2, 2.13.61 and 2.13.62 behave in
 the same way.
 
 Could you prepare a tiny example that demonstrates this, please? (See
 http://lilypond.org/website/bug-reports.html)
 
 The original example showed that the beam-mangling didn't start (in the
 real-world case) for several bars and that the mangling occurred only on
 the 1st and 3rd beats of the original 4/4. (Bugs within bugs?)

The beam-mangling is unrelated to the bar number (with the possible
exception of bar 1).  It also can easily be made to occur on beats 2 and 4.
See the code below for an example.

It most likely is related to a particular set of pitches compared with the
neighboring pitches; Mike Solomon would have a better idea of what is broken
here.  Hilary, if you can get the example even smaller, it would be helpful.

HTH,

Carl


\version 2.13.62

csu = \change Staff = upper
csl = \change Staff = lower
sd = \stemDown
sn = \stemNeutral
su = \stemUp

manualBeam =
#(define-music-function (parser location beg-end)
   (pair?)
   #{
   \once \override Beam #'positions = #$beg-end
   #})

upper = \relative a {
   \clef treble \key a \major \time 4/4
   \su
   r16 \csl \manualBeam #'(1 . 1.5) ais^( g \csu e' % 7
   g16 \csl \manualBeam #'(1 . 1.5) ais,^( g \csu e' % 7
   \csl \manualBeam #'(1.5 . 2) ais, \csu g' e g) % 7
   r \csl \manualBeam #'(1 . 1.5) ais,^( g \csu e'
   \csl \manualBeam #'(1.5 . 2) ais, \csu g' e g) % 7
   r \csl \manualBeam #'(1 . 1.5) b,^( gis! \csu e' % 8
   \csl \manualBeam #'(1.5 . 2) b \csu gis' e gis) % 8
   r \csl \manualBeam #'(1 . 1.5) b,^( a \csu dis % 8
}

lower = \relative a, {
   \clef bass \key a \major \time 4/4
   \sd a4 r a r |
   a r a r |
}

\score {
   \new PianoStaff {
 
   \new Staff = upper { \upper }
   \new Staff = lower { \lower }
 
   }
}


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