Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On a related issue: one thing that's probably clear looking at Ferneyhough scores is the way in which the vertical placement of hairpin endpoints is strongly coupled with the vertical placement of dynamic marks. I don't think it's really appropriate to bundle all of this together into one feature request, but it would probably be useful as a complementary feature request to do some re-evaluation of Lilypond's vertical placement of hairpin end-points, and whether it's possible to automate the placement of angled hairpins so as to optimize the relative positions of hairpin start- and endpoints and nearby dynamic marks. N.B. this is useful for all music, not just Ferneyhough. It's a fairly consistent bugbear of mine that hairpin start- and endpoints are not better placed relative to dynamic marks. I think this has already been touched on to an extent in the discussion above ... ? https://codereview.appspot.com/7615043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 2013/03/17 14:37:52, thomasmorley65 wrote: > This is doable, but I'd wait to see from someone who knows how these things work > if this is actually how they are printed. > I want to say that they are always printed with the line going up irrespective > of the side of the staff, but I could be wrong. The only Ferneyhough-score I've at home prints the dynamics always below the system. There are Ferneyhough scores with dynamics above the staff -- some of the piano works (e.g. Lemma-Icon-Epigram), and some of the vocal works. See e.g. the second movement of his 4th String Quartet which has a part for soprano: http://www.youtube.com/watch?v=hVaDOz7bWU0 In this you see flared hairpins above the staff, and also dynamic brackets above the staff (e.g. at about 1:33 where there's a great long bracket above the soprano part). The more general remark is that even if Ferneyhough did only place his dynamic markings below the staff, you couldn't assume that would remain true of all composers wanting to use Ferneyhough-like dynamic indicators in their scores :-) Final remark: while it's nice to see Ferneyhough getting namechecked might it be worth naming this alteration as flared-hairpin rather than ferneyhough-hairpin? https://codereview.appspot.com/7615043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG tweak: some extra info on make doc and doc build times. (issue 6206071)
On 2012/05/31 00:01:55, dak wrote: That's not the Google tracker issue number, but the Rietveld issue number. The Google tracker number would have been 2534 . Please enter a valid google tracker issue number (or enter nothing to create a new issue): 2534 WARNING: could not change issue labels; please email lilypond-devel with the issue number: 2534 Tracker issue done https://codereview.appspot.com/6206071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG tweak: some extra info on make doc and doc build times. (issue 6206071)
I have always been using git-cl but for all patches after the first I got an error message after entering the google tracker issue number: --- We were not able to associate this patch with a google tracker issue. Please enter a valid google tracker issue number (or enter nothing to create a new issue): 6206071 WARNING: could not change issue labels; please email lilypond-devel with a general description of the problem Server responded with: 404, issue 6206071 in project lilypond not found Tracker issue done --- As the patches did in fact upload, I didn't realize there was a problem. :-( Anyway, the warning is included and I can push this to a new issue if it's needed to make sure it gets included. https://codereview.appspot.com/6206071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG tweak: some extra info on make doc and doc build times. (issue 6206071)
On 2012/05/30 21:16:09, Graham Percival wrote:
The @warning{}
... I'm blind. Give me 2 seconds to fix that.
https://codereview.appspot.com/6206071/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG tweak: some extra info on make doc and doc build times. (issue 6206071)
On 2012/05/30 16:55:17, Graham Percival wrote: I'm not convinced that the added text will help. How about instead you change it to ... done :-) https://codereview.appspot.com/6206071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG tweak: some extra info on make doc and doc build times. (issue 6206071)
Latest patches update as suggested The build section has a link to 4.6.2 and I've slightly tweaked the language of the latter section as well as mentioning the doc-stage-1 build option. https://codereview.appspot.com/6206071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
CG tweak: some extra info on make doc and doc build times. (issue 6206071)
Reviewers: ,
Message:
As per earlier discussion on devel list, this patch just adds a little
bit of extra info on the make process, noting the documentation build
commands and the possible length of build times.
Basically it's to stop other people getting worried as I did when a
single step of the doc build process seemed to have hung with no
progress.
Description:
CG tweak: some extra info on make doc and doc build times.
Please review this at https://codereview.appspot.com/6206071/
Affected files:
M Documentation/included/compile.itexi
Index: Documentation/included/compile.itexi
diff --git a/Documentation/included/compile.itexi
b/Documentation/included/compile.itexi
index
e95cf2629cd8122a1f7c0c909f3f8d731d5bef0e..4b87ce1fc7602edccb32592a6aa232d62ce08b74
100644
--- a/Documentation/included/compile.itexi
+++ b/Documentation/included/compile.itexi
@@ -456,6 +456,23 @@ targets, run:
make help
@end example
+For example, to build documentation, you can use
+@example
+make doc
+@end example
+
+or to build only the PDF documentation,
+
+@example
+make doc-stage-1
+@end example
+
+Documentation builds can take much longer than building LilyPond itself.
+Some individual commands issued during the make process may take as long
+as an hour to complete on older single-core machines, so don't panic if
+for a long time it looks like nothing is happening! Be patient, and the
+build will complete.
+
TODO: Describe what @command{make} actually does.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG tweak: some extra info on make doc and doc build times. (issue 6206071)
On 2012/05/16 12:05:19, Graham Percival wrote: Don't we have a different place that discusses the doc-related build stuff? You're right; it's in Section 4.6.2. It's not necessarily obvious/easy to find as Section 4.6 is simply titled 'post-compilation options'. I'll tweak as you suggest, with links. https://codereview.appspot.com/6206071/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes not propagating when (re)building docs
On 07/05/2011 11:16 AM, Joseph Wakeling wrote: > So, it looks like changes made to .itely files are not being picked up > as relevant to the build process. > > Any suggestions on how to fix this? Sorry, missed a "Known Issues" note in the contributors' manual: touch Documentation/notation.tely ... also works. Still, it's a hefty rebuild that results -- all the different untouched .itely files seem to be reprocessed -- is there any way of narrowing down the amount of stuff that needs to be rebuilt? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Changes not propagating when (re)building docs
Hello all, I'm preparing a few patches for the notation manual (the section on contemporary music I started ages back but didn't follow through on properly), but have encountered a problem. I've built both Lilypond and the docs successfully, and now I'm editing the file Documentation/notation/contemporary.itely Once done with changes, naturally I use make doc or make doc-stage-1 to rebuild the docs. However, my changes to contemporary.itely are not picked up on. The only way I've found to remedy this is to entirely delete the notation manual output: rm -r Documentation/out-www/notation* rm -r Documentation/notation/out-www and redo the make doc-stage-1 from there, which seems rather messy. To check it wasn't just contemporary.itely, I also tried playing with a few of the other files in the Documentation/notation/ directory, with the same result. So, it looks like changes made to .itely files are not being picked up as relevant to the build process. Any suggestions on how to fix this? It's not such a big deal to have to manually delete and rebuild, but it would be nice for the build system to automatically pick up on such changes. Thanks and best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 04/29/2011 07:15 PM, Carl Sorensen wrote: > This might work, but fails to meet the major criterion of the proposed > branching scheme. The proposal is to make 2.14 stable. Yes, that's why my proposal was to apply every BUGFIX to 2.14 first, not every patch. :-) (Of course, by "bugfix", I mean "fix for a bug in 2.14". Bugs in dev only should get fixed in dev only.) > Actually, I think your final comment is backwards. Every patch is > applicable to dev, but only some are applicable to 2.14. Backwards for patches in general; not for bugfixes. The idea is that bugfixes get applied to 2.14 first and then merged into dev (minimal cherrypicking here); while other patches (new features etc.) get applied to dev and never go near 2.14. dev still gets everything, 2.14 gets just what it needs, and in the best case scenario, you should _never have to cherrypick_, just merge from 2.14 to dev every time there is a bugfix. Is the idea clearer now? By the way, sorry for not following up on this sooner. Busy time in the office. :-( Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 04/15/2011 07:05 PM, Carl Sorensen wrote: > Just to be sure I understand correctly, the only things I will cherry-pick > into stable/2.14 will be bugfixes for critical bugs. Just as a remark, I wonder if you may find it easier to adopt an alternative workflow: -- bugfix gets applied first in 2.14 branch -- bugfix gets merged into master dev branch since that probably reduces the amount of cherry-picking that's needed -- I expect that probably almost every patch applied to 2.14 is also applicable to dev, but not vice versa. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/21/2010 10:33 PM, Joseph Wakeling wrote: > On 09/21/2010 08:13 PM, Graham Percival wrote: >>> Does that settle the matter adequately? :-) >> >> No, because it's not in the issue tracker. > > I'll put it there! Just checking that the source is adequate. Done, but could not attach the scans -- too big. :-( ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/21/2010 08:13 PM, Graham Percival wrote: >> Does that settle the matter adequately? :-) > > No, because it's not in the issue tracker. I'll put it there! Just checking that the source is adequate. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/21/2010 05:28 PM, Joseph Wakeling wrote: > Stone's guidance about the choice of accidentals is IMO something for > composers to consider rather than Lilypond. From a Lilypond point of > view, the issue should simply be: the composer can have the accidentals > s/he chooses. ... but ... thank you for uploading the page. :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/21/2010 04:52 PM, Carl Sorensen wrote: > However, I was wrong in my assumption that something about the key signature > should determine which of the enharmonic equivalents should be used. > Instead, it appears that the neighboring notes should govern in tonal music. > In atonal music, it doesn't matter, except that it does in rapid passages. > There's virtually no guidance there that I can see for nontonal music. Stone's guidance about the choice of accidentals is IMO something for composers to consider rather than Lilypond. From a Lilypond point of view, the issue should simply be: the composer can have the accidentals s/he chooses. > Transposition of exact quarter tones into appropriate notation is likely to > remain a *very* tricky problem. Why do you think so? If you're transposing in a regular fashion (i.e. by a certain number of semitones) you just transpose the underlying notes and preserve the arrows. If you want to transpose up/down by a quarter-tone, you just add an up/down-arrow to all the accidentals that don't already have one; all those that do, you bump them up/down to the next 'tonal' accidental. The only thing you have to take into account is that you almost certainly need to convert double-sharps and flats to naturals of the staff pitches above and below respectively. That requirement is one reason I've been trying to address Lilypond support for chromatic transposition recently. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/21/2010 04:42 PM, Han-Wen Nienhuys wrote: > This is not the nuance implied, since by your definition, > natural-uparrow (+1/4) and sharp-downarrow are the same, and you > clearly want them to mean something different. They are enharmonically the same pitch, which can be notated in two (symbolically and semantically) different ways. 0 + 1/4 and 1/2 - 1/4 are the same if you consider only the sum, but they're not the same if you consider the _series_. Lots of microtonal notations work on the basis of a superposition of ever-smaller intervals in this way. > What is the difference between both? Similar to the difference between C-sharp and D-flat. C raised by a semitone is musically not the same as D lowered by a semitone, even though in equal-tempered tuning they correspond to the same enharmonic pitch. Likewise, C-natural raised by a quarter-tone is musically not the same as C-sharp lowered by a quarter-tone, even though the resulting frequency is the same. > The current system satisfies these constraints obviously, but it > possibly does not represent well various nuances of scales that may > exist. Exactly. :-) Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/21/2010 02:16 PM, Hans Aberg wrote: > Yes - accidentals do not affect the degree: they are of degree zero. One > can add notes and intervals on this abstract level, and the degrees add > as well. In mathematics, a function f is called a homomorphism (of > abelian groups) when f(0) = 0, f(x + y) = f(x) + f(y), f(-x) = -f(x). > The degree, which is the sum of the coefficients is a homomorphism. Ahhh, NOW you are bringing the discussion into terms that I can appreciate. I have studied group theory, but it was 10+ years ago without using it since, and hence my recollection is extremely flaky. So it was difficult to work out what you were getting at with your earlier explanations which tried to limit the use of precise mathematical terminology. In my case I need _more_ maths, not less, because it helps me re-familiarize myself with the exact concepts I need to understand your system ... :-) Anyway, I will take the time to go over your answers properly and surely be back with more questions. >> ... so if we extend this vectorial representation to a 3D case for >> quarter-tones, (x_M, x_m, x_q), (NB my q is different from yours:-) > > Yes, some mathematicians do that error, too, though in print, q as a > variable might be typeset in italic, whereas as constant in upright type. I don't understand what you consider an error here. I understood very well that you were using the letter q to represent a coefficient. I just wanted to use q to represent a group element, so re-labelled the coefficients of the elements M, m and q by x_M, x_m and x_q. It may be an error to think of "vectorial representation", but ... :-P ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 05:27 PM, Graham Percival wrote: >> For arrowed quarter-tones the notation is described (and recommended) in >> Kurt Stone's book "Music Notation in the Twentieth Century". > > Excellent reference! That book is frequently quoted on this list, so > this should settle any question of "is it necessary". I remembered that I have copies (from JSTOR) of a couple of articles Stone wrote prior to the publication of the book, giving a very condensed summary of the notation issues. The attached PNG (I hope it is small enough to get through) gives the appropriate paragraphs of that article. The full citation is K. Stone, Music Educators' Journal, vol. 63 no. 3 (Nov. 1976), pp. 54-61; it's available online at: http://www.jstor.org/stable/3395098 Unfortunately it doesn't explicitly note the enharmonic issues in the same way as the book, but their existence is obvious given the accidentals described. The article adds: Conferees of the International Conference on New Music Notation in Ghent ... preferred this arrowed set of accidentals for two reasons: (1) there has been increased acceptance of the arrow system among composers, even though there is not yet a clearly discernible preference for _any_ of the systems of adaptation shown; (2) arrows are superior in clarity to any of the other alterations because they are self-explanatory. In other words, the conferees, in this case, based their choice on statistical as well as evaluative considerations. Does that settle the matter adequately? :-) Best wishes, -- Joe <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 03:41 PM, Hans Aberg wrote: > A sharp is M-m and a flat m-M. If I understand right, this is a key "trick" of your system, since such representations allow you to raise or lower the pitch without affecting the degree. So by extension, if we say that q is a quarter-tone, to raise or lower by a quarter-tone would be to add (m-q) or (q-m); and to raise or lower by 3/4-tone would be to add (M-q) or (q-M). but where/how in that system do we distinguish between for example natural + 1/4 and sharp - 1/4 ? Presumably the former is (m-q) whereas the latter is (M-m)+(q-m) ... ? > In the traditional typesetting, one has a minor second m and a > major second M, so it is all combinations p m + q M, where p, q > are integers, which can be identified with all pairs (p, q). ... so if we extend this vectorial representation to a 3D case for quarter-tones, (x_M, x_m, x_q), (NB my q is different from yours:-) we can think of natural+1/4 as being (0, 1, -1) while sharp-1/4 would be given by (1, -2, 1). Depending on the notational system desired, those could then be represented by the same accidental (the half-sharp symbol) or different ones (natural-with-up-arrow and sharp-with-down-arrow). Suppose now that I wanted to extend the quarter-tone system to one including eighth-tones (I'm thinking here of Ferneyhough's "La chûte d'Icare" which uses the "standard" quarter-tone accidentals supported by Lilypond plus up- and down-arrows to indicate raising or lowering by an approximate eighth-tone). Would I have to add an extra dimension to my vector space, (x_M, x_m, x_q, x_e) ... or is there a cleverer way of dealing with this which lets you keep only 3 dimensions? The reason I ask is that I can't see a means of raising/lowering by an eighth-tone without altering the degree, unless I have the possibility to have forms (q-e) and (e-q). ... or did your term "neutral second" mean "something that does not alter the degree by definition"? Incidentally, if I understand right I think your system offers a way of separating out the definitions of staff pitches and accidentals, since one can define the former merely in terms of degree values, while the latter can be defined independently in terms of different zero-degree "vectors"; although I wonder whether it might be better from a representational view to think of maps rather than vectors, e.g. "Major second" -> 0 "minor second" -> 1 "quarter-tone" -> -1 for quarter-sharp, since this kind of representation allows you to maintain different "neutral seconds" without risk of overlap. (Forgive me if this kind of stuff is dealt with in your code; I haven't looked, because my Haskell knowledge is extremely basic and these days are extremely busy in my day job...:-) Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 05:27 PM, Graham Percival wrote: >> For arrowed quarter-tones the notation is described (and recommended) in >> Kurt Stone's book "Music Notation in the Twentieth Century". > > Excellent reference! That book is frequently quoted on this list, so > this should settle any question of "is it necessary". Yes. :-) He also explicitly highlights the enharmonic equivalence issue we discussed. > One scan should be fine. The first step is to convince people that > the representation needs to be extended, and Stone should be > sufficient for that. The next step is for somebody actually code it. Sure. I'll try and follow up with Hans separately, just to explore his code and ideas and see if they might be useful here. Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 03:22 PM, Graham Percival wrote: > Hmm. This is similar to the distinction between cis and des, correct? Yes, exactly, it's an enharmonic equivalence. > Am I also correct in assuming that d-3/4 is not sufficient? Also, is > there a frequency difference between c+1/4 and cis-1/4 ? Or is this > purely a difference in graphical notation? Indeed, d-3/4 is not sufficient [1]: in arrow quarter-tone notation you want to be able to indicate quarter-tone raising or lowering of any of the 12 standard tones. There should be no frequency difference between c+1/4 and cis-1/4. Some composers do use the arrow notation to indicate approximate quarter-tones, but many assume that the quarter-tones are exact. I did prepare a "cheat" implementation of quarter-tone arrow notation where there were subtle pitch differences (c+999/4000, cis-999/4000). This kind of works but it generates all sorts of nightmares with transposition and means having to write out a HUGE accidentals list (see discussion in Issue 694). > I believe that this is a valid feature request -- a single > "alteration" value is not sufficient to distinguish between c+1/4 and > cis-1/4. Yes -- but it goes beyond arrowed quarter-tone notation. I was a bit long-winded and abstract because I wanted to stress that it was a general problem for many different microtonal notations, rather than just arrow quarter-tones. > As a general rule -- please take the time to prepare a tiny .ly > example showing what you wanted to do. It took me about 10 minutes to > read your email, think about it, and prepare a good tiny example. > Since you're more familiar with this material, you probably could have > made the example in 2-3 minutes. Having an example makes the > difference between a developer understanding the issue in a matter of > 30 seconds vs. 3 minutes, and when we have over 400 open > bugs+enhancement requests, that difference is significant. Yes, I'll try and do that in future. > 2) make a scan of some published music that uses this notation. This > will immediately silence anybody who wants to argue (as I somewhat > did) that a single fraction is sufficient to show any microtonal > notation. For arrowed quarter-tones the notation is described (and recommended) in Kurt Stone's book "Music Notation in the Twentieth Century". I don't own a scanner :-( but will try and take a copy of the relevant page (it's pp.67-70 IIRC; I was looking at it last night). There are various other notations to consider that have a similar character. I'll try and prepare a variety of representative examples. > 3) send it the bug list so that it gets added to the tracker. > > 4) wait. Maybe offer a bounty to entice somebody to work on it. Hans Aberg's work looks promising. I don't understand it properly yet, but I'll try and prepare a set of examples to test whether it could provide a solution. Best wishes, -- Joe [1] There used to be a "how to do arrow quarter-tone notation" example somewhere in the docs, which "solved" the problem by simply not having a cis-1/4 symbol. That was what got me thinking about the whole issue in the first place. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 12:23 PM, Hans Aberg wrote: >> I saw the post but was not sure quite how to interpret it. > > I expected someone to ask for details. In the past, I discussed part of > it with Graham Breed, who did some LilyPond microtonal implementation, > but perhaps he is not working on it anymore. I get the feeling activity is rather focused right now on getting 2.14 released ... :-) I also discussed microtonal stuff with Graham Breed a while back, but we weren't really able to bring anything to a satisfactory conclusion. > If you want, I can explain it - the algorithm itself is very simple. > Writing up it in math style will probably not make it more accessible. It would make it clearer to me, surely. What I'd like to see is for it to be written up in a structured way along the lines of (i) this is the problem that needs solving, (ii) this is the approach the algorithm takes to solve the problem, (iii) this is the algorithm. >> I did wonder if the fact it was Haskell code was part of the reason for >> the lack of response. I have a lot of admiration for Haskell but I can >> see there being problems extending Lilypond with yet another language. > > It should not be difficult to translate into Scheme - no specific > Haskell features are used, only better syntax and type system to help > structuring the code. It is just a page. > > The difficulty is to figure out to put it into LilyPond. Indeed, it sounds like a pretty fundamental major-version-number-changing kind of modification. As a related issue, have you considered how (different kinds of) transposition would be handled in your pitch scheme? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 10:47 AM, Hans Aberg wrote: > On 20 Sep 2010, at 00:50, Joseph Wakeling wrote: > >> Hence why I say that the issue of effective microtonal support still >> requires action at the code level, and is not simply a matter of better >> documentation ... :-( > > I made a post about this issue last week, but there were no responses. > > http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00138.html I saw the post but was not sure quite how to interpret it. Could you write up some more extensive notes on the algorithm and its aims and possibilities? I did wonder if the fact it was Haskell code was part of the reason for the lack of response. I have a lot of admiration for Haskell but I can see there being problems extending Lilypond with yet another language. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond's internal pitch representation and microtonal notation
Hello all, This email is an attempt to clarify some outstanding issues regarding support for microtonal notation in Lilypond. It's being written in response to recent discussion with Graham Percival on Lilypond Issue 694: http://code.google.com/p/lilypond/issues/detail?id=694 To begin with, let's review how Lilypond represents pitch. A pitch is represented by a triple of numbers (octave, note, alteration) where "octave" is an integer, "note" is an integer in the range 0 to 6 (corresponding to note names C D E F G A B) and "alteration" is a continuous-valued variable whose unit is the whole tone. With these three values Lilypond is able to represent any pitch in a continuous frequency spectrum. >From a notational perspective, the first two numbers are used to calculate the vertical staff position of the notehead, while the value of the alteration is used to determine the accidental: e.g. (1,1,-1/2) corresponds to the D-flat a semitone above middle C. *A key assumption of this approach is that there is a one-to-one correspondence between accidental and alteration value.* This clearly holds for conventional Western 12-tone notation. However, it does _not_ hold for many _microtonal_ notations. For example, if we are using the very common 'arrow' notation for quarter-tones, there are two distinct accidentals that can be used to represent the alteration +1/4 (i.e. quarter-tone-sharp): the first is a natural sign with an up arrow, the second is a sharp sign with a down arrow. There is currently no effective, well-defined way to indicate which of the two is desired at any given moment. The arrow quarter-tone notation is just one of a whole variety of microtonal notations which operate not on the basis of single symbols per alteration, but on the basis of asuperposition of a successive hierarchy of symbols, each corresponding to smaller and smaller shadings up or down of the pitch. For example: sharp/flat + up/down arrow + plus/minus +/- 1/2 +/- 1/4 +/- 1/8 Lilypond's consideration of pitch alteration as a single number makes it very difficult to adequately represent such hierarchical pitch-alterations, and hence their corresponding notations. Hence why I say that the issue of effective microtonal support still requires action at the code level, and is not simply a matter of better documentation ... :-( Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Music properties and naturalization/transposition style
Hello all,
A few queries related to my ongoing project to implement customizable
transposition/naturalization styles.
It was suggested to me to use music properties to set the rules. I've
come to the conclusion that this may not be the right approach. Why?
Because as far as I can see music properties work via an "outmost wins"
hierarchy: if I have,
\withMusicProperty #'some-property = #1 {
\withMusicProperty #'some-property = #2 {
\withMusicProperty #'some-property = #3 {
\myMusic
}
}
}
... then #'some-property will have a value of 1 for \myMusic. By
contrast I think that a naturalization style needs to work like the
\relative command -- it should be the _innermost_ one that matters.
Specifically, the naturalization style should have the following
characteristics:
(i) possible to set a default value at Score, StaffGroup, Staff
and Voice level, with innermost overriding outermost [sample
use-case: in general a score will have a default style, but
individual instruments (e.g. harp) may have special rules]
(ii) possible to alter within the music, with innermost overriding
outermost [sample use case: whatever the character of the piece,
individual passages may need to be designated tonal, chromatic,
or whatever else suits]
(iii) ideally, possible to override in a manner that _ignores_ any
inner modifications [sample use case: an instrument like the
harp, where you need to be able to guarantee that the music
will be notated according to certain rules]
(iv) an option to employ naturalization _only_ for music that has
been passed through the "transpose" function, or alternatively
to apply to _all_ music where a rule is set -- so it can be
alternatively a transposition style _or_ a means of enforcing a
general notation style. Again, this property can be set at
Score, StaffGroup, Staff or Voice level.
Sample pseudo-Lilypond of use, excluding the 3rd case which I'm not sure
how best to notate.
\new Score \with {
% this setting turns naturalization "off",
% i.e. uses Lilypond's defaults.
naturalizationStyle = ##f
% this setting determines whether naturalization
% is applied to all music (#f) or just transposed
% music (#t). By default it is #t.
naturalizeTransposedOnly = ##f
} {
<<
\new Staff = "Clarinet" \with {
naturalizationStyle = #'chromatic
} {
\transpose a c' {
\someMusic
\naturalize #'tonal {
\someTonalMusic
}
}
}
\new PianoStaff = "Harp" \with {
naturalization = #'harp
} {
\harpMusic
}
\new Staff = "Voices" {
<<
\new Voice = "Soprano" \with {
naturalization = #'chromatic
} {
\chromaticVocalPart
}
\new Voice = "Alto" {
\defaultVocalPart
}
>>
}
>>
}
What I'd like: first, thoughts on the appropriateness and feasibility of
the above notation and "conceptual" model of the naturalize functionality.
Second, advice on implementing it, since I don't think music properties
are the way to go. In particular, where should naturalization be called
if it's aimed to apply to _all_ notes? (It's clear where it should be
called if it's to apply only to transposed music.)
Thanks in advance,
-- Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Setting the value of a music property
On 07/25/2010 10:14 PM, Neil Puttock wrote:
> The music property must be set after calling the naturalizeMusic
> function, otherwise it's too late:
Brilliant, that works, thank you! :-)
One small point of clarification -- do I have to put brackets {} around
the music that a \withMusicProperty statement applies to, or does it
apply the property to everything that follows?
It makes no difference in my sample .ly file where there are already
brackets around everything, but it makes a difference when I write all
this up ... :-)
I'll probably be a bit silent on this in the next few days because work
is busy, but next steps are to try and integrate this functionality into
the C++ in lily/music.cc. Something along the lines of (in pseudo-C++):
if('naturalize-style) // i.e. if it's not the empty list #f
{
run_pitches_through_scheme_function(naturalize-pitch);
}
... anyway, will let you all know how it goes, when (if) it goes... :-)
Thanks again & best wishes,
-- Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Setting the value of a music property
On 07/25/2010 09:49 PM, Joseph Wakeling wrote:
> I don't know how that typo got into my email, but it is _not_ what I
> have in my Lilypond input file.
For reference, I've attached a complete .ly file.
naturalizeMusic =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (ly:music-property m 'naturalize-style)))
microphrase = \relative c'' { geses4 geseh ges geh g gih gis gisih gisis }
\score {
\new Staff {
\set Staff.extraNatural = ##f
\time 9/4
\withMusicProperty #'naturalize-style #(list (cons >= 1) (cons <= -1) (cons
>= SHARP) (cons <= FLAT))
\naturalizeMusic { \microphrase }
}
\layout { }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Setting the value of a music property
On 07/25/2010 08:49 PM, Neil Puttock wrote: > This function has an arg called `m', but you're trying to access a > property from `music'. This doesn't cause an `unbound variable' error > since you have the following identifier (whose music has no > 'naturalize-style setting): I don't know how that typo got into my email, but it is _not_ what I have in my Lilypond input file. This is: naturalizeMusic = #(define-music-function (parser location m) (ly:music?) (naturalize m (ly:music-property m 'naturalize-style))) ... which still generates the error mentioned. :-( ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Setting the value of a music property
Dear everyone,
A possibly dumb question -- I'm having some difficulty working out how
to set the value of a given music property.
Here's a little piece of Lilypond Scheme adapted from the
naturalizeMusic.ly snippet:
naturalizeMusic =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (ly:music-property music 'naturalize-style)))
Now, naturalize-style I've defined in scm/define-music-properties.scm:
--
diff --git a/scm/define-music-properties.scm
b/scm/define-music-properties.scm
index 2af8f92..6709154 100644
--- a/scm/define-music-properties.scm
+++ b/scm/define-music-properties.scm
@@ -106,6 +106,7 @@ whether to allow, forbid or force a line break.")
(metronome-count ,number? "How many beats in a minute?")
(name ,symbol? "Name of this music object.")
+ (naturalize-style ,list? "The rules for what pitch-alterations are
permissible.")
(no-continuation ,boolean? "If set, disallow continuation lines.")
(numerator ,integer? "Numerator of a time signature.")
--
... but when I try some Lilypond code along the following lines,
> music = \relative c' { c4 d e g }
>
> \score {
> \new Staff {
> \set Staff.extraNatural = ##f
> \withMusicProperty #'naturalize-style #(list (cons >= 1) (cons <= -1)
> (cons >= SHARP) (cons <= FLAT))
> \naturalizeMusic \transpose c ais { \music }
> }
> \layout { }
> }
... I get an error:
> Parsing...code/lily/out/share/lilypond/current/scm/naturalize.scm:10:33: In
> procedure list-ref in expression (list-ref pitch-limits 0):
> code/lily/out/share/lilypond/current/scm/naturalize.scm:10:33: Argument 2 out
> of range: 0
... which suggests that 'naturalize-style is being taken as empty by the
ly:music-property function. Giving it a default value equal to an
actual list,
> naturalizeMusic =
> #(define-music-function (parser location m)
>(ly:music?)
>(naturalize m (ly:music-property music 'naturalize-style (list (cons >= 1)
> (cons <= -1) (cons >= SHARP) (cons <= FLAT)
... means it parses without error, so it looks like the
ly:music-property function is currently just using the default value
given, and does not appreciate the 'naturalize-style property as already
having a set value.
So, the question comes down to, what am I doing wrong in trying to set
the 'naturalize-style property of the music? Putting brackets {} round
the music to which the \withMusicProperty statement should apply doesn't
help.
I tried more directly using the ly:music-set-property! function, but
could not work it out. :-(
Can anyone advise?
Thanks & best wishes,
-- Joe
P.S. naturalize.scm is not really relevant to this question (I think),
but just in case, I've attached it.
(define (naturalize-limit lim)
(define (limit a)
((car lim) a (cdr lim)))
limit)
(define-public (naturalize-pitch p pitch-limits)
(let ((o (ly:pitch-octave p))
(n (ly:pitch-notename p))
(a (ly:pitch-alteration p))
(high (naturalize-limit (list-ref pitch-limits 0)))
(low (naturalize-limit (list-ref pitch-limits 1)))
(higheb (naturalize-limit (list-ref pitch-limits 2)))
(lowcf (naturalize-limit (list-ref pitch-limits 3
(do ((aa 0))
((= aa a) (ly:make-pitch o n a))
(set! aa a)
(cond
((and (higheb a) (or (eq? n 2) (eq? n 6)))
(set! a (- a (/ 1 2)))
(set! n (+ n 1)))
((and (lowcf a) (or (eq? n 0) (eq? n 3)))
(set! a (+ a (/ 1 2)))
(set! n (- n 1
(cond
((high a) (set! a (- a 1)) (set! n (+ n 1)))
((low a) (set! a (+ a 1)) (set! n (- n 1
(if (< n 0) (begin (set! o (- o 1)) (set! n (+ n 7
(if (> n 6) (begin (set! o (+ o 1)) (set! n (- n 7)))
(define-public (naturalize music pitch-limits)
(let ((es (ly:music-property music 'elements))
(e (ly:music-property music 'element))
(p (ly:music-property music 'pitch)))
(if (pair? es)
(ly:music-set-property!
music 'elements
(map (lambda (x) (naturalize x pitch-limits)) es)))
(if (ly:music? e)
(ly:music-set-property!
music 'element
(naturalize e pitch-limits)))
(if (ly:pitch? p)
(begin
(set! p (naturalize-pitch p pitch-limits))
(ly:music-set-property! music 'pitch p)))
music))
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Chromatic transposition -- a very small starting step
On 07/10/2010 12:25 PM, Joseph Wakeling wrote:
> On second thoughts, it seems like transposition constraints for the
> whole of LP could be set by four naturalize-limits: upper and lower
> limits respectively for c, e, f, b; and upper and lower limits for
> everything else.
OK, done. The attached example now contains a "complete"
naturalize-pitch which allows the user to define the too-high and
too-low rules for e, b and c, f respectively, as well as for the rest of
the notes.
This allows the definition of a "naturalizeMusicTonal" expression which
seems to leave properly-transposed stuff (by Lilypond's defaults) untouched.
The aim would be to allow the user to define custom naturalization rules
alongside defaults, e.g:
\withMusicProperty #'naturalize = ##f
% don't employ naturalization, use Lilypond's default
% functionality
\withMusicProperty #'naturalize = #'chromatic
% typical naturalize-music function
\withMusicProperty #'naturalize = #'harp
% naturalize with nothing > 1/2-tone
\withMusicProperty #'naturalize = #'tonal
% superfluous since Lilypond 2.13.14+ already handles this,
% but if the user wants to be sure ... :-)
\withMusicProperty #'naturalize =
#((naturalize-limit >= 1) (naturalize-limit < (/ -1 2))
(naturalize-limit >= (/ 1 2)) (naturalize-limit < (/ -1 2)))
% custom choice of user (my notation may be wrong here, but it
% gives the idea of what the user could do). I see why Lisp is
% sometimes referred to as "Lost in sodding parentheses" ... !
Note that the naturalization process could be employed in
transposition_mutable() or it could be employed after transposition (if
any) has been carried out, so the naturalization rules could be used to
enforce style choices anywhere in the composition.
e.g.
\naturalizeChromatic
...
bes8 \naturalizeOff ces % I really, really want this c-flat.
\naturalizeOn % default option, same as \naturalizeChromatic
There could even be two different music properties (#'naturalize or
#'transposition-style?) depending on at what stage one wishes to apply
naturalization; or with warnings if untransposed music is nevertheless
altered by the naturalization process.
Are there any other thoughts for what more needs to be done with the
naturalize-pitch function itself? Or is it good to go in terms of
hooking into Lilypond ... ?
Thanks & best wishes,
-- Joe
#(define (naturalize-limit lim val)
(define (limit a)
(lim a val))
limit)
#(define (naturalize-pitch p high low higheb lowcf)
(let ((o (ly:pitch-octave p))
(n (ly:pitch-notename p))
(a (ly:pitch-alteration p)))
(do ((aa 0))
((= aa a) (ly:make-pitch o n a))
(set! aa a)
(cond
((and (higheb a) (or (eq? n 2) (eq? n 6)))
(set! a (- a (/ 1 2)))
(set! n (+ n 1)))
((and (lowcf a) (or (eq? n 0) (eq? n 3)))
(set! a (+ a (/ 1 2)))
(set! n (- n 1
(cond
((high a) (set! a (- a 1)) (set! n (+ n 1)))
((low a) (set! a (+ a 1)) (set! n (- n 1
(if (< n 0) (begin (set! o (- o 1)) (set! n (+ n 7
(if (> n 6) (begin (set! o (+ o 1)) (set! n (- n 7)))
#(define (naturalize music high low higheb lowcf)
(let ((es (ly:music-property music 'elements))
(e (ly:music-property music 'element))
(p (ly:music-property music 'pitch)))
(if (pair? es)
(ly:music-set-property!
music 'elements
(map (lambda (x) (naturalize x high low higheb lowcf)) es)))
(if (ly:music? e)
(ly:music-set-property!
music 'element
(naturalize e high low higheb lowcf)))
(if (ly:pitch? p)
(begin
(set! p (naturalize-pitch p high low higheb lowcf))
(ly:music-set-property! music 'pitch p)))
music))
naturalizeMusic =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (naturalize-limit >= 1)
(naturalize-limit <= -1)
(naturalize-limit >= (/ 1 2))
(naturalize-limit <= (/ -1 2
naturalizeMusicHarp =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (naturalize-limit > (/ 1 2))
(naturalize-limit < (/ -1 2))
(naturalize-limit >= (/ 1 2))
(naturalize-limit <= (/ -1 2
naturalizeMusicTonal =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (naturalize-limit > 1)
(naturalize-limit < -1)
(naturalize-limit > (/ 1 2))
(naturalize-limit < (/ -1 2
music = \relative c' { c4 d e g }
microphrase = \relative c'&#
Re: Chromatic transposition -- a very small starting step
On 07/10/2010 12:16 PM, Joseph Wakeling wrote: > In principle I can also use these to define custom cases for the notes > c, e, f, b as well; not sure if I should, since the whole point of the > naturalizeMusic function is to kill things like c-flats and e-sharps, > and tonal transposition is already taken care of by Lilypond's default > options. On second thoughts, it seems like transposition constraints for the whole of LP could be set by four naturalize-limits: upper and lower limits respectively for c, e, f, b; and upper and lower limits for everything else. so (naturalize-limit > 1) (naturalize-limit < -1) (naturalize-limit > (/ 1 2)) (naturalize-limit < (/ -1 2)) should cover regular tonal transposition; make it >= and <= to get my naturalizeMusic function. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Chromatic transposition -- a very small starting step
On 07/09/2010 10:34 PM, Neil Puttock wrote:
> Sounds good to me.
So, here we go ... (faster to achieve than I expected, thanks to a
conversation with a friend who is Scheme-experienced).
I've defined a Scheme function "naturalize-limit" which can be used to
define limits for different cases, and given two examples -- one where
the maximum alteration must be less than a whole tone, and one where the
maximum alteration must be less than or equal to 1/2-tone (the old
naturalizeMusic).
In principle I can also use these to define custom cases for the notes
c, e, f, b as well; not sure if I should, since the whole point of the
naturalizeMusic function is to kill things like c-flats and e-sharps,
and tonal transposition is already taken care of by Lilypond's default
options.
(Other possible improvements -- getting rid of the (set! ...) functions?
My Schemer friend laughed at these...:-)
Next step, hooking this into the transpose_mutable() function... :-)
#(define (naturalize-limit lim val)
(define (limit a)
(lim a val))
limit)
#(define (naturalize-pitch p high low)
(let ((o (ly:pitch-octave p))
(n (ly:pitch-notename p))
(a (ly:pitch-alteration p)))
(do ((aa 0))
((= aa a) (ly:make-pitch o n a))
(set! aa a)
(cond
((and (>= a (/ 1 2)) (or (eq? n 2) (eq? n 6)))
(set! a (- a (/ 1 2)))
(set! n (+ n 1)))
((and (<= a (/ -1 2)) (or (eq? n 0) (eq? n 3)))
(set! a (+ a (/ 1 2)))
(set! n (- n 1
(cond
((high a) (set! a (- a 1)) (set! n (+ n 1)))
((low a) (set! a (+ a 1)) (set! n (- n 1
(if (< n 0) (begin (set! o (- o 1)) (set! n (+ n 7
(if (> n 6) (begin (set! o (+ o 1)) (set! n (- n 7)))
#(define (naturalize music high low)
(let ((es (ly:music-property music 'elements))
(e (ly:music-property music 'element))
(p (ly:music-property music 'pitch)))
(if (pair? es)
(ly:music-set-property!
music 'elements
(map (lambda (x) (naturalize x high low)) es)))
(if (ly:music? e)
(ly:music-set-property!
music 'element
(naturalize e high low)))
(if (ly:pitch? p)
(begin
(set! p (naturalize-pitch p high low))
(ly:music-set-property! music 'pitch p)))
music))
naturalizeMusic =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (naturalize-limit >= 1) (naturalize-limit <= -1)))
naturalizeMusicHarp =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m (naturalize-limit > (/ 1 2)) (naturalize-limit < (/ -1 2
music = \relative c' { c4 d e g }
microphrase = \relative c'' { geses4 geseh ges geh g gih gis gisih gisis }
\score {
\new Staff {
\set Staff.extraNatural = ##f
\transpose c ais { \music }
\naturalizeMusic \transpose c ais { \music }
\transpose c deses { \music }
\naturalizeMusic \transpose c deses { \music }
\bar "||"
\naturalizeMusicHarp \transpose c ais { \music }
\naturalizeMusicHarp \transpose c deses { \music }
\bar "||"
\break
\time 9/4
\microphrase
\bar ":"
\naturalizeMusic { \microphrase }
\bar ":"
\naturalizeMusicHarp { \microphrase }
\break
\transpose c ais { \microphrase }
\bar ":"
\naturalizeMusic \transpose c ais { \microphrase }
\bar ":"
\naturalizeMusicHarp \transpose c ais { \microphrase }
\break
\transpose c deses { \microphrase }
\bar ":"
\naturalizeMusic \transpose c deses { \microphrase }
\bar ":"
\naturalizeMusicHarp \transpose c deses { \microphrase }
\break
\transpose c cih { \microphrase }
\bar ":"
\naturalizeMusic \transpose c cih { \microphrase }
\bar ":"
\naturalizeMusicHarp \transpose c cih { \microphrase }
}
\layout { }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Chromatic transposition -- a very small starting step
Neil -- thanks ever so much for the detailed explanations.
> Take a look at lily/music.cc to see where the transposition takes place.
The transpose_mutable() function seems to be where it's at ... :-)
I note the following lines which are surely responsible for cleaning up
anything larger than a double flat:
if (transposed.get_alteration ().abs () > Rational (1,1))
{
string delta_str;
if (delta.get_alteration ().abs () > Rational (1, 1))
delta_str = (delta.normalized ().to_string ()
+ " " + _ ("(normalized pitch)"));
else
delta_str = delta.to_string ();
warning (_f ("Transposing %s by %s makes alteration
larger than double",
p->to_string (), delta_str));
transposed = transposed.normalized ();
}
So, thinking about the way to implement the various chromatic
transpositions, what seems natural is that once new_val has been
generated in the transpose_mutable() function, to run through one of the
naturalize-pitch Scheme functions (or perhaps a C++ version of it).
Anyway, first port of call, I'm going to try and implement those toohigh
and toolow options for the naturalize-pitch Scheme function...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Chromatic transposition -- a very small starting step
On 07/09/2010 12:09 AM, Neil Puttock wrote: > That sounds like a useful enhancement, except that it would be a music > property rather than a context property, since transposition happens > before translation. Can you explain more precisely ... ? This seems like something I should understand very well in order to provide an effective solution. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Chromatic transposition -- a very small starting step
On 07/08/2010 10:25 PM, Neil Puttock wrote:
> On 8 July 2010 19:47, Joseph Wakeling wrote:
>
>>(Example: take the music of bb. 9-10 in the sample music, and
>>put it through the _original_ naturalizeMusic function. You get
>>left with a g-double-flat instead of an f-natural.)
>
> You're using 2.12, I assume?
Yup.
> Since 2.13.14, transpositions greater than a double are normalized
> automatically, so the original \naturalizeMusic also produces an f
> natural here (see attached output using latest git).
Hah! I've not kept up, I missed that being introduced ... :-P
('original' and 'revised' refer to the original and my version of
naturalizeMusic?)
So ... other than that it might be nice to have the snippet for 2.12, is
there any contribution that I can meaningfully make to 2.13 with this?
The ensuring-convergence-of-naturalization seems superfluous now, but
the variable determination of maximum alteration might be worthwhile.
The reason I was working on this was with the longer-term aim of being
able to have an option to set transposition style in music:
\set Staff.transpositionStyle = #'chromatic
% what follows will be transposed in chromatic fashion
\set Staff.transpositionStyle = #'tonal
% tonal transposition
\set Staff.transpositionStyle = #'chromatic-harp
% chromatic transposition tailored for harp, so
% no alterations of > 1/2-tone
In any case, I should clearly update to 2.13.x before making further
revisions ...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Chromatic transposition -- a very small starting step
Hello all,
As per earlier discussion on the -user list:
http://www.mail-archive.com/lilypond-u...@gnu.org/msg51183.html
... I finally managed to put some time and mental energy towards
chromatic transposition, in particular, the naturalizeMusic function
from the LSR.
I've attached a draft version that makes two changes to the original:
(1) it takes out the original's focus on quarter-tones as the
units of alteration, and changes the conditions for rewriting
so that it will let pass any alteration less than a whole tone
(so e.g. 3/4-flats and sharps will not be rewritten; but see
below for caveat ...)
(2) it introduces a (do ...) loop to make sure that the process of
naturalization converges. This way you don't get accidental
(pun intended:-) double-flats hanging around due to weird
transpositions.
(Example: take the music of bb. 9-10 in the sample music, and
put it through the _original_ naturalizeMusic function. You get
left with a g-double-flat instead of an f-natural.)
What I still would like to do is make optional the question of the
largest alteration permitted. See lines 15--17 of the code:
(cond
((>= a 1) (set! a (- a 1)) (set! n (+ n 1)))
((<= a -1) (set! a (+ a 1)) (set! n (- n 1
In the original naturalizeMusic function, these conditional statements
were the equivalent of (> a (/ 1 2)) and (< a (/ -1 2)), which rewrote
any alteration larger than a semitone.
As Hans Aberg pointed out, this can be important for e.g. harp music
where there is a strict limit of +/- 1/2-tone on note alterations.
The best way to achieve this seems to be to make those conditions
variables in the function definition, something like,
(define (naturalize-pitch p toohigh toolow)
...
(cond
((toohigh a) (set! a (- a 1)) (set! n (+ n 1)))
((toolow a) (set! a (+ a 1)) (set! n (- n 1
... with toohigh or toolow being defined to give both a predicate (>,
>=, <, <=) and a value (1, -1, (/ 1 2), (/ -1 2) ...)
I'm shaky on how to define toohigh or twolow, though (not so much a
schemer as a meddler): can someone advise?
Thanks & best wishes,
-- Joe
#(define (naturalize-pitch p)
(let ((o (ly:pitch-octave p))
(n (ly:pitch-notename p))
(a (ly:pitch-alteration p)))
(do ((aa 0))
((= aa a) (ly:make-pitch o n a))
(set! aa a)
(cond
((and (>= a (/ 1 2)) (or (eq? n 2) (eq? n 6)))
(set! a (- a (/ 1 2)))
(set! n (+ n 1)))
((and (<= a (/ -1 2)) (or (eq? n 0) (eq? n 3)))
(set! a (+ a (/ 1 2)))
(set! n (- n 1
(cond
((>= a 1) (set! a (- a 1)) (set! n (+ n 1)))
((<= a -1) (set! a (+ a 1)) (set! n (- n 1
(if (< n 0) (begin (set! o (- o 1)) (set! n (+ n 7
(if (> n 6) (begin (set! o (+ o 1)) (set! n (- n 7)))
#(define (naturalize music)
(let ((es (ly:music-property music 'elements))
(e (ly:music-property music 'element))
(p (ly:music-property music 'pitch)))
(if (pair? es)
(ly:music-set-property!
music 'elements
(map (lambda (x) (naturalize x)) es)))
(if (ly:music? e)
(ly:music-set-property!
music 'element
(naturalize e)))
(if (ly:pitch? p)
(begin
(set! p (naturalize-pitch p))
(ly:music-set-property! music 'pitch p)))
music))
naturalizeMusic =
#(define-music-function (parser location m)
(ly:music?)
(naturalize m))
music = \relative c' { c4 d e g }
microphrase = \relative c'' { geses4 geseh ges geh g gih gis gisih gisis }
\score {
\new Staff {
\set Staff.extraNatural = ##f
\transpose c ais { \music }
\naturalizeMusic \transpose c ais { \music }
\transpose c deses { \music }
\naturalizeMusic \transpose c deses { \music }
\bar "||"
\break
\time 9/4
\microphrase
\bar ":"
\naturalizeMusic { \microphrase }
\break
\transpose c ais { \microphrase }
\bar ":"
\naturalizeMusic \transpose c ais { \microphrase }
\break
\transpose c deses { \microphrase }
\bar ":"
\naturalizeMusic \transpose c deses { \microphrase }
\break
\transpose c cih { \microphrase }
\bar ":"
\naturalizeMusic \transpose c cih { \microphrase }
}
\layout { }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quickstart guide
On 06/23/2010 05:37 PM, Graham Percival wrote: > What did you mean by "customized per platform, that would be part > of the install" ? > > I think I understand what you mean now, however... Well, to be clear: I mean that when you install Lilypond on Windows, it should create a menu item (and optionally, a desktop icon) that would load the aforesaid (HTML) quickstart guide when you click on it. Similar for Mac OS. It was a response to David K.'s remark about the experience of having people install Lilypond and then come back with remarks like, 'Where is it, then??': http://lists.gnu.org/archive/html/lilypond-devel/2010-06/msg00377.html > ... "Packaging it up" is extremely difficult. I'm not familiar with Windows or Mac development or installers -- is it genuinely difficult to have the installation program create a menu item or desktop icon which simply points to a locally-stored HTML file? :-( Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quickstart guide
On 06/23/2010 05:16 PM, Graham Percival wrote: > Given that AFAIK, none of the active developers know where to find > the source repository for the windows lilypond editor, let alone > being at all familiar with that code, this is an extremely > ambitious project. Hang on. Where did I say people should be working on a Windows development editor? > So something like we already have on the download page? Yes, exactly. So it's not so difficult to package it up so that the same guidance is available courtesy of an item on the Windows menu, no? 'Lilypond > Lilypond Quickstart Guide' > Look, for better or worse, we have absolutely no resources to > spend on editor stuff (have you looked at the bug tracker > lately?!). Feel free to suggest something to the lilypondtool or > frescobaldi people. I never said anything about editor stuff. :-\ Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quickstart guide
On 06/22/2010 09:38 PM, Graham Percival wrote: > On Tue, Jun 22, 2010 at 09:16:34PM +0200, Joseph Wakeling wrote: >> I was sure there was some kind of one-page quickstart guide in the >> documentation, but looking on the development version doc pages at >> http://kainhofer.com/~lilypond/ I can't find one -- at least, it's not >> immediately apparent that one exists. > > WTM are you talking about? something like this: > http://lilypond.org/website/macos-x.html > or this: > http://lilypond.org/doc/v2.13/Documentation/learning/tutorial > ? Please let me emphasize that I'm not talking about cutting material from the existing docs or website, nor am I saying that the information in question is not provided by the existing website. I'm talking about creating a 1-page quickstart readme guide, probably customized per platform, that would be _part of the install_ on platforms where people are used to GUIs. Example: Windows. Add a Lilypond menu item. Clicking on it loads the HTML quickstart guide and a command-line window. It's not what the user is used to, but it does provide an immediate offset to the 'HTM do I use this program?' reaction that some Windows users have. > What would you omit from the current Learning 1 in the 2.13 docs? I wouldn't omit anything from the current Learning 1. I'd just create a new page which gives the absolute, absolute minimum of information (edit file in text editor, open command line window, compile like this...), and CLICK HERE FOR MORE DETAILED INFORMATION. Something that jumps up in the face of the new user on Windows/Mac OS and gives them a pre-emptive answer to the 'How does this program work?' question that keeps arriving on the mailing list. > I'm really curious about what you think is irrelevant... I don't say it's irrelevant. I _do_ say that there is value in a simple 1-page quickstart guide. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Quickstart guide
On 06/21/2010 12:18 AM, I wrote: > On 06/20/2010 06:10 PM, David Kastrup wrote: > > You can't stop at selling Lilypond to somebody without having an > > answer to "how do I start this thing"? How many people are complaining > > that they double-click on the Lilypond icon and nothing happens? > > Hmmm ... so why not start by having the icon open a 'Quickstart' help > page that explains how to use Lilypond on the platform in question? > Trivial to implement, no? I was sure there was some kind of one-page quickstart guide in the documentation, but looking on the development version doc pages at http://kainhofer.com/~lilypond/ I can't find one -- at least, it's not immediately apparent that one exists. (I didn't look hard; it's kind of defeating the point of a Quickstart guide if you have to...) Most of the material you'd want for such a guide is covered in Chapter 1 of the Learning Manual, so it should be reasonably OK to condense into a 1-page piece of HTML that could (i) be included in a prominent place on the webpage and (ii) could load as a result of clicking on a 'Lilypond icon' installed with Windows or Mac OS. Shall I give it a go? Any thoughts/comments? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bounties
On 06/21/2010 06:37 PM, Kieren MacMillan wrote: > However, for me personally -- i.e., how I will spend my assistance and > sponsorship time, money, and effort -- trying to make Lilypond a better > *composing* tool is a total non-issue, whereas fixing the innumerable > *engraving* problems remaining to be solved is everything. I think that's a pretty good priority for Lilypond in general, actually. I mean, there are things that can be done, like enhanced MIDI performance (dynamics, articulation, ...) that could help make Lilypond a better tool for sketching out compositional ideas and producing demos of pieces, but engraving is the key strength Lilypond has and it should play to it. I would step back from that slightly and say that say that what makes Lilypond great is _engraving without cheating_ -- i.e. its source notation is in general a precise representation of the musical content (meaning as well as appearance). Its use of a well-defined human-readable semantic markup is also a big plus, particularly when it comes to archiving. >> You'll be fine raising grant money as long as you make case studies of >> typesetting and theses. > > That's probably an accurate assessment, at least in the immediate term. I > think the point about "non-serviced communities" (e.g., unsighted, less > affluent, etc.) is a good one, too. Platform options (i.e., emerging devices, > where FinSib likely won't go) will become important very soon. And so on. True, but you have to be careful that the grant gets used to develop a viable, supported long term solution to whatever you're trying to achieve, not just something that permits the people involved to write enough research articles to make themselves look good to the funding agency. I'm not sure about emerging devices, or rather, it seems there are a bunch of optimizations and improvements that would be needed to see Lilypond becoming a serious contender on mobile or low-power devices etc. I'm speaking purely from the experience of trying to compile Valentin's opera on my laptop. :-) > Personally, I'm not trying to "sell Lilypond to universities", at least not > in the way that particular phrase suggests (i.e., convince them to replace > their current FinSib setup with Lilypond). I'm trying to make a case to a > well-funded university (Rice) with a proven track record in the development > and promotion of digital, open, on-demand publishing (Connexions) and a > fabulous music school (Shepherd School) that there might be a great way to > extend their publishing platform into the [essentially untapped] sphere of > print music, and simultaneously support the development of an open-source > application/community. Agree about 'selling to universities' in that sense -- it's exactly what is likely to get the « Dans le cul de ta mère! » kind of response that Valentin received. :-P Your connection with Rice sounds very interesting. I don't know what your exact proposal is, but one thing I would be interested in is the development of 'free/open scholarly urtext editions' -- think Project Gutenberg but for music, not just the kind of 'engrave the old Breitköpf edition' stuff that you see from random enthusiasts on IMSLP, but carefully-prepared expert-scholarship urtext editions with well defined editorial guidelines, etc. etc. Take the Neue Mozart Ausgabe as an example -- it's available to browse free online, but it's _ridiculous_ that this scholarly archive of Mozart's texts is still under proprietary lock and key in this day and age. The scholarly and music-professional consequences of having a high-quality open archive that anyone can access and derive from are fairly profound. So, if you can persuade Rice to take up that kind of challenge -- kind of 'O'Reilly for music publishing' -- you'll have done something rather marvellous, IMO. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bounties
On 06/21/2010 01:46 PM, David Kastrup wrote: > You wish. It is a problem when Lilypond is the best tool for the job > and/or the cheapest. 'Cheapest' is IMO nowhere near as relevant as many people think, especially when it relates to organizations like publishers or universities that have large budgets anyway. As for 'best tool for the job', what job are you referring to? Are you sure it is the job that everyone else is trying to do? > Well, by now everybody and his dog writes diatribes how Stallman and the > Free Software Foundation and free software are on the road to total > failure and need to make themselves indistinguishable from those systems > for which they provide alternatives. Not me. I'm with Stallman in the struggle for software freedom, and find myself amazed by how often people misrepresent and misunderstand what he and the FSF are on about. Note that I did list ideological/philosophical reasons as one of the principal ways to get the self-motivation to learn to use Lilypond. (It worked for me.) > It takes a Stallman to keep course even when in the middle of a > popularity shouting contest. Yea, but right now we're not talking about a popularity contest. It would be very nice if universities and publishers all enthusiastically took up the use of Lilypond, but what we're talking about now is something much simpler -- raising money to dedicate to Lilypond development and project sustainability. > For each given platform. Separately. Sounds like employment for a > number of platform-localized frogs. Well, you have 3 platforms you need to address -- Windows, Mac and 'other UNIX' (GNU+LINUX/BSD/OpenSolaris/.), the commonalities and tech-savvy of the latter group being enough that you can group them together. Plus most of a 'quick start' would be platform-independent. All you need is an instruction along the lines of, 'Edit text file [suggest platform-specific editors], open up command line [with platform-specific instructions], run Lilypond from the command line. Then 'click here for more info', taking you to the online or locally installed documentation. > One way of evading the question is to make a compellingly good user > interface on Emacs (which then runs everywhere), but that's not exactly > a small task to do. And there are people who would balk at > "compellingly good" in the same sentence with "Emacs". Despite the power of Emacs it doesn't make sense to me to use it as the dedicated platform. Most users of Lilypond, especially beginners, don't need the possibilities it offers, and it's difficult to 'get' Emacs if you do not have a need for more than simple text editing. If I were aiming for an effective cross-platform editing environment for Lilypond, I would go for Frescobaldi as the leading candidate -- it has a nice, friendly interface, good functionality, and Qt/KDE based tools make for good long term candidates for cross-platform applications. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bounties
On 06/20/2010 06:10 PM, David Kastrup wrote:
> People want a _solution_ to their problem, not new problems they never
> thought about and which are not actually in their personal problem
> space.
That's true, but it only shows that Lilypond isn't yet capable of
operating as a general-purpose best solution. That's only a problem if
that's what Lilypond wants to _be_, or more precisely, what Lilypond
tries to sell itself as. ('Wants to be' is fine as long as you have a
plan to get there and don't sell yourself as such prematurely...)
It's a bit like GNU/Linux a few years ago, and to an extent even now --
it wasn't possible to market it as a general-purpose operating system
suitable for all, because learning to use it involved an expenditure of
effort that only made sense if you had a deliberate motivation. That
might be ideological/philosophical, it might be the opportunity for
hacking and customization, it might be that it provides better for your
particular technical needs, but whatever it was, you _needed_ that
self-motivation.
Lilypond's situation is almost exactly parallel, and like GNU/Linux, it
doesn't mean that you can't sell it -- it means you have to target your
sales pitch at the people in whom you can create that self-motivation.
Or rather, you have to target cases where the problem of learning to use
Lilypond is small compared to the benefit of having it.
The first such pitch can obviously be at those of us who already _have_
the motivation and are involved -- as Valentin is doing -- to create a
Lilypond 'subscription' model. I'd go further than that and create
classes of sponsorship, the most prominent of which come with very overt
display (logos on the webpage and in documentation, etc.). 'Lilypond,
sponsored by ...' etc. etc. Even if no one (for now) takes up the
higher classes of sponsorship, I think there are lots of us who would
happily offer regular monthly donations to Lilypond if there was a
well-defined funding (and spending) structure.
(I would suggest splitting any such initial funds between development
work and outreach -- spend some of the money on getting new features
implemented and some of it on pursuing a wider range of funding sources.
Someone mentioned the hassle of writing grants and tracking
deliverables and project bureaucracy, but once you've _got_ a grant you
can and should dedicate part of that money towards such admin work.)
Above and beyond that, look at special or specialist needs that Lilypond
can fulfil and even more, at special or specialist needs where _further
development_ can fulfil them -- that gives an obvious reason to people
to fund Lilypond development.
> You can't stop at selling Lilypond to somebody without having an
> answer to "how do I start this thing"? How many people are complaining
> that they double-click on the Lilypond icon and nothing happens?
Hmmm ... so why not start by having the icon open a 'Quickstart' help
page that explains how to use Lilypond on the platform in question?
Trivial to implement, no?
One other thing: yesterday a developer colleague of mine showed me the
following page,
http://tryhaskell.org/
... which he'd been inspired to implement by the equivalent 'Try Ruby'
page. (There are now apparently a bunch of 'Try X' sites out there.)
Lilypond isn't exactly equivalent, since AFAICS it can't meaningfully be
run in any kind of 'scripting mode', but there is surely scope for some
kind of online interactive Lilypond environment (most likely a primitive
online editor + output display + tutorial).
I'll try and keep this in mind as a potential pet project (I don't have
the skill, but together he and I probably do). There is no way we can
put time towards it in the immediate future, since we have strong
immediate priorities for the projects of our employer, but maybe a few
months down the line something can be done ...
Best wishes,
-- Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bounties
On 06/19/2010 07:50 PM, Valentin Villenave wrote: > Ditto here. I have contacted dozens of French universities, music > schools, government-funded music structures and whatnot. Everytime I > got an answer, the answer was: "Fuck off, we already have Finale". > > Or something like that. What were the nature of the proposals or enquiries you made? I'm asking because of my own experience, now, working for an organization where the leadership is quite traditional-business-oriented, and trying to steer their thinking in more open ways. What's clear is that their attitude is very much along the lines of, 'There are lots of different models/tools you could adopt, but these ones have clear and proven track record of success. So you have to prove to us that your alternative is viable and sustainable.' Returning to the music institutions, Finale/Sibelius work for them, _and the issue is not the money_, even on a student level. Music students will pay tens of thousands of euros for instruments -- €500 for a software licence, and €100 a year for an upgrade (if you really want to) is a piss in the park by comparison. The issue is also not the freedom, because it's not such a big deal in most cases to be able to read past files or hack the software. Once you've got a PDF of a composition your work is done, and it's common for music to be re-engraved from scratch. It's not even the beauty of results, because -- we see this on a regular basis -- the Finale- or Sibelius-produced editions are _good enough for purpose_. With publishers at least, the norm seems to be to use the music engraving software to produce the basic framework and then further edit the output postscript in some vector graphics tool where necessary. It really is about producing final graphical output. They won't even care if Lilypond offers them something they don't get from Finale/Sibelius, because -- well -- you guys are doing this anyway and give it away for free. :-P What they _will_ care about is if you can give them a concrete plan along the lines of, 'This is something that you care about that you don't have now, or don't have easily, and here is how we can provide it, and this is how much money it will cost.' You have to make it very clear to them, because although the people concerned may be very nice and talented and able in the general scheme of things, where software is concerned they generally have the level of understanding of the pointy-haired boss. Or else they have a pointy-haired technology boss to tell them what to think. :-) (Mind you: that's European and US colleges. I'd be curious to see if you might have more luck going to South American or Asian or African institutions, who might appreciate the budgetary implications of being able to secure a long-term reliably supported notation solution for a fraction of the cost of Finale/Sibelius licenses. To say nothing of the fact that it fits with the more communally-inclined cultural innovations that are taking place in these countries. Try taking the message to Brazil with their increasing enthusiasm for copyleft [Gilberto Gil as culture minister], try taking it to Venezuela with reference to Il Sistiema, try wedding it to projects built on top of the 'One Laptop Per Child' scheme.) Examples of things that could get people's attention: -- Lilypond as a tool for disabled (notably, blind) access to music notation software. Not just blind music students like our own Hui Haipeng -- as a tool for disabled outreach projects. You'd have to take account of the fact that while Finale and Sibelius aren't so helpful to a blind person from a visual point of view, they DO offer valuable support in their ease of entering music by playing on the keyboard. -- Lilypond as a tool for 3rd-world or poor country outreach, prison outreach (it happens!), educational outreach to deprived regions of their own country. -- Support for community outreach projects (bearing in mind that music students and even schools can probably deal with the costs of software licenses, but it lowers the point of entry and long- term sustainability of wider community participation; think of the way that community and church choirs already use Lilypond...) -- Support for niche notational needs not well supported by Finale or Sibelius, such as early music or extreme contemporary music, algorithmically-created music, etc. -- Support for non-Western musics. Bear in mind that one GREAT way to unlock the coffers of institutions is to provide them with something where, by spending this money, they can do something that makes them look good in terms of the public arts spending aims of the day. :-) Example of these priorities in terms of questions a friend of mine was asked to address when applying to have her work displayed in a music technology exhibition: 'How can new technology build local
Re: bounties
On 06/15/2010 09:19 PM, Graham Percival wrote: > One idea I've toyed with is seeking a grant to work on lilypond. > Various governments and agencies give research grants; I'm pretty > certain that we could get a grant to improve medieval chant > notation or contemporary non-Western scales or whatnot. However, > this would probably require > - a bunch of grant applications > - collaborating with some musicologists (i.e. a medieval chant > expert, or John Cage scholar, or whatever) > - overhead of writing reports about deliverables, giving > presentations to people, etc. > - etc. > In the process of doing the specialized notation, the developer > might fix a few "normal" bugs as well. An alternative would be to go directly to the institutions that have an interest in notation software -- the (many) music colleges. Most of these have large numbers of computers with either or both of Finale and Sibelius installed (to say nothing of other music software), and if I recall right, that means a fairly large payout _per computer_. Take a message to multiple music colleges, demonstrate Lilypond's coolest features, emphasise the fact that it is and always will be free both as in beer and freedom, the cool features, and then ask for development support on the order of the cost of 3 Sibelius desktop licenses. Multiply that out across multiple institutions across the whole of Europe and it could add up to a fairly substantial amount of money. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nice stockhausen excerpt
Valentin Villenave wrote: > Indeed. Similarly, WWI is said to have ended in 1921... go figure. Another amusing tale here. I'm from a part of Wales called Monmouthshire; but this is border country, and historically there was an extended period of ambiguity (from about the 1600s to the 20th century) about whether it was considered part of Wales or of England. It was quite common for laws to be declared as applying to 'Wales and Monmouthsire'. Anyway, allegedly, the text of the declaration of war in 1914 referred to 'England, Wales, and Monmouthsire', while the peace treaty signed at Versailles only referred to England and Wales -- technically leaving Monmouthshire and Germany still at war. A friend in the local town council tells me that this oversight was finally rectified only in 1998. When I was at school there (pre-1998...) we used to have a regular exchange with a German gymnasium, where the school orchestra would go over and perform concerts for them. If this wasn't a continuation of hostilities, I don't know what was ... I just hope this doesn't mean that copyright in Monmouthshire is 80 years behind the times ... :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nice stockhausen excerpt
Valentin Villenave wrote: > US-printed scores where still illegal in France when I was a student > (that means less than a decade ago). Our teachers had to smuggle these > when they went on holiday in the US... 1918 + 90 years = 2008, so makes sense ... > In addition to the death of the author, one have to take the editior's > year into account. Debussy might well be legally usable now, but we > certainly do not want to take any chances (let alone *truly* > contemporary composers such as Satie or Ravel, these guys you > definitely don't want to mess with). It's been interesting watching the things that have been happening with Henle Urtext, who have been bringing out editions of relatively contemporary works in the last few years (Berg Piano Sonata and Four Pieces for Clarinet); of course, in Europe, 1935 + 70 years = ... Alas for them, their Finale-engraved score of the latter is far less attractive than the old-style engraving of the edition still published by UE. :-P Amusingly, they have also brought out an edition of Debussy's Etudes, complete with a beautiful trilingual print of the foreword where Debussy explains very wittily why fingerings are not provided in the work, and the benefits of finding one's own fingerings; and then you turn the page and see the work itself -- an Urtext edition, a faithful reproduction of the composer's intended text! -- replete with editorially-added fingerings as per Henle's house style. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nice stockhausen excerpt
Graham Percival wrote: > On Tue, Feb 23, 2010 at 2:49 PM, Hans Aberg wrote: >> RMS says he thinks it is better using artificial examples, not risking a >> lawsuit when it is so easy to avoid and still have good results. > > 1) I don't care what RMS says. Though in this case his comment is apt, and provides a good justification for your points (2) and (3) :-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: nice stockhausen excerpt
Valentin Villenave wrote: > Certainly not. Even Debussy got banned from our docs, for GNU's sake! Oh Gawd. Really? Where on earth is he still in copyright? Even in the US (90 years after death) copyright should have expired by now, no? Or is the worry that another 10+ year extension will be put in place before the decade is out? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] CG Feedback
Carl Sorensen wrote: >> "The -a is short for --all which includes modified and deleted files, >> but not newly created files." >> >> would be better as: >> >> "The -a is short for --all which includes modified and deleted files, >> but only newly created files which have been added with git add." > > Thanks for the suggestion. I've made the change in git. An even better phrasing (IMO:-): "The -a is short for --all, which includes all modified and deleted files. Newly created files must first be added using git add or else they will not be included." ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG chapter 2, first draft
Mark Polesky wrote: > Yep. Thanks Joe! Brilliant. There's probably plenty more that can be added -- see all the info on the Wine wiki linked to -- but this seems to be the really _essential_ stuff. Maybe also a link to where to get dos2unix ... ? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Doc: CG: Sending and receiving git patches via email
Trevor Daniels wrote: > Thanks Joe > > Mark is currently redrafting this section of the CG and it seems > he has picked up and applied your changes in his latest patch. That's great. Glad it was useful. :-) Sometime soon I must get back onto the Contemporary Music docs. I'm sorry for the absence -- things have been very busy and complicated in my other life. Nothing bad, just busy and complicated ... :-P Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Doc: CG: Sending and receiving git patches via email
Hello all,
With the news on CG revision I remembered I had never got round to
contributing a patch about solving the issues I had with patches and
email MIME types. So here it is.
It can probably be improved but this gets across the basic info, and it
includes a link to pages with further information.
Best wishes,
-- Joe
From 0b16d7c2d074eeb8f33ed77494bdd26ef9b182db Mon Sep 17 00:00:00 2001
From: Joseph Wakeling
Date: Tue, 12 Jan 2010 15:42:04 +0100
Subject: [PATCH] Information on sending/receiving git patches via email.
This contains the solution for MIMEtype problems experienced
with some email clients, and a link to the Wine wiki page on
git which contains much useful info.
It also incidentally removes some trailing whitespace. :-P
---
Documentation/contributor/git-starting.itexi | 72 ++
1 files changed, 50 insertions(+), 22 deletions(-)
diff --git a/Documentation/contributor/git-starting.itexi
b/Documentation/contributor/git-starting.itexi
index fb45b59..d6e23e5 100644
--- a/Documentation/contributor/git-starting.itexi
+++ b/Documentation/contributor/git-starting.itexi
@@ -9,10 +9,10 @@ usage in this chapter, it may be a good idea to look at the
other
Git documentation listed in @ref{Other git documentation}.
@menu
-* Getting the source code::
-* Updating the source code::
-* Sharing your changes::
-* Advanced git stuff::
+* Getting the source code::
+* Updating the source code::
+* Sharing your changes::
+* Advanced git stuff::
* Git on Windows::
* Other git documentation::
* Roadmap of directories::
@@ -23,12 +23,12 @@ Git documentation listed in @ref{Other git documentation}.
@section Getting the source code
@menu
-* Git introduction::
-* Git user configuration::
-* Main source code::
-* Documentation translations source code::
-* Other branches::
-* Other locations for git::
+* Git introduction::
+* Git user configuration::
+* Main source code::
+* Documentation translations source code::
+* Other branches::
+* Other locations for git::
@end menu
@node Git introduction
@@ -146,9 +146,9 @@ internet through a router that filters out Git and/or SSH
connections.
@section Updating the source code
@menu
-* Importance of updating::
-* Update command::
-* Resolving conflicts::
+* Importance of updating::
+* Update command::
+* Resolving conflicts::
@end menu
@@ -225,8 +225,8 @@ any changes you have made!
@section Sharing your changes
@menu
-* Producing a patch::
-* Committing directly::
+* Producing a patch::
+* Committing directly::
@end menu
@@ -358,13 +358,14 @@ Some Git commands are introduced first, then a workflow
with several
Git branches of LilyPond source code is presented.
@menu
-* Introduction to Git concepts::
-* Git commands for managing several branches::
-* Working on LilyPond sources with several branches::
+* Introduction to Git concepts::
+* Git commands for managing several branches::
+* Working on LilyPond sources with several branches::
* Git log::
* Using local git branches::
-* Applying git patches::
-* Reverting all local changes::
+* Applying git patches::
+* Sending and receiving patches via email::
+* Reverting all local changes::
@end menu
@@ -373,7 +374,7 @@ Git branches of LilyPond source code is presented.
A bit of Git vocabulary will be explained below. The following is
just introduction material; for better understanding of Git concepts,
-you are invited to read further documentation, especially Git
+you are invited to read further documentation, especially the Git
Community Book at @uref{http://book.git-scm.com/}.
The @code{git pull origin} command above is just a shortcut for this
@@ -672,6 +673,33 @@ git commit -a --author="First Last "
@end example
+...@node Sending and receiving patches via email
+...@subsection Sending and receiving patches via email
+
+The default @code{x-diff} MIME type associated with patch files
+(i.e., files whose name ends in @code{.patch}) means that the
+encoding of line endings may be changed from UNIX to DOS format
+when they are sent as attachments. Attempting to apply such an
+inadvertently altered patch will cause git to fail with a message
+about @q{whitespace errors}.
+
+The solution to such problems is surprisingly simple --- just
+change the default file extension of patches generated by git to
+end in @code{.txt}, for example:
+
+...@example
+git config format.suffix '.patch.txt'
+...@end example
+
+This should cause email programs to apply the correct base64
+encoding to attached patches.
+
+If you receive a patch with DOS instead of UNIX line-endings,
+it can be converted back using the @code{dos2unix} utility.
+
+Lots of useful information on email complications with patches
+is provided on the Wine wiki at @uref{http://wiki.winehq.org/GitWine}.
+
@node Reverti
Re: copyright info... actually wanted!
Graham Percival wrote: > Please re-read my request. This is not what I asked for. 'As a separate patch, feel free to add the "this manual is under the FDL" as a comment to the top of any relevant files in Documentation/.' I took 'all relevant files' to mean all files in the manual, re-reading your request I now presume you mean just the top-level file for each manual ... ? Is there any particular reason why these per-file license statements are bad? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: copyright info... actually wanted!
Graham Percival wrote:
> As a separate patch, feel free to add the "this manual is under
> the FDL" as a comment to the top of any relevant files in
> Documentation/.
I think you'll find a couple of such patches, sent by me, from a while
back ... :-)
Attached again in combined form, hope it's OK.
Best wishes,
-- Joe
From 63a650c550357fd2372370db49e0676f1a79420f Mon Sep 17 00:00:00 2001
From: Joseph Wakeling
Date: Sun, 27 Sep 2009 00:38:19 +0200
Subject: [PATCH] Doc: GFDL licensing notices for all files in LM + NR.
(Plus some trailing whitespace fixes from my text editor:-)
---
Documentation/learning/common-notation.itely | 16 +++-
Documentation/learning/fundamental.itely | 14 +++
Documentation/learning/introduction.itely | 40 +--
Documentation/learning/preface.itely | 14 +++
Documentation/learning/scheme-tutorial.itely | 14 +++
Documentation/learning/templates.itely | 17 +++-
Documentation/learning/tweaks.itely| 14 +++
Documentation/notation/ancient.itely | 15 +++
Documentation/notation/changing-defaults.itely | 14 +++
Documentation/notation/cheatsheet.itely| 14 +++
Documentation/notation/chords.itely| 15 +++
Documentation/notation/contemporary.itely | 15 +++
Documentation/notation/editorial.itely | 17 -
Documentation/notation/expressive.itely| 15 +++
Documentation/notation/fretted-strings.itely | 23 +--
Documentation/notation/input.itely | 14 +++
Documentation/notation/keyboards.itely | 17 -
Documentation/notation/notation-appendices.itely | 14 +++
Documentation/notation/notation.itely | 15 +++
Documentation/notation/percussion.itely| 15 +++
Documentation/notation/pitches.itely | 15 +++
Documentation/notation/programming-interface.itely | 18 -
Documentation/notation/repeats.itely | 15 +++
Documentation/notation/rhythms.itely | 17 -
Documentation/notation/simultaneous.itely | 15 +++
Documentation/notation/spacing.itely | 16 +++-
Documentation/notation/specialist.itely| 15 +++
Documentation/notation/staff.itely | 17 -
Documentation/notation/text.itely | 15 +++
Documentation/notation/unfretted-strings.itely | 15 +++
Documentation/notation/vocal.itely | 15 +++
Documentation/notation/wind.itely | 15 +++
Documentation/notation/world.itely | 15 +++
33 files changed, 507 insertions(+), 28 deletions(-)
diff --git a/Documentation/learning/common-notation.itely
b/Documentation/learning/common-notation.itely
index c9eb78d..c34d8c4 100644
--- a/Documentation/learning/common-notation.itely
+++ b/Documentation/learning/common-notation.itely
@@ -1,4 +1,18 @@
@c -*- coding: utf-8; mode: texinfo; -*-
+...@ignore
+Documentation/learning/common-notation.itely
+
+This file is part of the documentation for GNU Lilypond.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1
+or any later version published by the Free Software Foundation;
+with no Invariant Sections, no Front-Cover Texts and no Back-Cover
+Texts.
+
+You should have received a copy of the GNU Free Documentation License
+along with this file. If not, see <http://www.gnu.org/licenses/>.
+...@end ignore
@ignore
Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
@@ -1400,7 +1414,7 @@ Learning Manual, you may want to read some sections again
and follow
cross-references for further reading.
If you have not done so already, @emph{please} read
-FIXME FIXME FIXME
+FIXME FIXME FIXME
@c @ref{About the documentation}.
There is a lot of information about LilyPond, so
newcomers often do not know where they should look for help. If
diff --git a/Documentation/learning/fundamental.itely
b/Documentation/learning/fundamental.itely
index 690c735..2fe3ebb 100644
--- a/Documentation/learning/fundamental.itely
+++ b/Documentation/learning/fundamental.itely
@@ -1,4 +1,18 @@
@c -*- coding: utf-8; mode: texinfo; -*-
+...@ignore
+Documentation/learning/fundamental.itely
+
+This file is part of the documentation for GNU Lilypond.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1
+or any later version published by the Free Software Foundation;
+with no Invariant Sections, no Front-Cover Texts and no Back-Cover
+Texts.
+
+You should h
Re: [PATCH] COPYING rewrite to clarify licensing
Graham Percival wrote: > ok, committed, and I dealt with the copying.documentation thing. Thanks! I've attached a small tweak to add front/back cover text mentions, for you to take or leave as you please. Best wishes, -- Joe From 7bdfa348918fab245f1130de988fbf3dc6ef49b4 Mon Sep 17 00:00:00 2001 From: Joseph Wakeling Date: Tue, 22 Sep 2009 19:47:12 +0200 Subject: [PATCH] COPYING.DOCUMENTATION tweak to mention (lack of) front/back cover texts. --- COPYING.DOCUMENTATION |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/COPYING.DOCUMENTATION b/COPYING.DOCUMENTATION index f9cd158..7fab1d7 100644 --- a/COPYING.DOCUMENTATION +++ b/COPYING.DOCUMENTATION @@ -1,8 +1,9 @@ Permission is granted to copy, distribute and/or modify the documentation for GNU LilyPond under the terms of the GNU Free Documentation License, Version 1.1 or any later version published -by the Free Software Foundation; with no Invariant Sections. A -copy of the license is contained in this file. +by the Free Software Foundation; with no Invariant Sections, no +Front-Cover Texts and no Back-Cover Texts. A copy of the license +is contained in this file. There exist the following exceptions to this license: -- 1.6.3.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Licensing dependencies
Graham Percival wrote: > What does this mean? I mean, *any* project would be a problem if > they changed to a non-GPLv2-compatible license. Are they > considering/planning such a change? Not that I know of. The point is just that most Lilypond dependencies are either called rather than linked to, or have permissive licenses -- (L)GPL'd dependencies like Pango have greater potential for a version upgrade that buggers GPLv2-only code. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Trevor Daniels wrote: > For example, we seem to have lost Joseph's really > promising work to document contemporary music. Not lost. :-) Actually, the delay came at least in part because I was looking through problems of functionality related to my docs. I'll post about this on -user. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
Graham Percival wrote: > I would have thought that > http://lists.gnu.org/archive/html/lilypond-devel/2009-09/msg00438.html > was right up your alley. Yep. I was having a bit of a look through what's there to see what would be involved. I'll see what I can do ... ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote: > For this reason, I categorically refuse to have file-specific > ownership. Documentation is documentation; any doc committers > will be listed in the same place. About docs, I completely agree. I didn't have to spend long in the git logs to realise that it just wasn't feasible to meaningfully identify contributors -- there's too much moving, renaming, copy-pasting, etc. > I still think it would be a complete waste of time, but if you > really want to track down file ownership of source code, _I_ won't > stop you. You'd better check that everybody else is ok with this, > though. And by "ok", I mean "agrees to you doing the initial > work, *and* commits to maintain such info in the future". I think with code it has more value, and ought to be reasonably easy to maintain. There's also the fact that the code, unlike the docs, _does_ contain per-file copyright notices, and that these are wrong. If we're going to have them, they ought to be accurate. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Licensing dependencies
Reinhold Kainhofer wrote: > Am Sonntag, 20. September 2009 13:46:32 schrieb Joseph Wakeling: >> It looks like the problems are FreeType (GPLv2 only or GPL-incompatible >> permissive license, so blocks upgrade); > > The FTL is GPLv2-incompatible, but according to the FSF, it's GPLv3- > compatible... See > http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses > No blocker here. Oh, great. Missed that when reading the compatible license list. >> Guile (future versions will be >> LGPLv3+, so GPLv2-only-incompatible); and potentially Pango (if it >> upgrades to LGPLv3+). > >> None are a present, active problem but all are clear risks. > > Yes, that's the only possible license issue in the future that I can see. > Everything else appears okay... So, the upshot is that, while not an absolute necessity, it would be highly convenient to gain GPLv3 compatibility. If there are no objections I will continue to track contributors and ask for their licensing preferences -- specifically, what is the most permissive license they are willing to permit (i.e. GPLv2/3, GPLv2+, BSD-style, etc.) -- and record in the publicly-viewable Google Doc mentioned previously. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] COPYING rewrite to clarify licensing
Following the earlier discussion with Graham and others, this patch slightly rewrites the COPYING file to clarify the Lilypond licensing situation. It might also be sensible to add a line mentioning that docs are released under GFDL, and a separate COPYING.DOCUMENTATION file that contains that license. Best wishes, -- Joe From d1ee19e7d7dd10d0504ebec2a621d675087f0f70 Mon Sep 17 00:00:00 2001 From: Joseph Wakeling Date: Sun, 20 Sep 2009 15:58:09 +0200 Subject: [PATCH] COPYING rewrite to clarify licensing. * Text is closer to FSF guidelines and explicitly states that Lilypond is released under GPLv2 only. --- COPYING | 38 -- 1 files changed, 20 insertions(+), 18 deletions(-) diff --git a/COPYING b/COPYING index 3ad0007..da2d00d 100644 --- a/COPYING +++ b/COPYING @@ -1,21 +1,23 @@ -If you want to redistribute LilyPond, you must comply with the GNU -General Public License (reproduced below). This license applies to -LilyPond with the following exceptions: - -- It does not apply to example input files (which are in -the subdirectory input/) that explicitly specify another license. - -- If you create a document which uses fonts included in LilyPond, and -embed this font or unaltered portions of this font into the document, -then this font does not by itself cause the resulting document to be -covered by the GNU General Public License. This exception does not -however invalidate any other reasons why the document might be covered -by the GNU General Public License. If you modify this font, you may -extend this exception to your version of the font, but you are not -obligated to do so. If you do not wish to do so, delete this exception -statement from your version. - - +GNU Lilypond is free software; you can redistribute it and/or modify +it under the terms of version 2 of the GNU General Public License as +published by the Free Software Foundation. A copy of the license is +contained in this file. + +The following exceptions are granted to this license: + + -- It does not apply to example input files (contained in the +subdirectory input/) that explicitly specify another license. + + -- If you create a document which uses fonts included in Lilypond, +and embed this font or unaltered portions of this font into the +document, then this font does not by itself cause the resulting +document to be covered by the GNU General Public License. This +exception does not however invalidate any other reasons why the +document might be covered by the GNU General Public License. +If you modify one or more of the fonts, you may extend this +exception to your version of the fonts but you are not obliged +to do so. If you do not wish to do so, delete this exception +statement from your version. GNU GENERAL PUBLIC LICENSE -- 1.6.3.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Licensing dependencies
Have had a look through the licenses of dependencies as listed in the Contributor's Guide. It looks like the problems are FreeType (GPLv2 only or GPL-incompatible permissive license, so blocks upgrade); Guile (future versions will be LGPLv3+, so GPLv2-only-incompatible); and potentially Pango (if it upgrades to LGPLv3+). None are a present, active problem but all are clear risks. Best wishes, -- Joe --- Running requirements: FreeType: FreeType license (GPL-incompatible due to advert clause) or GPLv2 only FontConfig: Permissive license, seems to be GPL-compatible (it's pretty much identical to the advertising-clause-free version of the BSD license; if there is anything wrong we're as buggered with GPLv2 as 3+). http://cgit.freedesktop.org/fontconfig/tree/COPYING Pango: Development version downloaded from Git is LGPLv2+. Guile: as already discussed, 1.8.x is LGPLv2+. Development version (1.9.x) is LGPLv3+. Python: GPL-compatible: see, http://www.python.org/download/releases/2.6/license/ Ghostscript: GPLv3+, but LP doesn't link to it, so it's OK. Dejaview: can't find any info on this, what is its provenance? Build requirements: FontForge: new BSD license (i.e. GPL-compatible) Metafont: seems a bit weird and uncertain (TeX licenses, some GPL) but this is just called, not linked to, no? t1utils: permissive license, seems GPL-compatible Guile: see above Texinfo: GPLv3+, but we only call it, don't link (?) g++: GPLv3+, but we only call it Python: see above GNU Make: GPLv3+, but we only call it Gettext: GPLv3+, but we only call it Flex: new BSD license (GPL-compatible) Perl: Artistic License/GPLv1 (!) but seems to be OK as we only call it and don't link. GNU Bison: GPLv3+, but we only call it Doc build requirements: texi2html: GPLv2+ (we only call it anyway) netpbm: seems horribly complicated, but we only call it imagemagick: own license, claims GPL compatibility (but we only call it in any case) rsync: GPLv3+, but we only call it. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
Reinhold Kainhofer wrote: > Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond can't use > guile any more, because LGPLv3 is not compatible with GPLv2... So, lilypond > then has to switch to GPLv3... But then we have a problem with freetype, > which > is FTL (BSD with advertising clause, thus incompatible with GPL) or GPLv2 > only... Argh. I wasn't aware of the LGPLv3/GPLv2 incompatibility until now. That's nasty. :-( > I really love it how FSF handles the GPL purely for political reasons... > (Which might make sense from an abstract viewpoint, but in daily developer > life that is just counterproductive and hindering productive development!) > > To be honest, as an open source developer, I'm really starting disliking the > GPL, simply for practical reasons. Well, they are a political organisation. They aren't there to make your life as a developer easy -- and if you follow their practical advice, you don't end up in these situations. (They are also generally pretty good about taking into account the practical issues that will be raised by any licensing change, and trying to minimise them.) >> That was one of the motivations for tracking who was OK with GPLv2+ -- >> to have an advance list of people ready for such an eventuality. > > See e.g. what KDE did a while ago: > http://techbase.kde.org/Projects/KDE_Relicensing > > I propose we also keep such a list (publicly available) about what the devs > allow with regards to their licenses. I am already doing so, although not as detailed as KDE's. http://spreadsheets.google.com/ccc?key=0AkXkBLpoZm-_dHdkUUZRRVJvX2ZHWVpOeloyTU00SHc&hl=en It's on Sheet 2 :-) Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Anthony W. Youngman wrote: > Aarrgghh. > > The snippets are not public domain, unless the author put them there. > The *music* may be public domain, but the *arrangement* is copyright > whoever wrote the lilypond code (unless you make the argument that the > snippet is too small to qualify for copyright). The snippets are taken from the LSR and a condition of submission to the LSR is that you consign your work to the public domain (and that you have the right to do so). I know, because I submitted a couple of snippets to the LSR and they later made it into the Lilypond docs' selection of snippets. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
Graham Percival wrote: > There's a *ton* of other janitorial work to be done, especially by > people who have proven that they're willing to do work (about 50% > of people who say "hey, I want to help out" never do anything!). > And not only that, but you're capable of using git! There's lots > of stuff that needs doing for the new website, for example. OK. I have not been following those discussions closely but if you can give me a rough todo list I will see what I can contribute in that respect and prioritise it over any copyright work. I also have to get back to the contemporary music documentation, which I've been neglecting ... > If you really want to keep on doing copyright stuff, then I'd > suggest that you look into the licenses of the projects which > lilypond *links* to. Stuff like ghostscript doesn't matter, since > we only call it on the command-line. But it would be good to > know, for example, what license guile 1.8 is under, if they > changed to GPLv3 when did it happen, etc. Yes, I think that's a good idea and will start tracking those things. Guile I think is LGPLv3 although parts may be GPL -- but that's only for the current development release (i.e. 1.9.x). 1.8.x is still under LGPLv2+. > I'm pretty certain that we're fine right now, but as more and more > projects switch to GPLv3, we might suddenly discoved that we can't > link to pango or freetype or something like that. It would be > great if we had a list of such projects, so that if/when we > seriously discover any license switch (again, in a few months) we > have that info handy. That was one of the motivations for tracking who was OK with GPLv2+ -- to have an advance list of people ready for such an eventuality. > There's no dual-licensing of doc contributions. Docs are > currently FDL 1.1 or later (sigh). Code is GPLv2. Exceptions to > this (such as cary.ly) should be remedied. Just tracking willingness, rather than proposing a change. It seemed worthwhile to see who would sign up for the Debian maintainer's proposal of dual-licensing the docs. On the broader scheme of things I'm going to keep tracing the contributors to individual files (but not with incredible speed). Besides any usefulness for Lilypond I have a vested interest which has nothing to do with Lilypond or licensing per se, but relates to a project that stems from my day job: http://project.liquidpub.org/ http://github.com/WebDrake/liquidpub-dvcs https://code.launchpad.net/~webdrake/liquidpub/peer-review ... so learning about tracing/tracking contributions and contributors in a version control system is interesting to me anyway, and since it's unlikely to HURT Lilypond and might be of some use, I might as well follow that interest ... :-) Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Licensing notices for NR and LM
Graham Percival wrote: > On Sat, Sep 12, 2009 at 04:32:16PM +0200, Joseph Wakeling wrote: >> I think this is a fairly uncontroversial addition (it's just stating in >> each file what's already true) so I'm submitting these patches now >> rather than later. > > For the benefit of the mailist archives, this *is* controversial, > but the discussion is occuring in other threads. Uncontroversial inasmuch as it doesn't propose to change the licensing situation, just states the license on a file-by-file basis. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote: > Bugger the GNU project guidelines. They're not the be-all and > end-all of good project mangement. In many ways, they're pure > rubbish. Toodle-pip, cheers, and all that. > > (I'm trying to be more British... I was really surprised at the > use of "cheers" here. It's a greeting! It's a farewell! It's a > thanks! It's an airplaine... no, it's super-word! :) One of the best words in the English language. ;-) GNU guidelines seem to me to be least important reason to do anything, but worth reading and understanding the motivation behind them, particularly where copyright/licensing is concerned -- just because the people behind GNU have put a lot of thought into these things and have a lot of experience. >>> Really? Line 22 says "Version 2, June 1991" to me. How exactly >>> do you propose to change the COPYING file? >> I propose to add text closer to the statement recommended by the FSF/GNU >> foundation and by the GPL itself: >> >> GNU Lilypond is free software; you can redistribute it and/or modify >> it under the terms of version 2 of the GNU General Public License as >> published by the Free Software Foundation. > > ok. > >> ... plus some further explanatory text that will probably be close to >> what the existing file says. Perhaps also a line emphasising the >> licensing situation (i.e. v2 only) as the Linux kernel COPYING file >> does, > > ok. I'll put forward a patch for this, then. >> and a note explaining how we are attempting to change the >> licensing situation. > > Not ok. Will not be in the aforementioned patch, then. (v) the link on the main page which (still) points to the text of GPLv3 on gnu.org (and has ever since v3 was released -- the first message pointing out this discrepancy was sent to the -devel mailing list over 2 years ago!). >>> This is fixed on the new website. >> But not on the current one, which is still live ... :-) > > Patches accepted. I'll see what I can do. (Depending on the timeline for launch of the new site. Not much point patching the current one if you're going to launch the new one in a couple of weeks' time.) >> Sure; this is just a useful policy to have (and maintain) because it >> clarifies the licensing situation on a file-by-file basis. > > But we *don't* have "a licensing situation" on a file-by-file > basis. Everything[1] under Documentation/ is FDL; everything > else[2] is GPLv2. I'll come to this in a moment after addressing your next points... > [1] it would be very useful if somebody could create an example to > replace cary.ly, since that's non-free. > > [2] it would be very useful if somebody could identify anything > (other than texinfo.tex and input/* since those are slated for > demolition) that isn't GPLv2. > > [3] haha, an unreferenced footnote! It would be very useful if > the note at the top of /COPYING had these exceptions noted. I can work on at least [2] and [3]. I can try to do [1] as well. > What's the point of per-file stuff? The only thing that I can > think of is that if somebody discovers the file via a google > search (say, in gitweb), but is too lazy to look at the top of the > gitweb repository, they can see the license and comply with it. > > That's ridiculous. Anybody who is moral will take the extra 30 > seconds to find the appropriate COPYING file. Anybody who isn't > moral is going to ignore the license anyway and just take whatever > they want. OK, well. Perhaps I should say 'credit on a per-file basis' rather than licensing[1]. The reason I can see is this: if I decide I want to use a file from Lilypond in my own piece of code, it's helpful to me to know exactly who the authors and copyright holders are for that particular file. With such a notice I immediately know who I have to contact if I need/want further permissions, I know who I have to credit in my AUTHORS file, etc. etc. Now, I can of course go searching through the git log to track them down. But then what happens when I discover the apparent contributors don't match with the copyright notice in the file (currently the case)? What happens if I trust the copyright/credit notice, then suddenly later get someone I didn't know about coming along and saying, 'Hey, you're using my code without credit'? (Or, what happens if someone adds third-party material to Lilypond code or docs? OK, we have the git log, but it's handy to be able to see without delving into version history whether a particular file contains material from a given source.) So, I see maintaining good file-by-file contribution records as being both helpful to Lilypond (it helps us track who did what) and courteous to people receiving the code (it helps facilitate the process of adapting parts of the code for other projects). [1] Where the licensing issue might be important is this: what if someone forks Lilypond and adds a bunch of t
Re: Copyright/licensing action plan + a sample [PATCH]
Graham Percival wrote: > I know you all want to rush ahead on this, but this is one issue > which will not be rushed. Later today, I have the choice of > working on GUB and dealing with this thread; I will prioritize GUB > (and therefore making releases, particularly ones with fixed OSX > 10.5 for both 2.13 and 2.12). >From my point of view that shouldn't be an issue. Patches I've submitted are as examples for people to comment on rather than with expectation that they be reviewed/accepted quickly. I will push ahead with tracking contributions to code, but not make/submit any further new patches until this debate is better addressed. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright/licensing action plan + a sample [PATCH]
Anthony W. Youngman wrote: > I think you don't understand copyright properly ... > > DON'T track "whether they support switching the licence". Because if > they do, they will (presumably already) have switched the licence on > their contributions. ... but we have no records of that switch, because copyright and licensing details have not been tracked on a per-file or per-contribution base. If the license has not been stated within the code they contributed, it can't be assumed by users of Lilypond, regardless of verbal/email assurances (which most users won't know about anyway). > For each contributor you want to track the licence THEY have used. > Obviously, it's v2-compatible - it must be. So I would suggest the > spreadsheet contain the following columns ... > > Contributor, licence, v3 compatible?, date, comment That's a very good suggestion and I will follow it. > You are exhibiting a touching, blind, blinkered faith in the FSF. If I > may speak for Han-Wen, I don't think he shares that faith. There may > well be lilypond contributors who don't believe in the GPL, surprising > as that may sound! But there's nothing stopping BSD believers (who may > find the GPL offensive!) from contributing to lilypond. > > DO NOT try to switch the licence to v2+. You will probably run into a > brick wall! And if the eventual plan is to be v3-compatible you're > setting yourself up for failure! I stress that the main point of my activity is not to switch the license (a decision not for me to take) but to attempt to identify who made significant (i.e. copyrightable) contributions what to which files. > Use your spreadsheet to *track* *all* the licences to lilypond, not > restrict the licences you can handle to an arbitrary subset of the > licences you think other people should use (that attitude is offensive). > That way, your spreadsheet will actually BE USEFUL. And it might achieve > something POSITIVE. As you describe your intentions, the spreadsheet > looks pretty useless at the moment. Yes, very fair point -- I do not want to force a license choice on anyone. The main point of the spreadsheet is not in any case to track license choices but contributions. Perhaps you would like to take a look: http://spreadsheets.google.com/ccc?key=0AkXkBLpoZm-_dHdkUUZRRVJvX2ZHWVpOeloyTU00SHc&hl=en > As it is, I find your emphasis on v2+ offensive, and I doubt I'm alone. > Given the choice of "v2 or v2+", I'd go for "v2 only". But if you ask me > "what licence would *I* choose?", my reply would be "v2/v3". See what I > mean about your approach being counter-productive? Again, fair point. I've no wish to argue (now) the merits of different licensing choices. > I repeat. Sod *your* choice of favourite licences. Just *track* the > licences contributors have chosen, and then you can also track whether > the licences are v3-compatible. If you ask Han-Wen "will you change your > licence to v2/v3" I think you stand a decent chance of getting a "yes". > If you ask "will you change to v2+?" you'll almost certainly get a flat NO! The only reason for mentioning v2+ was just to get an idea of the number of people willing to relicense in a way that could satisfy all other licensing desires -- not an attempt to force it on anyone. Note that in the sample patch I posted the license was very clearly v2 only -- the existing license of Lilypond. Not really the actions of someone trying to ram his 'favourite license' down everyone's throats, is it? > By the way, I said to put a column in the spreadsheet called "date". > That spreadsheet should be in the source code, probably in a LICENSING > subdirectory, along with copies of all the emails contributors send > confirming their license. That way you can track how and when people > change licensing. (And you're not adding yet ANOTHER dependency, namely > Google Docs, that people have to have if they're going to contribute to > lilypond. And how do they patch the spreadsheet, if you screw up? I > certainly don't want Google Docs on my system!) Eh??!!! Google Docs is a web app, you don't have to have anything on your system. It's just handy because this way I can share a link (like above) that lets anyone view the progress of my work, and I can also open the document to others who want to contribute. I can export the data to OpenOffice, Excel or any damn format you like -- it can wind up as a comma- or tab-separated text file if you really want it to. It's not about requiring Lilypond to do anything, it's just something that is useful for me, now, actually trying to work out who authored what. And since I don't see anyone else wanting to take on that (arguably sensible) task, it might be nice to let me get on with it without beating me over the head for what you assume are my intentions regarding Lilypond's license(*). Thanks nevertheless for your useful suggestions -- I hope this email clears up what I do and don't intend. I'll update the licensing part of the spreadsheet ac
Copyright/licensing action plan + a sample [PATCH]
Hello everyone,
A word or more about the action plan to deal with the
copyright/licensing issue raised earlier.
The main aim is not relicensing but just to try and get a handle on who
wrote what parts of Lilypond. So, for each code file, I'm using git
shortlog to get the list of contributors (thanks to Francisco's .mailmap
file this is much simplified) and then using gitk to browse the commit
history of the file.
I'm dividing commits into Tweaks and Contributions. Tweaks are things
like removing whitespace, changing a version statement, changing the
name of a symbol or function -- small editorial changes in other words.
Contributions involve addition of a reasonable amount of novel
material. Following the GNU guidelines at:
http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant
I've taken the line that tweaks are not significant for copyright
purposes unless there are a lot of them (i.e. 10+). So far anyone with
10+ tweaks has also got at least one commit that counts as a
'contribution' anyway.
For each significant contributor (C) I note their earliest and most
recent commit and use that to date their copyright. In the event a
contributor already has a copyright notice in the file, I take the
earliest starting date of the two. For tweakers (T) I note the number
of tweaks (in commits).
I'm then entering these details into a Google Docs spreadsheet (which
I'll share with anyone who requests it). The same spreadsheet also
contains a complete list of contributors (from Francisco's .mailmap) and
a note on whether they support switching the license to GPLv2+ and
whether they are willing to dual-license doc contributions as GPLv2+.
The attached patch for lily/accidental.cc shows one result. A git
shortlog shows that the contributors are Han-Wen (68 commits), Jan (17),
Joe Neeman (8), and Mats Bengtsson and Neil Puttock (1 each) and Werner
Lemberg (2). Mats', Neil's and Werner's contributions are all small
tweaks, while Han-Wen, Jan and Joe have all made at least one
significant contribution. Han-Wen's first patch is dated from 2002, but
the existing copyright notice puts the beginning of his work in 2001; so
I've taken the earlier date, but kept the final date at 2008 with his
last commit. Jan's commits date from 2002-2009 and Joe's from
2007-2009. The proposed copyright/licensing notice gives copyright to
all 3 for the appropriate dates, and credits contributors of tweaks and
corrections without declaring copyright for them.
Feedback (most of all from the authors!) on whether this notice is
acceptable would be gratefully received.
The docs are much more difficult to trace than code, with material
having been moved and copied and pasted all over the place. :-( But
when the code parts are finished, I'll see what I can do with them.
Best wishes,
-- Joe
From 848114f18748bb70f199e6d8f6a9c6cc0cdf6a32 Mon Sep 17 00:00:00 2001
From: Joseph Wakeling
Date: Sat, 12 Sep 2009 21:02:26 +0200
Subject: [PATCH 5/5] accidental.cc licensing and copyright notice.
* Contributions (major and minor) tracked via git logs
* Copyright credited to major contributors with dates
corresponding to first and last commit
* Contributors of small tweaks and corrections given
brief credit in alphabetical order
* ... and trailing whitespace correction courtesy
of Kate editor :-)
---
lily/accidental.cc | 35 ++-
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/lily/accidental.cc b/lily/accidental.cc
index a017cf8..16d57e0 100644
--- a/lily/accidental.cc
+++ b/lily/accidental.cc
@@ -1,9 +1,26 @@
/*
accidental.cc -- implement Accidental_interface
- source file of the GNU LilyPond music typesetter
+ Copyright (c) 2001--2008 Han-Wen Nienhuys
+ Copyright (c) 2002--2009 Jan Nieuwenhuizen
+ Copyright (c) 2007--2009 Joe Neeman
- (c) 2001--2009 Han-Wen Nienhuys
+ Small corrections and tweaks by Mats Bengtsson, Werner Lemberg
+ and Neil Puttock.
+
+ This source file is part of the GNU Lilypond music typesetter.
+
+ GNU Lilypond is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 of the License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License along
+ with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "accidental-interface.hh"
@@ -19,7 +36,7 @@ Stencil
parenthesize (Grob *me, Stencil m)
{
Font_metric * font
-= Font_interface::get_default_font (me);
+= Font_interface::get_def
[PATCH] Licensing notices for NR and LM
These patches add licensing notices (GFDL1.1+) but _not_ copyright notices to individual files making up the Notation Reference and Learning Manual. There's also another dual-licensing my section on contemporary music (my sole copyright) with GPL2+. I think this is a fairly uncontroversial addition (it's just stating in each file what's already true) so I'm submitting these patches now rather than later. Currently going through git logs to track down authors of other documentation sections (docs are looking more difficult than code as content has been shifted around and tweaked a fair bit more than a lot of code files). Question -- in _code_ (not docs) are there preferences/constraints regarding the use of (c), (C) or © as copyright symbol (bearing in mind files are in UTF-8 format)? Best wishes, -- Joe From eb5a242818bda7994e6897533113240de5b842c3 Mon Sep 17 00:00:00 2001 From: Joseph Wakeling Date: Fri, 11 Sep 2009 16:08:22 +0200 Subject: [PATCH 2/4] Doc: add GPLv2+ permission to contemporary music section. --- Documentation/notation/contemporary.itely | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/notation/contemporary.itely b/Documentation/notation/contemporary.itely index c92ea47..08e512c 100644 --- a/Documentation/notation/contemporary.itely +++ b/Documentation/notation/contemporary.itely @@ -12,8 +12,14 @@ with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. -You should have received a copy of the GNU Free Documentation License -along with this file. If not, see <http://www.gnu.org/licenses/>. +Permission is also granted to redistribute and/or modify this file +under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +You should have received copies of the GNU Free Documentation License +and the GNU General Public License along with this file. If not, see +<http://www.gnu.org/licenses/>. @end ignore @ignore -- 1.6.3.3 From 77e36108b17549ea065400901805739e733d82db Mon Sep 17 00:00:00 2001 From: Joseph Wakeling Date: Fri, 11 Sep 2009 16:43:11 +0200 Subject: [PATCH 3/4] Doc: GFDLv1.1+ licensing notice for files in Notation Reference. * All files in the Notation Reference now contain individual licensing notices for GNU Free Documentation License version 1.1 or later, with no Invariant Sections, Front-Cover Texts or Back-Cover Texts * ... incidentally, my text editor cleaned up some trailing whitespace :-) --- Documentation/notation/ancient.itely | 15 + Documentation/notation/changing-defaults.itely | 14 Documentation/notation/cheatsheet.itely| 14 Documentation/notation/chords.itely| 15 + Documentation/notation/editorial.itely | 17 +- Documentation/notation/expressive.itely| 15 + Documentation/notation/fretted-strings.itely | 23 --- Documentation/notation/input.itely | 14 Documentation/notation/keyboards.itely | 17 +- Documentation/notation/notation-appendices.itely | 14 Documentation/notation/notation.itely | 15 + Documentation/notation/percussion.itely| 15 + Documentation/notation/pitches.itely | 15 + Documentation/notation/programming-interface.itely | 18 +- Documentation/notation/repeats.itely | 15 + Documentation/notation/rhythms.itely | 17 +- Documentation/notation/simultaneous.itely | 15 + Documentation/notation/spacing.itely | 16 +- Documentation/notation/specialist.itely| 15 + Documentation/notation/staff.itely | 17 +- Documentation/notation/text.itely | 15 + Documentation/notation/unfretted-strings.itely | 15 + Documentation/notation/vocal.itely | 15 + Documentation/notation/wind.itely | 15 + Documentation/notation/world.itely | 15 + 25 files changed, 380 insertions(+), 11 deletions(-) diff --git a/Documentation/notation/ancient.itely b/Documentation/notation/ancient.itely index cd01c94..c37db4c 100644 --- a/Documentation/notation/ancient.itely +++ b/Documentation/notation/ancient.itely @@ -1,6 +1,21 @@ @c -*- coding: utf-8; mode: texinfo; -*- @c vim: foldmethod=marker @ignore +Documentation/notation/ancient.itely + +This file is part of the documentation for GNU Lilypond. + +Permission is granted to cop
Re: [PATCH] Doc: copyright/licensing notice for contemporary music section.
Graham Percival wrote: > I'll examine this in a day or two; I'm still sorting out basic > issues about how to live on the other side of the Atlantic. No rush whatsoever -- I will need time to work on this stuff. Currently going through Notation Reference source one file at a time and tracking down the user commits. Good luck with the other-side-of-Atlantic issues! Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Francisco Vila wrote:
> 2009/9/11 Francisco Vila :
>> Those stats are very old now.
>
> They are now up to date, just in case.
>
> http://paconet.org/lilypond-statistics/
Thanks very much for this! :-)
It leads to the question -- already in mind from browsing the git log --
who is 'fred'? There is no full name and no email ('fred '), but
a lot of commits are in his name. Is this someone responsible for much
code? Or just someone responsible for managing the git or cvs repo in
the past?
And no, it seems docs are (fortunately) already 'or later', so we don't
have to worry on that account. :-)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Doc: copyright/licensing notice for contemporary music section.
This one IS for inclusion in the main source tree, unless there is a problem with it. :-) I'll be adding the same licensing notice to all files in the docs unless anyone objects. (Debian-related comments particularly welcome.) For COPYRIGHT notices I will take longer and try and identify concretely who contributed what on a file-by-file basis. Best wishes, -- Joe From ac8a3517383a3f5aea9ab9b6c0efb672b620800f Mon Sep 17 00:00:00 2001 From: Joseph Wakeling Date: Fri, 11 Sep 2009 10:58:26 +0200 Subject: [PATCH] Doc: copyright/licensing notice for contemporary music section. --- Documentation/notation/contemporary.itely | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/Documentation/notation/contemporary.itely b/Documentation/notation/contemporary.itely index 34dda95..c92ea47 100644 --- a/Documentation/notation/contemporary.itely +++ b/Documentation/notation/contemporary.itely @@ -1,5 +1,22 @@ @c -*- coding: utf-8; mode: texinfo; -*- @ignore +Documentation/notation/contemporary.itely + +Copyright © 2009 Joseph Wakeling + +This file is part of the documentation for GNU Lilypond. + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.1 +or any later version published by the Free Software Foundation; +with no Invariant Sections, no Front-Cover Texts and no Back-Cover +Texts. + +You should have received a copy of the GNU Free Documentation License +along with this file. If not, see <http://www.gnu.org/licenses/>. +...@end ignore + +...@ignore Translation of GIT committish: FILL-IN-HEAD-COMMITTISH When revising a translation, copy the HEAD committish of the -- 1.6.3.3 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Carl Sorensen wrote: > Amen to that. If only they had made some kind of an accomodation clause > that would have allowed projects with mixed v2 and v3 licenses to go > forward, as long as the v3 license terms were followed on the combined > package (e.g. no tivoization, and following the patent stuff). But they > don't. There was no way they could have done that, unfortunately. :-( It's not a matter of GPLv3 accommodating GPLv2 but the other way round -- GPLv2 has a 'no additional clauses' requirement and GPLv3 applies ... additional clauses. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Graham Percival wrote: > The beginnings of the manuals. In my restructuring, that's now in > macros.itexi, although this may well move to a third macro file. > Hmm, I just noticed that the copyright years are messed up... I'll > fix that fairly soon. Brilliant. So as far as the docs are concerned that reduces my task to 'Who contributed to ... ?' rather than 'Do they agree to ... ?' In that case I'll submit a patch with licensing notices for doc files. I will still work on identifying who should be credited as authors on a file-by-file basis. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Graham Percival wrote: > Docs have always been FDLv1.1 or later. I was thinking about > unilaterially changing them to FDLv1.3 or later, as soon as I've > got GUB working. Great, that should simplify matters A LOT. Where in the source tree is the explicit statement of the 'or later' ... ? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Graham Percival wrote: > Mao, I missed the flamewar. I'm very disappointed that this > happened without me. :( :-) > The manuals include the FDL, so I'd argue that it's clear that the > sources are under the same license. I'd argue the same about the > source files, actually. This is basically about good (unambiguous) practice as far as I'm concerned (see e.g. GNU project guidelines). > Yes. Including people for whom we lost contact 10 years ago, and > including the heir(s) of Rune Zedeler, who passed away last year. > > Are you offering to track down those people? And write to his > family to find out who owns his software (I'm sure they won't > know), and ask for their permission? How good's your German, by > the way? I have no clue if his family speaks English well enough > to understand the nuances of GPLv2 vs. GPLv3. Or at least the > notation of changing a software license, where both licenses > essentially say the same thing[1]. > > [1] yes, you and I know the differences, but normal people have a > hard enough concept with "I'll share this software with you if you > share it with others". Yes, I'm prepared at some point to attempt this task. That's not a cop-out; it's just that I want to see how much we can do _without_ that tracking-down before I go down that particular difficult route. More on that to follow. > Really? Line 22 says "Version 2, June 1991" to me. How exactly > do you propose to change the COPYING file? I propose to add text closer to the statement recommended by the FSF/GNU foundation and by the GPL itself: GNU Lilypond is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. ... plus some further explanatory text that will probably be close to what the existing file says. Perhaps also a line emphasising the licensing situation (i.e. v2 only) as the Linux kernel COPYING file does, and a note explaining how we are attempting to change the licensing situation. >> (v) the link on the main page which (still) points to the >> text of GPLv3 on gnu.org (and has ever since v3 was >> released -- the first message pointing out this >> discrepancy was sent to the -devel mailing list over >> 2 years ago!). > > This is fixed on the new website. But not on the current one, which is still live ... :-) >> In addressing this there are several policies that can be put in place NOW: >> >>(1) All new files added to the code or docs must contain an >>unambiguous copyright AND licensing notice: I suggest in this >>case GPLv2 or later for code, and the GFDL 1.1 or later for docs. > > I really don't see why we MUST do this. Is there any legal > requirement that every single file contain the license? I'm not > aware of any. Material is copyright by default. Sure; this is just a useful policy to have (and maintain) because it clarifies the licensing situation on a file-by-file basis. >>(2) Contributors of new material to existing files should add >>copyright/licensing notices *for their contributions*, again with >>appropriate 'or later' bits. > > That's going to get ridiculous. We should add a name for each > one-line bugfix? No. My statement was not clear enough. There are guidelines on this in the 'Information for Maintainers of GNU Software': http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant A change of just a few lines (less than 15 or so) is not legally significant for copyright. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places. Keep in mind, however, that a series of minor changes by the same person can add up to a significant contribution. What counts is the total contribution of the person; it is irrelevant which parts of it were contributed when. >>(1) How well have the copyright notices for individual files been >>maintained? > > Not. > >> Do they refer only to original authors of files >>or all authors over that file's history? (More precisely: is >>there not just a list of who contributed to LP but also who >>wrote exactly what?) > > Original authors of files. Look at the git log for more details. Yup, as I discovered after a few sessions with git annotate. :-) >>(2) Is there a preference for transferring copyright to some third >>party (either the FSF or some LP-dedicated organisation)? If >>not, it seems a good idea for future contributions to LP to be >>'or later', as it avoids a repeat of this issue in the future. > > This has been discussed privately, and might occur if the > copyright-fixing issue is undertaken seriously. Personally I'm not in favour of copyright-transfer agreements, I
Re: Overview of copyright issues + Debian
Travis Briggs wrote: > The source material could be public domain, but the snippet itself is > a 'derivative work' and is thus under the copyright of whoever made > it. What I recall from submitting to LSR was that I was asked to agree that by submitting this snippet, I was (a) consigning it to the public domain and (b) had the right to do so. As Valentin says, public domain is not a license, but public domain is arguably the optimal copyright status for most musical examples given in the documentation. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Reinhold Kainhofer wrote: > Because they are not allowed by copyright law. They cannot change the license > if the file is only "mostly" their work. They can only change the license if > the file is SOLELY their work. Well, technically they can release their bit of the file under their own license, as long as it is compatible with the original. What they can't do is unilaterally rewrite the license for the whole file (see the whole mess last year when some guy working on the Linux kernel rewrote the licensing notice for a file copied from the BSD kernel). Having a 'one license per file' rule just makes things simpler, is all. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues + Debian
Don Armstrong wrote: > This is now my problem,[1] so I'll attempt to get it addressed at some > point in the future. [I'd certainly like to see Lilypond at least > clear up some of the issues so that the above can become correct.] Hmm, I noted you were listed as the Debian maintainer on Launchpad's Lilypond page, and brain went off: "The same Don Armstrong as ... ?" Nice to have you involved in this discussion (and congratulations on getting your PhD). Disclaimer: I'm a relatively new contributor to (but long-time user of) Lilypond, so what I say are my own thoughts and I don't speak for the Lilypond developer community. But, since I'm putting myself forward to try and deal with some of this, any advice you can give would be very welcome. From my point of view the DFSG are a very nice benchmark against which to test code and doc licensing and compatibility is an important aim. > (There are a significant number of files distributed in lilypond which > are under v2 or later, or v3 or later, as well as things like > input/mutopia/claop.py, which isn't even Free Software, as it cannot > be modified.[2]) If I'm not mistaken, isn't that file only used for a regression test? How does that affect the situation? > Furthermore, the licensing statement in COPYING is immensely > ambiguous, as it only states "GNU PUBLIC LICENSE" without specifying a > version, or anything. > >> (1) All new files added to the code or docs must contain an >> unambiguous copyright AND licensing notice: I suggest in this >> case GPLv2 or later for code, and the GFDL 1.1 or later for >> docs. > > I'd personally prefer it if documentation was at least licensed under > the same license as the code to allow for easily inclusion of code > examples (and to obviate the problems I [and Debian] have with > specific aspects of the GFDL.) It certainly can be dual licensed under > GFDL >= v1.1 + GPL >= v2, though. AFAIK the docs have always been GFDLv1.1 -- I don't think we can unilaterally relicense them. Can you clarify the particular issue with GFDL? I thought the Debian consensus was that GFDL is OK as long as there are no invariant sections. What does GPL imply for docs? Would it mean e.g. that someone who distributes a PDF of the Learning Manual would have to also be prepared to provide Texinfo sources? >> (1) How well have the copyright notices for individual files been >> maintained? > > As near as I can tell, they haven't been maintained at all. Very few > of them actually have the boilerplate that they should have, which > makes this kind of thing very difficult. > > But by all means, please help work on this. It'll certainly make my > life easier when I have to go through and audit the code for inclusion > in Debian (which I naïvely assumed had already been done before I took > over maintenance.) What I have noted is that copyright dates have been updated but I'm not clear whether author names have. What I propose is that I maintain a separate branch of the code (but keep pulling/rebasing against the Lilypond master) to insert appropriate copyright and licensing notices. git blame should help to give a better idea of who has contributed to what, so I can fire of queries to authors where necessary. What would be good is if as many contributors as possible can reply to this email just to OK (i) my putting copyright/licensing notices in the files they have contributed to and (ii) their licensing preferences for their contributions: -- for code, GPLv2 only or GPLv2 or later; -- for docs, GFDLv1.1 or later and/or GPLv2 or later; -- freer licenses (BSD/MIT-style, or donated to the public domain). I think that snippets are already public domain since it's a condition of submission to LSR. I have Han-Wen's OK already for his contributions, but would like others. :-) Now, future policies -- I would suggest new contributions be requested to follow these rules: -- for code, GPLv2 or later or a more liberal compatible license; -- for docs, GFDLv1.1 or later/GPLv2 or later dual license (or more liberal compatible license); -- when altering a file that already exists, use the same license as for the rest of that file (so if someone contributes a code file under a BSD/MIT-esque license, anyone who adds to that file uses the same); -- patches that make a significant alteration to a file should add the author's name to the copyright notice -- new files should be required to carry a copyright and licensing notice when added to the source code. Note that if all this goes OK, we should then be OK to unilaterally upgrade to GPLv3 (if that's desired). Does this sound good to everyone? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: > In GNU projects, the normal thing is that contributors sign a paper > which is sent in to GNU that they donate the code to GNU. Nope. "For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you." from: http://www.gnu.org/help/evaluation.html#whatmeans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Han-Wen Nienhuys wrote: > I think having to sign paperwork (esp. having your employer sign > something) is something that puts a big barrier up for potential > contributors. I am not sure it is worth the effort. I would not want to see users in general having to sign a contributor agreement or any such. What does seem like a good idea is moving existing code from 'v2 only' to 'v2 or later' (or v3 if desired), because that takes a lot of the sting out of potential future license upgrade decisions. I don't know whether that needs formal paperwork or whether emailed permission will suffice (again, allowing for the fact that LP contributors are most likely not interested in suing over such factors:-) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Han-Wen Nienhuys wrote: > Jan and I know that the current situation wrt copyright headers and > license notes is not ideal, but we never could bring ourselves to fix > it, because there always were more important things to do. > Nevertheless, if someone feels energetic to take this on, they have my > blessing. Well, I'm happy to go fix the actual files, just not sure what the precise legal ramifications of this are. I mean, if _I_ change the copyright notice in a file that is _your_ copyright ... :-) But anyway, I'm willing to do the typing side of it. I just need you to clarify exactly what I should put: presumably GPLv2 for code files and GFDLv1.1 for docs are the base licenses, but would you and Jan approve putting GPLv2 or later for your own contributions? What are your thoughts (and recommendations) for code written by others? I know that you ran into a paperwork issue some time back that has never been resolved. I'd consider taking on the paperwork side as well (not right now, maybe a month or two from now) but I want to try and to as much as possible of what can be done without it. What I could suggest as an approval mechanism is for individual authors to 'sign off' the patches (as git allows) that add licensing notices to their files, to show that they consent to what has been put there. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Reinhold Kainhofer wrote: > ... which I'm sure will NOT hold up in court, so I propose we really end this > discussion. Please leave the lawyering to the lawyers and lets go back to > coding. Please understand the motivation for OPENING this discussion -- not to debate which license or what license, but to propose a few concrete things the LP coding team can do to clarify licensing and (perhaps) make it easier to upgrade the license if that's desired. I particularly think it would be a good idea to make sure that all files in the source tree -- code and docs -- have both copyright and licensing statements in them. More particularly, does anyone object to me adding a GFDL 1.1 or later notice to the doc files I have written? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: > The point is that if you want to be up-to-date with latest GPL in both > new restrictions and permissions, the only way to do it is to refer to > the latest version when the source is published. "Or later" will admit > later restrictions, "or latest" will impose them quietly on old sources. No, it won't, because if a piece of code has been released under particular license conditions (say, GPLv2) you can't revoke that. You can't rewrite the license for old sources -- you can only upgrade the license for new releases. And for that, 'or later' is a much better formulation than 'or latest', because it also allows you to choose NOT to upgrade if that is your desire or interest. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: > As long as you use "or later", tivoization and other new restriction in v3 is > allowed. No, as long as you use _GPLv2_, whether it's GPLv2 or later or GPLv2 and only GPLv2, tivoization is possible. 'GPLv3 or later' would not allow tivoization. > It is probably simplest to just make sure that the latest GPL is copied > into the lilypond sources by some semi-automated scheme. Unless you have an 'or later' cause already in place, or you have the permission of the copyright holders, you cannot unilaterally substitute GPLv3 for GPLv2. That's what the whole problem is about. I don't see much point in continuing this discussion further because I don't think you understand what the real problems (or solutions) are, or what the requirements of the GPL (in any version) are. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: > You might check with the GNUers if it is the intention. It means that > sources can be tivoized, even in the face of the new v3. It's GPLv2, and not the 'or later', that allows for tivoization -- but you have to question whether this is a serious risk for Lilypond. > Linking is always allowed if you make sure the interfaces are provided > and other linking info is provided - copyright only controls > distribution of the parts that makes it creatively unique, and v3 seemed > to have changed over v2 to bring that out. There is no legal requirement > that the parts should have the same license. The parts need a compatible license if one links to the other. GPLv2 and GPLv3 are not compatible licenses. That's why the 'or later' is important -- it allows that compatibility. > But it has the effect that sources that formerly have been OK to > distribute may not be so. For example, if they are tivoized, then when > the GPL v3 now has arrived, the old sources cannot be tivoized, even if > the package itself has not been changed. > > On the other hand, the formulation "or later" means that new sources can > be tivoized even if the new version v3 has been released, unless they > explicitly mention v3. Again, the 'or later' has nothing to do with tivoization. It's GPLv2 that allows for that possibility (which, again, is not likely). If Lilypond does switch to GPLv3 I would strongly argue for a 'GPLv3 or later' formulation, to avoid this problem arising again if a further GPL revision is released. I don't think it matters much whether Lilypond moves to GPLv3 because most of the risks that GPLv3 is designed to obviate are unlikely to arise in the case of Lilypond. I _do_ think it matters that Lilypond be released under license terms that are compatible with GPLv3 and future potential releases of the GPL. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Matthias Kilian wrote: > On Wed, Sep 09, 2009 at 06:04:17PM +0200, Joseph Wakeling wrote: >> So, having read the past discussion and looked through source code etc. >> it seems like there are several general observations, some conclusions, >> and some questions. >> >> Observations: >> >>(1) Lilypond isn't violating any copyright/license requirements. > > So what's the point of this discussion? Part is that there's some general consensus that it would be nice to move Lilypond to GPLv3, or at least to have the chance to do so. Hence some of the practical points on how to make that easier. The other part is that there are some aspects of the way Lilypond code and docs are managed with respect to licensing that are confusing or problematic -- lack of licensing notices in source code, lack of copyright or licensing notices in docs. Those really should be fixed and better practices established for maintaining them. I would see that as pretty urgent actually, far more important than the 'what license?' question, because it relates to LP's ability to track who wrote what and which conditions they made it available under. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overview of copyright issues
Hans Aberg wrote: > I think that the formulation should be "GPL, v2 or latest", because > otherwise those that want to redistribute the code can choose which > version, which is not the intent - v3 is in fact more restrictive with > respect to tivoization. Only one GPL should be applicable. The > formulation "or later" is probably spilled usage when indicating which > version can be used - then it means one can choose version. The standard formulation, as advised in the GPL appendix which describes how to apply the GPL to your programs, is This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The whole point of this formulation is to give users of the program the option to choose which version of the license they want to be bound by if they redistribute or modify the code, and in particular to make it easy for a project to upgrade the license OR NOT. > This formulation also means that the distribution conditions may change, > even though the copyright notice is not changed of a package, when new > version of the GPL are issued. I think that is fully legal. The problem with your formulation is that it is too restrictive. Consider this scenario: a program is being distributed as 'GPLv2 or latest' as you suggest. Someone writes a GPLv3 program which links with that code (as they are allowed to do at that point). Now Version 4 of the GPL is released. Suddenly the person with the second program can no longer keep linking to new releases of the first one, because 'GPLv2 or latest' now means v2 or v4 and neither v2 nor v4 are compatible with v3. It's a scenario that is completely undesirable. 'or later' basically is about making sure that writers of programs using all future versions of the GPL will have the right to link to or incorporate your code (as well as being handy if, as a community, you decide you want to upgrade the license). ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Overview of copyright issues
So, having read the past discussion and looked through source code etc. it seems like there are several general observations, some conclusions, and some questions. Observations: (1) Lilypond isn't violating any copyright/license requirements. There's no LEGAL pressure to switch to GPLv3, although there may be issues related to Lilypond's status in the GNU project. (That said, the longer we leave the situation as it is, the more likely a legal issue WILL arise.) (2) The intention of the original authors, and the strict interpretation of the COPYING file, is that Lilypond is GPLv2 only. (3) Individual code files contain copyright notices but not licensing notices. It's not clear if these notices have been maintained beyond updating the date -- have author names been persistently added where appropriate? (Most the files have a single author listed; the one two-author file I saw was by Han-Wen and Jan.) (4) Individual documentation source files (.itely files) in general contain neither copyright notices nor licensing notices. (5) We have a full list of contributors to Lilypond but need to have PAPER documentation giving their permission to change the license of the code/documentation they wrote. (6) Confusion has come from (i) a Debian copyright file for the package, apparently last updated in 2004, stating that Lilypond is 'v2 or later' (ii) the fact that the Lilypond COPYING file, while describing the licensing situation accurately, does so in non- standard language (people expect to see the statement recommended in the GPL appendix, which allows for unambiguous distinction between 'vN or later' or 'vN') (iii) the lack of licensing notices within code and documentation (iv) GNU recommendations that GNU packages always use the latest version of the GPL (v) the link on the main page which (still) points to the text of GPLv3 on gnu.org (and has ever since v3 was released -- the first message pointing out this discrepancy was sent to the -devel mailing list over 2 years ago!). In addressing this there are several policies that can be put in place NOW: (1) All new files added to the code or docs must contain an unambiguous copyright AND licensing notice: I suggest in this case GPLv2 or later for code, and the GFDL 1.1 or later for docs. (2) Contributors of new material to existing files should add copyright/licensing notices *for their contributions*, again with appropriate 'or later' bits. (3) For files with single authors, those same authors can send patches containing explicit licensing notices for their files. If those licensing notices are GPLv2 or later (which they can do unilaterally since they are sole authors) that solves problems for a good part of the code. (4) It's still a good idea to get appropriate paperwork from EVERY contributor but with the above done we have a much less heavy amount of OBLIGATORY work. Questions: (1) How well have the copyright notices for individual files been maintained? Do they refer only to original authors of files or all authors over that file's history? (More precisely: is there not just a list of who contributed to LP but also who wrote exactly what?) (2) Is there a preference for transferring copyright to some third party (either the FSF or some LP-dedicated organisation)? If not, it seems a good idea for future contributions to LP to be 'or later', as it avoids a repeat of this issue in the future. OK, I think that's the lot. Thoughts/disagreements/comments anyone? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: kainhofer docs not updating
John Mandereau wrote: > Le mardi 08 septembre 2009 à 12:30 +0200, Joseph Wakeling a écrit : >> I note that texi2html is only 1.78 on my system (it's the version native >> to Ubuntu Karmic). Is this going to be a blocker? > > If you want HTML output of the documentation, yes. OK, that's tolerable. doc-stage-1 now builds successfully, so I can check the PDF and the correctness of the markup. HTML is not absolutely necessary. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
I wrote: > Second: Lilypond is part of the GNU project and GNU programs typically > have the 'or later' option, and indeed there is a perception that they > will upgrade to the latest GPL by default. ... see the general information on making a package part of the GNU project: http://www.gnu.org/help/evaluation.html "A GNU program should use the latest version of the license that the GNU Project recommends—not just any free software license." ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
Jan Nieuwenhuizen wrote:
> Op dinsdag 08-09-2009 om 13:16 uur [tijdzone +0200], schreef Jan
> Nieuwenhuizen:
>
>> Not only out-of-date, but also /wrong/. I just checked our sources,
>> a very early one and the one that was claimed to be packaged
>>
>>git show release/{1.0.1,2.2.2}:{COPYING,main.cc}
>
> git show release/{1.0.1,2.2.2}:{COPYING,lily/main.cc
There are several possible sources of this confusion.
First: nowhere in the LP source can I find the typical notice that the
FSF recommends/requests in the 'How to Apply These Terms to your new
program' appendix to the GPL.
The notice in the COPYING file is technically unambiguous but is so
atypical as to not necessarily be clear.
Second: Lilypond is part of the GNU project and GNU programs typically
have the 'or later' option, and indeed there is a perception that they
will upgrade to the latest GPL by default.
Third -- and this is really important: Lilypond's source code and other
files lack often copyright/licensing notices. This is explicitly
contrary to the policies of the GNU project:
http://www.gnu.org/prep/maintain/html_node/License-Notices.html#License-Notices
I gather there is a complete list of Lilypond contributors but are there
records of who contributed what?
Best wishes,
-- Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
Jan Nieuwenhuizen wrote: > Op dinsdag 08-09-2009 om 12:34 uur [tijdzone +0200], schreef Joseph > Wakeling: > >> The >> copyright file in my distro (Ubuntu) refers to GPLv2 or later > > Which file are you referring to, and what does it say? /usr/share/doc/lilypond/copyright Its contents: This package was Debianized by Anthony Fok on Wed, 6 Aug 1997 04:30:28 -0600 The development branch, lilypond1.3, was packaged separately on Tue, 9 Nov 1999 22:30:32 -0700 but was merged back into the lilypond package as of Mon, 16 Apr 2001 21:58:42 -0600 It was downloaded from http://lilypond.org/download/v2.2/lilypond-2.2.2.tar.gz For more information about GNU LilyPond, please visit: http://lilypond.org/ Authors: Han-Wen Nienhuys Jan Nieuwenhuizen Copyright: GNU LilyPond is Copyright (C) 1996--2004 Jan Nieuwenhuizen & Han-Wen Nienhuys This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. *** NOTE This license applies to all files except the included example input files (which are in the subdirectory input/ ) *** END NOTE All the other scripts and control files for building and installing GNU LilyPond under Debian GNU/Linux are also under the GNU General Public License (GPL) version 2 or later. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. I didn't read it properly before, but it looks like a severely out-of-date notice added by the Debian packager which no one has ever bothered to revise. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: kainhofer docs not updating
John Mandereau wrote:
> Le mardi 08 septembre 2009 à 12:30 +0200, Joseph Wakeling a écrit :
>> [century_schoolbook_l_serif_3.0673828125]Segmentation fault (core
>> dumped)
>> command failed: /home/myusername/code/lily/out/bin/lilypond
>
> What is the snippet that causes a segmentation fault?
It's trying to build BUILD-DIR/out/lybook-db/snippet-names--494188324.ly
whose content is:
snippet-map--494188324.ly
c3/lily-e7ee339b.ly
98/lily-8b8d1acf.ly
The two snippets are respectively as follows:
%% Generated by lilypond-book.py
%% Options: [alt=[image of
music],printfilename,indent=0\mm,texidoc,line-width=160\mm]
\include "lilypond-book-preamble.ly"
%
% Start cut-&-pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
force-assignment = #""
line-width = #(- line-width (* mm 3.00))
}
\layout {
}
%
% ly snippet:
%
\sourcefilename "page-spacing-system-count-overfull.ly"
\sourcefileline 0
\version "2.13.4"
\header {
texidoc = "Page breaking doesn't crash when the line-breaking
is invalid."
}
\book {
\paper {
system-count = #1
}
\repeat unfold 20 { c d e f }
}
%
% end ly snippet
%
%% Generated by lilypond-book.py
%% Options: [alt=[image of
music],printfilename,indent=0\mm,texidoc,line-width=160\mm]
\include "lilypond-book-preamble.ly"
%
% Start cut-&-pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
force-assignment = #""
line-width = #(- line-width (* mm 3.00))
}
\layout {
}
%
% ly snippet:
%
\sourcefilename "warn-unterminated-span-dynamic.ly"
\sourcefileline 0
\version "2.13.4"
#(ly:set-option 'warning-as-error #f)
\header {
texidoc = "A warning is printed if a dynamic spanner is
unterminated."
}
<<
\new Staff {
% warning expected: unterminated crescendo
c'1\<
}
\new Staff {
% warning expected: unterminated decrescendo
c'1\>
}
>>
%
% end ly snippet
%
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copyright issues
John Mandereau wrote: > Even if any program in LilyPond linked with gs, we'd have no problem > since LilyPond is licensed under GPLv2+ (GPL v2 or later). > > Please correct me if I'm wrong. That was the point of the re-opening of discussion -- my query on that very point in relation to the new website design. The COPYING file in Lilypond source code references GPLv2 only. The copyright file in my distro (Ubuntu) refers to GPLv2 or later, which may be where confusion comes from. Past discussion on -devel notes that LP is v2 only and the difficulty comes from the paperwork needed to get permission from contributors to move to 'v2 or later' or 'v3 or later'. By the way, I note that individual source/documentation files often have no notice of copyright or license. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
