Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On 7/4/11 11:32 PM, Jan Nieuwenhuizen jann...@gnu.org wrote: Also, I tried to make the output of the modified fixcc+asytle pass unchanged through emacs, but the very many cases of line-broken asssignments will be different. That's a problem. long_variable_name = first_term + second_term; // emacs This is correct. If we want to change the indentation, can't we do it with long_variable_name = (first_term + second_term); and have Emacs indent it this way? Emacs users will forget to run fixcc That won't do, sorry. Let's make it as easy as possible for non-Emacs users; but choosing a coding style that Emacs does not support is a no-go. This seems reasonable. We can still opt for using the current astyle solution, just as long as we see that this approach is a huge step forward and recognise that astyle still needs some fixes (and request these on the astyle development list). This also seems reasonable. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Carl Sorensen writes: If we want to change the indentation, can't we do it with long_variable_name = (first_term + second_term); and have Emacs indent it this way? We could; python requires this anyway. I still prefer option 3 below: have astyle support 2 space indentation for broken statements, but this is nit-picking. This seems reasonable. great, thanks Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3 - C++ formatting (probable decision)
Graham: ... ** Eliminate tabs I'm going to make the bold step of assuming that we will eliminate tabs in all C++ files. ... That implies that tabs in strings should be replaced with \t, is that what you want? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Carl Sorensen wrote Tuesday, July 05, 2011 7:12 AM On 7/4/11 11:32 PM, Jan Nieuwenhuizen jann...@gnu.org wrote: Also, I tried to make the output of the modified fixcc+asytle pass unchanged through emacs, but the very many cases of line-broken asssignments will be different. That's a problem. long_variable_name = first_term + second_term; // emacs This is correct. If we want to change the indentation, can't we do it with long_variable_name = (first_term + second_term); and have Emacs indent it this way? I prefer this indentation too. If Emacs users forget the brackets Astyle will indent it, but without the brackets. Can Astyle/fixcc be made to add brackets to keep Emacs sweet? Emacs users will forget to run fixcc That won't do, sorry. Let's make it as easy as possible for non-Emacs users; but choosing a coding style that Emacs does not support is a no-go. This seems reasonable. Yes. We can still opt for using the current astyle solution, just as long as we see that this approach is a huge step forward and recognise that astyle still needs some fixes (and request these on the astyle development list). This also seems reasonable. Also yes. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes multiple line glissandos the right way. (issue4631086)
On Jul 4, 2011, at 11:49 PM, n.putt...@gmail.com wrote: LGTM apart from some indentation infelicities (space before tab in indent). http://codereview.appspot.com/4631086/ Infelicities incapacitated, pushed as 0c258f3f339573d25080dadd0a1a5078ec35b09a. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On Jul 4, 2011, at 4:39 PM, Neil Puttock wrote: On 4 July 2011 15:31, Carl Sorensen c_soren...@byu.edu wrote: Would a redundant check of settings from default context definitions be a problem? I can't imagine that such a check would take 1% of the processing time. I don't know, though I agree is unlikely to be a significant overhead. Plus, I don't think it's really a redundant check; I think it's a real check. Absent such a check, we're trusting on the *-init.ly files being correct, which admits a potential programming error. The *-init.ly files are covered by regression testing since -dcheck-internal-types triggers an assertion error for incorrect context property settings. Cheers, Neil Just to get the ball rolling on this, were I to start on a patch that implements this sort of settings checking, where would be a good place to start? I know where the context mods are set and where the properties are set, but I don't know how the layout block escapes this checking. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tuplet number on cross-staff kneed-beam
On Mon, Jul 4, 2011 at 11:10 PM, David Nalesnik dnale...@umail.iu.edu wrote:
Hello, all --
Greetings,
First of all, I hope that I'm asking this question on the appropriate list!
Since you're demonstrating a regression, I'm forwarding your message
to our bug- list.
I'm trying to simplify the workaround relating to tuplet-number
position on kneed beams
http://lsr.dsi.unimi.it/LSR/Snippet?id=646
and I'm running into an unexpected problem.
My reasoning is that, since the tuplet number is positioned according
to the bracket, a logical first (certainly hacky!) step is to move the
(invisible) bracket to the beam by setting the 'positions property of
the bracket to that of the beam. Then, the position of the number
could be refined according to its height, the thickness of the beam,
etc.
This works as planned, except that in 2.14.1, the staves are pushed
apart dramatically. \override Beam #'collision-voice-only has no
effect on the problem. Manually setting Beam #'positions can be used
to fix the problem, but that is obviously inconvenient.
I've attached an .ly file with the function (stripped down to fit just
this case), and several images of the output (one is produced with
2.12.3, the other two with 2.14.1 -- one with an override of the Beam
#'positions). There doesn't appear to be any problem in 2.12.3.
Is there anything I can do to fix this problem with the function? Any
help would be greatly appreciated!
Indeed, it's a problem I've been stumbling across as well. Several new
properties have been introduced with 2.14 (stretchability, etc.);
you may want to have a look at
http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-within-systems#within_002dsystem-spacing-properties
Whether the default behavior can/should be improved, is a question for
the Bug Squad :-)
Cheers,
Valentin.
attachment: function-current-stable.pngattachment: function-current-stable-positions-override.pngattachment: function-previous-stable.png\version 2.14.1
#(define (tuplet-number-to-beam tuplet-number)
(let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
(note-column (ly:grob-parent tuplet-number X))
(stem (ly:grob-object note-column 'stem))
(beam (ly:grob-object stem 'beam)))
;; Move (invisible) TupletBracket to beam, taking number with it
(ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions))
;; Number is now centered on beam. Offset it based on width of beam and height
;; of tuplet number.
(ly:grob-set-property! tuplet-number 'Y-offset
(-
(+
(ly:grob-property beam 'beam-thickness)
(/ (interval-length (ly:grob::stencil-height tuplet-number)) 2))
\new PianoStaff
\new Staff = 1 {
s4
}
\new Staff = 2 {
\relative c {
\clef bass
%% following line has no effect
\override Beam #'collision-voice-only = ##t
%% following line improves situation
%\override Beam #'positions = #'(5 . 5)
\override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
\times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
}
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
correcting note about rerunning regtests (issue4675048)
Reviewers: ,
Description:
correcting note about rerunning regtests
looks like it is necessary to make test-clean
if you want to check regtests on a new branch
without making test-baseline
Please review this at http://codereview.appspot.com/4675048/
Affected files:
M Documentation/contributor/regressions.itexi
Index: Documentation/contributor/regressions.itexi
diff --git a/Documentation/contributor/regressions.itexi
b/Documentation/contributor/regressions.itexi
index
13c17651b9605d3f22b2c254e44c384a9f6bc8aa..7f4c9276169c22f9f52462b9fa95ee595df245c1
100644
--- a/Documentation/contributor/regressions.itexi
+++ b/Documentation/contributor/regressions.itexi
@@ -273,8 +273,8 @@ unless git master changed. In other words, if you work
with several branches
and want to do regtests comparison for all of them, you can
@code{make test-baseline} with git master, checkout some branch,
@code{make} and @code{make check} it, then switch to another branch,
-@code{make} and @code{make check} it without doing @code{make
test-baseline}
-again.}
+@code{make test-clean}, @code{make} and @code{make check} it without doing
+@code{make test-baseline} again.}
@node Finding the cause of a regression
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tuplet number on cross-staff kneed-beam
- Original Message - From: David Nalesnik dnale...@umail.iu.edu To: lilypond-devel@gnu.org Sent: Monday, July 04, 2011 10:10 PM Subject: tuplet number on cross-staff kneed-beam Hello, all -- First of all, I hope that I'm asking this question on the appropriate list! I'm trying to simplify the workaround relating to tuplet-number position on kneed beams http://lsr.dsi.unimi.it/LSR/Snippet?id=646 and I'm running into an unexpected problem. My reasoning is that, since the tuplet number is positioned according to the bracket, a logical first (certainly hacky!) step is to move the (invisible) bracket to the beam by setting the 'positions property of the bracket to that of the beam. Then, the position of the number could be refined according to its height, the thickness of the beam, etc. This works as planned, except that in 2.14.1, the staves are pushed apart dramatically. \override Beam #'collision-voice-only has no effect on the problem. Manually setting Beam #'positions can be used to fix the problem, but that is obviously inconvenient. I've attached an .ly file with the function (stripped down to fit just this case), and several images of the output (one is produced with 2.12.3, the other two with 2.14.1 -- one with an override of the Beam #'positions). There doesn't appear to be any problem in 2.12.3. Is there anything I can do to fix this problem with the function? Any help would be greatly appreciated! Thanks, David This looks to me like a bug in the beam collision-avoidance code. It look like it think it has to lengthen the stem to allow space for something, but it doesn't. I'd like to have someone who properly understands this to chime in first, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds glissando stems to Lilypond. (issue4661061)
On Jul 5, 2011, at 6:10 AM, carl.d.soren...@gmail.com wrote: Looking at the details of the code, it seems fine. But I tend to agree with Han-Wen's concerns. I'm wondering if it's possible to avoid code dup by making a base_stem_engraver of which glissando_stem_engraver and stem_engraver would be children. I probably don't have the right terminology for this (in fact I'm sure I don't), but I'm thinking of what happens with ligature_engraver and mensural_ligature_engraver. This is a good idea, although I think that the overlap is significant enough that they can co-habitate one engraver (I can see them varying in one function call maximum). But the logic is exactly this. I absolutely agree w/ Han-Wen that solutions should be generic, and I feel that this problem is the subset of the larger problem that the simple spacer is agnostic of the spacing in other lines. This fouls up a few scenarios: 1) Glissando stems are grobs whose directions change based on horizontal spacing, causing certain elements to change direction, which causes different stencils (think tremolos / articulations) extents that could subsequently effect the value of the line forces calculated in Constrained_breaking::initialize (). A better way to say this is that these forces should not be static but rather contingent on the distribution of stems on neighboring lines. 2) Certain arpeggio substitutes, such as chord braces and chord slurs, change their width in response to the distance between staves, which changes based on horizontal spacing. Currently, this distance between staves is calculated way downstream from the simple spacer. 3) textLengthOn and textLengthOff. Currently, there is no way to automatically space lines such that (a) a4^really really really really really really really really long doesn't fall towards the end of a line; or even better (b) a function distributes spacing error across subsequent lines such that other quarter notes around a4^really really really really really really really really long have similar distances that get more normal as the quarters get farther away from this distance. This function calculates a sort of force can be accessed via the same system of penalties used for ties/slurs/beams. All of these issues would be solvable in the following scenario. Note that the following scenario is VERY inefficient, but there are shortcuts that could be taken to cache certain values. 1) In any given score, there are always 2**(n-1) line breaking configurations possible, where n is the size of the vector breaks (see line 396 of simple-spacer.cc). 2) Each of these configurations is subject to various callbacks that determine how to handle glissando stems, distribute spacing error, widen/shorten arpeggios, etc. The properties that are changed based on these functions would be marked internally as `volatile', and their values would not be cached until after a good spacing was chosen. For example, in glissando stems, stem direction, stem tremolo direction / extent / stencil, articulation direction / extent / stencil are all volatile. 3) Make the lines_ of a constrained breaker a sparse binary tree (see below) of matrices, not a single matrix, that stores the information above. Each node of the tree would branch off into break/noBreak for a single point in breaks. The above approach is, of course, absurdly large as it would require 1125899906842624 line-breaking matrices for a 51 measure score (2**(51-1)). However, a lot of caching can happen based on where there are and aren't volatile grobs. It is for this reason that I say sparse binary tree (or a binary tree where, if after node n all paths lead to the same result, node n represents all of these paths). This can be made even sparser because certain paths will invariably start the same, diverge, and meet back up at certain places - their similarities can be represented by one data structure that holds a group of node indices and the shared result for these indices. Thoughts? Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
On 7/4/11 11:32 PM, Jan Nieuwenhuizen janneke at gnu.org wrote: Also, I tried to make the output of the modified fixcc+asytle pass unchanged through emacs, but the very many cases of line-broken asssignments will be different. Emacs users will forget to run fixcc That won't do, sorry. Let's make it as easy as possible for non-Emacs users; but choosing a coding style that Emacs does not support is a no-go. Well, the good news is + Most of the problems we had were due to the prefilter, not emacs + emacs onlyd does the indentation, so probably we need not worry about which emacs version + emacs can indent spaces instead of tabs + The prefilter can protect block comments from emacs indentation Therefore here is a new patch set showing a restricted pre-filter using emacs. I have only had a quick look at the diffs but what I saw looked good. Runnign the formatter on the full tree gives a clean make; I have a busy Tuesday, but at the end of it I can run make check and report back here. Since the operation is emacs( prefilter (code)), then further editing using emacs will make no changes -- assuming emacs indentation is idempotent, which is my big word for the day. http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py File scripts/auxiliar/fixcc.py (right): http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py#newcode64 scripts/auxiliar/fixcc.py:64: # trailing operator, but don't un-trail assignment operators or close angle-braces On 2011/07/04 20:45:23, Keith wrote: Looking through the existing code, line-broken assignments /do/ get the '=' on the second line long_name = long_initializer; so I could restore that. Done. http://codereview.appspot.com/4662074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
- Original Message - From: Janek Warchoł lemniskata.bernoull...@gmail.com To: lemniskata.bernoull...@gmail.com; percival.music...@gmail.com; james.l...@datacore.com; carl.d.soren...@gmail.com; lilypond-devel@gnu.org; re...@codereview.appspotmail.com Sent: Monday, July 04, 2011 10:46 PM Subject: Re: an example of minimal example (issue4636082) 2011/7/4 percival.music...@gmail.com: On 2011/07/04 21:01:44, Janek Warchol wrote: Umm.. is it right now? why the mao are you asking me? Cutpaste this and tell me yourself: cd build/ make website It either compiles, or it doesn't. Ooops, sorry... I didn't know that it's possible to compile website separately from all other documentation (which takes a lot of time, according to CG, and i've never done it). I did this, and it compiled. However, when i opened build/out-website/index.html, a black-and white text only page apperared. Does it mean i should do things described in CG 6.3? That's what I get as well. Providing it's compiled and looks approximately like you want it, you should be OK. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
2011/7/5 Graham Percival gra...@percival-music.ca
On Mon, Jul 04, 2011 at 11:46:30PM +0200, Janek Warchoł wrote:
2011/7/4 percival.music...@gmail.com:
On 2011/07/04 21:01:44, Janek Warchol wrote:
Umm.. is it right now?
why the mao are you asking me? Cutpaste this and tell me yourself:
cd build/
make website
It either compiles, or it doesn't.
Ooops, sorry... I didn't know that it's possible to compile website
separately from all other documentation (which takes a lot of time,
according to CG, and i've never done it).
I did this, and it compiled.
???
unless I clicked on the wrong draft by mistake, you still had a {,
which shouldn't compile.
Ah, i see now. I should've changed all { to @{ and } to @}.
I understood what you meant when i saw the code of example bug report.
Done.
However, when i opened
build/out-website/index.html, a black-and white text only page
apperared. Does it mean i should do things described in CG 6.3?
look at:
build/out-website/website/index.html
instead.
It's almost like our website - only misses graphics and shading on
menu bars. But i don't suppose it's because of anything i did.
Thanks!
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds glissando stems to Lilypond. (issue4661061)
On Jul 5, 2011, at 9:58 AM, m...@apollinemike.com wrote: 3) Make the lines_ of a constrained breaker a sparse binary tree (see below) of matrices, not a single matrix, that stores the information above. Each node of the tree would branch off into break/noBreak for a single point in breaks. Errata - the binary tree nodes would hold either null (no break) or vectors (break), where each vector represented the forces of the previous lines. Or maybe not even this...essentially, it'd be a data structure that holds the forces associated with a lot of different line breaking configurations in a way that eliminates redundant storage.* Cheers, MS * I know nothing about best practices in data management, but I'd be willing to learn if there isn't anyone who is good at this and would be willing to take on this project with me :)___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Changes not propagating when (re)building docs
Hello all, I'm preparing a few patches for the notation manual (the section on contemporary music I started ages back but didn't follow through on properly), but have encountered a problem. I've built both Lilypond and the docs successfully, and now I'm editing the file Documentation/notation/contemporary.itely Once done with changes, naturally I use make doc or make doc-stage-1 to rebuild the docs. However, my changes to contemporary.itely are not picked up on. The only way I've found to remedy this is to entirely delete the notation manual output: rm -r Documentation/out-www/notation* rm -r Documentation/notation/out-www and redo the make doc-stage-1 from there, which seems rather messy. To check it wasn't just contemporary.itely, I also tried playing with a few of the other files in the Documentation/notation/ directory, with the same result. So, it looks like changes made to .itely files are not being picked up as relevant to the build process. Any suggestions on how to fix this? It's not such a big deal to have to manually delete and rebuild, but it would be nice for the build system to automatically pick up on such changes. Thanks and best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an example of minimal example (issue4636082)
New patch set uploaded.
I have a problem with the box at the bottom: code examples are
center-aligned, not left-aligned. I didn't found any example of how
it's done in our manuals; i searched texinfo documentation and found
@flushleft, but it didn't work... How should i do this?
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode283
Documentation/web/community.itexi:283: The simpler the example is, the
quicker potential helpers can
On 2011/07/05 00:14:30, J_lowe wrote:
The tinier the example, the simpler it is and therefore, the
quicker...
I'm not sure if this is straightforward enough.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode287
Documentation/web/community.itexi:287: A simple example demonstrates
that you have put effort towards
On 2011/07/05 00:14:30, J_lowe wrote:
A tiny example also demonstrates to others on the email lists that
some kind of
effort has been taken to...
Too wordy imo.
[PS Are we talking 'simpler' or 'tinier' here? While I can see that
both work,
they are two different ideas and you are already moving away from
'tiny'. Can we
stick to tiny?]
Umm, i didn't touch anything here. I've only added that example part.
However, i agree that 'tiny' sounds better at the beginning of this
sentence.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode289
Documentation/web/community.itexi:289: input, it looks like they don't
care how if we help them or not.
don't care how if we help them or not. Should 'how' be there? Looks
wrong to me...
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode289
Documentation/web/community.itexi:289: input, it looks like they don't
care how if we help them or not.
On 2011/07/05 00:14:30, J_lowe wrote:
solving the problem yourself. Whereas overly complex, large or
unedited examples
look like no effort has been made to try to attempt to solve the
problem
yourself and can discourage others from helping.
I think it's too wordy, and the repetition about solving the problem
yourself is not necessary.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode292
Documentation/web/community.itexi:292: Creating a tiny example forces
you to understand what is
On 2011/07/05 00:14:30, J_lowe wrote:
A tiny example can also help you to ...
I agree about the 'helping' part, but i wouldn't remove word 'creating'.
It's creating the tiny example that helps in understanding, not merely
having it.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode296
Documentation/web/community.itexi:296: insufficient understanding of
LilyPond, not an actual bug!
On 2011/07/05 00:14:30, J_lowe wrote:
...then the problem is usually due to a lack of understanding of how
the
LilyPond syntax works.
I prefer the original, it's grammatically simpler.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode305
Documentation/web/community.itexi:305: @subheading How do I create them?
On 2011/07/05 00:14:30, J_lowe wrote:
How to create them.
[we try to not personalise the text or talk in first/second person]
Good point, i agree.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode311
Documentation/web/community.itexi:311: Include the \version number.
On 2011/07/05 00:14:30, J_lowe wrote:
Include the LilyPond @code{\version} number you are using.
I changed it so that it should be plain that the version of the actual
binary matters, not what \version statement you are using in your files
(i don't update \version numbers in my files quite often myself).
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode314
Documentation/web/community.itexi:314: Make it small! Examples about
spacing or page layout might
On 2011/07/05 00:14:30, J_lowe wrote:
Keep it tiny! Examples about...
I'd leave word 'make' because creating a tiny ex is a process of
removing material.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode320
Documentation/web/community.itexi:320: or @code{%@{ @dots{} %@}})}
sections of your file. If you can
On 2011/07/05 00:14:30, J_lowe wrote:
..or @code{%@{ @dots{} %@}})} sections of your file first. If you
can...
Done.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode321
Documentation/web/community.itexi:321: comment something while still
demonstrating the main idea, then
On 2011/07/05 00:14:30, J_lowe wrote:
comment something out while ...
sounds awkward to me.
http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode322
Documentation/web/community.itexi:322:
Re: Changes not propagating when (re)building docs
2011/7/5 Joseph Wakeling joseph.wakel...@webdrake.net: Hello all, I'm preparing a few patches for the notation manual (the section on contemporary music I started ages back but didn't follow through on properly), but have encountered a problem. I've built both Lilypond and the docs successfully, and now I'm editing the file Documentation/notation/contemporary.itely Once done with changes, naturally I use make doc or make doc-stage-1 to rebuild the docs. However, my changes to contemporary.itely are not picked up on. The only way I've found to remedy this is to entirely delete the notation manual output: Try touching the main itely file for this manual. Documentation/notation/contemporary.itely belongs to the notation manual, so you can touch Documentation/notation.tely then 'make doc' HTH -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes not propagating when (re)building docs
On 07/05/2011 11:16 AM, Joseph Wakeling wrote: So, it looks like changes made to .itely files are not being picked up as relevant to the build process. Any suggestions on how to fix this? Sorry, missed a Known Issues note in the contributors' manual: touch Documentation/notation.tely ... also works. Still, it's a hefty rebuild that results -- all the different untouched .itely files seem to be reprocessed -- is there any way of narrowing down the amount of stuff that needs to be rebuilt? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR lovers: walk the walk
On Sun, Jul 3, 2011 at 7:17 PM, Reinhold Kainhofer reinh...@kainhofer.com wrote: From a contributors point of view: If a snippet compiles with current stable, fine, it can be used at LSR. However, if it doesn't compile with current stable, I can't add it to the LSR now, so it probably won't get added to the LSR ever. If the release cycle does get shorter (wishful thinking inside ;), I can imagine making do with the current system. Maintaining a stable-only LSR does make sense, even if it means commenting out some snippets until they can be handled (see below). We also have several snippets with workarounds for 2.12, where some functionality has been added to 2.14 (like the compound time signatures). I think the LSR should more clearly state the version for which a snippet is actually intended. Indeed. However, the situation looked much worse to me a couple years ago when waiting for the 2.12 upgrade. It may because I've taken a step back since then, but it does seem less of a bloody mess today. This is also one of the reason why I introduced the notion of tags in lsr. We used to have only one version-specific tag that allowed me to browse through snippets that had a chance of being either outdated or fully commented out; we could improve upon this system by having a number of version-specific tags, such as 2.14, 2.15, 2.12 etc. Granted, this wouldn't solve the problem of multiple-version requirement (and possibly the necessity of temporary commenting out some snippets), but it would be a convenient (albeit inelegant) workaround, furthermore one we can set up in 15 seconds right now. People looking for compound signatures will find that snippet now, although the functionality has been added to 2.14. On the other hand, those who have to stay with 2.12 for some reason are interested in the 2.12-only snippet. I'm gonna go all grahamish on this one: we can't, won't, don't care enough to, support these users. There are a number of people still using 2.10 'cause it came with their distro, 2.8 'cause it's what they're used to, 1.6 'cause they like the TeX backend... (However, here again the tagging ability of the LSR may be of use to some of these people.) Anyways, the LSR lover I am has now pushed a minor update onto master. Nothing too extraordinary. Once again, Phil and I are available for any LSR-related question, a snippet that won't be accepted or whatevs. Perhaps the easiest way to go, btw, would be to simply add a basic contact-form to the LSR website, where people can send bleeding-edge/outdated/uncompilable snippets for us to manually review/comment out/translate/convert/commit as we see fit. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Changes not propagating when (re)building docs
Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of Joseph Wakeling )Sent: 05 July 2011 10:29 )To: lilypond-devel@gnu.org )Subject: Re: Changes not propagating when (re)building docs ) )On 07/05/2011 11:16 AM, Joseph Wakeling wrote: ) So, it looks like changes made to .itely files are not being picked up ) as relevant to the build process. ) ) Any suggestions on how to fix this? ) )Sorry, missed a Known Issues note in the contributors' manual: ) ) touch Documentation/notation.tely ) )... also works. Still, it's a hefty rebuild that results -- all the different )untouched .itely files seem to be reprocessed -- is there any way of )narrowing down the amount of stuff that needs to be rebuilt? ) --- [James' reply:] Joseph, being someone who makes small edits to the documentation regularly and also learning the hard way, if you are making changes to @lilypond examples it is best to use Lilypond-book in a 'test.tely' file first (then you can use texi2pdf to make a dummy PDF) this takes a few seconds and then when you are happy with your example you can cut/paste it into the real document and then make that final build. There is no way currently around just rebuilding your small bit in that single document that I am aware of. I'm happy to help off-list (if I can) if you need more explanation on this. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes not propagating when (re)building docs
- Original Message - From: Joseph Wakeling joseph.wakel...@webdrake.net To: lilypond-devel@gnu.org Sent: Tuesday, July 05, 2011 10:28 AM Subject: Re: Changes not propagating when (re)building docs On 07/05/2011 11:16 AM, Joseph Wakeling wrote: So, it looks like changes made to .itely files are not being picked up as relevant to the build process. Any suggestions on how to fix this? Sorry, missed a Known Issues note in the contributors' manual: touch Documentation/notation.tely ... also works. Still, it's a hefty rebuild that results -- all the different untouched .itely files seem to be reprocessed -- is there any way of narrowing down the amount of stuff that needs to be rebuilt? Is this any use? http://lilypond.org/doc/v2.14/Documentation/contributor/scripts-to-ease-doc-work -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds glissando stems to Lilypond. (issue4661061)
m...@apollinemike.com m...@apollinemike.com writes: On Jul 5, 2011, at 9:58 AM, m...@apollinemike.com wrote: 3) Make the lines_ of a constrained breaker a sparse binary tree (see below) of matrices, not a single matrix, that stores the information above. Each node of the tree would branch off into break/noBreak for a single point in breaks. Errata - the binary tree nodes would hold either null (no break) or vectors (break), where each vector represented the forces of the previous lines. Or maybe not even this...essentially, it'd be a data structure that holds the forces associated with a lot of different line breaking configurations in a way that eliminates redundant storage.* Cheers, MS * I know nothing about best practices in data management, but I'd be willing to learn if there isn't anyone who is good at this and would be willing to take on this project with me :) Well, the task sounds like the typical shortest path graph traversal. Basically, you keep a list of all feasible breakpoint sequences up to the currently examined breakpoint, including a set of characteristics that can still interact with the following breakpoints/lines, like the bottom skyline, and a (possibly discontinuous, like when skylines may interlock, but partly continuous) set of vertical dimensions and associated scores that the material above can assume. If one partial possibility can't be part of a solution scoring better than a solution using a different scored partial possibility, the inferior candidate is pruned from consideration. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 75: Allow multiple concurrent slurs (issue4643067)
I do wonder if David is right, and we should be using spanner_id instead of slur_id. Absolutely… but for the love of mao, don't ever tell David he was right. ;) K. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: correcting note about rerunning regtests (issue4675048)
http://codereview.appspot.com/4675048/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):
http://codereview.appspot.com/4675048/diff/1/Documentation/contributor/regressions.itexi#newcode276
Documentation/contributor/regressions.itexi:276: @code{make test-clean},
@code{make} and @code{make check} it without doing
What's the difference to running make test-redo?
http://codereview.appspot.com/4675048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: compiling documentation
Hello, )-Original Message- )From: Jonathan Kulp [mailto:jonlancek...@gmail.com] )Sent: 05 July 2011 15:41 )To: James Lowe )Cc: Graham Percival; lilypond-devel@gnu.org )Subject: Re: compiling documentation ) )On Mon, Jul 4, 2011 at 12:14 PM, Jonathan Kulp )jonlancek...@gmail.com wrote: ) My build env is fine, or at least it has been for more than a year. ) The doc-compile problem only started a couple of weeks ago. I have ) lilydev installed on another hard drive. Maybe I'll pop it in and try ) it out. I'd rather not bother with VMs at the moment. ) ) ) Well everything built fine on my lilydev system. Must be something ) wrong on Mint Debian. I get segfaults running 2.15.4 on my regular ) lilypond files too. No build errors compiling LP, but the compiled LP ) doesn't work right. :shrug: Not going to try to track this down ATM. ) ) )My Debian stable system builds everything fine, so it must be the Testing )branch with the problems. The segfault occurs right after a lilypond )compile command gets to emmentaler (sp?) ) )./configure output is pasted below. I suspect maybe Ghostscript 9.01, gcc )4.6? Does anyone know of build problems with the package versions )shown in this output? ) [James' reply:] http://code.google.com/p/lilypond/issues/detail?id=1717 Related? I would give you more threads but gmane is hanging - does anyone know if there is another 'site' I can look up dev/bug/user archives and search? Gmane is a PITA for me. james ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds glissando stems to Lilypond. (issue4661061)
Am Dienstag 05 Juli 2011, 06:10:12 schrieb carl.d.soren...@gmail.com: I'm wondering if it's possible to avoid code dup by making a base_stem_engraver of which glissando_stem_engraver and stem_engraver would be children. I probably don't have the right terminology for this (in fact I'm sure I don't), but I'm thinking of what happens with ligature_engraver and mensural_ligature_engraver. Hmm, I always thought that engravers should NEVER use inheritance... At least that´s what the comments in the slur-engraver.cc and the phrasing-slur- engraver.cc (which are basically identical except for melisma handling) says... Cheers, Reinhold -- -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/ * LilyPond music typesetting software, http://www.lilypond.org/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling documentation
On Mon, Jul 4, 2011 at 12:14 PM, Jonathan Kulp jonlancek...@gmail.com wrote:
My build env is fine, or at least it has been for more than a year.
The doc-compile problem only started a couple of weeks ago. I have
lilydev installed on another hard drive. Maybe I'll pop it in and try
it out. I'd rather not bother with VMs at the moment.
Well everything built fine on my lilydev system. Must be something
wrong on Mint Debian. I get segfaults running 2.15.4 on my regular
lilypond files too. No build errors compiling LP, but the compiled LP
doesn't work right. :shrug: Not going to try to track this down ATM.
My Debian stable system builds everything fine, so it must be the
Testing branch with the problems. The segfault occurs right after a
lilypond compile command gets to emmentaler (sp?)
./configure output is pasted below. I suspect maybe Ghostscript 9.01,
gcc 4.6? Does anyone know of build problems with the package versions
shown in this output?
Thanks,
Jon
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking Package... LILYPOND
checking builddir... /home/jon/lilypond
checking for stepmake... ./stepmake (${datarootdir}/stepmake not found)
checking for gmake... no
checking for make... make
checking for find... find
checking for tar... tar
checking for bash... /bin/bash
checking for python... python
checking python version... 2.6.7
checking for python... /usr/bin/python
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether compiler understands -pipe... yes
checking for IEEE-conformance compiler flags... none
checking for fc-list... fc-list
checking New Century Schoolbook PFB files...
/usr/share/fonts/type1/gsfonts/c059016l.pfb
/usr/share/fonts/type1/gsfonts/c059036l.pfb
/usr/share/fonts/type1/gsfonts/c059033l.pfb
/usr/share/fonts/type1/gsfonts/c059013l.pfb
checking for python... /usr/bin/python
checking /usr/bin/python version... 2.6.7
checking for /usr/bin/python... /usr/bin/python
checking gcc version... 4.6.0
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking g++ version... 4.6.0
checking whether explicit instantiation is needed... no
checking for stl.data () method... yes
checking for ar... ar
checking for ranlib... ranlib
checking for dlopen in -ldl... yes
checking for dlopen... yes
checking for bison... bison -y
checking for bison... bison
checking bison version... 2.4.1
checking for flex... flex
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking FlexLexer.h usability... yes
checking FlexLexer.h presence... yes
checking for FlexLexer.h... yes
checking for yyFlexLexer.yy_current_buffer... no
checking FlexLexer.h location... /usr/include/FlexLexer.h
checking language... English
checking for gettext in -lintl... no
checking for gettext... yes
checking for msgfmt... msgfmt
checking for mf-nowin... mf-nowin
checking for mpost... mpost
checking for working metafont mode... ljfour
checking for kpsewhich... kpsewhich
checking for guile-config... guile-config
checking guile-config version... 1.8.8
checking guile compile flags...
checking guile link flags...-lguile -lltdl -lgmp -lcrypt -lm -lltdl
checking libguile.h usability... yes
checking libguile.h presence... yes
checking for libguile.h... yes
checking for scm_boot_guile in -lguile... yes
checking for scm_boot_guile... yes
checking for scm_t_hash_fold_fn... no
checking for scm_t_hash_handle_fn... no
checking for scm_t_subr... no
checking GUILE rational bugfix... ok
checking for python-config... python-config
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for gs... gs
checking for gs... /usr/bin/gs
checking /usr/bin/gs version... 9.02
checking for fontforge... fontforge
checking for fontforge... /usr/bin/fontforge
checking /usr/bin/fontforge version... 20110222
checking for fontforge... (cached) fontforge
checking for fontforge... (cached) /usr/bin/fontforge
checking /usr/bin/fontforge version... 20110222
checking for t1asm... t1asm
checking for t1asm... /usr/bin/t1asm
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking grp.h
Accordion register sets
Hi, I have the following file (with outcommented usage examples at the end) flying around, and I think it is a reasonably workable approach to typesetting accordion register symbols. It should also be a good starting point for making extensions, like selecting Midi instruments at the same time (having the registers available both as pure markup as well as as music functions should help). Comments? % Accordion registration is tricky, partly because no two instruments % offer the same registers. In particular bass registers are not % standardized at all and often left unspecified (orchestra scores % don't use bass notes anyway). % % registration is indicated by using a control sequence name % indicating the register set as either a markup function or a music % function, taking a string as argument. The music function is a text % (super)script and can be employed either standalone or as % superscript attached to a music event. #(defmacro define-register-set (set-symbol instrument) `(begin (define-markup-command (,set-symbol layout props name) (string?) (let* ((instrument ,instrument) (register (ly:assoc-get name (ly:assoc-get 'register instrument))) (reedbanks (ly:assoc-get 'reedbank instrument))) (interpret-markup layout props (let markup-builder ((dots (or (ly:assoc-get 'dots register) (append-map (lambda (x) (ly:assoc-get 'dots (ly:assoc-get x reedbanks))) (ly:assoc-get 'reedbanks register (result (markup #:musicglyph (ly:assoc-get 'glyph instrument (if (null? dots) result (markup-builder (cdr dots) (markup #:combine result #:translate (car dots) #:musicglyph accordion.dot))) (define ,set-symbol (define-music-function (parser position register) (string?) (make-music 'TextScriptEvent 'direction 1 'text (markup ,(symbol-keyword set-symbol) register)) % The register names in the default Discant register set have been % more or less modeled after numeric Swiss notation like depicted in % URL:http://de.wikipedia.org/wiki/Register_%28Akkordeon%29, % omitting the slashes and dropping leading zeros. % % The names are basically three-digit numbers with the lowest digit % specifying the number of 16' reeds, the tens the number of 8' reeds, % and the hundreds specifying the number of 4' reeds. Without % modification, the specified number of reeds in 8' is in the symbol. % Newer instruments may have register choices between 8' with and % without cassotto. Notationally, the central dot then indicates use % of cassotto. You can suffix the tens' digits 1 and 2 with + % or - to indicate clustering the dots at the right or left % respectively rather than centered. #(define-register-set Discant '((glyph . accordion.discant) (reedbank (L (dots (0 . 0.5))) (M (dots (0 . 1.5))) (MM (dots (1 . 1.5))) (MMM (dots (-1 . 1.5))) (H (dots (0 . 2.5 (register (1 (reedbanks L)) (10 (reedbanks M)) (11 (reedbanks L M)) (1+0 (reedbanks MM)) (1+1 (reedbanks MM L)) (1-0 (reedbanks MMM)) (1-1 (reedbanks MMM L)) (20 (reedbanks MMM MM)) (21 (reedbanks MMM MM L)) (2+0 (reedbanks MM M)) (2+1 (reedbanks MM M L)) (2-0 (reedbanks MMM M)) (2-1 (reedbanks MMM M L)) (30 (reedbanks MMM MM M)) (31 (reedbanks MMM MM M L)) (100 (reedbanks H)) (101 (reedbanks H L)) (110 (reedbanks H M)) (111 (reedbanks H L M)) (11+0 (reedbanks H MM)) (11+1 (reedbanks H MM L)) (11-0 (reedbanks H MMM)) (11-1 (reedbanks H MMM L)) (120 (reedbanks H MMM MM)) (121 (reedbanks H MMM MM L)) (12+0 (reedbanks H MM M)) (12+1 (reedbanks H MM M L)) (12-0 (reedbanks H MMM M)) (12-1 (reedbanks H MMM M L)) (130 (reedbanks H MMM MM M)) (131 (reedbanks H MMM MM M L) % The default bass register definitions have been modeled after the % article URL:http://www.accordions.com/index/art/stradella.shtml % originally appearing in Accord Magazine. % % If you aren't composing for a particular target instrument, using % the five reed definitions makes more sense than using a four reed % layout: in that manner, the Master register is unambiguous. % Since this is rather the rule in literature bothering about bass % registrations at all, we use this as the default setting. % Instrument-specific variants follow. #(define-register-set StdBass '((glyph . accordion.stdbass) (register (Soprano (reedbanks Soprano)) (Alto (reedbanks Alto Soprano)) (Tenor (reedbanks Tenor Alto Soprano)) (Master (reedbanks Bass Tenor Contralto Alto Soprano)) (Soft Bass (reedbanks Bass Tenor Contralto)) (Soft Tenor (reedbanks Tenor Alto)) (Bass/Alto (reedbanks Bass Alto Soprano))) (reedbank (Soprano (dots (0 . 3.5))) (Alto (dots (0 . 2.5))) (Contralto (dots (1 . 2))) (Tenor (dots (0 . 1.5))) (Bass (dots (0 . 0.5)) % StdBassIV is
Re: compiling documentation
2011/7/5 James Lowe james.l...@datacore.com I would give you more threads but gmane is hanging - does anyone know if there is another 'site' I can look up dev/bug/user archives and search? all the links are here: http://lilypond.org/contact.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling documentation
Hi James Try http://lists.gnu.org/archive/html/lilypond-devel/ etc Trevor - Original Message - From: James Lowe james.l...@datacore.com To: Jonathan Kulp jonlancek...@gmail.com Cc: lilypond-devel@gnu.org Sent: Tuesday, July 05, 2011 4:20 PM Subject: RE: compiling documentation Hello, )-Original Message- )From: Jonathan Kulp [mailto:jonlancek...@gmail.com] )Sent: 05 July 2011 15:41 )To: James Lowe )Cc: Graham Percival; lilypond-devel@gnu.org )Subject: Re: compiling documentation ) )On Mon, Jul 4, 2011 at 12:14 PM, Jonathan Kulp )jonlancek...@gmail.com wrote: ) My build env is fine, or at least it has been for more than a year. ) The doc-compile problem only started a couple of weeks ago. I have ) lilydev installed on another hard drive. Maybe I'll pop it in and try ) it out. I'd rather not bother with VMs at the moment. ) ) ) Well everything built fine on my lilydev system. Must be something ) wrong on Mint Debian. I get segfaults running 2.15.4 on my regular ) lilypond files too. No build errors compiling LP, but the compiled LP ) doesn't work right. :shrug: Not going to try to track this down ATM. ) ) )My Debian stable system builds everything fine, so it must be the Testing )branch with the problems. The segfault occurs right after a lilypond )compile command gets to emmentaler (sp?) ) )./configure output is pasted below. I suspect maybe Ghostscript 9.01, gcc )4.6? Does anyone know of build problems with the package versions )shown in this output? ) [James' reply:] http://code.google.com/p/lilypond/issues/detail?id=1717 Related? I would give you more threads but gmane is hanging - does anyone know if there is another 'site' I can look up dev/bug/user archives and search? Gmane is a PITA for me. james ___ 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: Accordion register sets
On 7/5/11 10:27 AM, David Kastrup d...@gnu.org wrote: Hi, I have the following file (with outcommented usage examples at the end) flying around, and I think it is a reasonably workable approach to typesetting accordion register symbols. It should also be a good starting point for making extensions, like selecting Midi instruments at the same time (having the registers available both as pure markup as well as as music functions should help). Well, I know next to nothing about accordion, so I can't comment at all on the technical accuracy of your work. The code is very nice, and self-explanatory. The output looks wonderful. Having music functions available, and using your markup-builder macro should provide a nice infrastructure for building an AccordionDiagram grob and an accordion-diagram context, should you wish to do so. Looks to me like very nice work. You continue to impress me with the quality of your programming work. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
'git log --shortstat' hangs
I am sorry if this is too offtopic. When I do git log --shortstat | wc -l git does not complete the process and refuses to give control back to the user. Tested with git 1.7.0.4 and 1.7.4.1, on two different (large) git repositories. The same happens if you type git log --shortstat and hit the 'end' key in the less pager. I have dumped the output to a file and it just freezes and stops dumping. Without the --shortstat option it takes a fraction of a second even on large git histories. Could anyone test it? Thank you! -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: compiling documentation
Hello, From: Graham Percival [gra...@percival-music.ca] Sent: 05 July 2011 20:24 To: James Lowe Cc: Jonathan Kulp; lilypond-devel@gnu.org Subject: Re: compiling documentation On Tue, Jul 05, 2011 at 03:20:40PM +, James Lowe wrote: I would give you more threads but gmane is hanging - does anyone know if there is another 'site' I can look up dev/bug/user archives and search? Gee, it would sure be useful if our contacts page on the website gave a few different options for archives... like 3 different ones, in fact... Yeah! Those idiots who don't RTFM (they just edit them). James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 5 July 2011 08:26, m...@apollinemike.com m...@apollinemike.com wrote: Just to get the ball rolling on this, were I to start on a patch that implements this sort of settings checking, where would be a good place to start? I know where the context mods are set and where the properties are set, but I don't know how the layout block escapes this checking. Context::internal_set_property (). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling documentation
On Tue, Jul 05, 2011 at 03:20:40PM +, James Lowe wrote: I would give you more threads but gmane is hanging - does anyone know if there is another 'site' I can look up dev/bug/user archives and search? Gee, it would sure be useful if our contacts page on the website gave a few different options for archives... like 3 different ones, in fact... Cheers, - Graham PS don't mind me, I just don't deal with the heat very well. WTF am I in Italy? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)
On 5 July 2011 21:26, m...@apollinemike.com m...@apollinemike.com wrote: Thanks Neil! I should have been clearer before: what I don't understand is not the function call (pardon the double negative), but rather how the layout block evades setting do_internal_type_checking_global and/or how layout blocks are excepted in the function type_check_assignment. If -dcheck-internal-types is set, do_internal_type_checking_global is set, so the type-checking is applied to all \layout blocks. I'm not sure how you can ensure there's no checking for internal .ly files (i.e., what the lexer sets as new input before user files via `init.ly'). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: 'git log --shortstat' hangs
Francisco, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Francisco Vila [paconet@gmail.com] Sent: 05 July 2011 20:32 To: LilyPond-Devel list Subject: 'git log --shortstat' hangs I am sorry if this is too offtopic. When I do git log --shortstat | wc -l git does not complete the process and refuses to give control back to the user. Tested with git 1.7.0.4 and 1.7.4.1, on two different (large) git repositories. The same happens if you type git log --shortstat and hit the 'end' key in the less pager. I have dumped the output to a file and it just freezes and stops dumping. Without the --shortstat option it takes a fraction of a second even on large git histories. Could anyone test it? --- tested it on my LilyPond Git. Indeed git log | wc -l takes a few seconds but git log --shortstat | wc -l does complete but takes more time. However I am using 6 CPUs on this server and I noticed that one CPU was constantly at 100% all the others hovered about 4% while I did this. I expect on lesser machines it will also complete. Here is my output with date james@james-LilybuntuVM:~/lilypond-git$ date ; git log --shortstat | wc -l ; date Tue Jul 5 22:18:17 BST 2011 222369 Tue Jul 5 22:18:53 BST 2011 james@james-LilybuntuVM:~/lilypond-git$ james@james-LilybuntuVM:~/lilypond-git$ date ; git log | wc -l ; dateTue Jul 5 22:19:03 BST 2011 182473 Tue Jul 5 22:19:04 BST 2011 james@james-LilybuntuVM:~/lilypond-git$ HTH James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
listing a new value in font table files
Summary: flag glyphs need an additional value listed in table files. Should it be added to feta**.otf-table files or another table file should be created? The problem is that this value is specific to flags and it won't make sense in other glyphs - but would it make sense to have glyphs with different amount of characteristics in one table file? Should we split table files (have separate tables for flags and for exerything else)? Or maybe only the additional value should be in a separate table? Illustration of how it might look like: instead of (flags.u3 . ((bbox . (-0.00 -15.251400 4.505070 0.325030)) (subfont . feta-noteheads20) (subfont-index . 176) (attachment . (4.505070 . 0.00 there would be (flags.u3 . ((bbox . (-0.00 -15.251400 4.505070 0.325030)) (optimal-stem . 3.50) (subfont . feta-noteheads20) (subfont-index . 176) (attachment . (4.505070 . 0.00 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix segfault with ambitus and ligature (Issue 1715) (issue4667055)
On 2011/07/04 22:31:18, Carl wrote: OK, so I've added ligature-interface to NoteHead, and everything seems to work now. Erm, can I take back what I said yesterday? :) This looks really weird now, since it appears we're acknowledging ligature grobs. I think ligature-head-interface would be less confusing for the acknowledgers. Cheers, Neil http://codereview.appspot.com/4667055/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
print transposed guitar chords on piano sheets (issue4626094)
Reviewers: antlists_youngman.org.uk, carl.d.sorensen_gmail.com,
Message:
Modify chord-name-engraver to print transposed guitar chords on piano
sheets
Add associated properties capoPitch and capoVertical to
define-context-properties
Description:
print transposed guitar chords on pia
Please review this at http://codereview.appspot.com/4626094/
Affected files:
M lily/chord-name-engraver.cc
M scm/define-context-properties.scm
Index: lily/chord-name-engraver.cc
diff --git a/lily/chord-name-engraver.cc b/lily/chord-name-engraver.cc
index
d0ced5a395f836e99fe57970185e26793b52612f..5037825ca0149eb08d9e0150f0b45bc43334bf2e
100644
--- a/lily/chord-name-engraver.cc
+++ b/lily/chord-name-engraver.cc
@@ -2,6 +2,7 @@
This file is part of LilyPond, the GNU music typesetter.
Copyright (C) 1998--2011 Jan Nieuwenhuizen jann...@gnu.org
+ Copyright (C) 2011 Anthony Youngman anth...@youngman.org.uk
LilyPond is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -43,11 +44,14 @@ protected:
DECLARE_TRANSLATOR_LISTENER (note);
DECLARE_TRANSLATOR_LISTENER (rest);
private:
+ SCM capo_transpose( SCM, SCM) const;
+
Item *chord_name_;
vectorStream_event* notes_;
SCM last_chord_;
Stream_event *rest_event_;
+
};
void
@@ -76,6 +80,13 @@ Chord_name_engraver::process_music ()
SCM inversion = SCM_EOL;
SCM pitches = SCM_EOL;
+ SCM capo_markup;
+ SCM capo_bass = SCM_EOL;
+ SCM capo_inversion = SCM_EOL;
+ SCM capo_pitches = SCM_EOL;
+
+ bool capo = false;
+
if (rest_event_)
{
SCM no_chord_markup = get_property (noChordSymbol);
@@ -88,6 +99,17 @@ Chord_name_engraver::process_music ()
if (!notes_.size ())
return;
+ // This is set by \set ChordNames.CapoPitch = #(ly:make-pitch 0 1
1) in the lily source file
+ // declare properties in define-context-properties.scm
+
+ SCM capo_pitch = get_property ( capoPitch );
+ bool capo = false;
+ if ( !(capo_pitch == SCM_EOL) )
+ {
+Pitch *cp = unsmob_pitch (capo_pitch);
+capo = (Pitch::compare ( *cp, Pitch() ) != 0);
+ }
+
Stream_event *inversion_event = 0;
for (vsize i = 0; i notes_.size (); i++)
{
@@ -100,11 +122,27 @@ Chord_name_engraver::process_music ()
{
inversion_event = n;
inversion = p;
+ if (capo)
+ {
+capo_inversion = capo_transpose (p, capo_pitch);
+ }
}
else if (n-get_property (bass) == SCM_BOOL_T)
+{
bass = p;
+ if (capo)
+ {
+capo_bass = capo_transpose (p, capo_pitch);
+ }
+}
else
+{
pitches = scm_cons (p, pitches);
+ if (capo)
+ {
+capo_pitches = scm_cons (capo_transpose (p, capo_pitch),
capo_pitches);
+ }
+}
}
if (inversion_event)
@@ -123,10 +161,19 @@ Chord_name_engraver::process_music ()
}
pitches = scm_sort_list (pitches, Pitch::less_p_proc);
-
+ if (capo)
+ {
+capo_pitches = scm_sort_list (capo_pitches, Pitch::less_p_proc);
+ }
+
SCM name_proc = get_property (chordNameFunction);
markup = scm_call_4 (name_proc, pitches, bass, inversion,
context ()-self_scm ());
+ if (capo)
+ {
+capo_markup = scm_call_4 ( name_proc, capo_pitches, capo_bass,
capo_inversion,
+ context ()-self_scm ());
+ }
}
/*
Ugh.
@@ -135,8 +182,25 @@ Chord_name_engraver::process_music ()
chord_name_ = make_item (ChordName,
rest_event_ ? rest_event_-self_scm () : notes_[0]-self_scm ());
- chord_name_-set_property (text, markup);
-
+ if (!capo) {
+chord_name_-set_property (text, markup);
+ } else {
+SCM capovertical = get_property (capoVertical);
+SCM paren_proc = ly_lily_module_constant (parenthesize-markup);
+SCM line_proc = ly_lily_module_constant (line_markup);
+SCM hspace_proc = ly_lily_module_constant (hspace_markup);
+
+SCM final_markup = scm_list_n (line_proc,
+ scm_list_3 (markup,
+ scm_list_2 (hspace_proc,
+
scm_from_int(1)),
+ scm_list_2 (paren_proc,
capo_markup)),
+ SCM_UNDEFINED);
+
+chord_name_-set_property (text, final_markup);
+ }
+
+
SCM chord_changes = get_property(chordChanges);
if (to_boolean (chord_changes) scm_is_pair (last_chord_)
ly_is_equal (chord_as_scm, last_chord_))
@@ -145,6 +209,15 @@ Chord_name_engraver::process_music ()
last_chord_ = chord_as_scm;
}
+SCM
+Chord_name_engraver::capo_transpose (SCM scm_pitch, SCM capo_pitch) const
+{
+ Pitch *s_p = unsmob_pitch (scm_pitch);
+ Pitch *c_p =
Re: 'git log --shortstat' hangs
2011/7/5 James Lowe james.l...@datacore.com: Francisco, Indeed git log | wc -l takes a few seconds but git log --shortstat | wc -l does complete but takes more time. However I am using 6 CPUs on this server and I noticed that one CPU was constantly at 100% all the others hovered about 4% while I did this. I expect on lesser machines it will also complete. Here is my output with date james@james-LilybuntuVM:~/lilypond-git$ date ; git log --shortstat | wc -l ; date Tue Jul 5 22:18:17 BST 2011 222369 Tue Jul 5 22:18:53 BST 2011 james@james-LilybuntuVM:~/lilypond-git$ james@james-LilybuntuVM:~/lilypond-git$ date ; git log | wc -l ; dateTue Jul 5 22:19:03 BST 2011 182473 Tue Jul 5 22:19:04 BST 2011 james@james-LilybuntuVM:~/lilypond-git$ HTH James Thank you very much. On my dual core machine it's been running for hours now, and still. That involves four to six magnitude orders between both cases. (??) Sorry for the noise. I need it for another project also in Git, namely the RockBox player firmware. They have just moved from svn. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tuplet number on cross-staff kneed-beam
On 11-07-05 01:44 AM, Valentin Villenave wrote: On Mon, Jul 4, 2011 at 11:10 PM, David Nalesnikdnale...@umail.iu.edu wrote: Hello, all -- Greetings, First of all, I hope that I'm asking this question on the appropriate list! Since you're demonstrating a regression, I'm forwarding your message to our bug- list. I'm trying to simplify the workaround relating to tuplet-number position on kneed beams http://lsr.dsi.unimi.it/LSR/Snippet?id=646 and I'm running into an unexpected problem. My reasoning is that, since the tuplet number is positioned according to the bracket, a logical first (certainly hacky!) step is to move the (invisible) bracket to the beam by setting the 'positions property of the bracket to that of the beam. Then, the position of the number could be refined according to its height, the thickness of the beam, etc. This works as planned, except that in 2.14.1, the staves are pushed apart dramatically. \override Beam #'collision-voice-only has no effect on the problem. Manually setting Beam #'positions can be used to fix the problem, but that is obviously inconvenient. I've attached an .ly file with the function (stripped down to fit just this case), and several images of the output (one is produced with 2.12.3, the other two with 2.14.1 -- one with an override of the Beam #'positions). There doesn't appear to be any problem in 2.12.3. Is there anything I can do to fix this problem with the function? Any help would be greatly appreciated! Indeed, it's a problem I've been stumbling across as well. Several new properties have been introduced with 2.14 (stretchability, etc.); you may want to have a look at http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-within-systems#within_002dsystem-spacing-properties Whether the default behavior can/should be improved, is a question for the Bug Squad :-) Cheers, Valentin. This will probably require an issue, David, but could you send the code you used to produce the 2.12.3 version, please? I can't reproduce the previous stable example, in order to confirm the regression, because your Scheme-ing gives an error: LilyPond 2.12.3 [music.ly] starting (preview mode)... Processing `music.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems...music.ly:19:12: In procedure + in expression (+ (ly:grob-property beam #) (/ # 2)): music.ly:19:12: Wrong type argument in position 1: () LilyPond [music.ly] exited with return code 1. thanks, David Colin Campbell Bug Squad -- The human race has one really effective weapon, and that is laughter. -- Mark Twain ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tuplet number on cross-staff kneed-beam
Hi, Colin --
On 7/5/11, Colin Campbell c...@shaw.ca wrote:
This will probably require an issue, David, but could you send the code
you used to produce the 2.12.3 version, please? I can't reproduce the
previous stable example, in order to confirm the regression, because
your Scheme-ing gives an error:
LilyPond 2.12.3 [music.ly] starting (preview mode)...
Processing `music.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...music.ly:19:12: In procedure + in expression (+
(ly:grob-property beam #) (/ # 2)):
music.ly:19:12: Wrong type argument in position 1: ()
LilyPond [music.ly] exited with return code 1.
Oops -- yes, the error happened because 'thickness is now
'beam-thickness. I've attached the file I used for the 2.12.3 image.
I've also attached a pared-down version of the file which should work
in either release, as is. It distills the problem a little more -- at
the expense of centering the number directly on the beam . . .
I hope that in some way this is useful :)
Thank you for your help!
-David
\version 2.12.3
#(define (tuplet-number-to-beam tuplet-number)
(let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
(note-column (ly:grob-parent tuplet-number X))
(stem (ly:grob-object note-column 'stem))
(beam (ly:grob-object stem 'beam)))
;; Move (invisible) TupletBracket to beam, taking number with it
(ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions))
;; Number is now centered on beam. Offset it based on width of beam and height
;; of tuplet number.
(ly:grob-set-property! tuplet-number 'Y-offset
(-
(+
(ly:grob-property beam 'thickness)
(/ (interval-length (ly:grob::stencil-height tuplet-number)) 2))
\new PianoStaff
\new Staff = 1 {
s4
}
\new Staff = 2 {
\relative c {
\clef bass
\override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
\times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
}
}
}
\version 2.12.3
#(define (tuplet-number-to-beam tuplet-number)
(let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
(note-column (ly:grob-parent tuplet-number X))
(stem (ly:grob-object note-column 'stem))
(beam (ly:grob-object stem 'beam)))
;; Move (invisible) TupletBracket to beam, taking number with it
(ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions
\new PianoStaff
\new Staff = 1 {
s4
}
\new Staff = 2 {
\relative c {
\clef bass
\override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
\times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
}
}
}
tuplet-number-function-minimal.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tuplet number on cross-staff kneed-beam
Hi, again -- I've also attached a pared-down version of the file which should work in either release, as is. It distills the problem a little more -- at the expense of centering the number directly on the beam . . . My last email included an image produced with 2.12.3. Attached is the output from 2.14.1. Best, David attachment: tuplet-number-function-minimal.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
