Re: Doc: NR improve example of \accepts (issue 44420043)
Reviewers: Keith,
Message:
Keith's additions. Thank you.
https://codereview.appspot.com/44420043/diff/1/Documentation/notation/changing-defaults.itely
File Documentation/notation/changing-defaults.itely (right):
https://codereview.appspot.com/44420043/diff/1/Documentation/notation/changing-defaults.itely#newcode1347
Documentation/notation/changing-defaults.itely:1347: from the list. For
example, it would not normally be desirable for
On 2013/12/21 04:50:56, Keith wrote:
For example, a square-braced staff group is not usually found within a
curved-braced staff with connecting staff bars, and a
@code{GrandStaff} does not
accept a @code{StaffGroup} inside it by default. If this were
required it can
be done:
\new GrandStaff \with {\accepts StaffGroup }
\new Staff { c''1 }
\new StaffGroup
\new Staff { g'1 }
\new Staff { e'1 }
\new Staff {c'1 }
Thank you. Done.
Description:
Doc: NR improve example of \accepts
Issue 3641
Improve example given in NR 5.1.7
Please review this at https://codereview.appspot.com/44420043/
Affected files (+11, -4 lines):
M Documentation/notation/changing-defaults.itely
Index: Documentation/notation/changing-defaults.itely
diff --git a/Documentation/notation/changing-defaults.itely
b/Documentation/notation/changing-defaults.itely
index
cb8edf2c033a272ccf7aff8124f6a4080e76e343..ce2780275842377784076ea50112e56648cff4bf
100644
--- a/Documentation/notation/changing-defaults.itely
+++ b/Documentation/notation/changing-defaults.itely
@@ -1361,15 +1361,22 @@ be done:
@lilypond[verbatim,quote]
\score {
- \new Staff {
-c' d' e' f'
-\chords { d1:m7 b1:min7.5- }
- }
+ \new GrandStaff
+\new StaffGroup
+ \new Staff { c'1 }
+ \new Staff { d'1 }
+
+\new Staff { \set Staff.instrumentName = last f'1 }
+
\layout {
\context {
\Staff
\accepts ChordNames
}
+\context {
+ \GrandStaff
+ \accepts StaffGroup
+}
}
}
@end lilypond
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)
On 2013/12/22 07:01:10, Keith wrote:
On Sat, 21 Dec 2013 00:23:05 -0800, mailto:d...@gnu.org wrote:
Keith comments:
The other limitation of \unfoldRepeats is that it fails to see
repeats
in
parallel expressions {\repeat volta 2 s1 } {c2 d2} while this
approach
using the iterators will see them and be able to expand them when
requested.
I think he is wrong about that. I don't see anything inherent in
this
code that would work differently here.
I meant the future of this approach, after there is the option to
unfold volta
repeats.
I was thinking that by doing the unfolding in the iterators
(as opposed to working on music expressions as \unfoldRepeats does)
But \unfoldRepeats does not do its actual unfolding work on music
expressions. If it did, it would wreak havoc with \relative mode. It
merely replaces the RepeatedMusic expression with an (still folded)
UnfoldedRepeatedMusic expression which is then actually expanded in its
respective iterator.
Which is exactly the same thing Devon's patch does, except that the
shortcircuit to the UnfoldedRepeatedMusic code path is taken without
changing the music, by factoring out the respective code for use by both
iterators.
It would not be easy, because there are nonsense cases like
{s1 \repeat volta 2 s1 } {c1~ c2 d2}
and probably some very similar things that actually make sense.
Things break down anyway as soon as we are talking about more than one
context.
https://codereview.appspot.com/40720060/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown – December 25th – 06:00 GMT
Hello *Countdown – December 25th – 06:00 GMT* * * * * * * * * * * 3730 http://code.google.com/p/lilypond/issues/detail?id=3730q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Devon Schudy push Patch: Cleanup and generalization: get rid of Audio_column. 3724 http://code.google.com/p/lilypond/issues/detail?id=3724q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Keith Ohara push Slowdown under Windows 3719 http://code.google.com/p/lilypond/issues/detail?id=3719q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska push Patch: CG: Add comment about git-cl editor 3745 http://code.google.com/p/lilypond/issues/detail?id=3745q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Devon Schudy countdown Patch: Tremolo cleanup. 3742 http://code.google.com/p/lilypond/issues/detail?id=3742q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement James Lowe countdown Patch: Web: What we wrote... Book about LP in Turkish 3740 http://code.google.com/p/lilypond/issues/detail?id=3740q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Devon Schudy countdown Update documentation for what's supported in MIDI 3735 http://code.google.com/p/lilypond/issues/detail?id=3735q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe countdown website: why removing lilypond distro package? 3732 http://code.google.com/p/lilypond/issues/detail?id=3732q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Urs Liska countdown Patch: Website: Rewrite Features page 3654 http://code.google.com/p/lilypond/issues/detail?id=3654q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe countdown NR 2.1.2: tell explicitly that addlyrics cannot be used with NullVoice 3641 http://code.google.com/p/lilypond/issues/detail?id=3641q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe countdown Example for \accepts in N.R.5.1.7 broke 3492 http://code.google.com/p/lilypond/issues/detail?id=3492q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe countdown Usage 4.2: options of .vimrc to enable syntax highlighting 2067 http://code.google.com/p/lilypond/issues/detail?id=2067q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup countdown Patch: Give \displayLilyMusic and \displayMusic optional port arguments. 3744
CG organization (Git)
I'm somewhat confused about the organization of the CG chapters about Git and patch review. First: 3.2.2 Git for the impatient and 3.3 Basic Git procedures share some information, and this in a somewhat confusing way. Is there a _short_ explanation what these two chapters are intended for? Second: 3.2. seems to be targeted at absolute beginners. So why does it explain the workflow with pushing to staging? Anybody who needs to read this chapter won't have commit access. I wanted to add my experiences from the review cycle to the CG, but now I'm confused and don't know _where_ to put them. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
Urs, you wrote Sunday, December 22, 2013 8:55 AM Subject: CG organization (Git) I'm somewhat confused about the organization of the CG chapters about Git and patch review. The CG has never been properly revised and reorganised, with many sections added without considering the effect on others. This was a deliberate policy to permit the easier addition of material, so ensuring it was at least captured in the manual. Maybe it's now time (during release 19) to begin this revision. In the meantime, follow the present policy and dump your offering in whichever place seems easiest or most appropriate to you. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
Am 22.12.2013 10:29, schrieb Trevor Daniels: Urs, you wrote Sunday, December 22, 2013 8:55 AM Subject: CG organization (Git) I'm somewhat confused about the organization of the CG chapters about Git and patch review. The CG has never been properly revised and reorganised, with many sections added without considering the effect on others. This was a deliberate policy to permit the easier addition of material, so ensuring it was at least captured in the manual. Maybe it's now time (during release 19) to begin this revision. In the meantime, follow the present policy and dump your offering in whichever place seems easiest or most appropriate to you. Trevor OK, I'll do so. But I'm still more confused because this contradicts After a good deal of thinking, here's how i think CG should be structured. More thinking and discussion than we had the previous 4 times we reorganized the CG? from a week ago. ?? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl editor
Would somebody please be so kind and push the attached patch.
I rebased on origin/master and ran ct-section source-code.
make doc gave an error, but this pointed to
fatal error: failed files: 60/lily-338514d2.ly
so I think I can ignore this?
Urs
Original-Nachricht
Betreff: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl
editor
Datum: Sun, 22 Dec 2013 08:20:56 +
Von: lilyp...@googlecode.com
An: lilyli...@googlemail.com
Updates:
Labels: -Patch-countdown Patch-push
Comment #6 on issue 3719 by pkx166h: Patch: CG: Add comment about git-cl
editor
http://code.google.com/p/lilypond/issues/detail?id=3719
Patch counted down - please push
--
You received this message because you are the owner of the issue.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Reply to this email to add a comment or make updates.
From 0dd769ee4ec5befa5497548fadfcd972fc7a1926 Mon Sep 17 00:00:00 2001
From: Urs Liska g...@ursliska.de
Date: Thu, 12 Dec 2013 12:06:39 +0100
Subject: [PATCH] Issue 3719: CG: Add comment about git-cl editor
git-cl fires either the editor specified by the
EDITOR environment variable or vi if EDITOR isn't defined.
Commit mentions this in the CG
---
Documentation/contributor/source-code.itexi |5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/contributor/source-code.itexi b/Documentation/contributor/source-code.itexi
index f44dd31..7869f44 100644
--- a/Documentation/contributor/source-code.itexi
+++ b/Documentation/contributor/source-code.itexi
@@ -1384,6 +1384,11 @@ can be used.
@end itemize
+First you will see a terminal editor where you can edit the
+message that will accompany your patch. @code{git-cl} will respect
+the @code{EDITOR} environment variable if defined, otherwise it
+will use @code{vi} as the default editor.
+
After prompting for your Google email address and password, the
patch set will be posted to Rietveld, and you will be given a URL
for your patch.
--
1.7.10.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl editor
Urs Liska u...@openlilylib.org writes:
Would somebody please be so kind and push the attached patch.
I rebased on origin/master and ran ct-section source-code.
make doc gave an error, but this pointed to
fatal error: failed files: 60/lily-338514d2.ly
so I think I can ignore this?
Actually, you can't ignore this. Take a look at
out/lybook-db/60/lily-338514d2.ly and identify which place in your docs
it comes from.
It's not part of the reviewed patch, obviously, but it would seem like
you managed to mess something up in your tree for a different reason.
I see that you used @code{vi} and @code{git-cl} rather than @command{vi}
and @command{git-cl}: any particular reason for that?
If not, I would lean towards fixing this up before pushing. Ok with
you?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl editor
Am 22.12.2013 10:54, schrieb David Kastrup:
Urs Liska u...@openlilylib.org writes:
Would somebody please be so kind and push the attached patch.
I rebased on origin/master and ran ct-section source-code.
make doc gave an error, but this pointed to
fatal error: failed files: 60/lily-338514d2.ly
so I think I can ignore this?
Actually, you can't ignore this. Take a look at
out/lybook-db/60/lily-338514d2.ly and identify which place in your docs
it comes from.
It's not part of the reviewed patch, obviously, but it would seem like
you managed to mess something up in your tree for a different reason.
Oh, it's a different issue.
That one was caused by running make doc from a not current build
directory (the snippet used newer functionality or syntax).
Now make doc ends with
###
make[4]: Entering directory
`/shared/git/3rdParty/lilypond-builds/current/input/regression/lilypond-book'
GNUmakefile:24: warning: overriding commands for target
`out-www/collated-files.list'
../../../make/lysdoc-rules.make:6: warning: ignoring old commands for
target `out-www/collated-files.list'
cd ./out-www
/shared/git/3rdParty/lilypond-builds/current/scripts/build/out/run-and-check
dblatex suffix-lyxml.xml suffix-lyxml.dblatex.log
Please check the logfile suffix-lyxml.dblatex.log for errors
make[4]: *** [out-www/suffix-lyxml.pdf] Error 1
make[4]: Leaving directory
`/shared/git/3rdParty/lilypond-builds/current/input/regression/lilypond-book'
make[3]: *** [WWW-1] Error 2
make[3]: Leaving directory
`/shared/git/3rdParty/lilypond-builds/current/input/regression'
make[2]: *** [WWW-1] Error 2
make[2]: Leaving directory
`/shared/git/3rdParty/lilypond-builds/current/input'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/shared/git/3rdParty/lilypond-builds/current'
make: *** [doc-stage-1] Fehler 2
###
I don't see that logfile in input/regression/lilypond-book (nor a pdf).
I'm puzzled ...
I see that you used @code{vi} and @code{git-cl} rather than @command{vi}
and @command{git-cl}: any particular reason for that?
I was suggested to use that on Rietveld.
So, no, no particular reason.
If not, I would lean towards fixing this up before pushing. Ok with
you?
As I'm still working on it with the make doc issue I can also fix that
myself and resend a new patch.
Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl editor
Urs Liska u...@openlilylib.org writes:
Am 22.12.2013 10:54, schrieb David Kastrup:
I see that you used @code{vi} and @code{git-cl} rather than @command{vi}
and @command{git-cl}: any particular reason for that?
I was suggested to use that on Rietveld.
So, no, no particular reason.
Yes, I know: I'm not exactly being timely in bringing up issues. Sorry
for that.
As I'm still working on it with the make doc issue I can also fix that
myself and resend a new patch.
As you prefer.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
Urs Liska wrote Sunday, December 22, 2013 9:40 AM Am 22.12.2013 10:29, schrieb Trevor Daniels: The CG has never been properly revised and reorganised, with many sections added without considering the effect on others. But I'm still more confused because this contradicts After a good deal of thinking, here's how i think CG should be structured. More thinking and discussion than we had the previous 4 times we reorganized the CG? from a week ago. Well, the previous 4 times were quite some time ago, and a lot has been added since then. Your recent questions are evidence that more consolidation is needed. Big job, though. Graham and I have both experienced it reorganising the NR. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
On Sun, Dec 22, 2013 at 09:55:39AM +0100, Urs Liska wrote: I'm somewhat confused about the organization of the CG chapters about Git and patch review. First: 3.2.2 Git for the impatient and 3.3 Basic Git procedures share some information, and this in a somewhat confusing way. Is there a _short_ explanation what these two chapters are intended for? 3.2.2 was added more recently than 3.3, and was supposed to be a no fluff approach to git. Some people like more or less verbose explanations of what's happening. IMO, neither of these sections should be read by newbies, but I think that relied on the assumption that a mentor would be available. Without a mentor, we add 10+ hours to a new contributor's first patch (unless the contributor has previous experience with open-source projects). Second: 3.2. seems to be targeted at absolute beginners. So why does it explain the workflow with pushing to staging? Anybody who needs to read this chapter won't have commit access. Most of 3.2 was written before we had staging, and I think it was even before we had lily-git.tcl. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG organization (Git)
On Sun, Dec 22, 2013 at 10:40:04AM +0100, Urs Liska wrote: After a good deal of thinking, here's how i think CG should be structured. More thinking and discussion than we had the previous 4 times we reorganized the CG? from a week ago. Chapters 1 and 2 are solid (other than the bits about mentors, and possibly being out of date with respect to lilydev). The rest of the CG has decent chapters, but the material within each chapter is a mess. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website: rewrite Features page (issue 42770043)
LGTM https://codereview.appspot.com/42770043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Wed: Improve notes about Linux Dist LP Packages (issue 44440043)
LGTM https://codereview.appspot.com/0043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Re: Fwd: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl editor
Original-Nachricht Betreff: Re: Fwd: Re: Issue 3719 in lilypond: Patch: CG: Add comment about git-cl editor Datum: Sun, 22 Dec 2013 13:13:54 +0100 Von: Urs Liska u...@openlilylib.org An: David Kastrup d...@gnu.org Am 22.12.2013 11:59, schrieb Urs Liska: I don't see that logfile in input/regression/lilypond-book (nor a pdf). OK, running make doc in a clean new build and from master results in the same problem. So (as the previous error has disappeared with the newer build) it's not a problem with my patch but with my set-up. If I cd to that lilypond-book dir and run dblatex directly I get lilypond-book$ dblatex suffix-lyxml.lyxml Build the book set list... Build the listings... XSLT stylesheets DocBook - LaTeX 2e (0.3.4-2) === Build suffix-lyxml.lyxml.pdf pdflatex failed suffix-lyxml.lyxml.tex: File `docbook.sty' not found. suffix-lyxml.lyxml.tex:32: Emergency stop. suffix-lyxml.lyxml.tex:32: leading text: \renewcommand Unexpected error occured Error: pdflatex compilation failed Does anybody know how this docbook.sty should have reached my system? Or where I can get it? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)
Unfolding during iteration doesn't extend well to voltas, because it
changes their length. Even if the length is updated, the old length
has already been used by the parent iterator to compute moments for
subsequent events. So unless this can be changed, unfolding will have
to be done earlier, on music expressions. Unfortunately I think this
means unfold settings must come from the output def instead of the
context, so they can't be changed locally. This is not looking good
for voltas.
Keith wrote:
I think we need the tremolo-type property to hold the 32 from input c2:32
On TremoloEvent, yes. But do we need it on TremoloRepeatedMusic? I
suppose it might be handy for tweaking.
dak wrote:
This does not belong in the Repeated_music class. It's not a property
of the music, but of iteration.
Repeated_music isn't a music class — it should really be called
something like Repeat_utilities. (And it could be a namespace, not a
class.)
I'm not happy with the hardcoding of midi, but until we can write
\new Staff \with { \midi { repeatTypes = #'(volta-repeated-music } }
namely until context mods can get more discriminatory, we are probably
stuck with it.
\score { ... \layout { \context { \Score unfoldRepeats = #'(tremolo volta) } } }
is a tolerable way to specify non-midi unfolding.
That condition does not agree with the current implementation of
unfold-repeats-fully [...] Seems like I should push a fix to that...
Or export Repeated_music::unfolded_music to Scheme and call it. This
part of the patch doesn't depend on tremolo cleanup or anything else.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplifying input structure (was Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043))
Hi,
got a short moment for lily mail...
Devon - all these are valid concerns. However, i advise not to try
doing too much at once - let's do one level of abstraction at a time.
best,
Janek
2013/12/20 Devon Schudy dsch...@gmail.com:
Janek Warchoł wrote:
I believe we need to add an abstraction layer that would make it
conceptually simpler to write \score blocks.
Please take a look at
https://github.com/openlilylib/snippets/tree/master/templates/predefined-instruments
I believe that this is exactly what LilyPond needs to allow beginner
users easily create score structures. Notice how much it shortens the
\score definition.
These are convenient! It would be nice to have these for all the
common instruments — it would save most users the repetitive trouble
of setting clefs, transpositions, instrumentName, instrumentShortName,
midiInstrument and \dynamicUp. (But would it bother users who are
writing for an instrument that doesn't have a predefined staff?)
Other things that cause complexity in the SATB templates:
* Repeating \Time and \Key in each staff
* Putting \Time in parallel with each voice
* Explicitly creating Staff, and Lyrics contexts
With one voice per staff, VocalStaff etc. take care of the first four.
Users can get away with putting \time (and \repeat, if they don't use
\unfoldRepeats) in just one staff. The hard part is creating contexts.
Anything requiring understanding of contexts is beyond beginners. They
should be able to use implicitly created contexts for almost
everything. There are a few reasons this doesn't work:
* Music that is lyrics (i.e. a SequentialMusic whose first child is a
LyricEvent) creates a useless staff, not a Lyrics aligned to the
previous voice.
* Some group-level contexts have predictable children that are
different, so they can't be created correctly automatically.
PianoStaff's children are LH and RH; ChoralStaff's children are SATB.
If implicit contexts handled these (perhaps by making defaultChild a
callback instead of a string?), users wouldn't have to create explicit
staves just to get the normal behavior.
* Contexts are created even when a suitable context already exists.
Users expect { c' a d' b } to be equivalent to { c' d'
} { a b } , but it isn't when it creates contexts — it makes four
staves instead of two. This means intuitive operations like
concatenating tunes into a medley don't work.
* Implicit contexts aren't named, so they don't support \lyricsto,
\context, \change, etc.
* At top-level, StaffGroup isn't implicit when creating multiple staves.
Fixing these problems would make most explicit context creation
unnecessary. With the first two fixes, SATB scores would be simply:
\new ChoralStaff
\Soprano \SopranoLyrics
\Alto \AltoLyrics
\Tenor \TenorLyrics
\Bass \BassLyrics
\new PianoStaff \RH \LH
\new ChoralStaff
\new SopranoAltoStaff \Soprano \Alto
\VerseOne \VerseTwo %...
\new TenorBassStaff \Tenor \Bass
...which is simple enough to expect users to type.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)
On Sun, 22 Dec 2013 11:45:49 -0800, Devon Schudy dsch...@gmail.com wrote: Unfolding during iteration doesn't extend well to voltas, because it changes their length. Even if the length is updated, the old length has already been used by the parent iterator to compute moments for subsequent events. So unless this can be changed, Okay. That eager evaluation of lengths by the iterators also frustrated my attempt at a \RestUntil function (to fill the tuba part, for example, with rests until the next tempo change) so we might change that someday. Keith wrote: I think we need the tremolo-type property to hold the 32 from input c2:32 On TremoloEvent, yes. But do we need it on TremoloRepeatedMusic? I suppose it might be handy for tweaking. I see. It is not very likely that anyone refers to tremolo-type of the Music, so possible tweaking does not seem enough reason to keep it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)
On 2013/12/22 22:01:25, Keith wrote: On Sun, 22 Dec 2013 11:45:49 -0800, Devon Schudy mailto:dsch...@gmail.com wrote: Unfolding during iteration doesn't extend well to voltas, because it changes their length. Even if the length is updated, the old length has already been used by the parent iterator to compute moments for subsequent events. So unless this can be changed, Okay. That eager evaluation of lengths by the iterators also frustrated my attempt at a \RestUntil function (to fill the tuba part, for example, with rests until the next tempo change) so we might change that someday. The lyric-combine-music-iterator seems to get along with that preevaluation just fine, doesn't it? Well, at least if one wants to call what it does just fine: no idea whether things like http://code.google.com/p/lilypond/issues/detail?id=2010 could be due to that. https://codereview.appspot.com/40720060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Draft of 2.18 release news (issue 45070043)
Fails make need to escape some braces here and there in the @examples -
some nits.
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi
File Documentation/web/news-front.itexi (right):
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode26
Documentation/web/news-front.itexi:26: the occurence of unsightly large
gaps.
'occurrence'
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode26
Documentation/web/news-front.itexi:26: the occurence of unsightly large
gaps.
I like my adjectives comma-separated, but hey! (you say potato etc.).
'...of unsightly, large gaps.'
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode41
Documentation/web/news-front.itexi:41: \tuplet 3/2 4 { c8 c c c c c }
I think these braces need escaping @{ @}
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode45
Documentation/web/news-front.itexi:45: \times 2/3 { c8 c c } \times 2/3
{ c8 c c }
Ditto
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode70
Documentation/web/news-front.itexi:70: Sawada, and Zefram.
If it matters, Zefram's name is Andrew Main.
https://codereview.appspot.com/45070043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft of 2.18 release news (issue 45070043)
Reviewers: J_lowe,
Message:
On 2013/12/22 23:03:46, J_lowe wrote:
Fails make need to escape some braces here and there in the @examples
- some
nits.
Embarrassing. I did not bother all too much about seeing Patchy
complain since I was not expecting a patch to the stable branch to apply
at all.
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi
File Documentation/web/news-front.itexi (right):
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode26
Documentation/web/news-front.itexi:26: the occurence of unsightly
large gaps.
'occurrence'
Fixed.
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode26
Documentation/web/news-front.itexi:26: the occurence of unsightly
large gaps.
I like my adjectives comma-separated, but hey! (you say potato etc.).
'...of unsightly, large gaps.'
I was using unsightly as an adverb on large rather than as an
adjective, so no. It's like dangerously close hornets.
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode41
Documentation/web/news-front.itexi:41: \tuplet 3/2 4 { c8 c c c c c }
I think these braces need escaping @{ @}
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode45
Documentation/web/news-front.itexi:45: \times 2/3 { c8 c c } \times
2/3 { c8 c c
}
Ditto
https://codereview.appspot.com/45070043/diff/1/Documentation/web/news-front.itexi#newcode70
Documentation/web/news-front.itexi:70: Sawada, and Zefram.
If it matters, Zefram's name is Andrew Main.
I think that in the final version I'll be taking the content from the
updated authors.itexi instead, so it should not matter.
Description:
Draft of 2.18 release news
The contributor list needs to be completed.
Please review this at https://codereview.appspot.com/45070043/
Affected files (+73, -10 lines):
M Documentation/web/news-front.itexi
M Documentation/web/news.itexi
Index: Documentation/web/news-front.itexi
diff --git a/Documentation/web/news-front.itexi
b/Documentation/web/news-front.itexi
index
0d8b05774d703d4ce3423f1c2f26944609fb7ff0..dab13f66ef7bf242b706bf43d700201ae2a0834d
100644
--- a/Documentation/web/news-front.itexi
+++ b/Documentation/web/news-front.itexi
@@ -9,16 +9,65 @@
@c used for news about the upcoming release; see CG 10.2
@newsItem
-@subsubheading LilyPond 2.17.97 released! @emph{December 8, 2013}
-
-We are excited to announce the release of LilyPond@tie{}2.17.97 as
-a potential final beta release for the upcoming stable release@tie{}2.18.
The
-developers believe this to be feature-complete, the
-documentation to be accurate, and no important issues to be
-overlooked. For upgrading the syntax of your input files to the
-latest version, see
@uref{http://www.lilypond.org/doc/v2.17/Documentation/usage/updating-files-with-convert_002dly,
Updating files with convert-ly}.
-Please test this release and report back any problems, see
-@uref{http://www.lilypond.org/website/bug-reports.html, Bug reports}.
+@subsubheading Lilypond 2.18.0 released! @emph{December 28, 2013}
+
+We are proud to announce the release of GNU LilyPond 2.18.0.
+LilyPond is a music engraving program devoted to producing the
+highest-quality sheet music possible. It brings the aesthetics of
+traditionally engraved music to computer printouts.
+
+Among the numerous improvements and changes, the following might
+be most visible:
+
+@itemize
+@item
+Many items are now positioned using their actual outline rather
+than a@tie{}rectangular bounding box. This greatly reduces
+the occurence of unsightly large gaps.
+
+@item
+Sets and overrides can now use the syntax
+@example
+\override Voice.TextSpanner.bound-details.left.text = rit.
+@end example
+instead of the previous
+@example
+\override Voice.TextSpanner #'(bound-details left text) = rit.
+@end example
+
+@item
+Triplets with a given group length can now be written as
+@example
+\tuplet 3/2 4 { c8 c c c c c }
+@end example
+instead of
+@example
+\times 2/3 { c8 c c } \times 2/3 { c8 c c }
+@end example
+@end itemize
+
+A full list of noteworthy new features is given in:
+
+@example
+@uref{http://lilypond.org/doc/v2.16/Documentation/changes/index.html}
+@end example
+
+Great thanks go to the large number of LilyPond enthusiasts whose
+financial backing enabled one core developer, David Kastrup, to
+focus exclusively on LilyPond during the entire development cycle.
+
+@c TODO: list more than just the committers
+LilyPond 2.18 has been brought to you by Adam Spiers, Aleksandr
+Andreev, Anders Pilegaard, Arnold Theresius, Benkő Pál, Colin
+Campbell, David Kastrup, David Nalesnik, Federico Bruni, Francisco
+Vila, Frédéric Bron, Graham Percival, Guy Stalnaker, Han-Wen
+Nienhuys, Heikki Tauriainen, Ian Hulin, James Lowe, Jan
+Nieuwenhuizen, Janek Warchoł, Jean-Charles Malahieude, Johannes
+Rohrer, John Mandereau, Julien Rioux, Keith OHara, Luca
Re: Cleanup and generalization: get rid of Audio_column. (issue 42600043)
I wrote:
I was imagining it. [...] it never actually says it *can't* be
explicitly created.
It's in engraver-init.ly: “You cannot explicitly instantiate a
@code{Score} context”.
David Kastrup wrote:
Doing start_translation_timestep in mid-timestep is unclean, though,
and may confuse translators that expect it to be called at the
beginning.
How would they know the difference? There is nothing sent to an
implicit context before it is created. If it did not miss any piece
of the action, where is the problem?
They could miss earlier events from that timestep — but if no
translators care about events from before their context was created,
that doesn't matter. If a translator announces something in
start_translation_timestep (is this allowed?), other translators would
hear it in mid-timestep.
Part of the reason to use events for about anything is the ability to
_record_ them and reply them, like the quote iterator does.
Does it replay (or even see) timestep boundaries?
I think I find the start_translation_timestep will occur before
process_music invariant pretty important
Yeah. The CG even says so, in the engraver tutorial:
“`start_translation_timestep ()' is called before any user information
enters the translators, i.e., no property operations (\set, \override,
etc.) or events have been processed yet.”
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplifying input structure (was Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043))
Janek Warchoł wrote: Devon - all these are valid concerns. However, i advise not to try doing too much at once - let's do one level of abstraction at a time. Yeah. That was a wishlist, not a list of things needed for the SATB framework. :) I hope the predefined staff contexts do get into Lilypond, though; they're a big help. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft of 2.18 release news (issue 45070043)
https://codereview.appspot.com/45070043/diff/20001/Documentation/web/news-front.itexi
File Documentation/web/news-front.itexi (right):
https://codereview.appspot.com/45070043/diff/20001/Documentation/web/news-front.itexi#newcode52
Documentation/web/news-front.itexi:52:
@uref{http://lilypond.org/doc/v2.16/Documentation/changes/index.html}
Shouldn't this link to the 2.18 doc?
https://codereview.appspot.com/45070043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draft of 2.18 release news (issue 45070043)
On 2013/12/23 00:41:28, Devon Schudy wrote:
https://codereview.appspot.com/45070043/diff/20001/Documentation/web/news-front.itexi
File Documentation/web/news-front.itexi (right):
https://codereview.appspot.com/45070043/diff/20001/Documentation/web/news-front.itexi#newcode52
Documentation/web/news-front.itexi:52:
@uref{http://lilypond.org/doc/v2.16/Documentation/changes/index.html}
Shouldn't this link to the 2.18 doc?
Uh, yes. Will do in next upload.
https://codereview.appspot.com/45070043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
