Re: Feedback wanted: syntax highlighting in the LilyPond documentation
Jean Abou Samra wrote: [Robin] The stroke width I see is 1px (Firefox at 100%). This makes the stroke dominated by edge effects; the surrounding white dilutes its colour. Do the WCAG recommendations recognise this? If not, please don't apply their levels to this case. I don't know. I am not a great specialist of all the (complicated) WCAG rules. All I have been interested in so far was the ones for color; their criteria were a handy way to know if the scheme was OK It looks like the contrast tools offer comparison of two colors, without considering such context complications. Very idealised. But I found tentative recognition at the top of https://www.w3.org/WAI/GL/WCAG3/2021/how-tos/visual-contrast-of-text/#design-button This shows me that they have no handy criteria to offer (yet). Cheers, Robin P.S. Their #design-button fragment doesn't work for me. I have to click on the [Design] tab. All very bleeding edge.
Re: slash-only chords
Oops, successive redundant *chords* with a changing bass note, I meant to say. LT Harm, Thanks so much for sharing and tightening up this code for hiding redundant bass notes in successive slash chords, and thanks Elaine Alt for initiating the thread. It's a really useful feature to have in a leadsheet, and one I had been hoping was possible in Lilypond without too much trouble. Much appreciated! LT Am So., 2. Jan. 2022 um 09:06 Uhr schrieb Flaming Hakama by Elaine : > > On Fri, Dec 31, 2021 at 8:07 AM Thomas Morley > wrote: >> How about: [...] > Yes, thanks, this works well if the initial chord is a minor chord. > > What would it take to have it work when the initial chord has a 7th? > > For other chord types, it seems to hide the root, but print the rest of the > chord symbol. Thanks spotting this, it means the whole approach changing chordRootNamer is insufficient. > Perhaps, in this block it would be possible to set additional properties > related to other parts of the chord symbol to ""? Regrettable: no. > I wasn't able to guess what those might be. > Are they listed somewhere? Well, all context-properties are listed in IR. You can observe the default settings their as well (alphabetical listed, see context Score) In /ly/engraver-init.ly they are thematical ordered. But none of them will help here, afaict. Instead please try the attached file - recreating the chords text, if conditions are matched. Cheers, Harm
Re: slash-only chords
Am Di., 4. Jan. 2022 um 20:52 Uhr schrieb jerome talkington : > > Harm, > > Thanks so much for sharing and tightening up this code for hiding redundant > bass notes in successive slash chords, and thanks Elaine Alt for initiating > the thread. It's a really useful feature to have in a leadsheet, and one I > had been hoping was possible in Lilypond without too much trouble. Much > appreciated! > > LT You're welcome. Because the code already works with 2.18.2 I've added it to LSR https://lsr.di.unimi.it/LSR/Item?u=1&id=1137 Alas, there's again a glitch in LSR so that new snippets don't display an image :( Anyway, I tagged it DOC, thus it will be implememted into our source with next LSR import and should be available in Snippets-manual with the then following release. Cheers, Harm
Re: slash-only chords
Thanks again! On Wed, Jan 5, 2022 at 5:31 AM Thomas Morley wrote: > Am Di., 4. Jan. 2022 um 20:52 Uhr schrieb jerome talkington > : > > > > Harm, > > > > Thanks so much for sharing and tightening up this code for hiding > redundant bass notes in successive slash chords, and thanks Elaine Alt for > initiating the thread. It's a really useful feature to have in a leadsheet, > and one I had been hoping was possible in Lilypond without too much > trouble. Much appreciated! > > > > LT > > You're welcome. > Because the code already works with 2.18.2 I've added it to LSR > https://lsr.di.unimi.it/LSR/Item?u=1&id=1137 > Alas, there's again a glitch in LSR so that new snippets don't display > an image :( > Anyway, I tagged it DOC, thus it will be implememted into our source > with next LSR import and should be available in Snippets-manual with > the then following release. > > Cheers, > Harm >
Re: point-and-click default
On Sat 01 Jan 2022 at 22:27:31 (+0100), Valentin Petzel wrote: > May I just fan the fire by saying that on kde this works out of the box? > > That being said, the only really usable pnc implementation is Frescobaldi, as > that one will keep track while you’re editing the file and thus always point > to > the right thing. Interesting. How precise is the forward indication (ie in the score display), and how does it point to it. Do you know what mechanism it's using to keep track? The way reverse indications work is relatively straightforward (except for how LP inserts the textedits), but I've never slogged through the paper that describes SyncTeX, nor installed Okular, which is one viewer that's supposed to be able to perform forward indications, but comprises 134 extra packages in Debian. > And I don’t see much of a problem with disabling pnc by default, but it would > not change much as most people would probably activate it somewhere and still > forget to deactivate it for sharing. Of course, many other document formats can also leak information unless you work around the problem, by sanitising the documents, naming their source locations carefully, logging in anonymously, or whatever's most straightforward. Cheers, David.
Fingering collision with tempo when using cross-staff beams
The fingering here collides with the tempo. If the cross-staff beams are
commented out (all notes on the upper staff), the fingering displays fine.
Is there a workaround? Am I doing something wrong?
\version "2.23.5"
global = {
\time 6/8
\tempo "Allegro"
}
goUp = { \change Staff = "right"
\stemDown
}
goDown = { \change Staff = "left"
\stemUp
}
right = \relative c'' {
\global
8-2-4 \goDown \goUp \goDown d,4.->_5 |
}
left = \relative c' {
\global
s2. |
}
\score {
\new PianoStaff <<
\new Staff = "right" \right
\new Staff = "left" { \left }
>>
}
Re: Fingering collision with tempo when using cross-staff beams
Le 05/01/2022 à 20:59, Michael Rivers a écrit :
The fingering here collides with the tempo. If the cross-staff beams
are commented out (all notes on the upper staff), the fingering
displays fine.
Is there a workaround? Am I doing something wrong?
\version "2.23.5"
global = {
\time 6/8
\tempo "Allegro"
}
goUp = { \change Staff = "right"
\stemDown
}
goDown = { \change Staff = "left"
\stemUp
}
right = \relative c'' {
\global
8-2-4 \goDown \goUp \goDown d,4.->_5 |
}
left = \relative c' {
\global
s2. |
}
\score {
\new PianoStaff <<
\new Staff = "right" \right
\new Staff = "left" { \left }
>>
}
I've just added this bug to the tracker here:
https://gitlab.com/lilypond/lilypond/-/issues/6250
You can work around it by positioning the tempo mark yourself, adjusting
its Y-offset:
\version "2.23.5"
global = {
\time 6/8
\once \override Score.MetronomeMark.Y-offset = 6
\tempo "Allegro"
}
goUp = { \change Staff = "right"
\stemDown
}
goDown = { \change Staff = "left"
\stemUp
}
right = \relative c'' {
\global
8-2-4 \goDown \goUp \goDown d,4.->_5 |
}
left = \relative c' {
\global
s2. |
}
\score {
\new PianoStaff <<
\new Staff = "right" \right
\new Staff = "left" { \left }
>>
}
See this for more information:
https://lilypond.org/doc/v2.22/Documentation/notation/aligning-objects.html#setting-x_002doffset-and-y_002doffset-directly
Best,
Jean
Re: Guile V1 vs. V2?
On Tue, 21 Dec 2021, Valentin Petzel wrote: Hello, Hello Mike, Guile 1 to Guile 2 did change some syntax and some mechanics, which means that guile code must be reworked for guile 2 and using guile 2 makes the program much slower. There is ongoing long time effort to port Lilypond to guile 2 and eventually 3 which does make progress, but for the time being using Lilypond with guile 2 is not recommended. The way FreeBSD handles this seems to be a bit bad. One can very well have different guile versions one one system, and Lilypond can be compiled with it's own embedded guile version. As I wasn't involved with the decisions I can only speculate as to why things were done the way they are now. Probably nobody was expecting guile 1 to still be around almost a decade later... Anyway, I started work on making the different guile ports able to coexist. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260960 for progress there. Building lilypond with guile embedded probably is an excellent approach for a standalone package, but attempting to do this within the ports framework promises to be a rather distasteful experience. (This isn't meant as a criticism of lilypond nor the ports collection. It just goes against the core principles of having a comprehensive package repository in the first place.) So you should probably report this to the system/package maintainers. No need if the maintainer is already on this mailing list (although not particularly active these days...) Cheers, Valentin 21.12.2021 05:48:20 Mike Andrews : Greetings. This is intended primarily for the folks who build packages for FreeBSD. I recently installed the current LilyPond on FreeBSD 12, using the pkg command to install a precompiled set of binaries and other files. One of the prerequisites was GNU Guile V1. I had some other packages installed which used Guile V2; those packages and Guile v2 were deinstalled, which was inconvenient at best. Is there a particular reason to specify Guile V1, and to not use Guile V2.* ? As Valentin stated above, while there has been quite significant progress with support for guile 2 lately, guile 1 still has the official blessing as standard version for lilypond. If you don't mind building your own package, the port already has the option to use guile 2 instead. At some point in the (probably not too distant) future I the default will definitely change, but right now I'm still hesitant. Best, Mike Andrews Tired old sysadmin I hope this wasn't too discouraging. All the best, Martin PS: For giggles, the lily configure script does some dubious stuff: checking for guile-2.2... yes checking libguile18.h usability... no checking libguile18.h presence... no checking for libguile18.h... no -- Sollte sich jemand, von dem Sie nicht sicher wissen, daß er ein babelusischer Rechtsgelehrter ist, ein paar Dachschindeln ausborgen wollen, ist Vorsicht geboten; oder richten Sie wenigstens schon einmal Waschzeug her.
2.23.5 articulate.ly and repeat alternatives
A nice thing I’ve discovered in reviving my old (2.18) project is that
articulate.ly now expands repeats without `\unfoldRepeats`. A less-nice
thing is that this behavior behaves oddly around `\alternative`:
\version "2.23.5"
\include "articulate.ly"
music = \relative c' {
c1
\repeat volta 2 {
e
\alternative {
{ g } { gis }
}
}
b
}
\score { \music }
\score { \unfoldRepeats \music }
\score { \articulate \music }
\score { \articulate \unfoldRepeats \music }
Both alternatives print each time with `\articulate`, though naked
`\unfoldRepeats` works on its own.
(And `\articulate \unfoldRepeats` behaves the same as `\articulate`,
which suggests my mental model of these as music functions is missing
something.)
—Joel C. Salomon
dynamics: sf vs sfz
Hi; Musical question here, not specific to Lilypond. I have an excerpt that I am engraving as a sample which uses the dynamic "sf". In the Wikipedia article https://en.wikipedia.org/wiki/List_of_musical_symbols "sfz" is mentioned but not "sf". Ah, I see in my printed Norton/Grove Concise Encyclopedia of Music that "sf" and "sfz" are both the abbreviations of sforzando and/or sforzato. Answered my own question :-( Thanks, Ken Wolcott
