>> Thanks! Please check whether
>>
>> moveDyn =
>> #(define-event-function (X Y etc) (number? number? ly:music?)
>> #{ \tweak DynamicLineSpanner.outside-staff-priority ##f
>> \tweak DynamicText.X-offset #X
>> \offset DynamicLineSpanner.Y-offset #Y
>> etc #})
> Oops, and of course #etc (or whatever it is called now).
I now have
% A tweak-like function to move dynamics.
moveDyn =
#(define-event-function (x y event) (number? number? ly:event?)
#{ \tweak DynamicLineSpanner.outside-staff-priority ##f
\offset DynamicText.X-offset #x
>> no code for module (ice-9 readline)
>>
>> [...]
>>
>> This seems to mean I should install Guile modules that Lilypond
>> doesn't install by default, but I haven't been able to work out
>> from the doc where to install them so that Lilypond will be able to
>> find them. Any suggestions on how t
[As a side note: Calling `lilypond guile-debugger.ly' using the
MacPorts `lilypond-devel' port works just fine on my old MacOS Lion.]
> I'm afraid the information I see at
> https://github.com/lilypond/lilypond/blob/master/Documentation/usage/running.itely
> ,
> or at
> http://partitura.org/wp-c
>> If it hasn’t changed since 2.19.82 you could use
>>
>> \override Staff.NoteCollision.prefer-dotted-right = ##f
>
> Thank you, this is exactly what I needed to find but didn't know how
> to search for ...
I've just added the corresponding snippet to the NR.
Werner
___
> It may be the case that only lilypond-devel is actively maintained,
Probably true. I only take care of `lilypond-devel' and know nothing
of `lilypond'.
> but it was reported on the devel list that the dependency gcc8
> didn’t build.
The patch to fall back to gcc9 has been applied to the git
>>> Maybe if a compiler is not listed as a dependency, it will just
>>> take what is currently installed.
>>
>> Yes.
>
> So perhaps it suffices to remove it from the lilypond-devel
> dependency list to get it to install.
What dependency?
Werner
___
> On my current (10.14.6) system lilypond-devel does not build:
>
>> error: expected initializer before '__OSX_AVAILABLE_STARTING'
>> https://trac.macports.org/ticket/59130
Try to install gcc9, then retry installation of lilypond-devel (with
`port clean lilypond-devel' before doing that).
error: expected initializer before '__OSX_AVAILABLE_STARTING'
https://trac.macports.org/ticket/59130
>>
>> Try to install gcc9, then retry installation of lilypond-devel
>> (with `port clean lilypond-devel' before doing that).
>
> I have already done this - no success.
OK. Unfortunately
> Do you believe that it is impermissible for us to offer a binary
> compiled using XCode on lilypond.org? [...]
AFAIK, the limitation is only *building* on Mac OS hardware, not
*distributing*.
Werner
___
lilypond-user mailing list
lilypond-user
> Frankly, I think the most satisfactory course would be to let have
> \underline some default padding/outline action that will make nested
> applications of \underline just work according to naive
> expectations.
+1
Werner
___
lilypond-user mail
> I have just published the beta release (0.90.1) of the library
> 'harmonyli.ly': https://github.com/kreincke/harmonyli.ly It is a
> library for integrating Functional Harmony Analyse Symbols into a
> music score as it is used by musicologists.
This looks very nice, thanks!
The only thing I wo
> I fixed the bug [that] Werner found.
Thanks for that! Much better IMHO, but there is still room for
improvement :-) If the `D' has a diagonal slash through it, I suggest
that you move the left parenthesis a bit to the left.
Werner
On the TeXLive mailing list, Norbert Preining , one
of the maintainers of TeXLive posted the following today.
With the end of 2019, Python2 will be deprecated and not receive any
security updates. Most distributions will throw out Python2
completely. (Don't ask me about my opinion on the
>> This package is written by Urs Liska , who is
>> quite busy these days. In case you have experience with Python 2
>> to 3 conversion, please help produce a new version!
>
> Should it still be backwards compatible with Python 2.7 if possible or
> is it ok to drop Python2 backwards compatibili
Folks,
I've just tried
http://lsr.di.unimi.it/LSR/Search
and it works fine.
> It may not be a good thing that nobody seems to know who runs and
> manages LSR.
Uh, oh, it was and still is Sebastiano Vigna. This has never changed.
Seems there is a lot FUD around here...
> Should we devote
Folks,
how can I control the default horizontal position of rehearsal marks
at the beginning of a line? As can be seen in the attached image, the
rehearsal mark gets shifted up because it would otherwise collide
with the bar number. Consequently, I would like to have the default
position shift
>> how can I control the default horizontal position of rehearsal
>> marks at the beginning of a line? As can be seen in the attached
>> image, the rehearsal mark gets shifted up because it would
>> otherwise collide with the bar number. Consequently, I would like
>> to have the default position
> how can I control the default horizontal position of rehearsal marks
> at the beginning of a line? As can be seen in the attached image,
> the rehearsal mark gets shifted up because it would otherwise
> collide with the bar number. Consequently, I would like to have the
> default position shif
>>> how can I control the default horizontal position of rehearsal
>>> marks at the beginning of a line? As can be seen in the attached
>>> image, the rehearsal mark gets shifted up because it would
>>> otherwise collide with the bar number. Consequently, I would like
>>> to have the default po
>> https://sourceforge.net/p/testlilyissues/issues/5621/
>
> I would have preferred to have it printed over an "imaginary bar
> line", see issue 1150.
>
> https://sourceforge.net/p/testlilyissues/issues/1150/
I don't object. Honestly, I don't care where it is positioned as long
it is not l
Folks,
the music engraving conference in Salzburg (January 17.-19.) aims to
present as much note engraving programs as possible. While some
companies send representatives (e.g., Dorico, Capella, Finale) – some
even with talks – we don't have something similar for LilyPond in the
main part of th
> [...] I'll let you know if I think of anything else.
Great suggestions, from you and all other contributors!
> I wish I could help a little more directly, but I'm in the middle of
> a few very busy weeks. I would like to be involved in some way next
> year.
Well, we need all posters approxima
> Now in LSR
> lsr.di.unimi.it/LSR/Item?u=1&id=1099
Thanks a lot! Is there something that should be changed in LilyPond
to make it simpler to achieve this result? If yes, please open an
issue.
Werner
> I think that the problem with the bracket I just described is a bug
> or a feature that should be enhanced...
Vertical alignment of cross-staff material is partially broken, yes,
from the very beginning. Search for
cross AND staff AND status:Accepted
in the issue tracker.
Werner
> pango-font.cc emits the warning with %0X, so that U+ number is in
> hex.
BTW, I've now slightly adjusted the warning message in git to make
LilyPond emit 'U+0092' instead of 'U+92' – the 'U+' notation should
return at least four uppercase hex digits.
Werner
> At this point, here's the complete all-in-one .ly template. [...]
It would be nice if you could format this to avoid line lengths longer
than 80 characters. As the non-HTML part of your e-mail shows, the
code becomes very hard to read otherwise.
Werner
>>> https://sourceforge.net/p/testlilyissues/issues/5621/
>>
>> I would have preferred to have it printed over an "imaginary bar
>> line", see issue 1150.
>>
>> https://sourceforge.net/p/testlilyissues/issues/1150/
>
> I don't object. Honestly, I don't care where it is positioned as
> long i
> \fill-line references the line-width property. By default it is set
> to #f which indicates the entire line.
>
>
> \version "2.18"
> \markup \fill-line { left center right }
> \markup \override #'(line-width . 100)
> \fill-line { left center right }
> \markup \override #'(line-wi
Folks,
some publishers repeat accidentals not only if a tie gets broken
between staves but also if it crosses a bar line:
|||
#o| #o
\/
Is there a property in LilyPond to automatically activate this?
Werner
>> some publishers repeat accidentals not only if a tie gets broken
>> between staves but also if it crosses a bar line:
>>
>> |||
>>#o| #o
>> \/
>>
>> Is there a property in LilyPond to automatically activate this?
>
> probably:
>
> {
> \override Accidental.aft
I have to typeset a snippet that is an excerpt of a longer piece, and
this snippet ends with a key change:
\relative c' {
\key d \major
d1
\key c \major
}
However, the staff stops right before the key change, see attached
image. What can I do to avoid that?
Werner
> \once \override Score.BreakAlignment #'break-align-orders =
> #(make-vector 3 '( staff-bar
> clef
> span-bar
> breathing-sign
> ...
> key
> time-signature)),
>
> To in
>> I think it is necessary to somehow keep the staff line alive – I
>> guess I can probably fake a solution by adding another bar with a
>> suppressed bar line that contains some invisible music. Not sure
>> yet whether this is sensible, and if yes, how to make the width of
>> this extra bar (alm
>> I have to typeset a snippet that is an excerpt of a longer piece,
>> and this snippet ends with a key change:
>>
>> \relative c' {
>> \key d \major
>> d1
>> \key c \major
>> }
>>
>> However, the staff stops right before the key change, see attached
>> image. What can I do to avo
From: David Kastrup
Subject: Re: key change at end of snippet
Date: Sat, 25 Jan 2020 09:41:45 +0100
> \relative c' {
> \key d \major
> d1
> \key c \major
> \grace s256
> }
Thanks for the suggestion! I'm now trying Thomas's route.
Werner
> thank you for your positive reaction. There are 3 files¹:
>
> - a cheat sheet: https://joramberger.de/files/lilypond_sheet_2.18_en.pdf
> - “visual index”: https://joramberger.de/files/lilypond_visualindex.pdf
> - spacing overview: https://joramberger.de/files/LilypondSpacing.pdf
All of them ar
> I had gonville- and emmentaler-fonts in two directories:
> ~/fonts and ~/.local/share/fonts
> (I probably may have put them in there for some tests long time
> ago...) Deleting all of them there solved the issue.
>
> Anyway, I think LilyPond should be able to always pick emmentaler as
> defau
> In order to avoid this problem of sequence, I've first removed
> Script_column_engraver and appended it again /after/
> New_fingering_engraver. Looks funny but actually solves the
> problem.
>
> [...]
> \remove "Script_column_engraver"
> \consists "New_fingering_engraver" % *before* Script
>> Or maybe there is a bug somewhere? I think not having to think
>> about the order would be quite beneficial.
>
> I totally agree there, but the New_fingering_engraver has been
> designed that way and it's complicated enough. It'd be great of
> course if someone had a good idea how to get ri
> The reason for the not minimal example is because each staff has its
> own timing. [...]
Well, the problem at hand is not related to polymetric notation at
all, AFAICS; you can use standard stuff also to demonstrate the
problem...
Werner
> [...] This is the snippet! I know that it would do a lot for people
> like me, maybe it should be included in the section about barlines?
Mhmm, this is very special, and LilyPond's documentation is already
more than 2000 pages...
I rather suggest that you contribute a well-documented snippet
> The lilypond port for MacPorts (i.e. the stable version) doesn’t
> have a mactex variant like lilypond-devel and thus will end up
> installing several the MacPorts texlive packages which are redundant
> on systems which already have MacTex installed. Should I be
> reporting this to the MacPorts
>> I never saw any music engraver who uses it.
>
> and most of my piano scores of publishing houses do it like this. I
> have examples here by Schott and Henle.
I think this dispute deserves an issue in our tracker. Obviously,
there are two engraving schools, an older one to which Paolo refer
Hello Emre,
> [...] Turkish Folk Music has its own flat and sharps.
>
> How can I add this fonts/graphs to lilypond system
This should be rather easy, I think – however, some information is
missing.
* Is it correct that the 'Dort' sharp doesn't have number 4 assigned
to it?
* In the scores
> A combination of makam.ly and this definitions.ily should be easy to
> do. But as Werner said, having them in the Emmentaler font (one way
> or the other) would be better.
Well, here's the question: Shall we add such glyphs at all? A
cautionary and a digit can easily be combined on the macro
> If a pattern like TFM.LY (Turkish Fol Music) is created, I think it
> will be a more rational and progressive solution like MAKAM.LY. I
> think the use of numbers for every flat and sharp in the work will
> make things more difficult.
I don't understand the last sentence. Please elaborate.
[Carl, could you somehow improve the layout of your responses? If I
view the plain text version of your e-mails, it's completely
impossible to differentiate between quoted material and your reply.
But even in the HTML version I have such difficulties...
What about using the classic '>' delim
> Unfortunately, as is shown in the thread that Aaron refers to in his
> excellent response, Outlook for Mac does not support setting the
> indent character; the only thing we have available is indentation.
>
> After all, why would anybody want to do anything other than
> top-posting? (
Then wh
> I just discovered that the “style” tag created inside svg output
> uses the wrong syntax, [...]
>
> A trivial one-line patch to fix this (based on git master): [...]
Thanks.
> Wanting to submit this patch, I've looked at the LilyPond
> Contributor's guide¹, and frankly, I'm amazed by the heig
> In any case, I'm subscribed so I'll cross-post and CC James so
> that the patch (which looks correct to me) is not lost.
I've just applied it to staging.
Werner
>> The "," trigger the magic. However, I do not find the document about it.
>> Maybe I am in a wrong way.
>
> In
> http://lilypond.org/doc/v2.20/Documentation/notation/fonts#single-entry-fonts
> there's:
> "font-name can be described using a comma-separated list of ‘fonts’
> and a white-space sep
> \caps does not work with non ASCII characters:
> \version "2.19.84"
> \markup { \caps "Blée" }
> In this example, the 3rd character "é" is not converted to É.
> Kind regards,
Irrespective of the problem, the character 'é' is *not* part of ASCII.
The ASCII character is quite an old 7bit characte
>> > \caps does not work with non ASCII characters:
>>
>> Irrespective of the problem, the character 'é' is *not* part of
>> ASCII. The ASCII character is quite an old 7bit character set,
>> approximately what we have today in Unicode at positions U+ to
>> U+007F.
>
> yes, this is why I wrote
> On this perennial topic, it would be great if this function could be
> in baseline lilypond. It's in countless scores, and I know people
> want it.
Assuming that your problem can't be handled in current lilypond I'm
rather sure that a merge request prepared by you will go into the git
reposit
> I’m trying to build LilyPond 2.21.3 locally, both on Debian 9 and
> Mac OS X 10.14.6 (Mojave). On the latter, I installed Apple’s
> XCode, the needed tools in /opt with MacPorts, and the needed fonts
> in /opt/local/share/fonts/urw-core35-fonts.
You might apply
https://github.com/macports/m
> In fact I did the ‘git clone’ afresh, moving aside previous
> attempts. Thus the contents of ‘build’ on both OSes is the result of
> the commands I showed, up to '../configure'.
>
> That’s why I don’t get what happens…
For me, using an up-to-date MacPorts system, compilation of LilyPond
from
>> Seems to me like kind of a chicken-and-egg problem, though. In
>> order to build lilypond I need to read INSTALL.txt, but in order to
>> read INSTALL.txt, I need to build lilypond first... I ended up
>> googling for the file on the website and following the steps from
>> there instead.
>
> Wh
Look at this example
\relative c' {
\clef "alto" d'2 \tweak positions #'(8 . 4) ~
\clef "treble" d2
}
The `\tweak positions` doesn't work – which is kind-of expected.
However, for this very situation it would be nice if I could change
the start and end position of the slur manually.
> Look at this example
>
>
> \relative c' {
> \clef "alto" d'2 \tweak positions #'(8 . 4) ~
> \clef "treble" d2
> }
>
> The `\tweak positions` doesn't work – which is kind-of expected.
> However, for this very situation it would be nice if I could change
> the start and end position
> I see at least three options:
>
> - The tie should be sloped like a slur.
If you really have to do that (for whatever reason), this is the
solution to go IMHO.
> - The tie should be split into a two halves (possibly
> dotted/dashed), each half attached to the terminal notes but
> individua
> o "incorrect" has a tie winding its way from one vertical position
> to another, in the process wrapping around the new clef sign.
Thanks for the info! I just want to mention that in complex piano
music even the 'incorrect' solution has to be used from time to time.
Note that the problem to b
> I don't find that Tie supports 'positions. Strange.
Seeing Gould's advice it's not so surprising. On the other hand, I'm
actually in favor of adding it, for very special situations.
> You could do this with \shape used as a tweak. Roughly:
>
> \relative c' {
> \clef "alto" d'2 \shape #'
> you could translate the control-points _iff_ left/right-bound's
> staff-positions are not equal.
Thanks a lot for the code! It's something to have in mind if it
becomes *really* necessary.
Werner
Consider the following chord:
{ }
I would like to parenthesize the lower two notes of the chord. There
should be a single parenthesis to the left and right (contrary to what
`\parenthesize` does).
Looking up the LSR I couldn't find a generic solution that isn't an
ad-hoc trickery, thus I'm
>> I would like to parenthesize the lower two notes of the chord.
>> There should be a single parenthesis to the left and right
>> (contrary to what `\parenthesize` does).
>
> Does something like this help?
Yes, very nice!
> (The logic here is for the engraver to generate a single
> Parenthese
> Here is a version that still relies on scaling, but does so in a
> hopefully more visually appealing manner. Note that I am using the
> square root of the y-scaling factor for the x-scaling factor, as 1:1
> scaling made the parens too fat in my opinion.
Brilliant, thanks a lot! Please contri
> ParenthesesItem.stencils relies on
> "accidentals.leftparen"/"accidentals.rightparen". The size is
> usually done via ParenthesesItem.fontsize. I often find this not
> convincing, especially for huge Parens. Why not build the stencils
> using (improved) parenthesize-stencil? Including sort
Folks,
look at this example:
\paper {
line-width = 50\mm
}
{ c'4 cis' \bar "" \break
cis' c' }
Is there a possibility to automatically get a sharp accidental for the
third quarter note? I could neither find a hint in the manual nor in
the regression tests...
Werner
> If you need it automatically, I'm not sure if \accidentalStyle
> "neo-modern" repeats the accidental after a break.
Thanks for the idea, but no, it doesn't. As far as I can see, broken
bars aren't covered at all by the available accidental rules.
Werner
> That's a pity, I guess, but seeing that you're manually putting a
> mid-bar break, it makes sense to manually mark the needed accidental
> as well.
For my use case I really would like to have automatic behaviour. The
example sent to the list was just for demonstration purposes; in
reality I'm
>> Is there a possibility to automatically get a sharp accidental for
>> the third quarter note? I could neither find a hint in the manual
>> nor in the regression tests...
>
> Accident rules are implemented before line-breaking. If they were
> to take line-breaking into account, they'd need t
Folks,
I wonder whether there is a possibility to have a working equivalent
to
oo = \once\override
so that I can say
\oo foo.bar = #'baz .
It should work with LilyPond 2.18, BTW.
A quick search in the internet didn't bring something relevant. Help
would be much appreciated.
We
>> I wonder whether there is a possibility to have a working equivalent
>> to
>>
>> oo = \once\override
>>
>> so that I can say
>>
>> \oo foo.bar = #'baz .
>
> The best you can aim for is
>
> \oo foo.bar #'baz
This would be just fine. The thing is to replace `\once\override`
with somethi
> Like this, I would imagine:
>
>
> \version "2.18.2"
>
> oo =
> #(define-music-function
> (parser location grob-path value)
> (list? scheme?)
> #{ \once \override $grob-path = #value #})
Great, thanks!
Werner
> I side step the whole thing by having dynamic expanable macros in
> the text editor.
But this gives overlong lines, which I want to avoid for snippets
taken from the LSR and being part of the NR.
> And why use 2.18?
Because right now LSR is still using this version.
Werner
> oo = #(define-music-function (parser location prop value)
>(symbol-list? scheme?)
> #{ \once \override #prop = #value #})
>
> should likely work fine in 2.18.
Thanks! Aaron provided this version
oo = #(define-music-function (parser location prop value)
(list? sche
>> Because right now LSR is still using this version.
>
> Then that means we have to use that oo code in the NR? I am not sure
> I follow. I'd rather not please.
Right now I'm checking the NR for bad typography in the PDF version,
which usually means overlong lines. A lot of snippets are directly
>> However, saying
>>
>> \oo VeryLong.Grob.PropertyToBeChanged = foo
>>
>> for this (and only this) snippet is just fine.
>
> I don't think that it makes sense for snippets to introduce
> convenience shorthands unless the snippet in itself tries is about
> showcasing the shorthand. It detracts
>> Well, we have to make a compromise. The PDF document has a small line
>> width, and you can't scroll horizontally...
>>
>> Theoretically, the snippet could be printed with a smaller font size,
>> but this doesn't look very pretty IMHO. I consider the `\oo`
>> shorthand both innocuous and sim
>> Well, we have to make a compromise. The PDF document has a small
>> line width, and you can't scroll horizontally...
>
> Then you just have to wrap the line.
I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think
that wrapping is suboptimal and reduces legibility I hope you ha
> No. I'm against it. Introducing abbreviations into examples is a
> slippery slope and sets a bad precedent. In my scores I use \t for
> \tuplet, but I would never inflict that on any public example, even
> to save space. Wrapped lines are not a visual or semantic issue to
> me at least. Ple
> Maybe
>
> \void \displayLilyMusic
> \once
> \propertyTweak color #red
> \propertyTweak font-size #3
> \propertyTweak direction #UP Voice.Slur
>
> helps?
It does, thanks a lot! I didn't have this function on my radar, and
it isn't documented in the NR at all.
Attached a version using \proper
>> BTW, would it be possible to enhance `\propertyTweak` to write
>>
>> \propertyTweak fret-diagram-details.dot-color #'white
>> FretBoard
>>
>> as
>>
>> \propertyTweak dot-color #'white
>> FretBoard.fret-diagram-details ?
>
> Have you even tried?
Only
> \propertyTweak finger-code #'below-string
> FretBoard.fret-diagram-details
>
> is completely indistinguishable from
>
> \propertyTweak fret-diagram-details.finger-code #'below-string
> FretBoard
>
> So any commands stacked before this last \propertyTweak command have
> no way of knowing
>> Is there an easy way to have a slur enclosed by parentheses or
>> brackets? Some urtext editions use parenthesized slurs to indicate
>> editorial additions.
>
> \parenthesize does not currently handle spanners, so you would need to
> do some manual work.
>
> Consider: [...]
Here is a slightl
> I would like to request an implementation for text emphasis points
> native to East Asian scripts.
Please give an example how this is used. And with “example” I mean a
real-word example like existing scores.
Note also that LilyPond is *not* suited for large textual works.
Support for text is
> Yes, but I can exactly see that one of the few places
> Japanese/Chinese emphasis dots may be used is in lyrics, which I
> guess is the OP's intent.
Also having a (minor) Sinology background, I've never seen emphasis
dots in scores from Taiwan, including music using the jiǎnpǔ notation.
I guess
> The new \text-emphasis markup command mostly maps to the CSS style
> of the same name but does not have full feature parity. Of note,
> the markup command will apply the emphasis mark to any character,
> whereas the CSS standard says to omit marks for certain character
> classes (Z* and P*, in
> Does that idea gazump my offer to put it in OLL? I'd really like to
> see it there.
LSR and OLL are certainly not exclusive :-) I know that your code fits
well to the former, but I have no idea about the latter.
Werner
>>> * The _soft_ pedal (left, una corda) does indeed have a rough
>>>equivalent on many organs, namely the "Schweller":
>>>https://en.wikipedia.org/wiki/Swell_box
There is another one: The most natural damper for an organ is the main
entrance door of a church...
Werner
> What is the current state of the art with musicxml export? Any work
> being done on that?
I think the best stuff currently avaible is what Jacques is working on
in the (external) `libmusicxml` git repository (in the `lilypond`
branch).
Werner
> I disagree with the approach the NR demonstrates. [...]
Could you submit a patch that improves that?
Werner
>> \reshape ?
>
> Dude… nice work. =)
Care to submit a MR?
Werner
> Where is \unfoldRepeats in the NR?
Its usage is described in section 3.5.6, “Using repeats with MIDI” –
it's also in the index...
Werner
> Ah. It's described in A.19 Available Music Functions. Hard to find
> because not indexed.
Really? In my locally generated PDF of the NR the entry in the
appendix *is* indexed.
Werner
>> I was engraving a piece of chant in modern notation recently, and
>> discovered that none of the custodes will draw a ledger for middle
>> C (C4) or A5, notes beyond the 5-line staff. These notes do occur
>> in chant and polyphony. [...]
>
> Perhaps this: [...]
>
> The above hack does nothin
Hello Jacques,
> There have been very interesting discussions about all this at the
> Salzburg conference last January, which lead me to dream of things
> being done another way in an ideal world: [...]
>
> - switch to another, easier to read and write extension language.
> Someone suggested
> I've set up two PDFs for comparing the original and my current
> working draft design (the triple flat missing in the original
> design, though). All existing accidentals containing flats both on
> and between stave-lines in all design sizes. In my printout, the
> opening-up of counters does n
Folks,
is it possible to attach a markup to a time signature?
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
201 - 300 of 1420 matches
Mail list logo
