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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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,
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
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
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 ?
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
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
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
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)
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
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
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
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
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
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
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
On 07/08/2010 10:25 PM, Neil Puttock wrote:
On 8 July 2010 19:47, Joseph Wakeling joseph.wakel...@webdrake.net 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
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
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
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
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
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
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 ...
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
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
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
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.
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
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
Graham Percival wrote:
On Tue, Feb 23, 2010 at 2:49 PM, Hans Aberg hab...@math.su.se 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
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
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
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 ... ?
information.
Best wishes,
-- Joe
From 0b16d7c2d074eeb8f33ed77494bdd26ef9b182db Mon Sep 17 00:00:00 2001
From: Joseph Wakeling joseph.wakel...@webdrake.net
Date: Tue, 12 Jan 2010 15:42:04 +0100
Subject: [PATCH] Information on sending/receiving git patches via email.
This contains the solution
.
Best wishes,
-- Joe
From 63a650c550357fd2372370db49e0676f1a79420f Mon Sep 17 00:00:00 2001
From: Joseph Wakeling joseph.wakel...@webdrake.net
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
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
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,
2001
From: Joseph Wakeling joseph.wakel...@webdrake.net
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
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.
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
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
that license.
Best wishes,
-- Joe
From d1ee19e7d7dd10d0504ebec2a621d675087f0f70 Mon Sep 17 00:00:00 2001
From: Joseph Wakeling joseph.wakel...@webdrake.net
Date: Sun, 20 Sep 2009 15:58:09 +0200
Subject: [PATCH] COPYING rewrite to clarify licensing.
* Text is closer to FSF guidelines and explicitly
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
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
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 ...
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
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
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
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
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
From: Joseph Wakeling joseph.wakel...@webdrake.net
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
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 joseph.wakel...@webdrake.net
Date: Sat, 12 Sep
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
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
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 joseph.wakel...@webdrake.net
Date: Fri, 11 Sep 2009 10:58:26 +0200
Subject: [PATCH] Doc: copyright/licensing notice
Francisco Vila wrote:
2009/9/11 Francisco Vila paconet@gmail.com:
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
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
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
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
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,
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
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
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' ... ?
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
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
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
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
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
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
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
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
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
John Mandereau wrote:
Le dimanche 06 septembre 2009 à 09:30 +0200, Joseph Wakeling a écrit :
I'm not sure how to interpret what's there -- presumably that only a
subset of the intended output has been written to collated-files.pdf?
As Graham pointed out, you didn't paste the relevant part
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
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
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}
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:
Graham Percival wrote:
In the case of Arabic music, I think part of the argument (in
favor) was that the notation isn't standard, but the author(s) did
the best they could, and people interested in seeing the
inconsistencies can progress to X, Y, and Z. It's also only one
page... I could see
Reinhold Kainhofer wrote:
It might help to look into said log file... Usually, the error messages
towards
the end will tell you something about the problem.
I'm not sure how to interpret what's there -- presumably that only a
subset of the intended output has been written to
Graham Percival wrote:
Umm, I was joking. Well, kind-of joking. Yes, that's the only
way you can do it, but no, I don't recommend it. I don't think
that Joseph is desperately awaiting HTML output... actually, I'm
pretty certain he builds them himself, anyway. And he's the only
person
c7c98441d1a51963d33b84cf6bf4b20c5b98e1a0 Mon Sep 17 00:00:00 2001
From: Joseph Wakeling joseph.wakel...@webdrake.net
Date: Sat, 5 Sep 2009 22:30:58 +0200
Subject: [PATCH] Doc: Further Reading for contemporary music.
---
Documentation/notation/contemporary.itely | 50 +
1 files changed
1 - 100 of 121 matches
Mail list logo