PATCHES: Countdown for January 6th - 06:00 GMT
Hello (and Happy New Year), 3762 http://code.google.com/p/lilypond/issues/detail?id=3762q=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 push Patch: Doc: NR Tidy up of A4 - fretboard diagrams 3755 http://code.google.com/p/lilypond/issues/detail?id=3755q=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 push add chord names to A2. Common Chord Modifiers 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 push Patch: Tremolo cleanup. 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 push Example for \accepts in N.R.5.1.7 broke 3635 http://code.google.com/p/lilypond/issues/detail?id=3635q=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 Trevor Daniels push The explanation of force-hshift in the LM should be improved 3304 http://code.google.com/p/lilypond/issues/detail?id=3304q=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 Defect Janek Warchol push Unequal spacing in odd n-tuplet with other simultaneous subdivisions spacing 2096 http://code.google.com/p/lilypond/issues/detail?id=2096q=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 Patch: Implements cross-staff stem avoidance for dynamics. 3770 http://code.google.com/p/lilypond/issues/detail?id=3770q=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: Print semantic values for -ddebug-parser in display-lily-music style. 3769 http://code.google.com/p/lilypond/issues/detail?id=3769q=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: Lexer/Parser: Don't package location data in SCM_TOKEN semantic value 3767 http://code.google.com/p/lilypond/issues/detail?id=3767q=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 Change vim plugin from f6 view .ps to .pdf 3764 http://code.google.com/p/lilypond/issues/detail?id=3764q=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 Janek Warchol countdown Patch: Swap 'polite' and 'l2r' variable definitions 3761 http://code.google.com/p/lilypond/issues/detail?id=3761q=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 countdown LeftEdge no longer takes up space 3753 http://code.google.com/p/lilypond/issues/detail?id=3753q=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 Carl Peterson countdown Patch: Cleanup of ugly MI and SOL shaped noteheads 3751
Re: Suggestion about input languages
On 03/01/14 00:07, Noeck wrote: Dear developers, [tl;dr: how about ISO language codes for input language selection?] some time ago, I suggested to add French (français) to the list of note-name languages as an alias to italiano. This is the current state, español was also added. The discussion back then was about some inconsistencies: - the language for commands is English, these keywords are in different languages: \language deutsch ^ English ^ German - problem: français needs a utf8 char ç - espanol is a valid note-name language, francais isn’t *Summary*: special characters are needed for some languages to spell them correctly, this is because no international system is used here Now I have a new suggestion: We could use ISO 639-1 language codes for the input language specification: http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes Advantages: - international standard - widely adopted and known for language selection - the user language doesn't matter (no need to decide between French and français) - no special characters (plain ascii) - it is short The current language names could be kept for backwards compatibility. This would mean, the current alias list scm/define-note-names.scm:968 would be extended like this: - '((espanol español) - (italiano français))) + '((espanol español) + (italiano français) + (nederlands nl) + (catalan ca) + (deutsch de) + (english en) + (espanol es) + (italiano fr) + (italiano it) + (norsk nb) + (norsk nn) + (portugues pt) + (suomi fi) + (svenska sv) + (vlaams vls))) ; unclear* * I have no good proposition for vlaams as the language code is nl like Dutch/nederlands. The ISO 639-2 code is vls, another option might be nl-BE? What do you think? Cheers, Joram ___ Thanks I have created: http://code.google.com/p/lilypond/issues/detail?id=3771 James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Content of Introduction-Our Goal
On Wed, Jan 01, 2014 at 06:03:01PM +0100, Urs Liska wrote: I see the need to modify the Our Goal box on Introduction, but I wouldn't want to do that on my own because it would feel like modifying someone else's tune instead of only adding a figured bass to it. I have no objection to any of the changes suggested by you, Phil, and Carl. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Announcing 2.18.0 widely?
Apparently, from LilyPond 2.13 on, no GA code was added to track conversions. On Thu, Jan 2, 2014 at 4:43 PM, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: David Kastrup d...@gnu.org; lilypond-devel@gnu.org Sent: Thursday, January 02, 2014 3:37 PM Subject: Re: Announcing 2.18.0 widely? BTW, are the number of downloads recorded anywhere? It would be interesting to track this for stable releases. Google analytics should track this. If you can persuade GP to log in and check -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Jan 01, 2014 at 07:45:15PM +, James wrote: If you are comfortable with making patches and compiling, LilyDev is probably not for you. If you are not or want a ready-to-go environment and don't care that it's on some 'old' Linux release (i.e. not new and shiny) then LilyDev is perfectly fine. Agreed. Urs: if you didn't get that impression from reading the CG, then could you suggest somewhere to add something to that effect (or maybe just copy James' comment literally) ? We don't actually want to discourage experienced linux users from using their native environment; like you, I would find it a bit insulting if a project really did claim that I wasn't able to set up my own devel environment. That said, we want to make it absolutely clear that sorting out the potentially-complicated build dependencies is not *required* from contributors. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
On Wed, Jan 01, 2014 at 03:47:32PM +0100, Janek Warchoł wrote: 2014/1/1 Graham Percival gra...@percival-music.ca: Not quite. 1) is obvious, but equally important is 1.5) update incorrect info. Remember this latest iteration of interest in the CG happened because one or two new contributors tried to follow the published (incorrect) info, got into trouble, and understandably were irritated. You're right that updating incorrect info is important. However, as far as i remember there's not much _incorrect_ info left - the problem that we have now is more that the information is confusing: duplicated, placed in unexpected places, etc. We rarely (if ever) have perfectly duplicated material. We tend to have duplicated and slightly different material. In such cases, at least one of the duplications contains incorrect info. ... I'll admit that 10 minutes of poking around in the CG didn't find any such instances of duplicated material. CG 1.4 Mentors should be removed, and most of the stuff in CG 14 Administrative policies is probably useless and/or misleading, but I didn't see any obvious huge holes in those 10 minutes. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributing instructions are misleading!
Zitat von Graham Percival gra...@percival-music.ca: On Wed, Jan 01, 2014 at 07:45:15PM +, James wrote: If you are comfortable with making patches and compiling, LilyDev is probably not for you. If you are not or want a ready-to-go environment and don't care that it's on some 'old' Linux release (i.e. not new and shiny) then LilyDev is perfectly fine. Agreed. Urs: if you didn't get that impression from reading the CG, then could you suggest somewhere to add something to that effect (or maybe just copy James' comment literally) ? We don't actually want to discourage experienced linux users from using their native environment; like you, I would find it a bit insulting if a project really did claim that I wasn't able to set up my own devel environment. That said, we want to make it absolutely clear that sorting out the potentially-complicated build dependencies is not *required* from contributors. Cheers, - Graham I'll give it a shot ASAP. Probably it's only an issue of two or three tiny rewordings, just to give the right *impression*. I think I'm quite clear about how it should be. Unfortunately I'm suffering from Holiday's Disease. That is, as long as the children and particularly my wife are at home I don't have access to a Linux box or in general to a computer with more than 10 minutes of coherent concentration ;-) Any activity that relies on either of these conditions has to wait until next week. And I have to admit that LilyPond documentation/website isn't absolutely on the top of the list. Best Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Content of Introduction-Our Goal
Zitat von Graham Percival gra...@percival-music.ca: On Wed, Jan 01, 2014 at 06:03:01PM +0100, Urs Liska wrote: I see the need to modify the Our Goal box on Introduction, but I wouldn't want to do that on my own because it would feel like modifying someone else's tune instead of only adding a figured bass to it. I have no objection to any of the changes suggested by you, Phil, and Carl. Cheers, - Graham Thanks for the feedback, all. I'll make a concrete proposal next week. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Images on Introduction and Features
The images in the first text boxes on Introduction and Features are the same. Is there any specific reason for this? If not I would suggest to replace one of them with something else. IMHO the 'flat-design.png' is much more suitable for Features. On Introduction we're talking about freeing from the details of layout, and it's somewhat contradictory to display an image beside that which *is* about tiny details. Opinions? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Images on Introduction and Features
On Fri, Jan 03, 2014 at 02:49:35PM +0100, u...@openlilylib.org wrote: The images in the first text boxes on Introduction and Features are the same. Is there any specific reason for this? nah, I was just copying material from the old website to the new website. It makes sense to use different images. IMHO the 'flat-design.png' is much more suitable for Features. On Introduction we're talking about freeing from the details of layout, and it's somewhat contradictory to display an image beside that which *is* about tiny details. I slightly disagree there; showing that we have a mathematical representation of the tiny details *does* mean that humans are freed from dealing with it (since computers can do it). But I agree that might not be an obvious conclusion for non-programmers, so I have no objection to using a different image there. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Images on Introduction and Features
Graham Percival gra...@percival-music.ca schrieb: On Fri, Jan 03, 2014 at 02:49:35PM +0100, u...@openlilylib.org wrote: The images in the first text boxes on Introduction and Features are the same. Is there any specific reason for this? nah, I was just copying material from the old website to the new website. It makes sense to use different images. IMHO the 'flat-design.png' is much more suitable for Features. On Introduction we're talking about freeing from the details of layout, and it's somewhat contradictory to display an image beside that which *is* about tiny details. I slightly disagree there; showing that we have a mathematical representation of the tiny details *does* mean that humans are freed from dealing with it (since computers can do it). But I agree that might not be an obvious conclusion for non-programmers, so I have no objection to using a different image there. Good point. Maybe that can easily be made clear through the text. I'll consider this when I'm at that text anyway. I'd be happy to keep that image on introduction - it's so beautyful. Urs - Graham -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Images on Introduction and Features
Graham Percival gra...@percival-music.ca schrieb: On Fri, Jan 03, 2014 at 02:49:35PM +0100, u...@openlilylib.org wrote: The images in the first text boxes on Introduction and Features are the same. Is there any specific reason for this? nah, I was just copying material from the old website to the new website. It makes sense to use different images. IMHO the 'flat-design.png' is much more suitable for Features. On Introduction we're talking about freeing from the details of layout, and it's somewhat contradictory to display an image beside that which *is* about tiny details. I slightly disagree there; showing that we have a mathematical representation of the tiny details *does* mean that humans are freed from dealing with it (since computers can do it). But I agree that might not be an obvious conclusion for non-programmers, so I have no objection to using a different image there. Good point. Maybe that can easily be made clear through the text. I'll consider this when I'm at that text anyway. I'd be happy to keep that image on introduction - it's so beautyful. Urs - Graham -- Urs Liska openlilylib.org -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 2.4.1 - add Hammer/Pull snippets (issue 46730043)
LGTM Thank you James! https://codereview.appspot.com/46730043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
when is 2.19 going to be released?
Hello all, Now that 2.18 has been released (kudos, by the way!!!), when is the unstable branch going to be updated? I like to be on the bleeding edge… ;) Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
- Original Message - From: Kieren MacMillan kieren_macmil...@sympatico.ca To: Lilypond-User Mailing List lilypond-u...@gnu.org Cc: Lilypond Dev lilypond-devel@gnu.org Sent: Friday, January 03, 2014 4:24 PM Subject: when is 2.19 going to be released? Hello all, Now that 2.18 has been released (kudos, by the way!!!), when is the unstable branch going to be updated? I like to be on the bleeding edge… ;) Thanks, Kieren. ___ Well, you need to compile your own version then :-) Unless anyone complains, probably this weekend. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
Hi Phil, Well, you need to compile your own version then :-) I have VirtualBox and Lilybuntu and Janek’s script installed. The problem is, there are 437.5 “versions of Lilypond in git, and I don’t know which I should compile. :-p Unless anyone complains, probably this weekend. Thanks. =) Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
Kieren MacMillan kieren_macmil...@sympatico.ca schrieb: Hello all, Now that 2.18 has been released (kudos, by the way!!!), when is the unstable branch going to be updated? I like to be on the bleeding edge… ;) Then you should build your own LilyPonds ;-) -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
Kieren MacMillan kieren_macmil...@sympatico.ca schrieb: Hi Phil, Well, you need to compile your own version then :-) I have VirtualBox and Lilybuntu and Janek’s script installed. The problem is, there are 437.5 “versions of Lilypond in git, and I don’t know which I should compile. :-p As long as you don't want to try out a specific feature that someone develops you should simply checkout master and run build-lilypond. This will give you the mainstream bleeding edge in a current subdir. HTH Urs Unless anyone complains, probably this weekend. Thanks. =) Kieren. ___ lilypond-user mailing list lilypond-u...@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Urs Liska openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hello all, Now that 2.18 has been released (kudos, by the way!!!), when is the unstable branch going to be updated? What do you mean, updated? There are a lot of changes in the unstable branch already. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi Phil, Well, you need to compile your own version then :-) I have VirtualBox and Lilybuntu and Janek’s script installed. The problem is, there are 437.5 “versions of Lilypond in git, and I don’t know which I should compile. :-p Verified bleeding edge is called master. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
On 1/3/14 9:26 AM, David Kastrup d...@gnu.org wrote: Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hello all, Now that 2.18 has been released (kudos, by the way!!!), when is the unstable branch going to be updated? What do you mean, updated? There are a lot of changes in the unstable branch already. I believe that the question might be better stated as When will a new development release be made? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: when is 2.19 going to be released?
I believe that the question might be better stated as When will a new development release be made?” Yes. That. =) Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Your app listing has been updated on MacUpdate.com
Hi lilypond.org, We have updated your application listing for LilyPond 2.18.0-1 on MacUpdate.com. Please take a moment to review your application's information to make sure that everything is correct. You may view your updated listing by visiting: https://www.macupdate.com/app/mac/19024/lilypond Create a Developer Account today to reply to comments and view stats: https://www.macupdate.com/developers/signup/ You may submit new updates, or changes to your app listing here: https://www.macupdate.com/developers/update/ Questions? Contact our Content Update Team upda...@macupdate.com. Thank you for being part of the MacUpdate Software Community!: -The MacUpdate Team ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Create Score context before starting iteration. (issue 44860045)
David Kastrup wrote:
https://codereview.appspot.com/44860045/diff/60001/input/regression/initial-contexts.ly#newcode10
input/regression/initial-contexts.ly:10: %%and iteration can't skip time
without it.
This comment is a bit of a non-sequitur: time is kept in the Global
context, so it could get skipped.
Hmm, \skip successfully skips time, but doesn't update
measurePosition, because Timing_translator doesn't exist yet, so the
barlines are in the wrong places.
I am not actually sure how SkipEvent even works.
Apparently it (and SkipMusic) just works by having a nonzero length.
https://codereview.appspot.com/44860045/diff/60001/lily/global-context.cc#newcode148
lily/global-context.cc:148: find_create_context (default_child_, ,
SCM_EOL);
This precludes \new Score \with ..., quite a no-no.
\new Score creates the context in construct_children, so that still
works. Something like { \skip 4 \new Score ... } would fail, though.
Should that work?
[on calling start_translation_timestep for new translators]
Isn't that sufficient to have the Score context created in time?
Without requiring the other fixes?
It doesn't create it in time, but it does start the Score translators
properly when they're created late — but it still doesn't start
Score_performer correctly, because it's a Translator_group, not a
translator. However, the only Translator_group per_timestep
initialization is creating Score_performer::audio_column_, so if
Audio_column goes away, there's nothing left to do there.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Create Score context before starting iteration. (issue 44860045)
On 2014/01/03 19:07:55, Devon Schudy wrote:
David Kastrup wrote:
https://codereview.appspot.com/44860045/diff/60001/input/regression/initial-contexts.ly#newcode10
input/regression/initial-contexts.ly:10: %%and iteration can't skip
time
without it.
This comment is a bit of a non-sequitur: time is kept in the Global
context, so it could get skipped.
Hmm, \skip successfully skips time, but doesn't update
measurePosition, because Timing_translator doesn't exist yet, so the
barlines are in the wrong places.
Ugh. Ok, that's bad.
https://codereview.appspot.com/44860045/diff/60001/lily/global-context.cc#newcode148
lily/global-context.cc:148: find_create_context (default_child_, ,
SCM_EOL);
This precludes \new Score \with ..., quite a no-no.
\new Score creates the context in construct_children, so that still
works.
That sounds shaky enough to warrant a good explanation in comments.
Something like { \skip 4 \new Score ... } would fail, though.
Should that work?
Excellent question. Could be used for putting some delay into the MIDI
before the score starts. But whether that _should_ work in that manner?
No idea. What when the Timing_translator is moved to Staff level? It
would seem like nothing makes sense but having MeasurePosition start at
\new Staff when a staff is started after other staves. In analogy to
that, should that work might indeed warrant a tentative yes,
starting with a measurePosition of 0.
[on calling start_translation_timestep for new translators]
Isn't that sufficient to have the Score context created in time?
Without requiring the other fixes?
It doesn't create it in time, but it does start the Score translators
properly when they're created late — but it still doesn't start
Score_performer correctly, because it's a Translator_group, not a
translator. However, the only Translator_group per_timestep
initialization is creating Score_performer::audio_column_, so if
Audio_column goes away, there's nothing left to do there.
This is really headache material.
https://codereview.appspot.com/44860045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
License of files in Documentation/pictures and ability to distribute them unclear
There are a lot of files in Documentation/pictures which have no clear license, and unfortunately, the git log for them isn't clear at all either. Some of them cannot be distributed by lilypond either, for example, logo-debian.png is the Debian Restricted Use Logo.[1] It's great that a lot of them have the source which they were built from present, but there are some which are still missing the source. [For example, logo-debian.png can (and probably should) be built directly from the SVG[2] at the appropriate size (or just the SVG used).] 1: http://www.debian.org/logos/index.en.html#restricted-use 2: http://www.debian.org/logos/openlogo-nd.svg -- Don Armstrong http://www.donarmstrong.com We have to face the fact that either all of us are going to die together or we are going to learn to live together and if we are to live together we have to talk. -- Eleanor Roosevelt ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Accidental no longer clashes with TupletNumber or TupletBracket (issue 45520044)
Hi Mike, LGTM, after a visual check, but just some suggestions re the comments you've added. Cheers, Ian https://codereview.appspot.com/45520044/diff/1/lily/tuplet-bracket.cc File lily/tuplet-bracket.cc (right): https://codereview.appspot.com/45520044/diff/1/lily/tuplet-bracket.cc#newcode667 lily/tuplet-bracket.cc:667: // must come AFTER everything else Better as a block comment aligned with code /* We need to account for accidentals. This has to be done AFTER everything else. */ https://codereview.appspot.com/45520044/diff/1/lily/tuplet-bracket.cc#newcode672 lily/tuplet-bracket.cc:672: Real padding = scm_to_double (me-get_property (padding)); add end-of-line comment so it's clear what the variable's doing. ... // current value of padding property https://codereview.appspot.com/45520044/diff/1/lily/tuplet-bracket.cc#newcode674 lily/tuplet-bracket.cc:674: // won't be under the bracket Again /* Avoid the first column, as accidentals from that column won't be under the bracket. */ https://codereview.appspot.com/45520044/diff/1/lily/tuplet-bracket.cc#newcode684 lily/tuplet-bracket.cc:684: // tuplet numbe and a lot if it is. Again (and I reckon you were thinking in French here) /* Don't raise it by the full amount of padding as that would be too high, so adjust it by a little if the accidental is not under the tuplet number and by a lot if it is. */ https://codereview.appspot.com/45520044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
