Re: Copyright issues
On 2009-09-07, Joe Neeman wrote: > On Tue, 2009-09-08 at 01:05 +0100, Graham Percival wrote: > > On Mon, Sep 07, 2009 at 04:42:07PM -0700, Patrick McCarty wrote: > > > In light of recent suggestions to change LilyPond's copyright to GPLv2 > > > or later, I am reminded of the Ghostscript 8.70 announcement to > > > gs-devel back in July. > > > > > > Thoughts? > > > > If you meant ghostscript in particular, then I guess we'll have to > > stay with ghostscript <8.70 for now. > > We don't link to ghostscript -- we merely call the command line program > -- so the GPL doesn't apply. Okay, thanks for the clarification. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On Tue, 2009-09-08 at 01:05 +0100, Graham Percival wrote: > On Mon, Sep 07, 2009 at 04:42:07PM -0700, Patrick McCarty wrote: > > In light of recent suggestions to change LilyPond's copyright to GPLv2 > > or later, I am reminded of the Ghostscript 8.70 announcement to > > gs-devel back in July. > > > > Thoughts? > > Yes. My thoughts are "could people reading the maoing previous > discussions already?!?!". > > http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg9.html > http://lists.gnu.org/archive/html/lilypond-devel/2008-05/msg00085.html > > If somebody is SERIOUSLY interested in this, and is SERIOUSLY > willing to spend around 50 hours working on the paperwork, and > SERIOUSLY wants to pester everybody to fill out their share of the > paperwork, and SERIOUSLY wants to figure out what to do about > casual or new contributors... then fine. Step forward. > > > If you meant ghostscript in particular, then I guess we'll have to > stay with ghostscript <8.70 for now. We don't link to ghostscript -- we merely call the command line program -- so the GPL doesn't apply. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: defining make vars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 8. September 2009 01:19:11 schrieb Graham Percival: > I'm looking at automatically replacing download links in > general.texi (and subfiles) with macros. I think that's the best > way to deal with them; we already have the @version macro that's > auto-generated. > > @version is defined from TOPLEVEL_VERSION, which in turn is > defined from TOPLEVEL_MAJOR_VERSION (etc). But how is > TOPLEVEL_MAJOR_VERSION defined? I'm guessing that one of the > makefiles or stepmake stuff actually reads from /VERSION, but I > can't figure out which piece of the build system does it. TOPLEVEL_VERSION is an (auto)make variable, defined in aclocal.m4: . $srcdir/VERSION FULL_VERSION=$MAJOR_VERSION.$MINOR_VERSION.$PATCH_LEVEL MICRO_VERSION=$PATCH_LEVEL TOPLEVEL_VERSION=$FULL_VERSION The first line above reads in the VERSION file, the second constructs the FULL_VERSION from the various parts defined in the VERSION file... Notice that aclocal.m4 also calls AC_SUBST on each $*_VERSION part, so these variables are available in makefiles... Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKpahiTqjEwhXvPN0RAi6oAJ4m6VrqVr94TilcDpWlQBf7YFL35gCeL5Cp MWP9rhlkApM8/uYWSRaDr1g= =xZt1 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On 2009-09-08, Graham Percival wrote: > On Mon, Sep 07, 2009 at 04:42:07PM -0700, Patrick McCarty wrote: > > In light of recent suggestions to change LilyPond's copyright to GPLv2 > > or later, I am reminded of the Ghostscript 8.70 announcement to > > gs-devel back in July. > > > > Thoughts? > > If you meant ghostscript in particular, then I guess we'll have to > stay with ghostscript <8.70 for now. Yes, sorry, I should have added that to the subject line; I was just talking about Ghostscript. Since GUB uses an SVN checkout before the official 8.70 release, I guess we are okay. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
On Mon, Sep 07, 2009 at 04:42:07PM -0700, Patrick McCarty wrote: > In light of recent suggestions to change LilyPond's copyright to GPLv2 > or later, I am reminded of the Ghostscript 8.70 announcement to > gs-devel back in July. > > Thoughts? Yes. My thoughts are "could people reading the maoing previous discussions already?!?!". http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg9.html http://lists.gnu.org/archive/html/lilypond-devel/2008-05/msg00085.html If somebody is SERIOUSLY interested in this, and is SERIOUSLY willing to spend around 50 hours working on the paperwork, and SERIOUSLY wants to pester everybody to fill out their share of the paperwork, and SERIOUSLY wants to figure out what to do about casual or new contributors... then fine. Step forward. If you meant ghostscript in particular, then I guess we'll have to stay with ghostscript <8.70 for now. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Copyright issues
Hi, In light of recent suggestions to change LilyPond's copyright to GPLv2 or later, I am reminded of the Ghostscript 8.70 announcement to gs-devel back in July. It is here: http://www.ghostscript.com/pipermail/gs-devel/2009-July/008545.html The part that (I think) is relevant to LilyPond is below: [...] The licensing of the Free version of the core Ghostscript code has been changed to GPLv3 or later. Previously, the core code was GPLv2 only. Ghostscript can now be used with GPLv3 applications, and can no longer be used with applications that are GPLv2-only. [...] Thoughts? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
defining make vars
I'm looking at automatically replacing download links in general.texi (and subfiles) with macros. I think that's the best way to deal with them; we already have the @version macro that's auto-generated. @version is defined from TOPLEVEL_VERSION, which in turn is defined from TOPLEVEL_MAJOR_VERSION (etc). But how is TOPLEVEL_MAJOR_VERSION defined? I'm guessing that one of the makefiles or stepmake stuff actually reads from /VERSION, but I can't figure out which piece of the build system does it. I'm tempted to just dump the raw numbers into stepmake/stepmake/texinfo-rules.make for now -- at least the texinfo files can be generic (i.e. using proper macros, which would be defined in version.itexi). And I don't mind updating that file manually for a month or so. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Kieren MacMillan wrote Monday, September 07, 2009 7:40 PM which works fine, if I understand what you want. So I was wondering if Trevor was referring to something else... Yes, I was thinking more of \lyricsto, which needs a named context, and perhaps SATB on two staves. I originally placed the \\ construct first as it seemed simpler, but too many people adopted it as the only or at least the recommended way of writing concurrent music, only to find difficulties when they moved on to more complex scores. The \\ construct has its use, but I now think teaching the \new Voice method at the start gives a better and sounder grounding. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtest spacing-loose-grace-linebreak.ly is broken
2009/9/7 Neil Puttock : > I'm just trying to do a binary search to work out when this broke. Found it. It's Joe's empty barline fix (#462). I thought setting protected-scheme-parsing to #f might cause the regression tests to break for this snippet, but it carries on merrily to the end. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtest spacing-loose-grace-linebreak.ly is broken
2009/9/7 Patrick McCarty : > I did a completely clean build yesterday, so I don't think this is the > problem. Hmm, this is weird; I also did a clean build last night, and there's no image for this regtest in the collated files (it's also missing from kainhofer). I'm just trying to do a binary search to work out when this broke. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtest spacing-loose-grace-linebreak.ly is broken
On 2009-09-07, Graham Percival wrote: > On Mon, Sep 07, 2009 at 01:17:14PM -0700, Patrick McCarty wrote: > > P.S. Why doesn't this break `make doc' ? > > If it compiled under a previous git version, and you don't do a > make doc-clean, then lilypond won't attempt to recompile the > previously-compiled regtest. I did a completely clean build yesterday, so I don't think this is the problem. This is what my make-doc.log looks like compared to the log I posted: Renaming input to: `spacing-loose-grace-linebreak.ly'] Interpreting music... elapsed time: 0.01 seconds Element count 96 (spanners 7) Preprocessing graphical objects... Grob count 164 Calculating line breaks... Drawing systems... programming error: bounds of spanner are invalid programming error: bounds of spanner are invalid programming error: bounds of spanner are invalid programming error: bounds of spanner are invalid programming error: bounds of spanner are invalid programming error: bounds of spanner are invalid Element count 63 [ programming error: system with empty extent0][ programming error: system with empty extent1] Writing header field `texidoc' to `./b3/lily-393380fd.texidoc'... Writing ./b3/lily-393380fd-1.signature Writing ./b3/lily-393380fd-2.signature Layout output to `./b3/lily-393380fd-1.eps'... Layout output to `./b3/lily-393380fd-2.eps'... Converting to `./b3/lily-393380fd-1.pdf'... Invoking `gs -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile="./b3/lily-393380fd-1.pdf" -c .setpdfwrite -f "./b3/lily-393380fd-1.eps"'...GPL Ghostscript 8.70 (2009-07-31) Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtest spacing-loose-grace-linebreak.ly is broken
On Mon, Sep 07, 2009 at 01:17:14PM -0700, Patrick McCarty wrote: > P.S. Why doesn't this break `make doc' ? If it compiled under a previous git version, and you don't do a make doc-clean, then lilypond won't attempt to recompile the previously-compiled regtest. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtest spacing-loose-grace-linebreak.ly is broken
Hi,
I tried compiling the regression tests in a separate directory (just
using the lilypond binary), and the test
"spacing-loose-grace-linebreak.ly" fails to compile.
Attached is the tail end of `lilypond --verbose'.
Thanks,
Patrick
P.S. Why doesn't this break `make doc' ?
Interpreting music...
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-20.otf]
elapsed time: 0.30 seconds
Element count 96 (spanners 7)
Preprocessing graphical objects...
Grob count 164
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-11.otf]
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-13.otf]
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-14.otf]
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-16.otf]
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-18.otf]
[/home/pnorcks/usr/share/lilypond/2.13.4/fonts/otf/emmentaler-23.otf]
[feta-alphabet20_7.029296875]
Solving 1 page-breaking chunks...
[century_schoolbook_l_serif_3.865234375][1: 1 pages]
Drawing systems...
programming error: bounds of spanner are invalid
programming error: bounds of spanner are invalid
programming error: bounds of spanner are invalid
programming error: bounds of spanner are invalid
programming error: bounds of spanner are invalid
programming error: bounds of spanner are invalid
Element count 63
programming error: didn't find a vertical alignment in this system
programming error: didn't find a vertical alignment in this system
programming error: system with empty extent
programming error: system with empty
extent/home/pnorcks/usr/share/lilypond/2.13.4/scm/lily.scmBacktrace:
In unknown file:
?: 9* [#]
In /home/pnorcks/usr/share/lilypond/2.13.4/scm/lily.scm:
726: 10* [ly:parse-file "spacing-loose-grace-linebreak.ly"]
In /home/pnorcks/usr/share/lilypond/2.13.4/ly/init.ly:
42: 11* (let* ((book-handler #)) (cond (# #) (# #)))
45: 12 (cond (# #) (# #))
In /home/pnorcks/usr/share/lilypond/2.13.4/scm/lily-library.scm:
...
165: 13 [ly:book-process # #< Output_def> ...]
In unknown file:
?: 14* [ly:optimal-breaking #]
?: 15* [page-stencil #]
In /home/pnorcks/usr/share/lilypond/2.13.4/scm/page.scm:
328: 16* (if (not (ly:stencil? #)) (page-set-property! page (quote stencil)
...))
333: 17 [ly:prob-set-property! # stencil ...
333: 18* [make-page-stencil #]
209: 19 (let* (# # # # ...) (if # #) (if # #) ...)
288: 20* [map # (# #)]
In unknown file:
?: 21* [# #]
In /home/pnorcks/usr/share/lilypond/2.13.4/scm/page.scm:
242: 22* (let* (# # #) (add-to-page stencil # y) (if # #) ...)
246: 23* [# # 0.0 {()}]
232: 24 (set! page-stencil (ly:stencil-add page-stencil #))
233: 25* [ly:stencil-add # ...
234: 26* [ly:stencil-translate # ...
235: 27* [cons 0.0 ...
237: 28* [- 0 {()} 2.84527559055118]
/home/pnorcks/usr/share/lilypond/2.13.4/scm/page.scm:237:68: In procedure - in
expression (- 0 y ...):
/home/pnorcks/usr/share/lilypond/2.13.4/scm/page.scm:237:68: Wrong type: ()
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH v3] Fix crash when a stencil routine is missing
On 2009-09-06, Michael Käppler wrote: > Hi Patrick, > I recently noticed that /input/regression/bookparts.ly gives the > warning "Missing stencil expression: utf-8-string" what I think is > related to your patchset. > Could you please have a look at this? This should be fixed in git. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme compiler of Guile 1.9.2
On Wed, Sep 2, 2009 at 10:00 AM, weblily wrote: > Compiling LilyPond's scheme code might lead to a considerable speed up. > Guile 1.9.2 comes with a scheme compiler. I 've tried now for some time to > get the compiler running, but it will need some more work. > > * Is anyone doing the same and wants to share his/her experiences with me? > * Are there any opinions about possible speed ups? Does using a compiler for > Scheme make sense after all? Most of the code that takes a lot of time runs in C++. In random order: formatting beams, formatting slurs, spacing & line breaking. Before investing a lot of time in optimizing things, I recommend running a profile. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme compiler of Guile 1.9.2
On Fri, Sep 4, 2009 at 10:56 PM, Valentin Villenave wrote: > If nobody objects, I'll open a page in the tracker to keep track of this idea. Added as #835. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Hi Karl,
or when there are lyrics to assign.
What do you mean here?
Do you mean lyrics to assign to the *second voice* (since the first
voice assignment would be automagic)?
Try:
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << g \\ d >> g2 }
}
\addlyrics{ a b c }
}
No voice in the << \\ >> section gets any lyrics here.
My point was, if \\ did the right thing, your example would
automagically expand to become
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << { \voiceOne g } \context Voice =
"2" { \voiceTwo d } >> \oneVoice g2 }
}
\addlyrics{ a b c }
}
which works fine, if I understand what you want. So I was wondering
if Trevor was referring to something else...
Regards,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
...
> > or when there are lyrics to assign.
> What do you mean here?
> Do you mean lyrics to assign to the *second voice* (since the first
> voice assignment would be automagic)?
Try:
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << g \\ d >> g2 }
}
\addlyrics{ a b c }
}
No voice in the << \\ >> section gets any lyrics here.
Regards,
/Karl
---
Karl HammarAspö Data k...@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
---
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Hi Trevor, This change would help, but I don't think it would solve the whole problem. You'd still have an implied name for the second context, so it doesn't work in more than one staff Probably true... I'll have to examine the ramifications. or when there are lyrics to assign. What do you mean here? Do you mean lyrics to assign to the *second voice* (since the first voice assignment would be automagic)? Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Make default margin values depend on paper size.
I like what you've done. I've put a couple of comments in. They are not mandatory, but just for your consideration. Carl http://codereview.appspot.com/115065/diff/1001/1003 File scm/paper.scm (right): http://codereview.appspot.com/115065/diff/1001/1003#newcode220 Line 220: (scaleable-values (list I think it would be better to use symbols, rather than strings, here. I don't have a strong preference for this; obviously these strings are only used locally to define symbols later on. But the things they stand for are symbols elsewhere in the code, so I'd prefer using symbols here. http://codereview.appspot.com/115065/diff/1001/1003#newcode221 Line 221: (cons "left-margin" w) I think you could alternatively do (either with symbols or strings): (scaleable-values `((left-margin . ,w) (right-margin . ,w) (top-margin . ,h) ... (short-indent . ,w)) http://codereview.appspot.com/115065/diff/1001/1003#newcode232 Line 232: ((value-symbol (string->symbol (string-append (car value) "-default"))) I you were using symbols, you'd have (value-symbol (string->symbol (string-append (symbol->string (car value)) "-default"))) http://codereview.appspot.com/115065/diff/1001/1003#newcode244 Line 244: (module-define! m 'left-margin-default-scaled (cdr (assoc "left-margin" scaled-values))) This is a potential error waiting to cause problems for a user. assoc can return #f, and (cdr #f) is an error. If you use assoc-get, you can supply a default value, e.g. (module-define! m 'left-margin-default-scaled (assoc-get 'left-margin scaled-values default-value)) where default-value is whatever the reasonable default value would be if things somehow got broken. I realize that you have just built the list here, so you're in control and it can be argued that this is not necessary. I'm not demanding this change, just asking you to consider it. http://codereview.appspot.com/115065 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Make default margin settings depend on paper size
Hi all, I rewrote the patchset to have less doubled scheme code and make it extensible. Any comments are very welcome. Regards, Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: Further Reading for contemporary music
Graham Percival wrote: > In the case of Arabic music, I think part of the argument (in > favor) was that the notation isn't standard, but the author(s) did > the best they could, and people interested in seeing the > inconsistencies can progress to X, Y, and Z. It's also only one > page... I could see a section on contemporary music easily > becoming a monster. Especially if it includes scores. > > I guess I just don't have any firm feelings on this at the moment. I think the same arguments apply, to an extent, with contemporary music. We just have to be careful about limiting the list to essentials (especially if we include scores) -- that is, 'mainstream' references and scores rather than 'here's another notation that one or two composers are working with'. I will certainly not let MY list run away. I remember years ago there used to be a website listing the conclusions of the 1974 Ghent conference on music notation, but I can't find it any more. Does anyone have any memories/info? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: 'line' articulation
2009/9/7 Michael Käppler : > Hi all, > Hmm... was there any progress since July on this topic? > I'd like to year if there's anything new... ;) Not really, I'm afraid. The reason is that I've been abroad for a few months and couldn't really work on this for the last couple of weeks. I won't have any access to my computer for another week and will move to England afterwards, so expect it to be on hold for another month or so. But once I've settled on the island, I hope I can spend more time on this. Sorry for the delay. I'll keep you posted. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: Further Reading for contemporary music
On Mon, Sep 07, 2009 at 08:07:33AM +0100, Trevor Daniels wrote: > > Graham Percival wrote Monday, September 07, 2009 12:53 AM > >> No; dump it in the Advanced git section. It's not something we >> want to insist that first-time contributors do. Once they show >> themselves to be regular, and get more excited about seeing their >> work being added to the official docs, *then* we'll ask them to do >> this. Get them hooked first. > > Are you sure? I can't see anything that tells first-time > contributors how to mail a patch. I've had trouble with > every one so far - it seems they all use Thunderbird. In > fact I'm surprised that bouncing their first few attempts > because they don't apply hasn't put off more of them. Yes, I'm sure that I want the reviewer (i.e. you) to silently fix any end-of-line stuff, for the first 3-4 commits from somebody. Don't ask them to fix it, don't ask them to look in CG x.y, don't even tell them that there's anything questionable about their patches. (unless there's issues with the actual content) Let them attach patches on whatever system they have with whatever email program they use. If we can fix such broken patches by simply running "dos2unix foo.patch", then just do that. The above should probably be added to the CG section on applying patches. After 3-4 patches, point them at the relevant advanced git CG chapter that discusses different attachment options or git send-email or whatever. Taking it on an individual basis, of course -- if somebody seems technically challenged, then maybe don't bug them until 5 or 10 patches. If they seem quick, then maybe after only 2 patches. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Kieren MacMillan wrote Sunday, September 06, 2009 3:34 PM
\\ is quite more convenient than explicit voices and thus an
important
idiom that makes Lilypond friendlier to the user.
Yes, but as previously discussed, the confusion it (ultimately)
causes is a poor
trade-off. The whole problem would be solved if \\ Did The Right
Thing, i.e.
<< { musicA } \\ { musicB }>>
would automagically expand to
<< { \voiceOne musicA } \context Voice = "2" { \voiceTwo
musicB }>> \oneVoice
This change would help, but I don't think it
would solve the whole problem. You'd still have
an implied name for the second context, so it
doesn't work in more than one staff, or when
there are lyrics to assign.
I can take this on as my next Frog task, if it requires no C++.
Then, the
documentation can simply use \\ early on (e.g., in the LM), and
show what it does > later.
I think this is implemented in voicify-music
in scm/music-functions.scm.
I'll hold fire on the re-documentation a bit
longer until you've had a look at this.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB do_not_look_in_slash_usr
Op maandag 24-08-2009 om 23:33 uur [tijdzone +0100], schreef Graham Percival: > I'm getting build errors in freetype. Are you sure this is freetype and not cross/gcc? ;-) > File "bin/../gub/specs/cross/gcc.py", line 105, in patch > Gcc.patch (self) > File "bin/../gub/specs/cross/gcc.py", line 17, in patch > gcc.do_not_look_in_slash_usr (self) > AttributeError: 'module' object has no attribute > 'do_not_look_in_slash_usr' Are you up to date and have you looked if this makes any sense? Greetings, Jan. Hints: $ grep 'def do_not_look_in_slash_usr' gub/specs/gcc.py def do_not_look_in_slash_usr (self): 09:58:31 jann...@heerbeest:~/vc/gub $ python -c 'from gub.specs import gcc; gcc.do_not_look_in_slash_usr (0)' Traceback (most recent call last): File "", line 1, in File "gub/specs/gcc.py", line 60, in do_not_look_in_slash_usr self.file_sub ([ AttributeError: 'int' object has no attribute 'file_sub' [1]09:58:48 jann...@heerbeest:~/vc/gub -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: Further Reading for contemporary music
Joseph Wakeling wrote Monday, September 07, 2009 12:41 AM Joseph Wakeling wrote: the duplication of two @nodes called 'Further reading' may break the doc build -- just checking that now. Duplicate node names in the same manual do break the build. ... which the attached patch should fix. It does - thanks. I've also made the similar node name in Arabic more specific. I've now pushed all these changes to origin/master. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Implement new handling for margin settings
On Wed, 2009-09-02 at 09:34 +0200, Michael Käppler wrote: > Hi Neil, > > 1. Setting system-count = 1 causes a segfault (try running the file > > Documentation/general/examples/granados.ly) > > > I've checked out a fresh master and it seems that it also crashes > without my patches. Can you reproduce this? > The problem occurs after page-breaking.cc:525 I think. There > details.last_column_ contains an empty Grob (0x0). When calling the > methods of the Grob class on it, it crashes, which happens after > is_break (). > 2.13.3 doesn't have this problem, but there were lots of commits between. > Joe, can you help? Fixed in git. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: Further Reading for contemporary music
Graham Percival wrote Monday, September 07, 2009 12:53 AM
On Sun, Sep 06, 2009 at 11:22:42PM +0100, Trevor Daniels wrote:
Joseph Wakeling wrote Sunday, September 06, 2009 10:36 PM
This probably _is_ something which should be in the docs as it's
not
something you would imagine would be a solution.
Could you let me have a suitable form of words? I suggest a new
section in the CG - 1.3.3 Mailing a patch.
No; dump it in the Advanced git section. It's not something we
want to insist that first-time contributors do. Once they show
themselves to be regular, and get more excited about seeing their
work being added to the official docs, *then* we'll ask them to do
this. Get them hooked first.
Are you sure? I can't see anything that tells first-time
contributors how to mail a patch. I've had trouble with
every one so far - it seems they all use Thunderbird. In
fact I'm surprised that bouncing their first few attempts
because they don't apply hasn't put off more of them.
As for the patch: this particular part of the contemporary music
docs
('Further reading') is something it would be great for other
people to
pitch in on. I've split the section into two: on the one hand
books
and
articles (including webpages) that are useful; on the other,
scores and
musical extracts (again, possibly including online examples)
that are
interesting with respect to learning about contemporary
notation.
This information is undeniably useful, but I'm not sure it should
be part of the *LilyPond* Notation Reference. We haven't
included
external references like this elsewhere, yet the Stone and Read
books
are very general and useful to all kinds of musical notation.
I'll wait for comment from Graham (and others) before pushing
this.
Hmm. I'd forgotten (and still can't remember!) that World music
had such a section. At the very minimum, that section should be
renamed to "Further reading for arabic music" or "Arabic future
reading" or something like that.
Done
In the case of Arabic music, I think part of the argument (in
favor) was that the notation isn't standard, but the author(s) did
the best they could, and people interested in seeing the
inconsistencies can progress to X, Y, and Z. It's also only one
page... I could see a section on contemporary music easily
becoming a monster. Especially if it includes scores.
I guess I just don't have any firm feelings on this at the moment.
Neither did I, but as we have one in favour (Joe)
and two ambivalent I've pushed the changes. As
this is a manual on LilyPond notation rather than
contemporary music we must keep this section brief
and directly relevant to LilyPond notation.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
