Re: Kievan square notation in LilyPond
Hi, 2011/8/8 Aleksandr Andreev aleksandr.andr...@gmail.com: Hi everybody, Back to the topic of adding support for East Slavic (aka Kievan) music notation. Great to see you working on this! I've rewritten our font for Kievan notation (called Suprasl) in Metafont. Now, I am trying to figure out how to incorporate the new glyphs into the Feta files. Our contributor's guide contains a very brief introduction to modifying metafont files, it may be useful if you haven't seen it yet: http://lilypond.org/doc/v2.15/Documentation/contributor/modifying-the-feta-font If during your work you'll have anything to add there, contributions to CG will be most welcome! I've created a new file, feta-kievan.mf in the mf directory. Now I'd like to make sure I'm doing this right before I proceed .. this is the first time I've worked with Metafont, so please bear with me. In our file (suprasl.mf), the glyphs are defined with beginchar(name, width, height, depth). Next, I define a series of points in terms of the quantity u, which is derived from a sharped quantity u#. Basically, u# tells us what the size of the character should be given the font's design size. Finally, I draw the character with fill. can you send these files (in the patch format if possible)? It's easier to say something when you see the code (at least in my case). The question I have is this: what is the appropriate coordinate system to use for feta-kievan? What I've gleaned from reading the source of feta-notehead.mf is that things are somehow defined in terms of stafflinethickness# and staff_space. Yes, and also there is design_size used to encode differencies between particular versions of the font (see http://lilypond.org/doc/v2.15/Documentation/essay/engraving-details#optical-sizing). Am I right to understand that stafflinethickness is the thickness of a line in the five line staff? And staff_space is the amount of space between lines? stafflinethickness is the thickness of one line in the staff. staff_space is the distance between middle of one line to the middle of a next line (in other words, it's the amount of whitespace between lines + stafflinethickness) Would it be appropriate to define a basis unit u in terms of stafflinethickness and then specify the points in terms of u? In case of noteheads, i suppose that everything would be best defined in staff_space. For stems (as i understand there are special characters for stems) stafflinethickness will be more appropriate. However, i may be mistaken since i don't see the code. Where is the origin? origin of what? (sorry, i didn't understand) HTH, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Search box changes
2011/8/7 Phil Holmes m...@philholmes.net: I've prepared some changes for the web search box in line with what I suggested in http://code.google.com/p/lilypond/issues/detail?id=1806 - screenshot attached. It requires changes to search-box.ihtml and lilypond-website.css (to make room for the new box). Problem is, I've currently got a review going for the mozart horn regtest. I use lily-git.tcl for git. I'm presuming that I'm restricted to a single branch with this? I think so. If I try git from the command line to create a new local branch, I presume there's some way to tell git cl that you want to upload a different patch for review? There must be a way. I don't use lily-git and i don't have access to my Lilydev-enabled machine, so i cannot tell anything for sure, but here is my guess at how this should be done. Be sure to have the most recent version of your mozart horn regtest patch uploaded to Rietveld just in case. open terminal, go to main source directory (usually 'cd lilypond-git') call 'git status' to confirm where you are. I suppose it will say current branch: master, nothing to be committed (roughly). If it says that there are some changes to be committed, commit them before proceeding with 'git commit -a'). call 'git log' to see git history. You should see your commit(s) for mozart horn regtest at the top. Notice that every commit has a hexadecimal number, something like 46b423b3db2a90f8e8ac - this is commit's identifier, iirc called committish. copy the committish of the last commit before your mozart horn regtest commit(s). (copying in terminal is done using Ctrl+Shift+C, pasting with Ctrl+Shift+V) call 'git branch websearch [paste above committish, without brackets]' to tell git to create a new branch named websearch, pointing to that last commit before your mozart horn regtest (so the new branch won't contain your mozart horn regtest changes). call 'git checkout websearch' to move to that branch confirm that everything is right by calling 'git status' (it should tell that you are on websearch branch and there's nothing to commit) and 'git log' to check that your mozart horn regtest commit(s) is not included in this branch. make changes to the source as usual commit them by calling 'git commit -a' update repository by calling 'git pull -r' upload patch to Rietveld using 'git cl upload origin/master'. IIRC, vi might open at some moment; to close it press Esc : w q Enter This should work. I'll be at home with my Lilydev-enabled machine at around 20:00 UTC, if you'd like more help - we could talk using IRC chat for example.. HTH, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
2011/8/8 Trevor Daniels t.dani...@treda.co.uk: Graham Percival wrote Monday, August 08, 2011 6:06 AM Type-critical: * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. I agree this is important, but I don't see why it should prevent a new release per se. Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
2011/8/6 David Kastrup d...@gnu.org:
Going back to your colorful examples, here's what effects i'd expect:
\relative c' {
c4
\once\override Stem #'color = #red
\override Stem #'color = #blue
c4 c
\revert Stem #'color
c4
}
black blue blue black
That's a reasonable expectation, but it requires that \once\override
keeps track of just what it is supposed to revert at the end of the time
step. Popping the top of the stack would not work, leaving us with
black, blue, red, black. One possibility would be to store the
\once\override info in a separate location (or with a special mark)
where it does not mix with the \override info.
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
\revert Stem #'color
c4 c
c4
}
black black black black.
Actually, I think I'd prefer black, red, black, black. I feel a revert
should not cancel more than one \override, so something should happen at
the second time step. The pure stack approach would leave us with
black, blue, black, black, arguably weird. But pretty easy to explain.
If we aim for black, red, black, black, this would more or less imply
(if things should obey simple rules) that you can _never_ use \revert to
cancel \once\override. However, the syntax already permits
\once\revert, so maintaining what amounts to a separate stack for \once
could work reasonably well and be nice enough to document.
I'm not sure if i prefer black, red, black, black over 4 x black, but
it's not that important. Overall, your suggestion seems good to me.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
2011/8/6 David Kastrup d...@gnu.org: Jan Warchoł lemniskata.bernoulli...@gmail.com writes: 2011/8/6 James Lowe james.l...@datacore.com: Users and new contributors will interpret priority as importance, though, and will naturally want their favorites to be higher on the list. That's why I suggested putting issues where we don't know exactly what Lilypond should do, as Postponed. Obviously we can't program the behavior until we know what we want it to be, and that motivates users (who might know their area of notation better than we do) to think through what they want. Hmm. Interesting point of view. Not always helpful either. A lover of artwork won't be able to tell an artist how to improve his work. He still can be more, or less satisfied with it. You can tell critics do it yourself then, and they won't be able to. But it is not their job. Good point. 2011/8/6 Wols Lists antli...@youngman.org.uk: The whole philosophy of lilypond is that beautiful music is easily playable music. *Mostly* that's true. But as a bandsman, I place a *very* high penalty on page breaks. I wish I could force lily to force music on to one, or at most two, pages. But that goes completely against the grain of what most lily people want. IIRC it should be possible to set a custom penalty on line breaks. I know asking users to categorise importance to them is hard - yes they'll often say any bug is a serious bug - but to me for example printing one last stave on page two instead of cramming it onto page one is a massive failing of lily as a master engraver. I agree. I thought about fixing this, but i decided it's too difficult for me now. But automating page layout settings are on my TODO list; let me know if you will be trying to attack it (= CC me, i often miss e-mails not cced to me). Maybe we should have some scoring system whereby things are graded both on importance to user, and ease of fixing, along with program integrity (ie how serious a programmer would rate it - segfault, buggy code, etc). My formatting issues would probably rate about 1 on ease of fix and program integrity, but the higher the average score the more critical the feature because fixing it would have a far bigger impact across the board. Hmm. I was thinking about it some time ago, but do you know what? I think that it doesn't matter so much... Until we collectively hire a programmer to help us fixing bugs (or the development team will grow two times bigger), issue priorities (other than critical) have little impact. We'll spend more time discussing this than we'll gain by results. As for now i see that the only way to have things done is to start programming, hoping that other people will join you. It's hard, i know myself. 2011/8/6 Keith OHara k-ohara5...@oco.net: On Sat, 06 Aug 2011 00:55:46 -0700, James Lowe james.l...@datacore.com wrote: OK but it still doesn't get away from the 'when do we release the next stable release' question if we only have labels? I don't think Janek was suggesting we drop the field, only that my suggestion sounds more like a label than a rank. Yes, that's what i meant. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
2011/8/6 James Lowe james.l...@datacore.com: We don't have a GOP for 'isn't there a better way to keep track of issues AND upload patches' I see though. We have, but it's not yet put on schedule. http://lilypond.org/doc/v2.15/Documentation/contributor/policy-decisions 2011/8/6 Keith OHara k-ohara5...@oco.net: I suspect Graham meant order in which to best keep the project moving. Since the project doesn't control the order in which contributors attack issues, that would really be order in which the project encourages contributors to attack issues. Sounds good to me. Still, decision depends on our views about relative importance of user needs vs. developer needs. Theoretically, satisfying developer needs is more important to keep the project moving. However, if we follow this attitude to the extreme, there will be less users (and potentially new decelopers) coming. But any interpretation of priority in the sense of importance seems useless. We differ quite a lot in our opinions of importance. I suspect Janek and I would rank issues in near-opposite order of importance. That means that any importance-type priority estimated by the contributor who opens the issue, won't really help other contributors decide what to work on next. Probably, however, we would all sort issues into roughly the same types of problems: Regressions, crashes, incorrect output, ugly output, things that get in the way of contributing, ... So, all we really need to do is make useful classifications, and admit that we won't all agree on their relative priorities. This sounds a bit like let's drop 'priority' field and use labels only :) Users and new contributors will interpret priority as importance, though, and will naturally want their favorites to be higher on the list. That's why I suggested putting issues where we don't know exactly what Lilypond should do, as Postponed. Obviously we can't program the behavior until we know what we want it to be, and that motivates users (who might know their area of notation better than we do) to think through what they want. Hmm. Interesting point of view. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
2011/8/5 David Kastrup d...@gnu.org:
On the hopefully correct assumption that this was intended to go to the
list and just mistakenly sent in private
Yes, i occasionally misclick the button. Thanks!
I think that originally \override was a push, \revert was a pop, and
\once\override was a push/pop pair (that's more or less what is in the
user docs as well).
Then somebody probably thought that \override\override\revert should be
a nop since \override has to be used instead of \set anyway (which would
not push), and turned \override into a pop-push pair (pop never goes
beyond the current context, so little harm done). That explains why
the first example pairs the pop from the \once\override with the push
from \override. In the first example, the \override should, when
cancelling the push from \once\override, not leave the corresponding pop
lying around to be executed later.
Now take that incoherent mess, and add nested properties into it.
Apparently the current code has no qualms to start an \override with a
pop that will cancel an entirely unrelated operation.
Now if we do something like (never mind the value and the syntax)
\override a.b.c \override a
should the second \override be able to cancel the first one with its
implied \revert at its front? How about if we do
\override a \override a.b.c
instead? Should the second override be able to cancel the first one?
Only partially? What if we now do
\override a \override a.b.c \override a
How many \revert a should we need to have the stack empty again? If we
do
\override a \override a.b.c \revert a.b.c
what should the state of a.whatever be? Changed against before or not?
What should the state of a.b.c be? Changed against before (to the value
set by \override a) or not?
I'm not sure if i understand it (is a a property or a value?), but
it seems to me that \override should indeed not begin with a revert.
However, we may need additional command like
\revertTillDefaultIsReached or sth like that.
Going back to your colorful examples, here's what effects i'd expect:
\relative c' {
c4
\once\override Stem #'color = #red
\override Stem #'color = #blue
c4 c
\revert Stem #'color
c4
}
black blue blue black
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
c4 c
\revert Stem #'color
c4
}
black red blue black
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
\revert Stem #'color
c4 c
c4
}
black black black black.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dealing with nested properties.
2011/8/3 David Kastrup d...@gnu.org:
What is the general feeling about override/revert with nested
properties? The current implementation for property list of grob
properties maintains a data structure suitable for lazy updates of the
spine of the grob property list.
However, overrides for nested properties duplicate part of the _leaves_
of property lists which then are not updated anymore. Since alists are
not changed destructively, the update process for the spine of the
alists also gets triggered for changes in the leaves, but its effects
are restricted to updating the spine, so the copied environment of an
overriding leaf is not updated. The resulting data structures can't
distinguish
\override whatever #'a #'the-current-default-alist-for-a-with-changed-elements
and
\override whatever #'(a b c) #'something-new
But the first should disassociate the entire list for a from changes in
parent contexts, while the second should merely disassociate a.b.c from
changes in parent contexts.
So there is no way that the current data structures will work
consistently with the desired semantics. I see three ways of
proceeding:
a) Make things work as intended.
b) Document that override/revert are just a rough approximation of the
desired behavior, and make that approximation a good compromise between
usefulness and simplicity, so that people can understand what will fail
in what manner.
c) Remove access to nested property as it does not work.
I am currently working on angle a) but I am skeptical that it will
result in code that is both efficient as well as easily
understandable/maintainable. I find the current code already tough in
that area.
I'm not sure if i understand this well enough, but in my opinion b) is
not an option. If you say that a) can result in code that is
difficult to use and maintain, i vote for c). However, it'd be great
if you could provide some specific examples so that i can understand
better. For example, is \override Stem #'details #'lengths = #'(3 4
4.5) (if i remember syntax correctly) related to this and how will it
be affected?
2011/8/3 James Lowe james.l...@datacore.com:
But taking a specific and easy to get, example, I have in one score the
following in my \new Staff { } construct:
\override MultiMeasureRest #'expand-limit = #8
\override MultiMeasureRest #'minimum-length = #10
\override Score.OttavaBracket #'dash-fraction = #0.15
\override TextSpanner #'(font-name) = Baskerville
\override TextSpanner #'(font-size) = #0
Not that huge but it would be great to just be able to write
\override {
MultiMeasureRest #'expand-limit = #8 #'minimum-length = #10
Score.OttavaBracket #'dash-fraction = #0.15
TextSpanner #'(font-name) = Baskerville #'(font-size) = #0
}
Or perhaps
\override {
MultiMeasureRest (#'expand-limit = #8) (#'minimum-length = #10)
Score.OttavaBracket (#'dash-fraction = #0.15)
TextSpanner (#'(font-name) = Baskerville) (#'(font-size) = #0)
}
Or can we list within lists?
\override {
MultiMeasureRest #'((expand-limit, 8) (minimum-length, 10))
Score.OttavaBracket #'(dash-fraction, 0.15)
TextSpanner #'((font-name, Baskerville) (font-size, 0))
}
Interesting thing to discuss during GLISS.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities
2011/8/2 Graham Percival gra...@percival-music.ca: There is a long history of good programs never crash. I think we should take part in that. +1 Improvements to our development process won't be finished until the end 2011; I think it's irresponsible to actively recruit people until then. Do you mean that we should wait until GLISS ends? 2011/8/2 Graham Percival gra...@percival-music.ca: Something which makes it impossible for somebody to contribute is therefore more important than any graphical output problem (with the possible exception of regressions). [...] Priority-medium: * highest level for graphical output problems I don't agree. I agree that issues making contributions impossible should be critical and are perhaps the most important things. But I cannot agree that maintainability issues are more important then graphical output problems, to the extent of restricting graphical output problems to medium and low priority! 2011/8/2 Phil Holmes m...@philholmes.net: So any bug in Lily that produces bad output can never be High? Or - to put it another way, we, the developers ,only regard bugs as high when they hinder us, not when they make you, the user's life difficult. I don't like that. +1 I remain of the view that the words An issue which produces output which does not accurately reflect the input (e.g. where the user would expect an accidental, but none is shown) or which produces aesthetically poor output in a situation which could be expected to crop up frequently in real-world music. It should not be used where the problem can be avoided with a simple workaround. make a good definition of high. I think it's too vague. I'd rather say a noticeable problem with basic notation, except very weird or rare examples with easy workarounds, where basic notation is defined as follows: single-staff, single-voice music consisting of: - notes ( = noteheads, stems, flags, beams) - rests - accidentals - ties - augmentation dots We may wish to add dynamics, slurs and tuplets to this list, but i'm not sure about that. http://code.google.com/p/lilypond/issues/detail?id=1301 is an example of an issue that in my opinion doesn't meet above criteria (clef change is not basic notation, an it doesn't look frequently-appearing) and therefore shouldn't be high. 2011/8/2 Keith OHara k-ohara5...@oco.net: I suggest that Postponed can mean we're not quite sure what a proper fix would look like, yet. Then we know to give this issue a different kind of attention, like looking in the textbooks, before we start coding. Issues 39 and 621 had some dead-end programming that might have been avoided (although dead-end programming as part of a hobby is not the end of the world). No, i'd give a label for that. We shouldn't mix different types of information in priority field imo. 2011/8/2 Phil Holmes m...@philholmes.net: Another issue to tackle is how we use the priorities. We know that critical will focus developer's minds. But there's no drive to use the other priorities. I know that many devs work partly to make lilypond more to their taste, but also for general good. Perhaps we could agree that, say, a list of 10 high priorities is the current target list, and that anyone who wnats to contribute should/can look at fixing them as part of their contribution? I don't think so. Take my example: i do mostly mid-low priority issues, often ones that i found myself. That's because i don't have skills to attack important issues with a reasonable change of success without wasting too much time. I don't want to spend 5 hours banging my head on the wall trying to fix a critical issue that can be solved by Mike/Carl/HanWen/someone else in 30 minutes; i prefer to spend these 5 hours working on something that i understand and it interests me. Finally i'll learn enough to attack criticals on my own. However, i may be wrong. 2011/8/2 James Lowe james.l...@datacore.com: )So any bug in Lily that produces bad output can never be High? Or - to put )it another way, we, the developers ,only regard bugs as high when they )hinder us, not when they make you, the user's life difficult. and here is the rub (for me anyway) - a good example is slurs over line breaks. It's a hard problem (so it seems) to solve, but it produces (in some cases - all in my own personal experience) dreadful looking output. While not obviously critical, it should be High. Even if it is hard to solve. There was a time i thought they should be critical, but that's perhaps too much. 2011/8/4 Graham Percival gra...@percival-music.ca: Another thought: we could look at filling the patch countdown in order of priority (plus some amount of discretionary judgement if a patch has been waiting for a long time). I'm not sure if i like it. I usually work on issues that have low priority (as explained above) and every patch takes me quite a long time (i don't remember having any non-trivial patch pushed in less
Re: suspended whole notes - possibly a defect, please give your opinions
2011/8/5 Keith OHara k-ohara5...@oco.net: Janek Warchoł lemniskata.bernoullego at gmail.com writes: Good example! It reminded me that usually there are less suspended notes in a chord than normal ones (i.e. in your example the third pair consists of chords with two normal notes and one suspended). Because of that it is indeed better not to align horizontally such note columns (in other words, last two measures from attached example are typeset correctly indeed). Yes, it is good that Lilypond aligns horizontally the main note columns, as opposed to the suspended note-heads. Maybe you would like to have the suspended whole-note-heads always to the right of the main note column. Right now, LilyPond, suspends a whole-note head on the same side as she would suspend it in a stemmed chord of the same pitches. This is consistent, but maybe this particular consistency is not helpful to the reader. I'm still wondering about it. I'm curious whether there is a lot of variation between engraving books and publications in this matter. However, i'm unsure about the unequal measure length in that example. Lilypond tries to keep consistent space from the /main/ column of note heads to the end of the measure. The extra space given to a suspended note-head causes the measure to be longer; so the patch I proposed for issue 1779 makes these measures equal length. Yes, i'm looking at it and i'm still not sure how i'd like the output to look like. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour countdown for subvoice queues, breve vertical lines, staff-spacing, and notation appendix
2011/8/3 Graham Percival gra...@percival-music.ca: Friday, 1pm PST. Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices http://codereview.appspot.com/4816044/ font: change breve vertical lines http://codereview.appspot.com/4748044 Remove special case in staff-spacing http://codereview.appspot.com/4188051/ This is still being discussed. (i'm going to post a reply to Keith asap). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bar line shading in PNGs
2011/7/31 Phil Holmes m...@philholmes.net: Don't think this is a problem, but it is a bit interesting. I've been trying to run my pixel comparator to compare 15.7 to 15.5 and getting a difference in the bar lines of every image - presumably owing to the work to stop the PDF artefacts. Looking carefully at the bar lines, you can see they're not actually black - they're various shades of grey, in both versions. The difference is that the shading has changed. I attach 2 highly magnified images - one with normal contrast, and one with it adjusted to emphasise the shading. Interesting indeed. I guess it works like this: when rasterizing postscript output Lily decides that barlines are not thick enough to be represented by a perfectly black 2 pixel wide line. Therefore she chooses to draw it as a dark grey 2 pixel wide line (dark grey 2 pixel wide line looks from the distance like something a bit narrower than perfectly black 2 pixel wide line). However, on the spots where barline and stafflines intersect, the blackness of the barline is added to the pixel shade, making it darker. In other words, a pixel on the intersection of barline and staffline has more reasons to be completely black (namely, two reasons: being on a barline and being on a staffline) than pixels lying on a barline and not on the staffline. thanks for showing this! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please rebase local development on current master before pushing...
Hi David, sorry but i don't understand if this applies to me? (i don't have push ability) 2011/8/2 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: On Tue, Aug 02, 2011 at 10:32:15AM +0200, David Kastrup wrote: We have had several single-commit branches recently. Those appear in the history just as merge with master and require additional work for tracking the changes, worse so when the branchoff point is a long way backwards. So please make it a habit to do git rebase origin before doing git push The main point of a rebase is when you have been working on some private functionality, and the main development has continued. If you push your work after git pull, you get a merge from your private branch and the latest development. If you do git rebase origin before, then your development is rewritten as if it were done on top of the current origin/master. History is linear then and easier to follow. Regardless of whether this applies to me or not, does using git pull -r instead of plain git pull make this problem irrelevant, or am i wrong? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown delayed by Monster Trucks
2011/7/31 James Lowe james.l...@datacore.com: I imagine some underground bunker with walls of charts and a big map of the lilypond code with ladies wearing headsets pushing flags around with all our names on them. And Graham watches everything smoking a cigar :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 3)
LGTM. 2011/7/31 Graham Percival gra...@percival-music.ca: We have somebody willing to work on this stuff. He's twiddling his thumbs until we get the basic guidelines down. Of course there will be technical implementation problems to work out later, but I'm really hoping that he can start work; it's been a month! Are there any problems with those guidelines? If you disagree with a point (or if I have not convinced you that you should accept the proposal), please speak up. If you would like to add a point, please speak up. http://lilypond.org/~graham/gop/gop_5.html ** Proposal summary If there are no build problems, there should be no change to people’s workflow. If there are build problems, then it should be easier to find out why it’s failing. ** Rationale When the lilypond build breaks, it’s too hard to figure out why it broke. We see emails to lilypond-devel approximately once every two months about broken builds. On a subjective note, Graham has been the documentation editor since 2003, but even he cannot reliably pinpoint the cause of a failing doc build within 10 minutes. We waste a ridiculous amount of time, effort, and patience on build problems. ** Sea of output Before any of the current work on reducing output from make, the result of a make doc was over 500,000 lines of text. The prime reason for the output being so verbose is that all the processes that run as a result of the call to make echo their output to the screen, often in verbose mode. Lilypond itself produces around 370,000 lines of output as a result of lilypond-book building all the snippets. Much of this output can be redirected to logfiles and so the impossible-to-read clutter on the screen is cut out and could be referred to later. ** Proposal details When you run make or make doc, * All output will be saved to various log files, with the exception of output directly from make(1). * By default, no other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. The user may optionally request additional output to be printed; this is controlled with the VERBOSE=x flag. In such cases, all output will still be written to log files; the console output is strictly additional to the log files. * Logfiles from calling lilypond (as part of lilypond-book) will go in the relevant ‘build/out/lybook-db/12/lily-123456.log’ file. All other logfiles will go in the ‘build/logfiles/’ directory. * Both stderr and stdout will be saved in *.log. The order of lines from these streams should be preserved. * There will be no additional “progress messages” during the build process. If you run make --silent, a non-failing build should print absolutely nothing to the screen. * Ideally, a failing build should provide hints about the reason why it failed, or at least hints about which log file(s) to examine. ** Don’t cause more build problems However, there is a danger in this approach, that vital error messages can also be lost, thus preventing the cause of the failure of a make being found. We therefore need to be exceptionally careful to move cautiously, include plenty of tests, and give time for people to experiment/find problems in each stage before proceeding to the next stage. ** Implementation notes There is an existing make variable QUIET_BUILD, which alter the amount of output being displayed (http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables ). We are not planning on keeping this make variable. The standard way for GNU packages to give more output is with a V=x option. Presumably this is done by increasing x? If we support this option, we should still write log files; we would simply print more of the info in those log files to screen. Cheers, - Graham ___ 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: music function semantics
W dniu 31 lipca 2011 01:23 użytkownik James Lowe james.l...@datacore.com napisał: Then what would be the purpose of \once \override; or is that your point? Yeah, making \once \override work like \tweak is my point. But i'm not sure about it, it's just an idea for GLISS. W dniu 31 lipca 2011 01:48 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 7/30/11 4:37 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does I guess we'll have this out in GLISS. But I think it would be a major inconvenience. If I want to have the all the notes at the current instant made red, I can do it with a single call to \once \override. If we make \once \override work like \tweak, I'd need a call for each note head. Definately it's a topic for GLISS. 2011/7/31 David Kastrup d...@gnu.org: Carl Sorensen c_soren...@byu.edu writes: \tweak comes immediately before the object to be modified. Except when not. \tweak ... c does not work, you need to do \tweak ... c Yeah... While i can learn to live with that (albeit very painfully), there are plenty of people whose minds would simply blow because of this (you know, ordinary people without geek-skills). I have some more to say about this, but i guess it will be best suited when we discuss GOP-PROP roadmap of future development. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no movement on Critical issues; 2.16 in Oct ?
2011/7/31 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: On Sun, Jul 31, 2011 at 09:42:36AM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: I haven't seen any interest in http://code.google.com/p/lilypond/issues/detail?id=1771 My take on this (if nobody is going to protest in the next few hours) is to revert the flawed fix. I think that's entirely reasonable. IMO, if there's no clear offer of a fix within 48 hours of a bad commit, we should revert it. Within 48 hours of pinpointing the bad commit. +1. If we manage to get stable releases every few months, i think a policy of reverting any flawed commit that appeared after last stable release (i mean x in 2.x.y, not y) would be good. I can help with these bugs when i close currently opened issues and sort out my repository after grand fixcc-ing (estimated to happen next weekend). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown delayed by Monster Trucks
W dniu 31 lipca 2011 22:07 użytkownik James Lowe james.l...@datacore.com napisał: From: Jan Warchoł [lemniskata.bernoulli...@gmail.com] And Graham watches everything smoking a cigar :) No...stroking a white fluffy cat you mean? I didn't know Winston had a cat! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
2011/7/29 David Kastrup d...@gnu.org: Jan Warchoł lemniskata.bernoulli...@gmail.com writes: if i understood you correctly (it's about the difference in syntax between tweak and override?), i agree that it's quite a serious problem. There is not all that much, really. Take a look at music-functions.scm, for example style-note-heads. It's sort of polymorphic since it can be called in various places. It looks at the type of received music expression in order to figure out where it was called, and does a tweak or an override depending on what will work in that context. I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. GLISS - i can't wait for you! cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 7: Developers as resources
2011/7/29 Graham Percival gra...@percival-music.ca: On Fri, Jul 29, 2011 at 09:56:38AM +0200, Jan Warchoł wrote: What will happen if we sign up to a team and not do our homework? Same idea? Team leader has a chat with you, and in extreme cases would just stop assigning you work to do. I don't think this is a huge worry -- we're all reasonable people wanting to make lilypond better. Yes, i've just asked this question because it looked like being overlooked. If we had a central authority leading a team (or teams) of developers – or at least, leading developers for X hours a week – The question is, who will it be. *shrug* All I know is that it can't be me for the remainder of 2011. In the first place I'd be an iffy choice due to my relative inexperience with lilypond programming, but the main reason is that I'm needed to run GOP and GLISS. Then i think it can't be you till 2013. I don't believe we'll sort GLISS out in less than a year ^^ I have lots, *lots* of issues myself. We could have rotating leaders -- Carl for a month while they work on fret stuff, Neil for two months while they work on fundamental scheme stuff, Keith for a month while they work on spacing stuff, Bertrand for a month while they work on ancient notation? That's fine, but i asked who the central authority would be. The one who will decide we work for a month on frets under Carl's leadership, on Scheme under Neil's, and after that on this, and that. You know, the Grand Master. Hmm. Han-Wen? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 7: Developers as resources
2011/7/30 James Lowe james.l...@datacore.com: Hello, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of David Kastrup )Sent: 30 July 2011 17:34 )To: lilypond-devel@gnu.org )Subject: Re: GOP-PROP 7: Developers as resources ) --snip-- )...with the aim to put )as many issues in the tracker behind, under the lead of a suitable )volunteer. ) )-- It might be more productive to assign a 'group of tracker items' with the aim to improve a specific area of identified problems, I think if a particular thorny problem was worked on 'en masse' or rather devs knew that it was being worked on 'en masse' we could perhaps get more done this way. Yes. For example I guess it would be more productive to fix tie formatting in general instead of working through all tie bugs separately. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
W dniu 30 lipca 2011 18:18 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 7/30/11 9:33 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I see... The more i think about it, the more i feel it would be good to merge \set, \override and \tweak into one thingy. Doing so would make music functions like above one quite simpler. While I could see that perhaps we could combine \set and \override, we cannot combine \tweak. \override and \set modify everything at the current moment. \tweak modifies only a single grob. The distinction between \override and \tweak needs to stay because it is a semantic distinction. Hmm, i'd say that \once \override could work like tweak. Currently \once \override affects all objects created at the same moment in given context, but i think it wouldn't be of much inconvenience if it affected only a single object, like tweak does. The reason i'm so concerned about it is because today i managed to do unbelieveable amount of mistakes when trying to move a markup. I've forgotten about the hash, the quote and the dash (in different combinations) before i finally wrote -\tweak #'X-offset #3 . At some moment i even thought it cannot be done like that. A shame - only i'm not sure who should be ashamed more, me or Lily :P cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown delayed by Monster Trucks
2011/7/30 Graham Percival gra...@percival-music.ca: On Fri, Jul 29, 2011 at 11:07:53PM -0600, Colin Campbell wrote: I just got home from taking my grandson to see the Monster Truck show, and we had an opportunity to go for a ride in one afterwards. Seeing the light in a six-year old's eyes when he realized what was about to happen was worth risking the wrath of the developers! Wow, definitely! Sounds like a great time! Today's batch of patches will come out tomorrow (Saturday) instead. Let's skip this one, and instead focus on nagging people to push stuff that should be pushed. The grand fixcc.py run will occur on Aug 01, so we don't have time to have another countdown before that change. Oops, i hoped that some of my patches would be counted down just before the fixcc :P Do i understand correctly that if i have the patch in a separate branch that is up-to-date with master, running a fixcc on it will produce a patch suitable for new master? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
David, 2011/7/27 David Kastrup d...@gnu.org: Neil Puttock n.putt...@gmail.com writes: On 26 July 2011 22:41, David Kastrup d...@gnu.org wrote: So the question basically is: which of those mechanisms is actually being in use? Are there examples for existing music functions interpreting a postevent or a chord constituent? \tweak would be the most common usage for both of these cases: c1-\tweak #'color #red -\fermata and \tweak #'color #red c1 So much for my nobody needs that theory. The problem I have is that accepting \transpose in all the same places as \tweak does not seem like a good idea. On the other hand, whether an error gets thrown by the parser or by the expression builder might not make that much of a difference to the end user than it feels like making to me. if i understood you correctly (it's about the difference in syntax between tweak and override?), i agree that it's quite a serious problem. ...ah, so it is possible to modify ties in a chord separately! Do you realize that i didn't know about it? I'd say that this means the current state of things is too complicated. I vote for changing the way things work completely (GLISS time approaches, after all :P). sorry if this is not very helpful... maybe i'll have specific ideas later. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 7: Developers as resources
2011/7/28 Graham Percival gra...@percival-music.ca ** Amateur orchestra I shall describe the workings of the (Vancouver) “West Coast Symphony Orchestra” (at least when I was playing with them, back in 2002-2006). There is no discouragement from missing a concert – members know that they all have busy lives, and if there is a big deadline at work or a family vacation during a rehearsal period, they simply do not sign up for that concert. However, if you do sign up for a concert, then you are normally only allowed to miss one rehearsal. And what happens if they miss more? What will happen if we sign up to a team and not do our homework? If we had a central authority leading a team (or teams) of developers – or at least, leading developers for X hours a week – The question is, who will it be. then we could “enforce” reviews. Maybe July-August would be directed towards the graphical display of rhythms. That team would dissect any patch for beaming, drawing longas, etc; any patch to the parser would be ignored (at least, ignored during the X hours of team work). What about new contributors? It would be bad to tell them you want get much help on this during next 5 months, come back again in December when we'll discuss fonts. In general, count me in (i don't know for how many hours yet). Additional idea: when there are teams, work can be split. One person can research proper notation, another write the code, another prepare some regtests, another write docs. Not everyone is good with all these. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: review process not working
I agree with Graham that it's a matter of bad luck (i.e. stuff happens). If i understand Graham correctly, the idea of countdown is not to add some beaurocratic order, but to force us to speak now, or forever be silent (tongue-in-cheek, of course). In other words, a patch without reviews is not put on countdown because it certainly must be good, but precisely to *get* some reviews. 2011/7/26 Graham Percival gra...@percival-music.ca: On Tue, Jul 26, 2011 at 07:36:43PM +0200, David Kastrup wrote: So it needs to tell its story in comments. It doesn't. There is a lot of code in Lilypond that nonchalantly expects people to get along without commenting what it does. This is often a nuisance, but if the code is written by a master, the pain of figuring out what it does is usually tolerable. Very true; I think that almost all developers (if not all!) would like to see better comments in the code! I'd like to see them for certain. Could you get into the habit of pointing out questionable / unclear parts of code in future patches, so that the author will explain them in comments? I'll try. This will probably be easy; as i won't understant anything i'll ask for comments everywhere :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postscript printer errors with rounded barlines?
2011/7/27 Han-Wen Nienhuys hanw...@gmail.com: On Wed, Jul 27, 2011 at 3:23 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I think this is an other issue. Due to rounding, PDF viewers can err the placement of the barline by a pixel. This is insolvable, as there is no way to hint that the barline should coincide with the staffline, yet we need to go the end of the barline to get the correct effect in the corners in staves. I'd accept this if it were not for the fact that Finale seems to handle this perfectly. I've never experienced any sticking out barlines in Finale pdfs, neither on screen nor in print (i can send you some if you want). Also, the thickness of the stems and barlines is consistent in Finale pdfs (i.e. it looks like second image from here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00076.html while Lily output looks like first one). I'd say that the fact that Finale does something this basic better than LilyPond is a serious insult to us, given how much Finale sucks in these matters (for example in flag attachment, see attached). You can make the problem disappear by - hard coding the output to a certain resolution Umm, i don't understand what you mean... - making the bar go to the middle of the staffline, rather than the outside. I have a patch doing this: http://codereview.appspot.com/4809057 both have disadvantages. (what does finale's barline at the end of a staff look like?) Sharp and pointy, example attached. cheers, Janek Canticorum.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 6: private mailing lists (probable decision)
2011/7/27 Graham Percival gra...@percival-music.ca: Most people seem to like the status quo. http://lilypond.org/~graham/gop/gop_6.html ** Proposal summary Potentially sensitive or private matters will be referred to Graham. He will then decide who should discuss the matter on an ad-hoc basis, and forward or CC them on future emails. For emphasis, the project administrators are Han-Wen, Jan, and Graham; those three will always be CC’d on any important discussions. The lilypond-hackers mailing list will be removed. I'm fine with this. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Figured Bass extenders syntax
2011/7/26 Reinhold Kainhofer reinh...@kainhofer.com: PS: I like the idea of using ties for the extenders, because that's exactly what an extender is meant to express! +1! +1! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Postscript printer errors with rounded barlines?
2011/7/26 Han-Wen Nienhuys hanw...@gmail.com: On Sat, Jul 23, 2011 at 7:45 PM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: I'm not experienced with PostScript, but i have an impression that this may be related to an issue discussed earlier - see here http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00485.html and here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00072.html I see that something about draw_round_box was said there... I think this is an other issue. Due to rounding, PDF viewers can err the placement of the barline by a pixel. This is insolvable, as there is no way to hint that the barline should coincide with the staffline, yet we need to go the end of the barline to get the correct effect in the corners in staves. I'd accept this if it were not for the fact that Finale seems to handle this perfectly. I've never experienced any sticking out barlines in Finale pdfs, neither on screen nor in print (i can send you some if you want). Also, the thickness of the stems and barlines is consistent in Finale pdfs (i.e. it looks like second image from here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00076.html while Lily output looks like first one). I'd say that the fact that Finale does something this basic better than LilyPond is a serious insult to us, given how much Finale sucks in these matters (for example in flag attachment, see attached). The one-pixel error is very noticeable on-screen due to low-resolution, but on a 1200dpi printer, a single dot error is about 0.02 mm, ie. not noticeable. I'm not sure whether you are referring to how it looked before your patch or how it looks after it. Before your patch it was certainly noticeable enough - even my friend Luke, who doesn't care that much about the details, said it irked him. As for how it looks after your patch - I hoped to be able to do some prints on my choir's printer to see how things looks like now, but it ran out of toner - new cartridge should be available in next week. Besides, many printers have resolutions lower than 1200dpi. cheers, Janek attachment: sucking Finale flags.PNG___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Figured Bass extenders syntax
+1
...GLISS?
cheers,
Janek
2011/7/25 Bertrand Bordage bordage.bertr...@gmail.com:
Hi all,
I am currently working on some huge figured bass projects and there's
something truely annoying and quite unnatural:
when using \bassFigureExtendersOn, we need to tell LilyPond when we don't
want an extender (by adding \! to the number) instead of telling when we
want one.
I'm making a lot of errors because of this :( .
This should behave like the lyric extenders. With a similar syntax. I know
that it's more tricky because we have parallel figures. Maybe a tilde would
be better since _ is used for the empty figure and tilde already exists in
chords.
Something like this:
\figuremode{
6+ 4 34 4 _+ _!2 64 6 52~ 54 5 3~2 6 34
}
We could get rid of figuredBassCenterContinuations too: 5~ 3~ 5 3 would
mean two extenders while 5 3~ 5 3 means one.
Regards,
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)
2011/7/24 lemzw...@googlemail.com: I don't mind if we have another obscure entry in the detail list currently. If your patches fixes the problem reliably, this would be a great immediate help. IMHO, at some point in the hopefully not too distant future, the whole handling of slurs and ties must be re-examined to make it more user-friendly and robust, and to improve its shapes, both on the macro and micro level. Additionally, due to the very graphical nature of the problem, it deserves a texinfo-like documentation (with many, many images), to be generated from the corresponding comments in the source code files. +100 I'm currently preparing an extensive report on the matter of ties. I estimate that 30% of work is done. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: balloontext and footnotes - what's the difference?
2011/7/24 James Lowe james.l...@datacore.com: I'm wondering now what the *real* difference between the two are, other than \footnote[Grob] lets you add a footnote to a balloon text - albeit without the 'balloon'. Perhaps i'm not understanding something, but isn't the primary difference that with footnotes the explanation of a footnoted music appears on the bottom of page, while with ballons it appears inside the score, near the notes? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 6: private mailing lists
2011/7/22 Graham Percival gra...@percival-music.ca ** Proposal summary What should we do with potentially sensitive or private matters in lilypond? I see two possible solutions: 1. Pick one person to manage private discussions. 2. Have a private mailing list with a known list of people who will discuss such matters. I have a slight preference for the first option. But i don't think it really matters. 2011/7/22 m...@apollinemike.com m...@apollinemike.com: The sole issue of trust is one of representation, and I think that Graham represents the project very well and can decide who to pass certain discussions onto. +1 2011/7/22 Trevor Daniels t.dani...@treda.co.uk: I would be in favour of a fixed private mailing list with publicly known members to decide a publicly known list of issues, including the obvious granting/withdrawing git push access, but probably little else. Membership should be either Graham, Han-Wen and Jan, or these three supplemented by two others. Requests for a private discussion would be sent to this list, avoiding the single-Graham point of failure. Other issues which are better discussed in private should be conducted by an ad hoc group chosen to suit the issue, since these are likely to be rare and diverse. The membership of such groups could be on the list of issues decided on the private mailing list described above. This sounds reasonable. 2011/7/22 Valentin Villenave valen...@villenave.net: And first off, obviously, it should be officially acknowledged that such non-public discussions exist. ?? It's obvious that non-public discussion do and will exist. The only important thing is what they are about (i.e. something important for the project, like giving push access or beginning an official collaboration with some university or organization). 2011/7/24 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: I'll reiterate that I don't think this is a great long-term solution -- I view the private CCing idea as a temporary compromise for the next 12-18 months. Once we've gotten into the habit of regular releases, a more firm set of development proposals+guidelines, and GLISS done, we should look at having an official steering committee or board of directors or something like that. I am somewhat afraid that it may amount to social overengineering for a project of this size. Factions, votes, in- and outsiders might detract more than they help. On the other hand, your listed preconditions don't sound like they would make those measures imminent real soon. Hey, don't we hope to attract hordes of new developers in the months-to-come? ;) Yes, a formal institution like that will make sense only when our development team will grow *much* larger. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable decision)
2011/7/21 Graham Percival gra...@percival-music.ca: Not much response from the previous GOP-PROP 5 (update); I'm not certain if silence is a form of consent [1] in this context. In my case it is, i guess :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable decision)
2011/7/21 Trevor Daniels t.dani...@treda.co.uk: In my case it's because I have difficulty in understanding precisely what the effect of this change will be on any work I do. But I have one comment. By far the commonest use of make by developers is to compile the most recent change to C++ source during the development cycle. To speed this cycle up one usually watches the console to follow progress. If the compile fails you need to immediately see the error messages on the console. It would be a nuisance if you had to fish these out from a file somewhere. If the compile and link succeed, you usually ctrl-C out of make as soon as linking has finished so you can get on with testing. So you need to see the relevant messages on the console to determine this. I'm not sure if i understand your workflow, but I think a far better solution than watching console output is to use a script. I attach a scipt that i use for this, it saves me some time. HTH, Janek makeandtest Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable decision)
2011/7/23 Trevor Daniels t.dani...@treda.co.uk: Jan Warchoł wrote Saturday, July 23, 2011 1:39 PM 2011/7/21 Trevor Daniels t.dani...@treda.co.uk: If the compile and link succeed, you usually ctrl-C out of make as soon as linking has finished so you can get on with testing. So you need to see the relevant messages on the console to determine this. I'm not sure if i understand your workflow, but I think a far better solution than watching console output is to use a script. I attach a scipt that i use for this, it saves me some time. Not really. If you have changed only one or two C++ routines the compile and link part of make take only a few seconds. There's no point in letting it go on to check all the doc files. Ah, i didn't know that! This can be very useful. However, i tried doing make and i didn't knew when i could interrupt it :( So really no time is wasted watching the console output. In my case there are usually compile errors to fix most of the time, so it takes even less time :) Actually Graham's suggestion to have a compile and link only target in make was a good one. That would save having to ctrl-C out. I'd like that too! thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond releases and GLISS roadmap
+1 everything +1 Graham in general :) cheers, Janek 2011/7/23 Graham Percival gra...@percival-music.ca: On Fri, Jul 22, 2011 at 11:49:40AM +0200, Xavier Scheuer wrote: Is there a roadmap of future releases of LilyPond (2.16, 2.18, 3.0), That discussion will happen in GOP: http://lilypond.org/doc/v2.15/Documentation/contributor/policy-decisions as well as a roadmap for the GLISS available somewhere on the LilyPond website? That is not yet written. Actually there has been a request on the French users mailing list that is actually issue #1316, which is currently Priority-Postponed waiting for the GLISS. It will wait some more. On CG 14.5 Grand LilyPond Input Syntax Standardization (GLISS) it is said that [GLISS will start] sortly after 2.14 comes out, which is currently estimated to happen in January 2011. I suppose I should change that. Where could we find up-to-date information about future LilyPond releases and Grand Projects roadmaps? You can't. I do 10 hours a week. I'm not going to start GLISS until I have at least 4 weeks of GOP policy questions prepared for discussion, and at least 2 weeks of GLISS material prepared. The more mundane tasks people do, the more time I'll have for unusual stuff like GOP and GLISS. Admittedly, Colin and James are doing a fantastic job of keeping patches rolling along for the past few weeks. I've fallen behind because I'm at the annual family music camp. http://wcams.com/ which we do a lot of organizing for, in addition to attending for about 20 years now (I missed 2 years in that period, so I'm only at 18 years so far). This year, I'm skipping the main orchestra in order to keep up-to-date with lilypond emails (much to the disgust of some other violinists here who feel that I'm letting down the team by not playing in the orchestra). So I still have 10 hours left this week, and that will carry over into next week. With that extra time, I hope to schedule GOP stuff for all of August and even reaching into Sep. Once that's done, I'll do more preparation for GLISS, but I would be surprised if we start that in August. Depends a lot of how many release issues there are for 2.16. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change in treble clef - do you accept?
2011/7/17 David Kastrup d...@gnu.org: Reinhold Kainhofer reinh...@kainhofer.com writes: On Sa., 16. Jul. 2011 21:05:37 CEST, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/7/16 Han-Wen Nienhuys hanw...@gmail.com: 2011/7/15 Janek Warchoł lemniskata.bernoull...@gmail.com: Surprisingly, CueClef currently uses regular clef glyph scaled down 1.5874 times (font-size -4), not a scaled down change clef. There is no particular reason I used a scaled regular clef, IIRC. We might just as well use a scaled change clef... Feel free to change that. What clef then to use for clef changes in a cue voice? I didn't know that it's possible to have clef changes in cue voice... But if it is, it might indeed be more clean to leave it as it is (i.e. use scaled regular clef for cue notes). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change in treble clef - do you accept?
2011/7/17 Reinhold Kainhofer reinh...@kainhofer.com: On So., 17. Jul. 2011 09:41:02 CEST, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: 2011/7/17 David Kastrup d...@gnu.org: Reinhold Kainhofer reinh...@kainhofer.com writes: There is no particular reason I used a scaled regular clef, IIRC. We might just as well use a scaled change clef... Feel free to change that. What clef then to use for clef changes in a cue voice? I didn't know that it's possible to have clef changes in cue voice... But if it is, it might indeed be more clean to leave it as it is (i.e. use scaled regular clef for cue notes). I have never tried it, but I don't think clef changes in cue notes work properly. I think they will mess up the original clef of the staff... Still, we might want to support it someday, so better leave this as is, i.e. use scaled down regular clef as the CueClef. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git-cl is down
2011/7/17 Carl Sorensen c_soren...@byu.edu: On 7/16/11 5:37 PM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote: IMO, we should be aiming at one commit per Rietveld issue, rather than a series of commits per Rietveld issue. That's beside the point, at least as far as I understand it. - Bertrand writes some code. - Bertrand makes a git commit. That commit has a nice message, it has his name, etc. - Bertrand gets this patch onto Rietveld using git-cl. More common, patch needs some changes. So Bertrand makes some changes and then makes a git commit. This commit reflects the changes. Then Bertrand pushes a new patch set. This happens a couple of times. Now Bertrand's repository doesn't have one commit on this branch, he has three or four commits on his branch. And the first two or three are not right -- they haven't passed code review. The final patch set passes code review. Graham wants to push this patch set. But he can't, unless he writes his own commit message and sets the author. But if Bertrand has been uploading as he did with his test issue, there are *3* patches, not *1*. And the first 2 are not accepted, so we don't want them in our source tree. They might even break compiling; if so, they'd mess up git bisect. Since we're only ready for committing after getting approval, we need to combine into a single commit after approval. Either you can do it (creating your own metadata, as you said) or he can do it (using git rebase -i). But somebody needs to make the change to the commits in order get them ready for pushing. Just for the record: i often make typos or style mistakes (in addition to regular fixes needed), so i often have more than 5 commits for a single issue, many of them with the message blalah, fix or something like that. I usually do rebase -i when i feel the patch is finished and there are no unsolved comments; it's usually during countdown. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git-cl is down
2011/7/16 Bertrand Bordage bordage.bertr...@gmail.com: Hi all, As mentioned in the title, git-cl's repository on neugierig.org is down. It looks like this project isn't supported anymore. I suggest we rewrite the last part of CG 3.3.4 Uploading a patch for review. In fact, why were we using git-cl ? What is git-cl providing that can't be done with upload.py from Rietveld codereview ? The doc should be explaining how to use upload.py. Furthermore, there's something we should solve : upload.py is just uploading diffs instead of full git commit patches. By changing a line on upload.py, we can easily change this git diff for a git format-patch. I created a fake issue to show the result : http://codereview.appspot.com/4721041/ When you click download raw set, this gives you what is really expected. Unfortunately, this changes the syntax of the input arguments of upload.py. The result is that it is no longer possible to upload a commit other than the latest. But the idea should be further explored, since it would save Graham's time. If you agree with this, the first thing to do would be to create an issue on http://code.google.com/p/rietveld/issues/list Wouldn't this be best discussed in connection to GOP Issue tracking with google code Patch review tool topics? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (update)
2011/7/14 Graham Percival gra...@percival-music.ca: ** Proposal summary When you run make or make doc, * All output will be saved to various log files. (including output from make(1)) * We will still display the output of make(1) on the console. * No other output will be displayed on the console, with one exception: if a build fails, we might display some portion(s) of log file(s) which give useful clues about the reason for the failure. * Logfiles from calling lilypond (as part of lilypond-book) will go in the relevant ‘build/out/lybook-db/12/lily-123456.log’ file. All other logfiles will go in the ‘build/logfiles/’ directory. * Both stderr and stdout will be saved in *.log. The order of lines from these streams must be preserved. * There will be no additional “progress messages” during the build process. If you run make --silent, a non-failing build should print absolutely nothing to the screen. * Ideally, a failing build should provide hints about the reason why it failed, or at least hints about which log file(s) to examine. LGTM. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-hour countdown
2011/7/12 Colin Campbell c...@shaw.ca: 21:00 MST Wednesday July 13 Reitveld Issue 4664060: Adds redirect-lilypond-output option to lilypond-book Issue 1736: clarify description of minimal examples - Reitveld Issue 4636082 Issue 1739: doc: correcting note about rerunning regtests - Reitveld Issue 4675048 ? This already was on the previous countdown, i've send patch to Mike for pushing. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Converting ly to musicxml
2011/7/11 cab www.big...@free.fr: About the website, I programmed an engine to search for melodies in scores, and then I use lilypond to display the score and to hear the music Ahh, sounds very nice. However, i haven't found any links section on lilypond.org and i think that it doesn't really fit to the Published sheet music section in introduction-productions. Maybe we want to create a links section? as for the ly- xml converter, I have been thinking of reusing the to-xml.scm (yeah i think I just grasped how lilypond was built) I would just remove the *-strings part, replacing them with (define-method (display [])) like in font.scm. But I don't know yet how I would build the xmldoc tree (once everything is programmed), What do you think about it ? Am i wrong doing so,(it would my first time contributing to the open-source community). Hmm, i'm not the tech-guy, so i'm afraid i cannot help you here... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make test-baseline fails
Jan's translation 446103a87933b297c209e87fec94e97fe9462ad0 is also my latest commit. make test-baseline worked for me. I'll build again from scratch just to make sure. 2011/7/12 James Lowe james.l...@datacore.com: Hello, I'v done this a couple of times now and cannot get a make test-baseline to work After pulling (Jan's NL translation is my latest commit in gitk) I get --snip--Traceback (most recent call last): File ../../scripts/lilypond-book.py, line 684, in module main () File ../../scripts/lilypond-book.py, line 666, in main chunks = do_file (files[0]) File ../../scripts/lilypond-book.py, line 560, in do_file do_process_cmd (chunks, input_fullname, global_options) File ../../scripts/lilypond-book.py, line 416, in do_process_cmd outdated = [c for c in snippets if c.is_outdated (options.lily_output_dir, output_files)] File /home/jlowe/lilypond-git/python/out/book_snippets.py, line 729, in is_outdated found, missing = self.all_output_files (output_dir, current_files) File /home/jlowe/lilypond-git/python/out/book_snippets.py, line 713, in all_output_files system_count = int(file (full + '-systems.count').read()) ValueError: invalid literal for int() with base 10: '' make[3]: *** [out-test/collated-files.texi] Error 1 make[3]: Leaving directory `/home/jlowe/lilypond-git/input/regression' make[2]: *** [local-test] Error 2 make[2]: Leaving directory `/home/jlowe/lilypond-git/input/regression' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/jlowe/lilypond-git' make: *** [test-baseline] Error 2 jlowe@jlowe-lilybuntu2:~/lilypond-git$ --snip-- Make itself works fine. Could someone else verify this? 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: Make test-baseline fails
2011/7/12 Jan Warchoł lemniskata.bernoulli...@gmail.com: Jan's translation 446103a87933b297c209e87fec94e97fe9462ad0 is also my latest commit. make test-baseline worked for me. I'll build again from scratch just to make sure. I confirm: make test-baseline compiles from scratch. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Converting ly to musicxml
2011/7/10 cab www.big...@free.fr: Converting from midi to ly is possible, but ly to musicxml has never been done... So my plan is to program it myself I think I would do it in python as musicxml2ly is also written in python. If I manage to do it , will it be possible to add it in the source tree ? If done nicely (i mean, not as an ugly hack) it will be most welcome! If you have any difficulties with setting up your development environment (installing and running Lilydev, handling git) i'll gladly help. And a last request , can you link my website (psautiers.org or score-catcher.org or both) from your website? Well, i cannot say anything about it because i don't read French so i don't know what is it about :) Besides, i don't recall any links section on our website. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: 48-hour countdown
2011/7/10 Carl Sorensen c_soren...@byu.edu: On 7/9/11 8:43 PM, Colin Campbell c...@shaw.ca wrote: 21:00 MST Monday A paltry pile of patches presented, presumably prior patches (of which there are a metric shedload marked for review) preoccupying people. Issue 1735 http://code.google.com/p/lilypond/issues/detail?id=1735 : modifying default behaviour of tremolo slashes, Reitveld Issue 4636081 http://codereview.appspot.com/4636081/ : It seems to me that this patch is not yet approved. There is a major objection; it could be resolved by making an easily adjusted setting part of the patch. But it is premature to push this patch before revising it, IMO. Yes, it's not ready - sory for forgetting to update label. I'll work on it, but i need to close other issues first. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output
2011/7/7 Graham Percival gra...@percival-music.ca: A variable, QUIET_BUILD, can be set and this will reduce the clutter but not eliminate it. (see http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables ) This variable currently does things like adding a -q flag to the TEXI2PDF call (quiet) and getting rid of the –verbose flag in some calls to LilyPond. However, it could be used more widely, as proposed below. ** Proposal * We do not change the output of make, make doc, or any of the other make commands - this is the default. * We use the variable QUIET_BUILD to signal to the make system that we want the minimum of progress output visible on the terminal, with all other output going to logfiles I'd make this quiet build default. I'm a fan of making things work nicely by default (i guess that most of the people will prefer quiet build - if not, it should not be default ofc). Perhaps it's partly because i'm a noob in some areas - for example i didn't know about QUIET_BUILD. * Wherever possible, the logfiles should be put in the ‘build/logfiles’ directory - which will have to be created as part of configure * Wherever possible, stderr output should go to *.err.log and stdout output to *.log * Running (for example) make -s QUIET_BUILD=1 doc should give the occasional progress message to indicate where it has reached in the build process, but a such a rate that it’s easy to read and a volume that allows the user to see the top of the output in terminal Sounds reasonable. * Ideally, running (for example) make -s QUIET_BUILD=1 on a build that fails should make it easy to see the file causing the build to fail. +1 2011/7/7 Matthias Kilian k...@outback.escape.de: On Thu, Jul 07, 2011 at 01:16:21PM +0100, Graham Percival wrote: * Wherever possible, stderr output should go to *.err.log and stdout output to *.log Wouldn't it be better to either collect both stdout and stderr in the same log file or to use three log files .err.log, .out.log and .log, where the latter contains the combined streams? Otherwise you are loosing the context between the two, which sometimes may be important. This sounds nice to me. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3 - C++ formatting (probable decision)
2011/7/4 Graham Percival gra...@percival-music.ca: I propose that we use a modified fixcc.py using astyle internally. * the final script will be run blindly on the lilypond source code. We will accept whatever formatting the final version of this script produces, with no manual tweaking. +1 * patches which have been run through this tool will not be rejected for style reasons. Any code formatting “desires” which are not enforced by fixcc.py will not be considered grounds for rejecting a patch. +1 [everything] +1 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 4: lessons from 2.14
2011/6/30 Han-Wen Nienhuys hanw...@gmail.com: Overall, I think this cycle took too long. As i'm pretty new here, i cannot compare this cycle to previous ones, but i think i agree :) 2011/6/30 m...@apollinemike.com m...@apollinemike.com: On Jun 30, 2011, at 4:17 PM, Han-Wen Nienhuys wrote: We should strive to have policies that make each development release be a worthy stable candidate. That means -for example- being serious about * changes passing through the regtest * bugfixes and features always having a test to check against I agree, and I'd go further to add that one of the problems with the 2.13 process towards the end was a difficulty in anticipating what to make regtests look like so that they tested all possible contingencies. In order to make sure that the regtests are robust w/o forcing each change to go through 5 hours of regression testing, I propose that before each minor release, a large regression test is run on a suite of real-life pieces followed by a pixel comparison. This'd take a while, but it'd provide a periodic check to nip problems in the bud. I like this idea, but i'm not sure if it will be feasible without a *very* smart program that would compare the results. The main problem i anticipate is that real-life pieces are much longer than regtests and therefore any change in spacing may easily result in different line breaks - and i suppose different breaking means that comparing outputs by machine is impossible, unless some very advanced algorithms are used (and i don't know if such are available at all). In other words, the check would probably have to be executed by a human, and preferably the same person every time (as (s)he will eventually memorize all this pieces - that would make comparison easier). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 4: lessons from 2.14
2011/6/30 Graham Percival gra...@percival-music.ca: On Thu, Jun 30, 2011 at 12:34:56PM -0300, Han-Wen Nienhuys wrote: On Thu, Jun 30, 2011 at 12:21 PM, Graham Percival gra...@percival-music.ca wrote: Daily tests would be awesome: http://code.google.com/p/lilypond/issues/detail?id=933 We used to have this, but it was rather fragile, so it only caught compilation errors, and no regtest breakage. Catching compilation (make and make doc) errors, and telling us exactly which commits occurred between the last successful build and the current failing attempt, would still save on average 5 hours of developer frustration each month. (oh, also running make distcheck) +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting (update)
2011/7/3 Graham Percival gra...@percival-music.ca: On Sat, Jul 02, 2011 at 03:13:05PM -0700, Keith OHara wrote: On Sat, 02 Jul 2011 13:19:23 -0700, Graham Percival gra...@percival-music.ca wrote: [...] but I'd still want to run fixcc.py on the entire repo. Why run an indenter over the entire repository? Simply having the indenter tool available for individual commits would solve the problem. 1. newbies tend to trust that the existing material shows how they should do things. It's confusing if we have to tell them not to follow the existing style. +1 !! 2. if we indent files in conjunction with patches, then each patch will display a huge number of irrelevant changes -- given that we're changing the indentation tabs, pretty much the entire file will change. Any important diffs will be lost in the sea of everything changed diffs. Granted, git can avoid this with the ignore-whitespace diff option, but IIRC astyle and fixcc.py also produce some other changes. +1 ! As for the actual formatting discussion, it got a bit too technical for me, but i'm fine with any option you choose as long as it's easy to use (automated as much as possible) and indents are in GNU-style. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: does anybody care about LSR?
2011/6/29 Reinhold Kainhofer reinh...@kainhofer.com No, that won't happen. LSR is something like a searchable FAQ for both common cases and special cases. Unless the manual gets some REALLY good search capabilities and anchors that you jump just to the right point without having to read through whole sections to find what you want, the LSR is just way more comfortable to work with. +1. The ease of searching is what makes LSR useful. Try searching for something in http://lsr.dsi.unimi.it/ and in http://lilypond.org/doc/v2.15/Documentation/snippets/index.html There are only two things that i don't like about LSR: i'd love to see all snippets at once, without the need to click through several pages. Also, preview of big snippets isn't very helpful. Everything else is great imo! 2011/6/29 Graham Percival gra...@percival-music.ca: On Wed, Jun 29, 2011 at 04:39:39PM +0100, Phil Holmes wrote: My suggestion would be: unless the snippet is tagged docs abandon the above and blind authorise if it compiles. How does this sound? Totally fine with me! +1 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: does anybody care about LSR?
2011/7/3 Francisco Vila paconet@gmail.com: 2011/6/28 Graham Percival gra...@percival-music.ca: If somebody here *does* care, then speak up. Please note: Sorry for the very late answer. I only wanted to say that LSR has been very helpful until now, both for me and the members of the Spanish-speaking community. I've found that most of the questions in the list can be answered with only a search word for the LSR and a look at first result. +1 A pity it goes down sooo frequently, I ignore if it's hardware or configuration to blame. I hope we will resolve this when we discuss Subdomains of *.lilypond.org GOP issue. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 4: lessons from 2.14
2011/6/30 Graham Percival gra...@percival-music.ca Oh, and thank you, Graham, for putting so much effort into organizing Lilypond development. One of the lessons learned IMO, though you may not like it, is that active leaders are necessary to push along a project of this size. Agreed. Thanks! I always worry about pushing too much (for example the recent does anybody care about LSR thread), so it's good to hear that other people appreciate the organizing efforts. I was a bit surprised when i saw that thread, but it's fine :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
2011/6/22 Graham Percival gra...@percival-music.ca: Speaking academically, C++ code style is a solved problem. Let’s pick one of the existing solutions, and let a computer deal with this. Humans should not waste their time, energy, and creativity manually adding tabs or spaces to source code. I see three main contenders: * emacs x.y.z with extra post-processing: our current “official” style with scripts/auxiliar/fixcc.py * astyle 2.0.2, possibly with extra post-processing * uncrustify 0.58 Ok, since comparing gperciva-fixcc and gperciva-astyle branches didn't work for me, plese verify whether i understood correctly: - we are discussing which program we will use for code formatting, not the actual style - each of the suggested programs uses style similar to http://en.wikipedia.org/wiki/Indent_style#GNU_style so whatever we choose, the results will be quite similar. Right? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
2011/6/26 Graham Percival gra...@percival-music.ca: On Sun, Jun 26, 2011 at 03:47:11PM +0200, Jan Warchoł wrote: Ok, since comparing gperciva-fixcc and gperciva-astyle branches didn't work for me, plese verify whether i understood correctly: - we are discussing which program we will use for code formatting, not the actual style Yes-ish. We are discussing which program we will use for code formatting, and the style will therefore be defined as the output of whichever program we choose. - each of the suggested programs uses style similar to http://en.wikipedia.org/wiki/Indent_style#GNU_style so whatever we choose, the results will be quite similar. Right? I would say vaguely similar. Some programs have bugs. We may use more than one program (for example fixcc.py) for the formatting, and any one of those programs may have bugs. etc. The difference between output of astyle and fixcc is 778Kb, and is 23173 lines long. ok. As long as braces indentation stays the same (i.e. it's GNU style), i'm fine. Let's choose the simplest solution, which doesn't require installing anything and can be automated as much as possible. I guess it means fixcc. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
W dniu 23 czerwca 2011 00:03 użytkownik Carl Sorensen c_soren...@byu.edu napisał: For the short term, you can do git pull origin dev/gperciva-fixcc git pull origin dev/gperciva-astyle to get those branches. I understand that i should call these in separate branches, not in master. ...something doesn't work: janek@janek-lilydev5:~/lilypond-git$ git branch astyle janek@janek-lilydev5:~/lilypond-git$ git checkout astyle Switched to branch 'astyle' janek@janek-lilydev5:~/lilypond-git$ git pull origin dev/gperciva-astyle From git://git.sv.gnu.org/lilypond * branchdev/gperciva-astyle - FETCH_HEAD Auto-merging lily/beam.cc CONFLICT (content): Merge conflict in lily/beam.cc Automatic merge failed; fix conflicts and then commit the result. I'm not desperate to see these differencies, so if it's a trouble to fix this/explain it to me then don't bother. Btw, Graham wrote origin/dev/gperciva-fixcc, and Carl wrote origin dev/gperciva-fixcc (with a space). Why? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs - probably decision
2011/6/22 Graham Percival gra...@percival-music.ca On Wed, Jun 22, 2011 at 12:11:36PM -0600, Carl Sorensen wrote: I think that the implied obligation is saying Mike will help people who are playing with beam collision avoidance. Perhaps the word expectation would better express my worry. Ah, expectations and obligations are two completely different things! I agree that it will cause some expectations, but similar expectations are caused by the sheer fact that someone worked on some piece of Lily (which can be observer by his activity on -devel or in git log). For example, i expect Han-Wen is able to give advice on virtually everything - if he has time to look at my work. Suppose Janek says hey, I want to work on frets to -devel, then Graham repliesr to say great! Go talk to Carl, he's the expert on them. Then Janek emails Carl personally (maybe cc'd to -devel, maybe not). A conversation in this tone going on on -devel would not be appropriate regardless of what i suggested, i think :) In my vision it looked like this: me: i'm working on a patch related to frets, but i'm stuck here. Please help 2 days of silence Graham: you may try to ask Carl about it, he has worked on them before. He may be able to help you - if he has time, that is. 1. will Carl feel that he should reply because Janek cc'd him? 2. will Carl feel that he should reply because Graham said, publicly, that Janek should talk to him? 3. if Carl is busy and ignores the cc'd email, will Janek feel disappointed? At the moment, I see little evidence that emails to -devel are routinely ignore by people who would want to answer them but just didn't notice that email. In the past 3 years, I can think of perhaps a dozen cases where this happened -- but with the PATCHES: 48-hours emails and the GOP-PROP emails, I think the danger of this miscommunication is much lower. ok, i'll not argue with facts. I can only say that right now because of GOP and other things majority of -devel e-mails goes completely unnoticed by me; generally i only read those cc'd to my address. I'm not a very experianced programmer, but if anyone would have questions about basic metafont or something related to flags, i could help - if i notice. Think about it this way: at the moment, we don't even have a smooth process for developers. There's 33 outstanding patches, many of them by developers. 15 of them have been abandoned -- about half of them were abandoned because they were silly ideas, but the other half are totally doable if only we have a bit more discussion about how to finish the job. There's another 15 patches that currently need work... maybe indentation, maybe a bit more architecture rethinking, maybe stuff that's actually been abandoned but nobody's bothered to mark it as such. Well, ok. I won't insist on my idea (at least for now). That said, I want to treat people honestly. If that means discouraging some new contributors, then let's do that. Hopefully in 3-4 months we'll have the development process sorted out for developers, and then we can consider actively recruiting new contributors. But it really will be months before we're in any position to support such a recruitment effort. ok A question: are there (m)any people in the development team who started as developers right away, without being just users for some time? (besides Jan and Han-Wen, of course) Actually, I started as a developer right away, because I wanted guitar fret diagrams. It was only after that development that I ended up helping with the documentation work under GDP. True. In fact, a quick glance at the paconet lilypond stats suggests that out of the top 30 developers, only about 20% of them (including me) started off as just users. Interesting. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
2011/6/25 Graham Percival gra...@percival-music.ca On Sat, Jun 25, 2011 at 09:18:13PM +0200, Jan Warchoł wrote: I understand that i should call these in separate branches, not in master. janek@janek-lilydev5:~/lilypond-git$ git branch astyle That creates a new branch. I think you should have done the git pull origin dev/gperciva-style without making a new branch first. IIRC i tried it and it resulted in merge conflicts and generally messed-up repository. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 39 by raising stems (issue3934041)
Hi, have you considered fixing issue 39 by shortening the flag (as we're going to have plenty of shortened flags available)? Or maybe shortening a flag a bit ang lenghtening the stem a bit would be the best solution? As Carl found a way to separate flags from noteheads in font (http://codereview.appspot.com/4662055/), the work on shortened flags starts moving again. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
2011/6/22 Graham Percival gra...@percival-music.ca: I see three main contenders: * emacs x.y.z with extra post-processing: our current “official” style with scripts/auxiliar/fixcc.py * astyle 2.0.2, possibly with extra post-processing * uncrustify 0.58 I'm confused. Are we talking about choosing indent style or choosing the tool that will automatically apply whichever style we want? ** Eliminate tabs I’m going to make the bold step of assuming that we will eliminate tabs in all C++ files. +1. Let's just say NO to tabs. ** Detailed analysis of emacs+post vs. astyle You can compare the results directly with this: git diff origin/dev/gperciva-fixcc origin/dev/gperciva-astyle when i call this in ~/lilypond-git, i get fatal: ambiguous argument 'origin/dev/gperciva-fixcc': unknown revision or path not in the working tree. ...? I went to http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=heads and compared some files manually, but there were almost no differencies - am i missing something? cheese, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
2011/6/22 Graham Percival gra...@percival-music.ca: On Wed, Jun 22, 2011 at 08:10:50AM +0200, Jan Warchoł wrote: I'm confused. Are we talking about choosing indent style or choosing the tool that will automatically apply whichever style we want? Specifying a code style would be far too much work, and/or would leave too many things undefined/ambiguous. Much easier to pick a tool, look at the output, tweak the tool/options if necessary, then declare the output of that tool to be our standard. ok. Good approach, i like it :) git diff origin/dev/gperciva-fixcc origin/dev/gperciva-astyle when i call this in ~/lilypond-git, i get fatal: ambiguous argument 'origin/dev/gperciva-fixcc': unknown revision or path not in the working tree. ...? Hmm. You're in the lilypond source directory, right? And you did a git pull first? I didn't know it's needed :O Something new to learn. I went to http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=heads and compared some files manually, but there were almost no differencies - am i missing something? There are plenty of differences. If you get the git diff command to work, you'll see. It still doesn't work. I'm in top source directory, on branch master which is up to date (and git diff origin/master shows no differencies) and when i call git diff origin/dev/gperciva-fixcc origin/dev/gperciva-astyle i get the same error: fatal: ambiguous argument 'origin/dev/gperciva-fixcc': unknown revision or path not in the working tree. Use '--' to separate paths from revisions I tired inserting -- at random places, but to no avail. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 3: C++ formatting
2011/6/22 Graham Percival gra...@percival-music.ca:
On Wed, Jun 22, 2011 at 12:54:15AM +, Keith OHara wrote:
Graham Percival graham at percival-music.ca writes:
My preference is just to say
let’s just use fixcc.py strictly.
Even those of us who fear emacs could probably run that script on changed .cc
.hh files before each commit.
Note that even people who use emacs will need to run that script
before each commit -- it contains tons of rules like:
('([\w\(\)\]])([ \t]*)(\.|-)([ \t]*)([\w\(\)])',
'\\1\\3\\5'),
('(\w+::\w+|[A-Z]\w*) ((\w+::\w+|[A-Z]\w*)[A-Z]\w*) ',
'\\1\\2 '),
which must be applied after emacs has done its formatting.
We may even want to add a git hook to call this script for commits
or pushes.
That would be great!
I'd very much prefer not to have to use another tool (i.e. Emacs) for
formatting.
Having style fixed automatically would be best i can dream of!
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs - probably decision
More ideas. Problem 1: a Frog tries to modify wind diagrams code and experiences some difficulties. (S)he sends an e-mail to -devel, but gets no answers because developer X (who wrote that code) overlooked his/her e-mail, and noone else knows the answer. Solution: a list of developers with specializations, for example: - beaming: Han-Wen, Mike, Z - slurs: Han-Wen, Z, Y - wind diagrams: X - grace notes: Han-Wen - dynamics: Z, U, Han-Wen ;) Our Frog finds that wind diagrams were written by X and sends his/her mail to -devel *and* X. X doesn't overlook the e-mail (because it's adressed directly to him), helps the Frog and everyone is happy :) Of course that list doesn't need to be super-precise or complete - simply something more detailed than authors.itexi and more readable than git log. I don't think that much effort would be needed to create and maintain it. Problem 2: an Enthusiastic User writes to -devel: it would be great if Lily supported foobar!. Graham replies: sure, add it yourself. and nothing else happens. Graham is right, but user gets discouraged. Solution: Graham (or anyone else) tells Enthusiastic User: sure, add it yourself. You may ask X for some clues - he is experienced with foobaz, so he may be able to help you with foobar or sure, add it yourself. If you have trouble, search our list of developers link for people who are familiar with foo-issues and may give you some clues. Thoughts? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs - probably decision
2011/6/22 Graham Percival gra...@percival-music.ca: On Wed, Jun 22, 2011 at 04:06:17PM +0200, Jan Warchoł wrote: Problem 1: a Frog tries to modify wind diagrams code and experiences some difficulties. (S)he sends an e-mail to -devel, but gets no answers because developer X (who wrote that code) overlooked his/her e-mail, and noone else knows the answer. Solution: a list of developers with specializations, for example: No. I absolutely reject any solution which lays any kind of obligation (implied or explict) on people. See the second paragraph of rationale: http://lilypond.org/~graham/gop/gop_2.html I remember it. I don't want to suggest laying implied obligations on anyone. Maybe there's a misunderstanding, so let's make things clear: do you say that asking Mike (who wrote automatic beam collision avoidance) Mike, I'm trying to improve automatic beam collision avoidance, but i can't figure out what foobar does. Can you give me some clues? is laying implied obligations on him? I don't think so. I think it's natural to ask questions to people who are experienced in the area that interests you, they can always say no or ignore you. Of course it should be made clear that they are free to ignore you - and i see nothing wrong in that. I have an impression that if we were to follow this no implied obligations policy strictly, we should delete authors list entirely. Yet i don't suppose anyone wants to do this. One thing that i definately agree is that it mustn't be obligatory to be on the list i proposed. I know that i would gladly be; if anyone has a problem with flags code i'll gladly help, no need to bother more experienced devs. Problem 2: an Enthusiastic User writes to -devel: it would be great if Lily supported foobar!. Graham replies: sure, add it yourself. and nothing else happens. Graham is right, but user gets discouraged. Is that a problem? :) We don't know, but probably it is. You said that Carl started as a documentation writer, so maybe that Enthusiastic User would become next project leader, after 3-4 years? You wrote yourself that recruiting new developers is crucial for the project. Of course encouraging enthusiastic users is a job for Frog Meister, not you, i agree. A question: are there (m)any people in the development team who started as developers right away, without being just users for some time? (besides Jan and Han-Wen, of course) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs
2011/6/18 Graham Percival gra...@percival-music.ca Well, I'm not encouraged by the general disinterest in this topic. I'm afraid it's because this problem isn't about finding some new solutions or establishing a policy (like with C++ code formatting), but about doing more work. *Maybe* someone will discover a great idea that will help with mentoring, but i don't think it can be so easy. It's rather about we have to put more effort in mentoring. Who wants to work harder and invest his time in a risky operation? (as you wrote mentoring is not always a gain to the project). Here's the responsibilities for mentors. Do any of these seem too heavy? We can relax/remove any that are a sticking point for many people. I see that these are the same that we have in CG plus one new, about weekly checks. [...] 5. Keep track of patches from your contributor. If you’ve sent a patch to -devel, it’s your responsibility to pester people to get comments for it, or at very least add it to the google tracker. I suggest to write about Rietveld reviews explicitely. I also think it should be mentor's responsibility, not a very least option, to add patch to google tracker. 6. Contact your contributor at least once a week. The goal is just to get a conversation started – there’s nothing wrong with simply copypasting this into an email: Hey there, How are things going? If you sent a patch and got a review, do you know what you need to fix? If you sent a patch but have no reviews yet, do you know when you will get reviews? If you are working on a patch, what step(s) are you working on? I suggest one more: if you are working on something not very difficult, ask your 'apprentices' to review *your* patches! In this case please review would mean please check if you can understand what is going on here. Of course it would require that your code is well commented. I see the following benefits: - contributors become more involved - contributors learn more about Lily internals - contributors feel valued - mentors learn how to comment their code well - well commented code is much easier to maintain and improve. (the last part is especially important to me because i spend more than half of the time figuring out how things work, so i'd like to see all code extensively commented; i suppose other Frogs can have similar problems as i have). Thoughts? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs
2011/6/18 James Lowe james.l...@datacore.com: Well I'm happy to help and of course I can 'mentor' someone around editing doc and formatting and uploading patches, however I seem to be of the 'rare' breed here that while understanding 'coding' principles and terminology, has no ability to write code (I can just about follow a relatively simple .py script). But I use the 'easy' tools (lilygit.tcl) and very limited git-cl and git commands, and so am probably less than useful to most potential contributors who probably know how to push a patch, can 'git their heads' (or is it 'head their gits'?) on the cli in their sleep. I cannot translate any doc either and just about get around the build process - I can deal with the problems I face with it better than I used to but not with any real technical understanding (i just worksforme). Well, you have similar programming skills as mine :) (i wouldn't spend days on simple patches like http://codereview.appspot.com/4609041/ if i were much more skilled.) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs - probably decision
2011/6/18 Graham Percival gra...@percival-music.ca: Of people who have git access, what (if anything) would make you consider being a mentor? Not everybody is cut out to be a teacher; if you don't feel comfortable in that position, then it's best not to offer. I think the answer came to my mind: i'd spend some time mentoring frogs if someone would do stuff that i wanted to do in that time. This doesn't help, but i'm afraid it may be the core of most problems. Maybe we'll just dump all newcomers on Janek? What's the status of this suggestion? I didn't notice any serious discussion about it. (i mean, what are your opinions? I don't want to take such a responsibility without your explicit approval) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 2: mentors and Frogs
2011/6/15 Graham Percival gra...@percival-music.ca: On Wed, Jun 15, 2011 at 08:56:54AM +0200, m...@apollinemike.com wrote: 2) Many-a-university have open-source-upkeep CS (or music in centers like CCRMA) courses (i.e. Case studies in advanced algorithmic auto-reglation of white space inconsistencies). I think we need *much* more of a culture of mentorship before we could honestly approach one of those programs (or even just google code!) for new contributors. I agree that we should wait a bit with active search for contributors. It will be extremely important, but we are not ready for it. 2011/6/15 Graham Percival gra...@percival-music.ca: gamma) a general mailing list diffuses the responsibility of answering. http://en.wikipedia.org/wiki/Bystander_effect Exactly! delta) a private personal connection can foster more of a personal bond between the two people I also think that communication with a mentor may be faster than with a whole list - in some cases. I'm not convinced we need a Frog Meister. Anyone capable of developing a patch to LilyPond code is capable of uploading it to Reitveld. Any help required could be given on the list by any of the contributors. Frog Meister, under this (re)interpretation, is more of a social position than a technical one. Yes. It will be good to know someone like this is there. Also if someone has a less-technical problem (he feels not appreciated or noobish), he certainly won't post such problems on a list, but will send them to a Frog master. Perfect example: two weeks ago, issue 1630 chord autosplit was almost finished (it only needed a few minor code formatting). But then it stalled until I suggested to Janek that he should get in touch with Karin 2 days ago. Then suddenly stuff started happening. I think the story of this patch http://code.google.com/p/lilypond/issues/detail?id=1630 http://codereview.appspot.com/4490045/ is a horrible black eye for us. Initial patch sent on 2011-04-29. Janek said (in private email) that he could mentor her on 2011-04-29, but the patch only went on rietveld on 2011-05-07 because he was on vacation. Just for the record: as far as i remember i didn't say anything on 2011-04-29 because i was already absent. You send me a mail about mentoring Karin on 2011-04-29 and i replied on 2011-05-07, uploading the patch. I may be wrong, though. A few comments, then nothing happened for two weeks. Then a few more revisions happened, followed by another two-week gap. This whole patch could have been done in 5 DAYS if we'd had our cards in order. - new contributor comes. - welcome, here's the guidelines, ask on frogs or xyz for personal help - revision 1, comments for 24 hours, revision 2, comment for 24 hours, revision 3, patch review countdown 48 hours. Instead, this has dragged out for almost 7 WEEKS. Given this experience, I fully expect Karin to abandon any attempt at future bugfixing in lilypond. Seven weeks for a 68-line patch?! 5 months (and counting) for a 500-line patch isn't much better. but OTOH, it's a new feature, not a bugfix ^^ cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: small reduction in output from make doc
2011/6/15 Graham Percival gra...@percival-music.ca: On Wed, Jun 15, 2011 at 06:02:54PM +0200, Reinhold Kainhofer wrote: Hiding all error messages together with the progress messages is throwing out the baby with the bath water (as we say here in German). Exactly the same phrase in English! We probably stole it from you. :) In Polish too :) I wonder who stole it first :P cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with beam collision (was: problem with cross-staff stems, on lilypond-user)
2011/6/14 James Lowe james.l...@datacore.com: [James' reply:] Anything you can give me specifically Keith? I've just got back from my travels so am trying to catch up the threads that are pertinent to me, so if you have done this or it has been resolved I apologise. I'm not Keith :) but this is rather closed now - no change to the docs is expected, a snippet Cross-staff chords - beaming problems workaround (id 770) was added. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CueClefs: Use middleCClefPosition in the key engraver (issue4551101)
LGTM. Btw, is it possible to download a source file from Rietveld? I'd like to copy the regression test written by Reinhold, and i'm too lazy to remove all the '+' at the beggining of lines manually... Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.1 with new fontforge
2011/6/11 Graham Percival gra...@percival-music.ca: 2.15.1 has fontforge 20110222. = fontforge 20110222 is required for building 2.15 and != fontforge 20110222 included in lilydev, but it will be? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
2011/6/6 Graham Percival gra...@percival-music.ca On Mon, Jun 06, 2011 at 11:11:00AM +0200, Jan Warchoł wrote: 2011/6/6 Graham Percival gra...@percival-music.ca Proposal: let’s follow PEP-8. http://www.python.org/dev/peps/pep-0008/ * use 4 spaces per indentation level * never max tabs and spaces * Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively Do you suggest to follow all PEP-8 guidelines or only the ones mentioned above? Only the above. 79 chars would be nice, but at the moment I don't think we need to officially disallow it. Ok. +1 Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
2011/6/6 Graham Percival gra...@percival-music.ca Proposal: let’s follow PEP-8. http://www.python.org/dev/peps/pep-0008/ * use 4 spaces per indentation level * never max tabs and spaces * Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively Do you suggest to follow all PEP-8 guidelines or only the ones mentioned above? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 06 June, 2011.
Congratulations everybody! Janek 2011/6/6 Graham Percival gra...@percival-music.ca It is now 00:00:10 BST on 06 June, 2011. I see precisely zero open Critical issues, and precisely zero Critical issues waiting to be verified. If you have been holding your breath, you can exhale. Cheers, - Graham ___ 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: Doc: NR rewrite of 3.2 Titles and Headers (issue4124056)
LGTM 2011/5/19 pkx1...@gmail.com On 2011/05/05 23:06:25, Graham Percival wrote: http://codereview.appspot.com/4124056/diff/32001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/4124056/diff/32001/Documentation/notation/input.itely#newcode674 Documentation/notation/input.itely:674: @example On 2011/05/05 11:05:22, J_lowe wrote: Yes we did, you'll also remember that you sent out an email to dev asking for help as I struggled to get this working No, it's worse than that -- I sent an email to the *user* list. Almost every user knows the answer. Certainly anybody who asks about scheme or page layout knows the answer. and it seemed to me that there are some very specific places where it will and won't work. It's not any more or less specific than any other type of layout command. :( Yes, definitely. I'll poke people again. Thanks, with that and my going back and re-reading the replies I have come up with an example and a para before the example, which I think might be a bit convoluted :) comments welcome. Nearly there I think? http://codereview.appspot.com/4124056/ ___ 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: Might understand this music stuff a bit better in the future
2011/5/12 Carl Sorensen c_soren...@byu.edu On 5/12/11 10:10 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Colin Campbell wrote Thursday, May 12, 2011 2:19 PM On 11-05-12 05:08 AM, Phil Holmes wrote: I've just received an unconditional offer to study a part-time BA(Hons) in music from a local university. I'm well pleased :-) Up the geezers! Good for you, Phil. Make us old farts proud! I'll second that! Go for it Phil! Three here! Four! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please close rietveld issues after pushing
2011/4/7 Graham Percival gra...@percival-music.ca: Hi guys, If you've put anything on rietveld recently, please go here: http://codereview.appspot.com/mine You'll probably see a bunch of issues under created by me. If you recognize anything that you pushed, could you go to that issue, click on edit issue, then click on close and save it? I'm toying with various automatic methods to help keep of patches, and clearing out patches that have already been pushed would certainly help! I see some, but they were pushed by you. Should i close them too or is this message aimed at people with git push ability? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the release
Hi Graham all, 2011/4/3 Graham Percival gra...@percival-music.ca: Ok, now that any doubts about my meta-april fool's joke are over, I'd like to sound out opinions about 2.14. GOOD NEWS I think we've finally resolved our technical debt -- it's been a while since I've seen Critical issues that were introduced over a year ago. The remaining Critical issues are things that we introduced in the past 2-3 weeks. BAD NEWS On the bad side of things, we have Critical issues that we introduced in the past 2-3 weeks. If those bugs hadn't slipped in, then my April fool's joke might not have been a joke. ... wow, that would have been an even better meta-joke. Almost everybody would think it _was_ a prank, but then when it turned out that the binaries were actually there... lol, eh? :) wondeful indeed :) CHOICE TIME For the past few months, I've been occupied with teaching, so I deliberately decided that I wouldn't jump up and down and try to get a stable release out. If it happened, it'd happen; if not, no worries. We had four release candidates, starting on 12 Jan until a few days ago. Development at the moment feels comfortable. That's not necessarily a bad thing, of course! But I don't think that we're getting as much done as we _could_ be doing. I'm reminded of the dilemma faced by conductors of amateur orchestras (and probably choirs, theatrical groups, etc). Some people (such as myself) like a strict conductor who always demands their best; rehearsals are always stressful, but very productive and (to me) fulfilling. Other people prefer a relaxed atmosphere; they come to orchestra after a hard day's work, they haven't touched their instrument in the past week... but they have enough stress in their lives and certainly won't put up with a conductor yelling at them. Neither group is objectively right; it's simply a question of deciding what type of orchestra you want to have. In a similar way, I'm wondering how we want to approach the next few weeks. When somebody introduces a regression, should we frown at them (and maybe revert the bad commit), or just shrug and laugh? Should we try to have a sprint towards resolving the current crop of Critical issues and get 2.14 out the door, or just let it happen when it happens? I prefer having a relaxed attitude. However, if anyone would discover that any of my patches introduces a regression, i would urge to revert it myself. I don't want to go too GOPish (there will be time for that), so just in a nutshell: let's not yell at people, but let's consider reverting probematic commits a valid way of solving a regression. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. (issue4243071)
What's the status of this? I don't see any objections, and also i don't see this pushed or being counted-down. In fact, i don't see a patch-issue at all. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. (issue4243071)
2011/3/13 Graham Percival gra...@percival-music.ca: On 3/13/11, Graham Percival gra...@percival-music.ca wrote: On 3/13/11, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: What's the status of this? I don't see any objections, and also i don't see this pushed or being counted-down. In fact, i don't see a patch-issue at all. Sorry, added now: http://code.google.com/p/lilypond/issues/detail?id=1558 Looks fine; could you send me the final patch for pushing? Here they are. From d7cf405d11d1abb6fdef1bc32323b003753f49ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Janek=20Warcho=C5=82?= lemniskata.bernoulli...@gmail.com Date: Tue, 8 Mar 2011 16:37:28 +0100 Subject: [PATCH 1/2] unbeamed 32nd stem is shortened by 0.25 ss to fit beamed stems better. as discussed in http://lists.gnu.org/archive/html/lilypond-devel/2011-03/msg00091.html --- scm/define-grobs.scm |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index e5658a8..95fca72 100644 --- a/scm/define-grobs.scm +++ b/scm/define-grobs.scm @@ -1864,7 +1864,7 @@ . ( ;; 3.5 (or 3 measured from note head) is standard length ;; 32nd, 64th, 128th flagged stems should be longer - (lengths . (3.5 3.5 3.5 4.5 5.0 6.0)) + (lengths . (3.5 3.5 3.5 4.25 5.0 6.0)) ;; FIXME. 3.5 yields too long beams (according to Ross and ;; looking at Baerenreiter examples) for a number of common -- 1.7.0.4 From d796825d562e4101d2b76c0dba993498790de6d5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Janek=20Warcho=C5=82?= lemniskata.bernoulli...@gmail.com Date: Wed, 9 Mar 2011 21:32:32 +0100 Subject: [PATCH 2/2] shortens 32nd flag to match shorter stem --- mf/feta-flags.mf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mf/feta-flags.mf b/mf/feta-flags.mf index 90407a4..104bab3 100644 --- a/mf/feta-flags.mf +++ b/mf/feta-flags.mf @@ -379,7 +379,7 @@ fet_beginchar (32nd (down), d5); save flagspace, total_depth, flag_count; flag_count = 3; - total_depth# = 3.85 staff_space#; + total_depth# = 3.75 * staff_space# - blot_diameter# / 2; flare = .84 staff_space; flagspace# = .9 staff_space#; hip_depth_ratio = .85; -- 1.7.0.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build system work
2011/3/4 Graham Percival gra...@percival-music.ca: PS I'm fairly certain that at the moment, all needs_work issues do not have any more recent drafts that you need to look at. Doesn't http://code.google.com/p/lilypond/issues/detail?id=1541 have a new draft? (with fixed indentation) http://codereview.appspot.com/4236043/ cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build system work
2011/3/5 Graham Percival gra...@percival-music.ca: On Sat, Mar 05, 2011 at 01:37:04PM +0100, Jan Warchoł wrote: 2011/3/4 Graham Percival gra...@percival-music.ca: PS I'm fairly certain that at the moment, all needs_work issues do not have any more recent drafts that you need to look at. Doesn't http://code.google.com/p/lilypond/issues/detail?id=1541 have a new draft? (with fixed indentation) Ah, ok. I commented on the rietveld issue two days ago, but forgot to update google code. I would have discovered it in a few days -- when I'm making up my list of 48-hour patches, I tend to scan the needs_work issues in case I missed something. No problem. Thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/24 Marek Klein ma...@gregoriana.sk I have created new [PATCH] issue for this: http://code.google.com/p/lilypond/issues/detail?id=1538 Thanks for remembering! However, i'm afraid this issue is invalid. We decided to divide this problem and the first part is discussed in http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00391.html (i hope to upload a patch for that within a few hours). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a present for Graham
2011/2/19 David Kastrup d...@gnu.org: Janek Warchoł lemniskata.bernoull...@gmail.com writes: PS Graham, i'm sorry if you felt offended by that kiss thing - i meant it as a joke only, referring to what you said to Owen Tuz at frogs list: 2010/11/15 Graham Percival gra...@percival-music.ca: (...) I think it quite contraproductive to offer kisses to frogs. Lilypond definitely can make better use of frogs than princes. :) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Squiggle picture
2011/2/12 Francisco Vila paconet@gmail.com: Hello, IMHO the green background rectangle of the squiggle image in our front page is not excessively aesthetic. See this preview with an alternative without: http://paconet.org/lilypond/out-website/website/index.html +1. I wondered some time ago why the background wasn't white :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened stems and flags (issue4134041)
2011/2/6 mts...@gmail.com:
Great work!
Thank you!
I can't really speak to the font stuff.
Why not? Every one has his own personal preferences.
And the font stuff is what matters the most for me :)
Of course some changes are very subtle. It's best to open pdfs called
flag testing side-by-side on a big resolution screen (i have 24,
1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
displays too.
Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
Here are pdfs made with 2.13.47 for comparison:
http://www.sendspace.com/file/ogl8rk
Here are the .ly files: http://www.sendspace.com/file/gjh6ng
You can make your C++ code a
lot shorter by using arrays.
I've made it shorter in some places by using grob properties, but i
was unable to upload that new patch. It should be available soon.
And I see that you've wiped a lot of the
tabbing in the original code. You may want to start by copying a fresh
version of the file into your git repository and then copying and
pasting the new code into that to save you the headache of dealing w/
all of those tabs.
Frankly, i really do not know what is happening here. Files before and
after the change look the same to me.
I'm using lilydev, but the default text editor wasn't to my taste, so
i edited the files outside lilydev, in Notepad++. I set Notepad++ to
write all tabs as spaces (if i remember correctly, our policy for the
code says that all indentation should be done with spaces?) and it
looked ok...
Other than that, arrays are your friend.
Everything else looks good!
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode92
lily/stem.cc:92: Staff_symbol_referencer::get_position (e[UP]));
Try to keep the same indentation from the previous file (here, there
were 2 tabs).
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode190
lily/stem.cc:190: while (flip (d) != DOWN);
Ditto.
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode231
lily/stem.cc:231: }
Ditto.
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode246
lily/stem.cc:246: {
Ditto. I'll stop dittoing, but check out the side by side diff to
rectify this :)
As i've said, i fail to see how it was different :(
there is the same amount of whitespace, and when i copy a fragment of
the file to some external editor, it behaves all the same (like if all
indentation was done with spaces).
If it weren't for these tiny » in side-by-side diff, i wouldn't know
what you are talking about :(
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode350
lily/stem.cc:350: Direction dir = get_grob_direction (me);
Try:
Real potential_lengths[] = {7,7,7,7,8.5,10,11.5};
length = potential_lengths[durlog-1];
This one i improved with grob properties.
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode373
lily/stem.cc:373: }
Same approach as above - you can use an array here.
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode388
lily/stem.cc:388: length -= shorten;
You can also use an array here.
Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
shorten *= potential_shortenings[(int)(head_positions (me)[dir])];
It didn't work, i got stems with length 0 and general mess :(
i'll investigate tomorrow.
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode715
lily/stem.cc:715: }
Ditto - use arrays.
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
lily/stem.cc:728: }
Same - arrays can be used here (see above for how to handle else if).
http://codereview.appspot.com/4134041/
Thanks for help!
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Difficult tweaks section - problem w/ tie in the example
2011/2/7 Mike Solomon mike...@ufl.edu: Is it supposed to be repositioned so high on the staff? Cheers, MS I see 'extra-offset '(-2 . 5) and the tie is just about 2 staffspaces to the left and 5 staffspaces above its default position, so it looks all right to me... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened stems and flags (issue4134041)
2011/2/7 m...@apollinemike.com m...@apollinemike.com:
On Feb 6, 2011, at 6:19 PM, Jan Warchoł wrote:
2011/2/6 mts...@gmail.com:
I can't really speak to the font stuff.
Why not? Every one has his own personal preferences.
And the font stuff is what matters the most for me :)
Of course some changes are very subtle. It's best to open pdfs called
flag testing side-by-side on a big resolution screen (i have 24,
1920x1080 screen), zoomed to 300-400%, but it can be done on smaller
displays too.
Here are the pdfs made with my commit: http://www.sendspace.com/file/j9dq5t
Here are pdfs made with 2.13.47 for comparison:
http://www.sendspace.com/file/ogl8rk
Here are the .ly files: http://www.sendspace.com/file/gjh6ng
And I see that you've wiped a lot of the
tabbing in the original code. You may want to start by copying a fresh
version of the file into your git repository and then copying and
pasting the new code into that to save you the headache of dealing w/
all of those tabs.
Frankly, i really do not know what is happening here. Files before and
after the change look the same to me.
I'm using lilydev, but the default text editor wasn't to my taste, so
i edited the files outside lilydev, in Notepad++. I set Notepad++ to
write all tabs as spaces (if i remember correctly, our policy for the
code says that all indentation should be done with spaces?) and it
looked ok...
I'm just passing along a comment I got about my code when
I tried to wipe out indentations. I actually have no idea what
best practice is, but as a general rule, commits should be centered
around one theme. A separate patch, titled eliminate indentations
in the stem.cc, could take care of the indentation problem
if it is in fact a problem (that said, my coding style is so bad
that I should really not even be talking...).
I think i get rid of this problem in stem.cc (feta-flags.mf are
changed so much that i don't think fiddling with tabs is feasible).
Real potential_shortenings[] = {0.833,0.666,0.555,0.333,0.166};
shorten *= potential_shortenings[(int)(head_positions (me)[dir])];
It didn't work, i got stems with length 0 and general mess :(
i'll investigate tomorrow.
Hm...lemme know. It should be doable w/ arrays somehow -
if you don't crack it, lemme know I'll give it a more protracted glance.
I've managed to do this, luckily :)
http://codereview.appspot.com/4134041/diff/1/lily/stem.cc#newcode728
lily/stem.cc:728: }
Same - arrays can be used here (see above for how to handle else if).
Arrays for handling intervals of floating point numbers?
I don't see how this could be done.
thanks,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Czech and Chinese webpages
2011/2/5 Francisco Vila paconet@gmail.com: 2011/2/5 Graham Percival gra...@percival-music.ca: On Sat, Feb 05, 2011 at 10:25:35AM +0100, Francisco Vila wrote: Is there a way of reviewing both pages publicly as they currently are on its branch? OK, here is a preview. http://paconet.org/lilypond/out-website/website/index.html May I merge and push? I see another problem here: http://paconet.org/lilypond/out-website/website/features.cs.html (Spojení not a textu column is too narrow) (WinXP, Chrome) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in ties over barlines
W dniu 31 stycznia 2011 17:06 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 1/31/11 3:04 AM, Jan Warchoł lemniskata.bernoulli...@gmail.com wrote: 2011/1/24 Phil Holmes m...@philholmes.net If you use #(set-accidental-style 'modern-cautionary) then you get the parenthesised accidental automatically, as requested. Indeed, thanks for the remainder. However, in my opinion it is necessary to *change* the 'default', 'voice' and 'forget' accidental styles, because their current behaviour result in wrongly typeset music. If the last note in the following example doesn't get a natural, it's *impossible* to tell that it's not another ces: ces'1~ | ces' ces'1( | c') It may be argued that the slur looks different than the tie, but it's not enough. I'm sure that engraving books will agree with me - may someone check this? I think that it would be fine to have a rule added that says if we're across a barline, and the scale step is the same, but the accidental is different, and the slur is two notes long ending on the current note, display a cautionary accidental in order to avoid confusion with a tie. +1, except that i think it should be unparenthesized (at least in accidental styles like default and voice, that don't use parenthesized accidentals at all). 2011/1/31 Alexander Kobel n...@a-kobel.de: But IMHO the important point here is the fact that the notation can be ambigous without the accidental, and is definitely clear with it. No matter if ? or !. +1. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in ties over barlines
Hi, sorry for the delay - i was busy making new flags for Lily. 2011/1/24 Phil Holmes m...@philholmes.net - Original Message - From: Jan Warchoł lemniskata.bernoulli...@gmail.com I don't agree. *Theoretically* accidental is not needed, but if it would be omitted, how can you tell the difference between aes~ | aes and aes( | a) ? In my opinion accidental here is necessary (surely it may be parenthesized). If it's necessary, it should be printed automatically in my opinion. cheers, Janek If you use #(set-accidental-style 'modern-cautionary) then you get the parenthesised accidental automatically, as requested. Indeed, thanks for the remainder. However, in my opinion it is necessary to *change* the 'default', 'voice' and 'forget' accidental styles, because their current behaviour result in wrongly typeset music. If the last note in the following example doesn't get a natural, it's *impossible* to tell that it's not another ces: ces'1~ | ces' ces'1( | c') It may be argued that the slur looks different than the tie, but it's not enough. I'm sure that engraving books will agree with me - may someone check this? cheers, Janek PS By the way, i think that modern-cautionary accidental style prints a cautionary accidental there not because of a potential confusion with a tie, but simply because it prints remainder accidentals in the following measure. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Odd vertical spacing of lyrics
2011/1/19 Mike Solomon mike...@ufl.edu:
I'll chime in and say that, although there is a workaround, the fact that
there is not good out-of-the-box spacing may effect a lot of real world
examples of choral music that is being engraved using lilypond.
It may be worth it to add this to the issue tracker and get this fixed in one
of the first 2.14 bug fixes (if not 2.14 itself) - thoughts?
In my opinion this issue is important and potentially widespread, and
as such it should be considered a high priority one.
I also think that a good solution would mean changing the lyrics
spacing mechanisms considerably (especially because it's connected
with some vertical and horizontal lyrics spacing issues that should be
addressed).
I have some thoughts on these topics, but from what i see the
discussion about them may become monstrous in size, so i'm waiting
until 2.14 is out.
I suppose that's what we should do: release 2.14 and fix this issue
thoroughly soon after that.
cheers,
Janek
Is there a way to add this to the issue tracker.
On Jan 19, 2011, at 3:42 PM, Jan Warchoł wrote:
2011/1/18 Carl Sorensen c_soren...@byu.edu
On 1/18/11 8:26 AM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
The following snippet is giving me the attached output w/ the soprano line
shifted way up after the line break. Is there any way to get the soprano
correctly aligned (w/o changing the distance between systems - this minimal
example approximates a larger one w/ many systems over several pages).
\version 2.13.47
Mike,
I got it to work successfully with the following change:
\new Lyrics = sopranos \with {
\override VerticalAxisGroup #'staff-affinity = #DOWN
} { s1 }
The lyrics were still a little bit high, however. It's almost like there's
a blank context hiding in the middle. But I haven't been able to get rid of
that small amount of extra space.
The reference point of lyrics is the baseline and this is the cause of
the problem - #'nonstaff-relatedstaff-spacing #'basic-distance
appropriate for lyrics below staff is not appropriate for lyrics above
staff. Consider the following (and look at the attachment):
\version 2.13.45
\paper { system-system-spacing #'basic-distance = #20 ragged-right = ##t }
\score {
\new ChoirStaff
\new Lyrics = abovelyrics \with { \override VerticalAxisGroup
#'staff-affinity = #DOWN }
{ s1 }
\new Staff {
\new Voice = empty { r4 r r r \break } \new Voice =
firstPart { f' f' f' f' } \new Voice = secondPart { e'' e'' e''
e'' }
}
\new Lyrics = belowlyrics { s1 }
\context Lyrics = abovelyrics \lyricsto firstPart \lyricmode { ma
-- ma ma -- ma }
\context Lyrics = belowlyrics \lyricsto secondPart \lyricmode { mo
mo -- mo mo }
\layout {
\context {
% \Lyrics \override VerticalAxisGroup
#'nonstaff-relatedstaff-spacing #'basic-distance = #4
}
}
}
You can see how this changes by uncommenting the
nonstaff-relatedstaff-spacing override.
The strange thing is that all this somehow doesn't affect first system.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Odd vertical spacing of lyrics
Graham, 2011/1/19 Graham Percival gra...@percival-music.ca: On Wed, Jan 19, 2011 at 10:28:38PM +0100, Jan Warchoł wrote: 2011/1/19 Mike Solomon mike...@ufl.edu: It may be worth it to add this to the issue tracker and get this fixed in one of the first 2.14 bug fixes (if not 2.14 itself) - thoughts? In my opinion this issue is important and potentially widespread, and as such it should be considered a high priority one. In my opinion, I don't care about your opinion, but I *do* care about evidence of bugs. Please submit a bug report and let's get it in the tracker. Doubly so if it's a regression. I suppose that's what we should do: release 2.14 and fix this issue thoroughly soon after that. If there's an actual regression, make a bug report. If you don't do it now, then somebody else will do it 12 days after we release the final release candidate, and we'll have to scrap the release plans and it'll be much more disheartening to have it happen then. If necessary, we can pretend that it's deliberate (after noting it in the Changes document), call it a non-regression, make it non-critical, and have a release. That's no reason to not submit a good bug report about it now. Sorry for that. Indeed i thought that vertical spacing is simply intended to work this way and that it's not a bug. I thought that this would just be an enhancement suggestion, with slight chances to have a high priority. Clearly i'm wrong. I'll investigate and report it tomorrow. 2011/1/19 Keith OHara k-ohara5...@oco.net: I started a lyrics template and shortcuts, but do not use lyrics myself, so I am wandering a bit aimlessly when I work on it. It sits on my to-do list for some time now... Sorry about that. I'll try to find more time and investigate. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: instrumentName in StaffGroup
2011/1/14 Reinhold Kainhofer reinh...@kainhofer.com: To be honest, I don't understand, why the Instrument_name_engraver is not added to all staff group contexts by default. It is a very simple engraver, so it would not induce much overhead. From a user's point of view, if he sets an instrument name, he wants it to be shown, and if he doesn't set an instrument name, the engraver will not do anything, anyway. So, from that POV, the sane thing would be to add it to staff groups, too. +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Potential fix for issue 37
2011/1/7 m...@apollinemike.com I'm not exactly sure what the desired output would be for issue 37, but my code assumes that if there are collision problems, flat beams look best. Lemme know what you think! Judging by my very own personal taste i'd say that when notes are not on the same staffline it would look better if the beams were slanted; i'd also prefer slightly smaller vertical gap between upper beams and noteheads (now it's something like 1 staff space, i'd go for 0.5 staff space). And it would be great if beams covered stafflines like in regular situations. But this is my personal opinion and of course the new output is far better than the old one, so keep up the good work! cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
