absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
https://codereview.appspot.com/235010043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/235010043/diff/1/ly/music-functions-init.ly#newcode36
ly/music-functions-init.ly:36: ((integer?) ly:music?)
Why use a number here instead of a pitch?
Just \absolute could be \absolute c, and I see no particular problem
with having
\absolute f { c d e f } be the same as
\absolute { f g a bes }. If you find that too cute, one can just
document the cases with note name c.
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 06:28:43, dak wrote:
https://codereview.appspot.com/235010043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/235010043/diff/1/ly/music-functions-init.ly#newcode36
ly/music-functions-init.ly:36: ((integer?) ly:music?)
Why use a number here instead of a pitch?
Just \absolute could be \absolute c, and I see no particular problem
with having
\absolute f { c d e f } be the same as
\absolute { f g a bes }. If you find that too cute, one can just
document the
cases with note name c.
Just \absolute could be \absolute c, ...
I was not proposing to use c, as reference, that would be weird.
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
Nice! However, I second David's concern: Please use \absolute pitch instead of \absolute number https://codereview.appspot.com/235010043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is GridLY the future?
Janek Warchoł wrote Sunday, May 03, 2015 12:53 AM The behaviour that discouraged me from working on LilyPond for some time was not obviously unacceptable (i.e. it wasn't some ad hominem attack, nor anything else unanimously condemned by others). Rather, it was the general attitude of some people who sometimes seem to oppose changes only because they personally don't like them (or think they're not important), without even suggesting reasonable alternatives. Hi Janek I think quite a high proportion of the LP developer community have gone through this at some stage, often more than once ;-) It's hard when others oppose one's cherished opinions - I know from experience! But that's how open source works - the community is judge and jury. Often it seems that just one individual is opposing you, rather than the community, but that's often because silence is the way of indicating satisfaction with the way the discussion or indeed the proposal is going. We don't want the list flooded with +1's. Anyway, many of us have returned (in my personal case more understanding and wiser, I hope) so welcome back! We missed you! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
I'm in favour of a change like this, but I'd prefer the syntax and options to parallel those of \relative. That is, an optional prefix pitch to indicate the starting octave, and taking the starting octave from the first contained note if the prefix is omitted. That would then become an attractive alternative to \relative. https://codereview.appspot.com/235010043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 08:20:03, Trevor Daniels wrote:
I'm in favour of a change like this, but I'd prefer
the syntax and options to parallel those of
\relative. That is, an optional prefix pitch to indicate
the starting octave, and taking the starting octave from
the first contained note if the prefix is omitted. That
would then become an attractive alternative to \relative.
It would seem that our proposals are on one page regarding \absolute c''
{ c ...
However, I _think_ that your comment would suggest \absolute f'' { f ...
to be the same
as \absolute { f'' ... whereas I suggested making \absolute f'' { f ...
the same as \absolute { bes'' ...
Now there _is_ a difference between \relative c and \relative f. With
what I guess from your proposal, \absolute c and \absolute f would be
the same. And so would be \absolute b.
Now I actually like the idea of using \absolute bes' for entering a
trumpet in audible pitch using an input scale of { c d e f g ... }.
That's a concept different from \transpose c' bes' { ... } or \transpose
c bes' which primarily suggest a connection between _printed_ pitch and
audible pitch (like \transposition does) rather than _input_ pitch and
printed pitch.
I do realize that \relative only ever touches the octave, and it seems
to make little sense to have \absolute f turn { c, d, e, f g a b c d e
f' ... } into one continous scale even though it would only touch the
octave (like relative) and allow using as few octave marks as possible
for a given tessitura. But while that would also be a consistent
possibility, I don't think having e be a higher pitch than f is going to
win us a lot of sympathies. I prefer the transposing interpretation.
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
Dan Eble d...@faithful.be writes:
On Apr 30, 2015, at 08:26 , David Kastrup d...@gnu.org wrote:
Dan Eble d...@faithful.be writes:
What if we defined \override Grob.property as addressing the nearest
enclosing context named “”, and aliased all contexts except
part/sub-voice to “”. (Maybe I’ll try that tonight and see what
happens.)
That sounds like a recipe for disaster in connection with implicit
context creation since an \override does _not_ create implicit contexts
_unless_ it is needed for the override to succeed.
So if you do things like
\new Staff { \voiceOne c d \oneVoice ...
then \oneVoice will no longer be able to cancel \voiceOne (with respect
to other voices) since \voiceOne will have registered at Staff level.
So a \new Voice { ... } will still be under the influence of \voiceOne.
Thanks to both of you for your feedback. These are my current
thoughts on \partcombine.
Adding a wrapper context will have undesirable effects.
The question is what requirements or mechanisms we could employ in order
to remove the undesirable effects.
For example, it could be possible to define a special translator for
subcontexts that diverts (all? all but specified?) overrides to the
parent context. Or generally let Bottom overrides register at the
topmost Bottom.
If a wrapper context would be a good tool except for undesirable
effects, addressing those seems like a good idea, probably not just for
this application.
I think I will experiment with a smaller step. I will try to make
part-combine-iterator route events using one list of outlet-change
instructions per part instead of a single split-list that ties the two
parts together. The outlet-change instructions would still be
separate from the music as the split-list is now. Turning the
split-list into per-part lists would be done in scheme, thereby
lowering the bar for experimentation and future improvements.
The part combiner is nowhere near where I consider it a smooth and
elegant tool in the box. There is a lot of room for experimentation but
also frustration and dead ends. Most current ways (or extensions) for
adapting its behavior to particular tasks are quite dissatisfactory all
with regard to the actions required by the user, with regard to the
mechanisms employed for implementing it, and somewhat related, with the
consistency and predictability of the results.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 16:42:02, Trevor Daniels wrote:
Yes, in Keith's and my model \relative sets a starting pitch,
\absolute would
set a starting octave only, and pitches thereafter are relative to the
octave of
the previous note.
That's not really absolute. It's a different mode of relative. I
very much doubt that this was Keith's proposal unless he corroborates
that. And then I'll suspect someone is impersonating him.
So the input notes are always in a clearly defined octave.
Perhaps a better name for this mode of entry would be \relativeOctave.
This would be as complex to implement as the normal \relative. I have
my reservations about how useful people would find this in practice.
Now I actually like the idea of using \absolute bes' for entering a
trumpet in
audible pitch using an input scale of { c d e f g ... }. That's a
concept
different from \transpose c' bes' { ... } or \transpose c bes' which
primarily
suggest a connection between _printed_ pitch and audible pitch (like
\transposition does) rather than _input_ pitch and printed pitch.
A nice idea (your original suggestion was too cute indeed to register
as meaning
this to my old brain ;) But it does rather muddy the concept of an
absolute
pitch, which is enshrined in 10 years of manuals.
Well, the whole point of giving \absolute an argument was to modify the
interpretation of absolute and thus is all about muddying it. This is
more about choosing the right balance between mud and convenience.
I find it awkward when \absolute c'' and \absolute g'' mean exactly the
same thing. But it's not like I could not live with it. But I still
would recommend just using c to keep one's options for possible later
changes. And not have too much choice without associated meaningful
difference.
I do realize that \relative only ever touches the octave, and it
seems to make
little sense to have \absolute f turn { c, d, e, f g a b c d e f'
... } into
one
continous scale even though it would only touch the octave (like
relative) and
allow using as few octave marks as possible for a given tessitura.
No, a continuous scale would be \relativeOctave { c, d e f g a b c' d
e f ... }.
The c' resets the octave. This doesn't work so well for a melody
oscillating a
tone or two above and below a c, of course, but it does avoid multiple
''' and
,,,.
Again: I don't think that this was Keith's proposal. And I am pretty
sure that none of my suggestions was Keith's proposal either: I just
angle for something useful to do with \absolute f.
I wouldn't oppose it. Indeed, the two possibilities could exist
together,
depending on the presence or absence of a prefix pitch. \absolute
bes' { ... }
transposes the input; \absolute { ... } works like \relativeOctave.
Uh, we _have_ \absolute { ... } already. And it does not work anything
like the \relativeOctave you describe and it would be a really bad idea
to change that.
\absolute x' { ... } should be a variation or parameterization on what
\absolute { ... } does. Just like with \relative.
Just some thoughts. We need some other views I think.
Well yeah. This is more or less in brainstorming phase. I think Keith
has a point that people generally don't cherish using \transpose just
for making octave entry easier. More often than not, it is used in the
context of some actually transposing instrument.
Maybe making \absolute transpose anything but octaves makes it scary
again. But if we only document it in relation to c, nobody needs to
know.
This indeed warrants some more opinions. Anybody want to ask on the
user list?
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Improving the Contributors Guide and LilyDev
Hello dev list, Below are some notes I made as I worked with the contributor’s guide and LilyDev in recent months. This started with minor things and grew from there. They represent my view as a novice who is basically learning git and the command line as I go. I found the learning curve pretty steep so even little things that make things easier would help. I was planning on preparing patches for some of these items when I can get to it, others are suggestions and possible topics for discussion. Janek’s interest in working on this inspired me to go ahead and type it up. -Paul A. Suggestions for LilyDev3: Make nano the default editor for git, git-cl, and anywhere else needed. This might be the simplest single thing that would improve the learning curve. Those who like another more advanced editor like vim will likely know how to set it as their default. (And/or in the CG walk the reader through the steps to change the editor settings.) The indicator of the current git branch (in the command line prompt) is not set up in the .bashrc file as it says it is in CG. This should already be set up. See CG 3.2.1 Configuring Git, where it says: Finally, and in some ways most importantly, let’s make sure that we know what branch we’re on. If you’re not using LilyDev, add this to your ‘~/.bashrc’: export PS1=\u@\h \w\$(__git_ps1)$ Add to LilyDev a text editor that has code highlighting (one that's simpler than emacs). For example LilyDev2 had geany and gedit but LilyDev3 doesn't. (Or at least suggest some as recommended optional installs.) Automatic formatting/indenting of C++ files currently doesn't work out of the box” and there’s no easy way to manually get it to work. Artistic Style 2.02 is required for LilyPond’s fixcc.py but LilyDev3 has 2.01, which is the version provided by Debian and the only version available through apt-get. Version 2.02 is no longer available from SourceForge. Possible solution: make fixcc.py work with Artistic Style 2.01 (Federico wrote that LilyDev will provide the default Debian version of Artistic Style so that rules out upgrading it to 2.02.) (Another possible solution: does LilyPond need its own formatting style or would the GNU one work fine and avoid this maintenance/overhead?) B. CG Notes CG 2.1 Installing LilyDev in VirtualBox Just for extra clarity, change: Click the browse icon and locate the LilyDev disk image… To: Click the browse icon and locate the LilyDev disk image file (the .iso file) that you downloaded… CG 3.3.4 Making Patches git format-patch origin doesn't work if you type it in literally, but gives ambiguous argument 'origin' message. Change it to git format-patch origin/master which I assume is the most common case. CG 3.3.4 duplication typo under git-cl configuration: 2. Move into the top source directory and then configure git cl with the following commands: 3. Move into the top source directory and then configure git cl with the following commands: CG 3.3.4 I think git-cl install should go elsewhere, where setup is covered, especially since it's already installed on LilyDev. CG 3.3.4 git-cl configuration add how to set the EDITOR variable for git cl, namely: export EDITOR=/usr/bin/nano Somewhere document how to access ~/.bashrc ( such as nano ~/.bashrc ) to see what environment variables are set, etc. In general avoid having sections that basically repeat each other in different ways, for example, consider merging: 1. Git for the impatient (3.2.2) and Basic Git procedures (3.3) 2. Compiling with LilyDev (2.3) and Compiling (4.x) C. A Few General thoughts FWIW: Since those working on the documentation, website, or even source code may not be programmers but they still have to learn how to use git etc. keep non-programmers in mind as a primary audience for the CG. For example: Assume the reader is using LilyDev. Those that aren't using LilyDev will have more experience and need less from the CG, so better to pitch things to those who need the most help. The reader may need some help with certain command line tasks. Go ahead and provide the literal command to type in when it is easy to do so, rather than assume the reader knows it already or should go look it up somewhere else. (For example how to change the default editor.) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
On May 3, 2015, at 16:42 , David Kastrup d...@gnu.org wrote: Dan Eble d...@faithful.be writes: Adding a wrapper context will have undesirable effects. The question is what requirements or mechanisms we could employ in order to remove the undesirable effects. For example, it could be possible to define a special translator for subcontexts that diverts (all? all but specified?) overrides to the parent context. That seems like it would help. Or generally let Bottom overrides register at the topmost Bottom”. That would still require mentioning Bottom in the override, right? If so, that’s ugly. (Otherwise, it’s not so bad.) If a wrapper context would be a good tool except for undesirable effects, addressing those seems like a good idea, probably not just for this application. I can’t fully support that statement yet. The handling of multi-measure rests is still an area of uncertainty. My wrapper-context experiment did not show any mmrest problems in the regression tests, but I wonder about the coverage; but I intend to let that rest for now while I try the part-specific split-list idea. The part combiner is nowhere near where I consider it a smooth and elegant tool in the box. There is a lot of room for experimentation but also frustration and dead ends. No kidding. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 20:04:28, dak wrote: There is no such thing as '' or s'' as a recognizable element in LilyPond's syntax and there is not even a tangible representation of it in Scheme. I don't think that such a feature warrants both messing with the parser as well as introducing new Scheme entities. So at least for me, those proposals are non-starters. Good points. I was only thinking about what might be best from a user's perspective and hadn't considered feasibility. I agree that this wouldn't warrant such invasive changes. (Although, it's too bad this won't work since only the octave is relevant in Keith's patches... I haven't thought through the other proposals on the table.) https://codereview.appspot.com/235010043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improving the Contributors Guide and LilyDev
Two notes: Paul Morris p...@paulwmorris.com writes: CG 3.3.4 Making Patches git format-patch origin doesn't work if you type it in literally, but gives ambiguous argument 'origin' message. Shouldn't happen unless you managed to create either a local branch named origin or a file with that name in the current directory. CG 3.3.4 git-cl configuration add how to set the EDITOR variable for git cl, namely: export EDITOR=/usr/bin/nano Nano does not offer point-and-click in connection with LilyPond I think. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 20:25:22, dak wrote: Again: I don't think that this was Keith's proposal. And I am pretty sure that none of my suggestions was Keith's proposal either: I just angle for something useful to do with \absolute f. It wasn't Keith's proposal, you're right, I rather ran on ahead. Keith's suggestion was to add a simple single octave offset. Maybe just this is the right thing to do after all. It's easy, effective, simple, non-scary, and maximises benefit/effort. I'm not too keen on creating Easter eggs - I've spent a fair fraction of the last several years documenting things previously hidden so ordinary users could benefit too. https://codereview.appspot.com/235010043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 20:25:22, dak wrote: I still would recommend just using c to keep one's options for possible later changes. And not have too much choice without associated meaningful difference. This is wise. https://codereview.appspot.com/235010043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improving the Contributors Guide and LilyDev
Am 04.05.2015 um 00:15 schrieb David Kastrup: CG 3.3.4 git-cl configuration add how to set the EDITOR variable for git cl, namely: export EDITOR=/usr/bin/nano Nano does not offer point-and-click in connection with LilyPond I think. I don't think so either. But I don't see why that should matter here. Without setting EDITOR to something different, e.g. nano, the user will be facing vi during the submission process. And for most of the new people this is really frightening. So this is actually important information. (Hm, I would have sworn that I had added that information - immediately after my first submission). Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
On 5/3/15 8:33 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 10/04/15 09:34, Werner LEMBERG wrote: So the question is whether Launchpad has a usable API, right? Joseph, do you know more?c Just to follow up on this, I exchanged a few messages on Reddit with Colin Watson (who's leading the git-support effort) following this announcement: http://blog.launchpad.net/general/git-code-hosting-beta Looks like right now, git hosting is available in beta version, but webooks (e.g. to trigger automated testing) are not yet. Colin's expectation was that these would arrive soon, but for obvious reasons he wasn't willing to provide a concrete ETA. In searching around on Savannah's page, I found InDefero http://www.indefero.net/ which claims to be an open-source lightweight copy of Google Code. Unfortunately, it doesn't appear that there are any publicly available hosting sites using it, so it may be somewhat challenging to test it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 20:25:22, dak wrote:
On 2015/05/03 16:42:02, Trevor Daniels wrote:
I find it awkward when \absolute c'' and \absolute g'' mean exactly
the same
thing. But it's not like I could not live with it. But I still would
recommend
just using c to keep one's options for possible later changes. And
not have too
much choice without associated meaningful difference.
The new patch (awkwardly) has \absolute c'' and \absolute g'' mean
exactly the same thing.
My reason for that was to present less of a surprise if someone used
\absolute g'' {g ...} wanting to start on G5, i.e., g''.
\absolute c' has no meaningful difference to \transpose c c' except
being shorter, and less scary. Making it incapable of 'transposing'
keeps it less scary.
This indeed warrants some more opinions. Anybody want to ask on the
user list?
A few times people brought up \transpose c c' {...} as a useful method
of music entry, but people went on to suggest other entry methods that
didn't seem to me to be any easier
https://lists.gnu.org/archive/html/lilypond-user/2003-10/msg00332.html
https://lists.gnu.org/archive/html/lilypond-user/2013-03/msg00494.html
In a thread complaining about \relative, I suggested the \absolute 3 {}
variant, also without much interest.
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 16:42:02, Trevor Daniels wrote:
a continuous scale would be \relativeOctave { c, d e f g a b c' d e f
... }.
The c' resets the octave. This doesn't work so well for a melody
oscillating a
tone or two above and below a c, of course, but it does avoid multiple
''' and
,,,.
This allows an entry method that is somewhere between \relative and
\absolute
I tried it a little, and find that I like it better than current
\relative, but not as much as
\transpose c c, {\clef bass c d e f g a b c' d' e' f' ... }
I always know if the next pitch I am typing is in the high- mid- or low
octave of an instruments' range, but somehow cannot remember the octave
of the previous pitch that I typed. (Well, I can remember the previous
note while entering a scale, but not in more complicated cases.)
I'm proposing \absolute c'' {} because the only complaint I hear about
absolute entry is the repeated ' characters, but I don't see anyone
using \transpose c c'' {} to simplify the typing.
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
Reviewers: dak, lemzwerg, Trevor Daniels, Dan Eble, pwm,
Message:
On 2015/05/03 08:20:03, Trevor Daniels wrote:
I'd prefer the syntax and options to parallel those of
\relative. That is, an optional prefix pitch to indicate
the starting octave, and taking the starting octave from
the first contained note if the prefix is omitted. That
would then become an attractive alternative to \relative.
I thought about this, but
1) \absolute { f'' g'' } is already documented to mean {f'' g''}
2) in contrast to \relative, which defines an order of the pitches
anyway (order of appearance in a depth-first search of the music
expression) and which needs a concept of a starting pitch so it had
might as well be the first pitch,
aa = \new Voice { \voiceOne r2 c''2}
bb = \new Voice { \voiceTwo c,4 e g c}
\new Staff \relative \aa \bb g4
a goal of \absolute was to allow re-ordering of contents without
changing the pitches.
Description:
absolute pitch entry: accept an offset octave; issue 4366
Please review this at https://codereview.appspot.com/235010043/
Affected files (+23, -5 lines):
A input/regression/relative.ly
M ly/music-functions-init.ly
Index: input/regression/relative.ly
diff --git a/input/regression/relative.ly b/input/regression/relative.ly
new file mode 100644
index
..a1dfed55d7a796b91b0f391c42eb4975115772fb
--- /dev/null
+++ b/input/regression/relative.ly
@@ -0,0 +1,12 @@
+\header {
+ texidoc = Notes are entered using absolute octaves,
+or octaves relative to the previous note.
+ }
+\version 2.19.20
+
+\new Staff {
+ \relative c'' { c4 g c e g1 }
+ \absolute c'' { c4 g, c e g1 }
+ \clef bass \absolute c { c4 g, c e g1 }
+ \absolute { c4 g, c e g1 }
+}
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index
cbba26a65256a366e3c2793cebb641e91d18266b..22e1a2dccb6417e6672bb9259d04224130946796
100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -32,12 +32,18 @@
%% TODO: using define-music-function in a .scm causes crash.
absolute =
-#(define-music-function (parser location music)
- (ly:music?)
- (_i Make @var{music} absolute. This does not actually change the
-music itself but rather hides it from surrounding @code{\\relative}
+#(define-music-function (parser location pitch music)
+ ((ly:pitch?) ly:music?)
+ (_i Make @var{music} absolute, optionally raised or lowered
+by the nubmer of octave marks on @var{pitch}. Wrapping as
+@samp{RelativeOctaveMusic} hides it from surrounding @code{\\relative}
commands.)
- (make-music 'RelativeOctaveMusic 'element music))
+ (let ((m (if pitch
+(ly:music-transpose
+music
+(ly:make-pitch (1+ (ly:pitch-octave pitch)) 0 0))
+music)))
+ (make-music 'RelativeOctaveMusic 'element m)))
acciaccatura =
#(def-grace-function startAcciaccaturaMusic stopAcciaccaturaMusic
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improving the Contributors Guide and LilyDev
On Mon, May 04, 2015 at 03:02:32AM +, Carl Sorensen wrote: A. Suggestions for LilyDev3: All of these suggestions would actually probably be for LilyDev4. I'm not sure that we will make another release of LilyDev3. But if we did, I'm still happy to host it. If somebody is available and interested in preparing lilydev4, I suggest splitting the list of improvements into lilydev4-stuff and CG-stuff. (And/or in the CG walk the reader through the steps to change the editor settings.) This is an immediately-accessible thing to do. Yes, although the editor settings can be done in advance in lilydev4. (I believe that /etc/skel/ is the place to look at, but I know that somebody already figured this out and it wasn't me) The CG could also have a section for turning a typical ubuntu installation into lilypond development-ready (a shorter name would be better), which gives details about this, setting PS1, etc. But ideally LilyDev4 should have as much as possible done in advance, so that interested contributors can jump into contributing. In general avoid having sections that basically repeat each other in different ways, for example, consider merging: 1. Git for the impatient (3.2.2) and Basic Git procedures (3.3) There are reasons (perhaps historical) for this duplication. 3.2.2 is supposed to be briefer than 3.3. The main reason is that when I wrote 3.2.2, I forgot that 3.3 existed. Either that, or I thought that 3.3 was too long. I forget which. Either way, I don't think we need both sections. 2. Compiling with LilyDev (2.3) and Compiling (4.x) 2.3 is about getting it set up with LilyDev. 4.x is about general work whether with or without LilyDev. We are much stronger about recommending the use of LilyDev than we were when the CG was originally written, so perhaps it's time to make a change here. I think it's worth keeping a section about compiling for non-lilydev, but perhaps something like Advanced unix compiling (again, bad name) would be better. Basically, make sure that 4.x is clearly about general work. (as an advanced Linux user, I would be annoyed if I had to wade through lots of hand-holding in a discussion about how to compile an open source project) We certainly want to make the CG accessible for new users/developers. But we also want to have the CG useful for old developers and those experienced with other software development environments. Perhaps we need to clarify these two different use cases, and separate them out more carefully in the CG. But IMO we need to avoid making the CG only useful for newbies. Yes. Thanks again for looking at this. Certainly improving the CG is an important part of the health of LilyPond. Absolutely! - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
I also favour
\absolute c'' { ... }
in Keith's original interpretation. However, I suggest to document
somewhere that only letter `c' is supported.
https://codereview.appspot.com/235010043/diff/60001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/235010043/diff/60001/ly/music-functions-init.ly#newcode38
ly/music-functions-init.ly:38: by the nubmer of octave marks on
@var{pitch}. Wrapping as
s/nubmer/number/
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improving the Contributors Guide and LilyDev
On 5/3/15 4:09 PM, Paul Morris p...@paulwmorris.com wrote: I think that it would be great to have you prepare patches for the CG. The CG is the least-reviewed manual in our set, so it's probably the easiest manual for which to get patches approved. A. Suggestions for LilyDev3: All of these suggestions would actually probably be for LilyDev4. I'm not sure that we will make another release of LilyDev3. But if we did, I'm still happy to host it. (And/or in the CG walk the reader through the steps to change the editor settings.) This is an immediately-accessible thing to do. The indicator of the current git branch (in the command line prompt) is not set up in the .bashrc file as it says it is in CG. This should already be set up. See CG 3.2.1 Configuring Git, where it says: Finally, and in some ways most importantly, let¹s make sure that we know what branch we¹re on. If you¹re not using LilyDev, add this to your Œ~/.bashrc¹: export PS1=\u@\h \w\$(__git_ps1)$ Personally, I'd love to see a patch for this in the CG (and it would be nice to have it in LilyDev out of the box). Add to LilyDev a text editor that has code highlighting (one that's simpler than emacs). For example LilyDev2 had geany and gedit but LilyDev3 doesn't. (Or at least suggest some as recommended optional installs.) vim has code highlighting, and it is simpler than emacs in my opinion. But I've been using it for 30 years, since I started with vi. A CG entry that would tell how to install geany and/or gedit would certainly be helpful. (Another possible solution: does LilyPond need its own formatting style or would the GNU one work fine and avoid this maintenance/overhead?) GNU's formatting style is less specific in the form of tabs/spaces, IIRC. We've had this discussion, and I believe it's a good idea to exclude tabs, and only use spaces in the source code. astyle isn't needed if you are careful with your editing and match the existing code. If you make a mistake, it will be pointed out in review, and it's simple to fix it. B. CG Notes Your notes on the CG are excellent in general. I hope you will prepare some patches! In general avoid having sections that basically repeat each other in different ways, for example, consider merging: 1. Git for the impatient (3.2.2) and Basic Git procedures (3.3) There are reasons (perhaps historical) for this duplication. 3.2.2 is supposed to be briefer than 3.3. 2. Compiling with LilyDev (2.3) and Compiling (4.x) 2.3 is about getting it set up with LilyDev. 4.x is about general work whether with or without LilyDev. We are much stronger about recommending the use of LilyDev than we were when the CG was originally written, so perhaps it's time to make a change here. C. A Few General thoughts FWIW: Since those working on the documentation, website, or even source code may not be programmers but they still have to learn how to use git etc. keep non-programmers in mind as a primary audience for the CG. For example: Assume the reader is using LilyDev. Those that aren't using LilyDev will have more experience and need less from the CG, so better to pitch things to those who need the most help. I'm not sure I agree with this. The CG is the only place in the manuals that we provide help for those who are not using LilyDev. And there are some quirks of LilyPond that need to be part of the docs in my opinion. I don't have a particular patch to comment on here, so I can only deal in generalities. But maybe we have a chapter that is something about Developing without LilyDev. We certainly want to make the CG accessible for new users/developers. But we also want to have the CG useful for old developers and those experienced with other software development environments. Perhaps we need to clarify these two different use cases, and separate them out more carefully in the CG. But IMO we need to avoid making the CG only useful for newbies. The CG has historically had a much less stringent editorial review process. Basically we said to developers If there's something you think should go in the CG, put it there. Perhaps it's time to be more selective, and see how we can tailor a short, accessible section of the CG for new users. And then we could leave the other stuff in chapters that are aimed at experienced developers. Thanks again for looking at this. Certainly improving the CG is an important part of the health of LilyPond. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1557: Migration from texi2html to texi2any
Le 02/05/2015 20:18, Jean-Charles Malahieude a écrit : What I've tried so far is: 4- replace any occurrence of @documentlanguage utf-8 by @documentlanguage UTF-8 and add it where needed Oops! should have read before sending: 4- @documentencoding UTF-8 Could anybody help? Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for May 6th 2015
Hello, Here is the current patch countdown list. The next countdown will be on May 6th. You can always view the most current countdown list here: http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaitingcolspec=Patch%20Owner%20ID%20Summarysort=patch PUSH: James Lowe: Patch: Fix lilypond-invoke-editor's temp dir http://code.google.com/p/lilypond/issues/detail?id=4359 Dan Eble: Patch: Set DynamicLineSpanner direction in \partcombine http://code.google.com/p/lilypond/issues/detail?id=4358 Carl Sorensen: Subdivision of beams is wrong http://code.google.com/p/lilypond/issues/detail?id=4355 Trevor Daniels: \compressFullBarRests and \skipBars need a health warning http://code.google.com/p/lilypond/issues/detail?id=4350 COUNTDOWN: Trevor Daniels: only full-measure-rests should be able to compress http://code.google.com/p/lilypond/issues/detail?id=3687 REVIEW: Keith OHara: zero-duration chords confuse repeat tremolo http://code.google.com/p/lilypond/issues/detail?id=4367 David Kastrup: Patch: Redesign listeners using templates http://code.google.com/p/lilypond/issues/detail?id=4357 Dan Eble: Patch: Part combiner: generate mark events in scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=4356 Phil Holmes: Partcombine documentation needs updating http://code.google.com/p/lilypond/issues/detail?id=4307 David Kastrup: Use \relative without explicit starting pitch in the docs http://code.google.com/p/lilypond/issues/detail?id=3229 James Lowe: Doc: NR section 3.5.x MIDI file creation tidy up http://code.google.com/p/lilypond/issues/detail?id=2877 Valentin Villenave: Attach lilypond source in pdf http://code.google.com/p/lilypond/issues/detail?id=2643 WAITING: Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures http://code.google.com/p/lilypond/issues/detail?id=3918 Mike Solomon: Patch: Prevents vertical axis groups with empty skylines http://code.google.com/p/lilypond/issues/detail?id=3156 Mike Solomon: Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. http://code.google.com/p/lilypond/issues/detail?id=3134 David Kastrup: Patch: Implement music functions in Scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=2716 Thank you, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
If people don't like numbers (I'm with you) are there any other feasible
ways to indicate an octave only? Maybe bare ''' and ,,,? Maybe with an
unpitched name?
\absolute '' { a b c }
\absolute s'' { a b c }
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partcombiner documentation (Issue 4307) (issue 233110043 by philehol...@googlemail.com)
Good point, Phil. Perhaps we should slightly amend the text too to cover this feature, as shown. Trevor https://codereview.appspot.com/233110043/diff/20001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): https://codereview.appspot.com/233110043/diff/20001/Documentation/notation/simultaneous.itely#newcode932 Documentation/notation/simultaneous.itely:932: rhythm as chords and separates notes more than a ninth apart into ... ninth apart or when the voices cross into separate ... https://codereview.appspot.com/233110043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix lilypond-invoke-editor's temp dir (issue 234900043 by truer...@gmail.com)
Patch counted down - please push to Staging branch. https://codereview.appspot.com/234900043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update NR font size section (Issue 3370) (issue 235920043 by philehol...@googlemail.com)
Reviewers: Trevor Daniels, J_lowe,
Message:
Please review
Description:
Update NR font size section (Issue 3370)
Please review this at https://codereview.appspot.com/235920043/
Affected files (+9, -0 lines):
M Documentation/notation/text.itely
Index: Documentation/notation/text.itely
diff --git a/Documentation/notation/text.itely
b/Documentation/notation/text.itely
index
ac5436b94b6fcde8e9119c01396a6e4aef43f745..221e2fdcfff717b4dc7dec71419debd61c82f037
100644
--- a/Documentation/notation/text.itely
+++ b/Documentation/notation/text.itely
@@ -573,6 +573,15 @@ b1^\markup { \abs-fontsize #8 da }
b1-\markup { \abs-fontsize #14 camera }
@end lilypond
+If the text includes spaces, then it is best to put it all inside quote
+marks, so that the size of each space is appropriate for the size of the
+other characters.
+
+@lilypond[quote,verbatim]
+\markup \fontsize #6 \bold { Sinfonia da camera }
+\markup \fontsize #6 \bold { Sinfonia da camera }
+@end lilypond
+
@cindex subscript
@cindex superscript
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
- Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: Werner LEMBERG w...@gnu.org; p...@gnu.org Cc: lilypond-devel@gnu.org Sent: Sunday, May 03, 2015 3:33 PM Subject: Re: Google Code shutting down On 10/04/15 09:34, Werner LEMBERG wrote: So the question is whether Launchpad has a usable API, right? Joseph, do you know more?c Just to follow up on this, I exchanged a few messages on Reddit with Colin Watson (who's leading the git-support effort) following this announcement: http://blog.launchpad.net/general/git-code-hosting-beta Looks like right now, git hosting is available in beta version, but webooks (e.g. to trigger automated testing) are not yet. Colin's expectation was that these would arrive soon, but for obvious reasons he wasn't willing to provide a concrete ETA. I'm going on the assumption that, with fully featured git support fully in place, Launchpad could host code, and handle both issue tracking and the review of merge requests (including automated testing); its issues allow the attachment of files (which ought to take care of Lilypond examples attached to issues, but I'd need to check that any file size limits meet Lilypond's issue requirements). However, I'd like to be sure I'm not missing any requirements, given Lilypond's rather particular needs. Any chance someone with a more detailed understanding of requirements than me could prepare a list of must have features for any new hosting service? Just something that I can run past launchpad folks on IRC or suchlike as a sanity-check that this really would be a workable solution. I'd be willing to start a draft requirements for issue handling document tomorrow, if no-one else is desperate. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partcombiner documentation (Issue 4307) (issue 233110043 by philehol...@googlemail.com)
Thanks for the comments.
https://codereview.appspot.com/233110043/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/233110043/diff/1/Documentation/notation/simultaneous.itely#newcode931
Documentation/notation/simultaneous.itely:931: @notation{a due} note,
and separates notes more than a ninth apart into
On 2015/05/02 17:34:32, Trevor Daniels wrote:
For the avoidance of doubt, perhaps insert here:
@notation{a due} note, combines notes less than a ninth apart with the
same
rhythm as chords, and separates ...
Otherwise, LGTM.
Done.
https://codereview.appspot.com/233110043/diff/1/Documentation/notation/simultaneous.itely#newcode937
Documentation/notation/simultaneous.itely:937: a second or more, setting
it to one splits notes of a third or more, and so one.
On 2015/05/03 05:19:13, Keith wrote:
Extra 'e' on and so on.
You might turn around the order of explanation so you don't have to
translate
between interval names and number of scale steps, but just let the
example show
it.
I decided to give examples of what value corresponded to what interval,
since the way it's been implemented actually seemed counterintuitive to
me and I had to check what was actually going on in my example. Given
this, I thought being explicit was best.
https://codereview.appspot.com/233110043/diff/1/Documentation/notation/simultaneous.itely#newcode941
Documentation/notation/simultaneous.itely:941: c4 d e f |
On 2015/05/03 05:19:13, Keith wrote:
Starting at a, will clarify what happens when the parts cross
Done.
https://codereview.appspot.com/233110043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google Code shutting down
On 10/04/15 09:34, Werner LEMBERG wrote: So the question is whether Launchpad has a usable API, right? Joseph, do you know more?c Just to follow up on this, I exchanged a few messages on Reddit with Colin Watson (who's leading the git-support effort) following this announcement: http://blog.launchpad.net/general/git-code-hosting-beta Looks like right now, git hosting is available in beta version, but webooks (e.g. to trigger automated testing) are not yet. Colin's expectation was that these would arrive soon, but for obvious reasons he wasn't willing to provide a concrete ETA. I'm going on the assumption that, with fully featured git support fully in place, Launchpad could host code, and handle both issue tracking and the review of merge requests (including automated testing); its issues allow the attachment of files (which ought to take care of Lilypond examples attached to issues, but I'd need to check that any file size limits meet Lilypond's issue requirements). However, I'd like to be sure I'm not missing any requirements, given Lilypond's rather particular needs. Any chance someone with a more detailed understanding of requirements than me could prepare a list of must have features for any new hosting service? Just something that I can run past launchpad folks on IRC or suchlike as a sanity-check that this really would be a workable solution. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update NR font size section (Issue 3370) (issue 235920043 by philehol...@googlemail.com)
LGTM Trevor https://codereview.appspot.com/235920043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Partcombiner documentation (Issue 4307) (issue 233110043 by philehol...@googlemail.com)
LGTM. Trevor https://codereview.appspot.com/233110043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 09:02:51, dak wrote:
However, I _think_ that your comment would suggest \absolute f'' { f
... to be
the same
as \absolute { f'' ...
Correct
whereas I suggested making \absolute f'' { f ... the same
as \absolute { bes'' ...
Now there _is_ a difference between \relative c and \relative f. With
what I
guess from your proposal, \absolute c and \absolute f would be the
same. And so
would be \absolute b.
Yes, in Keith's and my model \relative sets a starting pitch, \absolute
would set a starting octave only, and pitches thereafter are relative to
the octave of the previous note. So the input notes are always in a
clearly defined octave. Perhaps a better name for this mode of entry
would be \relativeOctave. I'll use this later to be clear what I mean.
Now I actually like the idea of using \absolute bes' for entering a
trumpet in
audible pitch using an input scale of { c d e f g ... }. That's a
concept
different from \transpose c' bes' { ... } or \transpose c bes' which
primarily
suggest a connection between _printed_ pitch and audible pitch (like
\transposition does) rather than _input_ pitch and printed pitch.
A nice idea (your original suggestion was too cute indeed to register as
meaning this to my old brain ;) But it does rather muddy the concept of
an absolute pitch, which is enshrined in 10 years of manuals.
I do realize that \relative only ever touches the octave, and it seems
to make
little sense to have \absolute f turn { c, d, e, f g a b c d e f' ...
} into one
continous scale even though it would only touch the octave (like
relative) and
allow using as few octave marks as possible for a given tessitura.
No, a continuous scale would be \relativeOctave { c, d e f g a b c' d e
f ... }. The c' resets the octave. This doesn't work so well for a
melody oscillating a tone or two above and below a c, of course, but it
does avoid multiple ''' and ,,,.
But while
that would also be a consistent possibility, I don't think having e be
a higher
pitch than f is going to win us a lot of sympathies.
No, e would never be higher than f in \relativeOctave.
I prefer the transposing interpretation.
I wouldn't oppose it. Indeed, the two possibilities could exist
together, depending on the presence or absence of a prefix pitch.
\absolute bes' { ... } transposes the input; \absolute { ... } works
like \relativeOctave.
Just some thoughts. We need some other views I think.
Trevor
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 13:23:15, Dan Eble wrote:
If people don't like numbers (I'm with you) are there any other
feasible ways to
indicate an octave only? Maybe bare ''' and ,,,? Maybe with an
unpitched name?
\absolute '' { a b c }
\absolute s'' { a b c }
I was thinking along the same lines. It's simpler for users if they can
indicate the (absolute) octave using ' and , in the way the always do.
It would be easy to see that the following would be the same:
\absolute '' { a b c }
\absolute s'' { a b c }
\absolute { a'' b'' c'' }
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
On Apr 30, 2015, at 08:26 , David Kastrup d...@gnu.org wrote:
Dan Eble d...@faithful.be writes:
What if we defined \override Grob.property as addressing the nearest
enclosing context named “”, and aliased all contexts except
part/sub-voice to “”. (Maybe I’ll try that tonight and see what
happens.)
That sounds like a recipe for disaster in connection with implicit
context creation since an \override does _not_ create implicit contexts
_unless_ it is needed for the override to succeed.
So if you do things like
\new Staff { \voiceOne c d \oneVoice ...
then \oneVoice will no longer be able to cancel \voiceOne (with respect
to other voices) since \voiceOne will have registered at Staff level.
So a \new Voice { ... } will still be under the influence of \voiceOne.
Thanks to both of you for your feedback. These are my current thoughts on
\partcombine.
Adding a wrapper context will have undesirable effects. I don't want to force
people have to specify a context where now they can just write \slurDashed, but
I still want to make the part-combine-iterator less of a nexus. Trying to turn
the input parts into segments of context-specific music as Keith suggested
would probably end in frustration.
I think I will experiment with a smaller step. I will try to make
part-combine-iterator route events using one list of outlet-change instructions
per part instead of a single split-list that ties the two parts together. The
outlet-change instructions would still be separate from the music as the
split-list is now. Turning the split-list into per-part lists would be done in
scheme, thereby lowering the bar for experimentation and future improvements.
Regards,
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On 2015/05/03 16:27:58, pwm wrote:
On 2015/05/03 13:23:15, Dan Eble wrote:
If people don't like numbers (I'm with you) are there any other
feasible ways
to
indicate an octave only? Maybe bare ''' and ,,,? Maybe with an
unpitched
name?
\absolute '' { a b c }
\absolute s'' { a b c }
I was thinking along the same lines. It's simpler for users if they
can
indicate the (absolute) octave using ' and , in the way the always do.
It would
be easy to see that the following would be the same:
\absolute '' { a b c }
\absolute s'' { a b c }
\absolute { a'' b'' c'' }
There is no such thing as '' or s'' as a recognizable element in
LilyPond's syntax and there is not even a tangible representation of it
in Scheme. I don't think that such a feature warrants both messing with
the parser as well as introducing new Scheme entities. So at least for
me, those proposals are non-starters.
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
