Re: Implements multiple-line non-cross-staff glissandi (issue4527086)
On Jun 2, 2011, at 9:00 PM, n.putt...@gmail.com wrote: > > http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm > File scm/output-lib.scm (right): > > http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm#newcode795 > scm/output-lib.scm:795: (define-public (glissando::before-line-breaking > grob) > Possibly silly question: can't you fold this into callbacks for > left-bound-info/right-bound-info instead? Sorry - I don't get what you mean :( Could you please elaborate? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows accidental placements to be individualized. (issue4526094)
On Jun 4, 2011, at 5:16 PM, n.putt...@gmail.com wrote:
> On 2011/06/04 12:50:55, MikeSol wrote:
>
>> This, in combination with my stem-attachment patch, allows for the
> small notes
>> above harmonics that give the sounding pitch to be typset well.
>
> I think you should consider making the sounding pitch a separate
> constellation of grobs, similar to a pitched trill. This has the
> benefit of not needing slightly naughty hacks to kill stem attachments.
> :)
>
> \relative c' {
> \override TrillPitchGroup #'X-offset = #0
> \override TrillSpanner #'stencil = ##f
> \pitchedTrill
> \startTrillSpan des''
> }
>
> Cheers,
> Neil
Brilliant! I'll nix my patch for the stem attachments, then (the only reason I
needed it was to typeset harmonics).
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Outside staff priority for tuplet bracket and tuplet number
Hey all,
I'm running into a problem with the following snippet of code and, before I try
to fix it, I was wondering if anyone knew why these two bits of code yielded
the same result:
\relative c'' { \override Staff . TupletBracket #'outside-staff-priority = #0
\override Staff . Script #'outside-staff-priority = #500
<< { \times 2/3 { bes8^\trill bes^\trill bes^\trill } } \\ { \times 2/3 { c,8 c
c } } >>
}
\relative c'' { \override Staff . TupletBracket #'outside-staff-priority = #500
\override Staff . Script #'outside-staff-priority = #0
<< { \times 2/3 { bes8^\trill bes^\trill bes^\trill } } \\ { \times 2/3 { c,8 c
c } } >>
}
I would have guessed that the order of the number w/ respect to the script
would have changed.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Outside staff priority for tuplet bracket and tuplet number
Hi Mike
Shouldn't you be using the TupletNumber grob?
Trevor
- Original Message -
From:
To:
Sent: Sunday, June 05, 2011 12:00 PM
Subject: Outside staff priority for tuplet bracket and tuplet number
Hey all,
I'm running into a problem with the following snippet of code and,
before I try to fix it, I was wondering if anyone knew why these
two bits of code yielded the same result:
\relative c'' { \override Staff . TupletBracket
#'outside-staff-priority = #0
\override Staff . Script #'outside-staff-priority = #500
<< { \times 2/3 { bes8^\trill bes^\trill bes^\trill } } \\ {
\times 2/3 { c,8 c c } } >>
}
\relative c'' { \override Staff . TupletBracket
#'outside-staff-priority = #500
\override Staff . Script #'outside-staff-priority = #0
<< { \times 2/3 { bes8^\trill bes^\trill bes^\trill } } \\ {
\times 2/3 { c,8 c c } } >>
}
I would have guessed that the order of the number w/ respect to
the script would have changed.
Cheers,
MS
___
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: New alist to replace special characters. (issue4553056)
Ok, I'll change these. What about 'No.' ? '№', 'N°' or '&N°;' ? http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Emit not-quite-cross-staff beams in the right context. (issue4564041)
If I understand well, there's no need anymore for manual beams in cross-staff cases ? If so, I suggest you remove the manual beams from input/regression/beam-collision-cross-staff.ly. You should also remove the knownissues in keyboard.itely and the last part of changes.tely's entry. Thanks, Bertrand http://codereview.appspot.com/4564041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc
On 28/05/11 17:16, Graham Percival wrote: > On Sat, May 28, 2011 at 04:54:57PM +0100, Phil Holmes wrote: >> - Original Message - From: "Graham Percival" >> >>> Why not redirect the compile-output from each .ly to the >>> appropriate .log file? I mean, we *already* have a .log for each >>> .ly file... what's in the .log file at the moment? Why not put >>> the --verbose output in there? etc. >> >> Don't believe there is a log file. Can't see one, anyway. > > huh, you're right. I just assumed that dirs like > build/out/lyubook-db/??/ > would have .log files as well as all the other stuff that's there. > Well, that makes the overall strategy easier. :) > >> I know Lily sends output to the console by default. What causes >> it to write logfiles instead? > > You, please. :) > Or use the code for lilypond -dgui gui (#f) Run LilyPond from a GUI and redirect stderr to a log file. Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Openoffice import?
Offlist http://www.haumacher.de/svg-import/> has been suggested to me. The JAR file mentioned in there works for converting lilypond-book images placed into PDF, extracted with preview.sty, converted with pdf2svg to SVG to .odg files (OpenOffice Draw Graphics?) as OLE links into an OpenOffice document from where they will export to scalable PDF again. So there is a reasonable hope they might also export to scalable DOC contents. However, the export contains strings like mimetypeapplication/vnd.oasis.opendocument.graphics that look suspiciously like something that would not be regarded as savory when looked at by Microsoft Word. It is probably possible to make this part of a processing pipeline eventually ending in DOC files processable my Microsoft Office, but whether it will actually work in the context "give me a DOC file to feed into my DTP system" is quite dubious. It's actually aggravating that people use DOC as an interchange format, something which it never was designed for. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Openoffice import?
David: > Offlist http://www.haumacher.de/svg-import/> has been suggested to > me. The JAR file mentioned in there works for converting lilypond-book > images placed into PDF, extracted with preview.sty, converted with > pdf2svg to SVG to .odg files (OpenOffice Draw Graphics?) as OLE links > into an OpenOffice document from where they will export to scalable PDF > again. So there is a reasonable hope they might also export to scalable > DOC contents. ... I found http://sk1project.org/modules.php?name=Products&product=uniconvertor which claims to be able to do eps -> svg, can that be of any help... Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Openoffice import?
k...@aspodata.se (Karl Hammar) writes: > David: >> Offlist http://www.haumacher.de/svg-import/> has been suggested to >> me. The JAR file mentioned in there works for converting lilypond-book >> images placed into PDF, extracted with preview.sty, converted with >> pdf2svg to SVG to .odg files (OpenOffice Draw Graphics?) as OLE links >> into an OpenOffice document from where they will export to scalable PDF >> again. So there is a reasonable hope they might also export to scalable >> DOC contents. > ... > > I found > > http://sk1project.org/modules.php?name=Products&product=uniconvertor > > which claims to be able to do eps -> svg, can that be of any help... Not really. I got the PDF->SVG part covered. Anyway, currently the ball is in the court of the editor. Unless he comes back again, I'll probably not try improving on the current result, since, while I think I may get the necessary parts together, it will require considerable manual work as well (the problem with a WYSIWYG oriented workflow is that the amount of things you can do with batch processing is limited, and it does not help that I have not yet tried working with OpenOffice macros). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Event listener to extract (some) music events. (issue4373046)
thanks all, this is now pushed. http://codereview.appspot.com/4373046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
06 June, 2011.
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
GOP-PROP 0: meta-discussion about the discussions
The below is copied from http://lilypond.org/~graham/gop/ There are a number of policy decisions -- some of them fairly important -- which we have been postponing for a few years. Now that 2.14 is out, we will finally begin tackling them More background is here: http://lilypond.org/doc/v2.13/Documentation/contributor/policy-decisions Meta-policies To summarize and/or hopefully avoid useless fluffy discussions: * Topics will be introduced by Graham. He will put an agenda for the next month (or so) on http://lilypond.org/~graham/gop/ * We will only seriously discuss topics when we have adequate background research. * Emails about policy questions will begin with GOP-PROP: in the subject line. Adjust your email filters accordingly, depending on whether you are interested or not in such discussions. * For each policy question, there will be at least one week for free-ranging discussion. At that point, Graham will summarize the discussion and announce a "probable decision". * We will then have one more week to let people point out flaws in the summary, make additional arguments, etc. * There should be no surprises, no time pressure, etc. If you are particularly concerned about a decision but lack time/energy to join the discussion, just say so and we will postponed the decision. I want to have clear, final, unambiguous decisions; if that takes a long time, so be it. Agenda (bad copy&paste job deleted; look at the webpage, or wait for emails to come) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 1: python formatting
Proposal website: http://lilypond.org/~graham/gop/gop_1.html (this proposal will be rushed because nobody will argue against it. Initial discussion 6 June, summary and tentative decision 8 June, implementation 10 June) 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 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
sorting out branch conflicts
To whoever enjoys this stuff, 1) please check that stable/2.14 has no useful commits that are not in master. I think the only difference is in VERSION and various disasters concerning Documentation/web/news-front.itexi, but I'd like to be safe. 2) make release/unstable be exactly what we have in master. I'd like to release 2.15.0 on the 7th. Yes, #2 is almost certainly a one-line "force fast-foward" or "force push" command, but I'm not going to screw around with that stuff in a public repository when it's after midnight. Much better to leave it to somebody who's alert and knows what they're doing. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: 06 June, 2011.
HOORAY! :) From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Graham Percival [gra...@percival-music.ca] Sent: 06 June 2011 00:00 To: lilypond-devel@gnu.org Subject: 06 June, 2011. 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: GOP-PROP 1: python formatting
Graham Percival writes: > Proposal website: > http://lilypond.org/~graham/gop/gop_1.html > > > (this proposal will be rushed because nobody will argue against > it. Initial discussion 6 June, summary and tentative decision 8 > June, implementation 10 June) > > 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 For the purposes of consistency (both within Lilypond's sources, and within code editors in general), I would modify Lilypond's version of PEP-8 to be the slightly more strict: Never use tabs for indentation. Only use spaces. -- Michael Welsh Duggan (m...@md5i.com) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
On Sun, Jun 05, 2011 at 07:42:56PM -0400, Michael Welsh Duggan wrote: > Graham Percival writes: > > > * Code indented with a mixture of tabs and spaces should be > > converted to using spaces exclusively > > For the purposes of consistency (both within Lilypond's sources, and > within code editors in general), I would modify Lilypond's version of > PEP-8 to be the slightly more strict: Never use tabs for indentation. > Only use spaces. Yes, absolutely. That was implied, but not explicitly stated, in the original proposal. I have added it (explicitly) to the proposal now. Thanks, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond 2.15.0 release candidate dumps core
Grabbed from git this morning, very simple file:
\version "2.15.0"
notes=\relative c' {
4
}
\score {
\context Staff \notes
}
I see:
GNU LilyPond 2.15.0
Processing `x.ly'
Parsing...
Interpreting music... *** glibc detected *** lilypond: double free or
corruption (out): 0x00c2b550 ***
=== Backtrace: =
/lib/libc.so.6(+0x725d6)[0x7f4f25f805d6]
/lib/libc.so.6(cfree+0x6c)[0x7f4f25f8530c]
lilypond[0x42a174]
lilypond[0x635372]
...
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond 2.15.0 release candidate dumps core
On Mon, Jun 06, 2011 at 10:06:31AM +1000, Peter Chubb wrote: > Grabbed from git this morning, very simple file: ick. However, I'm happy to report that 2.14.0 does not have this problem. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond 2.15.0 release candidate dumps core
> "Graham" == Graham Percival writes: Graham> On Mon, Jun 06, 2011 at 10:06:31AM +1000, Peter Chubb wrote: >> Grabbed from git this morning, very simple file: Graham> ick. I've fixed it. The problem was that the VERSION file in the toplevel doesn't depend on whatever it is that sets the version, so Make didn't recognise that it needed updating. The newly built-and-installed lilypond was using the /usr/local/share/lilypond/2.13.61 files instead of the ones in .../2.15.0/ Graham> However, I'm happy to report that 2.14.0 does not have this Graham> problem. :) Good. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 06 June, 2011.
Yeayyy!!! Thanks for all the hard work!! Paul Scott On 06/05/2011 04:00 PM, Graham Percival wrote: 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: GOP-PROP 1: python formatting
> Proposal: let’s follow PEP-8. > http://www.python.org/dev/peps/pep-0008/ > > * use 4 spaces per indentation level I prefer 2 spaces (this allows for longer lines while staying in the 80 char line length limit), but since all python code already uses 4 spaces, this is OK with me. Just curious: Is there any python code in lilypond which doesn't intentionally follow this rule? > * never max tabs and spaces > * Code indented with a mixture of tabs and spaces should be > converted to using spaces exclusively Both +1. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 06 June, 2011.
> HOORAY! > > :) Thanks A LOT especially to you, Graham, for your hard work on it! And kudos to all the other more active developers who have made this release possible. Werner ___ 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 > 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: GOP-PROP 1: python formatting
On Mon, 6 Jun 2011, Graham Percival wrote: * never max tabs and spaces max = mix ? -- MT ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 1: python formatting
On 06/06/11 00:01, Graham Percival wrote: > Proposal website: > http://lilypond.org/~graham/gop/gop_1.html > > > (this proposal will be rushed because nobody will argue against > it. Initial discussion 6 June, summary and tentative decision 8 > June, implementation 10 June) > > 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 nitpick: "max" -> "mix"? If we're laying down tablets of stone, lets get the engraving right. :-) Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 06 June, 2011.
HOORAY!! WOOT! YEEHAR! Well done to all Lilypond contributors, especially to Graham for being Releasemeister and all the project management stuff. Hoping to contribute more to 2.15/16 now I'm out of hospital. Cheers, Ian On 06/06/11 00:00, Graham Percival wrote: > 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
Re: GOP-PROP 1: python formatting
On Sun, Jun 5, 2011 at 4:01 PM, Graham Percival wrote: > > 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 Sounds good to me. Regards, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
