Re: Directory structure for docs and web site
On Tue, Jul 21, 2009 at 07:45:28PM +0200, John Mandereau wrote: I have a naive question with not so naive implications about the current shape of docs reorganization: what is the planned directory structure for the new web site? Do we want to make a clear distinction between the site and the docs in the URL, i.e. do we keep web/ and doc/v2.*/? I would personally remove the web/, and have things like lilypond.org/introduction.html lilypond.org/doc/v2.x/ lilypond.org/download/ lilypond.org/tiny_examples.html along with whatever redirects are desirable. I'm a bit confused by the below discussion; it makes no mention of the lilypond-general texinfo in master, lilypond-general imported into web repo, web built separately proposal. Does this fall under #1 or #2, or would you rather discuss it as a #3? 1) Keep the full web site away from Lily main source tree, i.e. on web branch. Are you using full web site as in the complete web site, including google analytics numbers, or full web site as in anything to do with the web site? I still think the texinfo files should be in master, but perhaps not the generated images, and not some really web-specific stuff like the htaccess. I'm honestly not certain if this fits into #1 or not. This implies that nothing of the web site requires compilation of ly snippets, e.g. Examples should be reintegrated into Documentation as a Texinfo document. No; Examples can stay exactly the way it is. It uses @image to include png files. This involves no compilation of ly snippets. I have *never* proposed, nor supported, the use of @lilypond for the website (or lilypond-general). Pros: clear separation of the web site (which is for all Lily versions) and the docs (which is version-specific). And as long as the texinfo files are in master, this still allows the building of an offline lilypond-general document for the doc tarball. 2) Merging the web site into LilyPond sources, with all problems of directory strucutre in mind that wouldn't happen without this merge. Pros: simple cross-references, easier use of ly snippets in the web site. Cons: merging the web site of the branch that actually hosts the web site into the other one, at least every time the latter branch is released (in order to distribute an up-to-date web site), potentially unclear distinction of what is precisely built on lilypond.org, more cluttering of Git history. ... now it looks like the import texinfo files from another repo fits better into #2. If the editing of texinfo is in main, then the git history is no more cluttered than any other manual. Due to our tight linkage of documentation and source (which, given the pace of development, is unavoidable), the git history is *already* cluttered up with Doc: a few minor edits or Doc: CG: clarify git instructions on windows. Not to mention all the translation updates! I can't imagine that adding a few Web: beautify contemporary rhythms example or Web: announce new version (especially if that was included in a bump VERSION update!) would complicate matters more. The precise building of what's on lilypond.org should be fairly clear: it is built from the web repo, with the exception of /doc/2.x/, which is built from the relevant branch of main. This wouldn't change at all from the current web-building process. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directory structure for docs and web site
Le mardi 21 juillet 2009 à 23:57 -0700, Graham Percival a écrit : I would personally remove the web/, and have things like lilypond.org/introduction.html lilypond.org/doc/v2.x/ lilypond.org/download/ lilypond.org/tiny_examples.html along with whatever redirects are desirable. I agree with this. I'm a bit confused by the below discussion; So am I :-) it makes no mention of the lilypond-general texinfo in master, lilypond-general imported into web repo, web built separately proposal. Does this fall under #1 or #2, or would you rather discuss it as a #3? This falls under #2. In my mind lilypond-general will be almost all of the web site; using Texinfo for it makes integrating it into main sources is the most reasonable solution. 1) Keep the full web site away from Lily main source tree, i.e. on web branch. Are you using full web site as in the complete web site, including google analytics numbers, or full web site as in anything to do with the web site? The (future) full web site refers to lilypond-general plus whatever will remain on web branch. I still think the texinfo files should be in master, but perhaps not the generated images, and not some really web-specific stuff like the htaccess. If lilypond-general (which includes examples) contains LilyPond music examples, generated images can (and probably should IMHO) be lilypond files or @lilypond blocks that are built along with the docs. I'm honestly not certain if this fits into #1 or not. It doesn't. I can't imagine that adding a few Web: beautify contemporary rhythms example or Web: announce new version (especially if that was included in a bump VERSION update!) would complicate matters more. Not significantly, you're right. The precise building of what's on lilypond.org should be fairly clear: it is built from the web repo, with the exception of /doc/2.x/, which is built from the relevant branch of main. This wouldn't change at all from the current web-building process. Except that HTML pages from lilypond-general are moved from /doc/2.x to /. As the Texinfo docs structure will be greatly simplified, this is an acceptable amount of hacking :-) Now it's more clear which direction we follow, I can comfortably get back to hacking makefiles and moving files. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docs and new web site reorganization steps
As the changes involved by the new web site are quite large and invasive, I try to give steps so you are not too surprised by what's going on with dozens of files suddenly moved or temporarily broken HTML links. Please report any breakage in case I haven't explicitly mentioned it in a commit (this will be soft breakage as much as possible, i.e. the docs will hopefully still build). Step 1) Move all Texinfo documentation in user/ and topdocs/ one directory higher (done in my working tree), in translations too. Step 2) Update all build and maintenance scripts and the CG. At the end of this step docs should be in a releasable state again. Step 3) Move Snippets and split out the essay (including CG updates). Step 4) Integrate lilypond-general and work on web branch to set up the new web site. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] autochange.scm: Use averaged chord pitches to determine staff.
In NR 2.2.1 Changing staff automatically, it says this:
Chords will not be split across the staves; they will be assigned
to a staff based on the first note named in the chord construct.
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Common-notation-for-keyboards.html#Changing-staff-automatically
Actually, this is not true; they are assigned to a staff based on
the *last* note named in the chord construct. The reason is that
in scm/autochange.scm, the NOTES variable referenced on line 17
ultimately comes from a *reversed* context-list (see line 38).
Anyway, I think that it would make a lot more sense if the staff
were determined by the average pitch of the chord. And, I think
I've solved this in the attached patch.
I've also attached 2 png's to demonstrate the difference: the
first one (current.png) was compiled with the current
autochange.scm and the second one (revised.png) was compiled with
my revised patch. You can look at the test file below to see how
it is set up.
Would anyone like to comment?
Are there any objections to me applying it?
Thanks.
- Mark
___
\version 2.13.2
uppersFirst = \relative {
b g8 c g c a d a
d b e b e c f c
f c e c e b d b
d a c a c g b g
}
lowersFirst = \relative {
g b8 g c a c a d
b d b e c e c f
c f c e b e b d
a d a c g c g b
}
\new PianoStaff \autochange \uppersFirst
\new PianoStaff \autochange \lowersFirst
___
0001-autochange.scm-Use-averaged-chord-pitches-to-determi.patch
Description: Binary data
attachment: current.pngattachment: revised.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.
I've also attached 2 png's to demonstrate the difference: the first one (current.png) was compiled with the current autochange.scm and the second one (revised.png) was compiled with my revised patch. You can look at the test file below to see how it is set up. The results looks fine for me; regarding the implementation, I won't comment since my Scheme skills are too limited. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Docs and new web site reorganization steps
Fingers crossed. 2009/7/22 John Mandereau john.mander...@gmail.com: As the changes involved by the new web site are quite large and invasive, I try to give steps so you are not too surprised by what's going on with dozens of files suddenly moved or temporarily broken HTML links. Please report any breakage in case I haven't explicitly mentioned it in a commit (this will be soft breakage as much as possible, i.e. the docs will hopefully still build). -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.
Mark Polesky markpole...@yahoo.com writes: Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. I don't think so. The purpose of staff changes is to avoid help lines. In particular where they would require systems to be paced further apart. For this, the average is irrelevant, only the total range (top and bottom note lines) is of interest. A staff change is a drastic measure: one will not typically do it unless more than two help lines would otherwise occur. So it is really a matter of the total vertical extent (after considering the signature, so an f flat counts as higher as an e sharp, never mind that its pitch is lower) and not the pitch average. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.
At 10:50 on 22 Jul 2009, David Kastrup wrote: Mark Polesky markpole...@yahoo.com writes: Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. I don't think so. The purpose of staff changes is to avoid help lines. In particular where they would require systems to be paced further apart. For this, the average is irrelevant, only the total range (top and bottom note lines) is of interest. A staff change is a drastic measure: one will not typically do it unless more than two help lines would otherwise occur. So it is really a matter of the total vertical extent (after considering the signature, so an f flat counts as higher as an e sharp, never mind that its pitch is lower) and not the pitch average. I presume by help lines you mean ledger lines? But you're correct that neither the average pitch or even the average pitch of the outer notes of the chord is enough. Consider the following: d' f'8 b, f' d' f' b, f' Clearly this would be best set in the bass clef, however the average pitches (e', gis) would (probably) result in it swapping between the two staves. So it's actually the extremity of the chord in the direction of potential staff change that is of primary importance. -- Mark Knoop ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.
Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. I don't think so. The purpose of staff changes is to avoid help lines. Perhaps it makes sense to provide different `modes', depending on the purpose. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request (concerning midi-output)
2009/7/21 Werner mey@web.de:
\midi {
\context {
\Score
% harmonies = ##f
% (output all voices but no harmonies from chordNames!)
}
}
There's already a way to do it. Try something such as
\midi {
\context {
\type Performer_group
\name ChordNames
\consists Swallow_performer
}
}
Regards,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.
Mark Polesky wrote Wednesday, July 22, 2009 8:32 AM In NR 2.2.1 Changing staff automatically, it says this: Chords will not be split across the staves; they will be assigned to a staff based on the first note named in the chord construct. http://kainhofer.com/~lilypond/Documentation/user/lilypond/Common-notation-for-keyboards.html#Changing-staff-automatically Actually, this is not true; they are assigned to a staff based on the *last* note named in the chord construct. The reason is that in scm/autochange.scm, the NOTES variable referenced on line 17 ultimately comes from a *reversed* context-list (see line 38). Clearly this needs to be corrected. Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. And, I think I've solved this in the attached patch. I've also attached 2 png's to demonstrate the difference: the first one (current.png) was compiled with the current autochange.scm and the second one (revised.png) was compiled with my revised patch. You can look at the test file below to see how it is set up. Would anyone like to comment? Are there any objections to me applying it? Yes and yes. I think this would not result in an improvement in the general case. In a passage in which the average fluctuated rapidly above and below middle C too many staff switches would be generated. The present scheme does not do this as (in a chord) you can choose to have the based on the higher or lower note depending on the order in which they appear. This probably offends your semantic sensibility though ;) Actually a scheme based the switch on the position of either extreme of the chord would be an improvement, which extreme being specified, and would restore the correct semantics :) Also being able to specify a lower limit on the number of notes/chords permitted on the staff to be switched to, to prevent short runs, would also be useful. - Mark Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.
On Wed, Jul 22, 2009, Trevor Daniels t.dani...@treda.co.uk said: Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. And, I think I've solved this in the attached patch. What would make the most sense is to consider the range of the intended instrument. music for a mid-range instrument (eg classical guitar) is conventionally presented on the same suboctave G clef a tenor vocalist uses. Some music for low brass and winds uses c-3, c-4, and f-4 clefs. Hopefully these automatic clef changes are an optional feature, many players find any clef change annoying. Also being able to specify a lower limit on the number of notes/chords permitted on the staff to be switched to, to prevent short runs, would also be useful. What of music contrasting the extremitys of a pianos keyboard, is it always going to be coded as two strains of polyphony? (left hand vs right). If coded for one hand, no changes at all are apropriate there, just alternation as to which half of the combined staff is employed (allowing some few ledger lines). Look to the earliest publications of Ottaviano Petrucci (Canti C, Canti B, Odhecaton), available in facsimile at the best music libraries (and direct from Broude Brothers if you care to purchase) for examples of how rare clef changes were even when movable C clefs were the norm. Initial clef should be chosen based on overall range, proposed changes should be evaluated in the light of ledger line use. Knowledge of the intended instrument and modern/classical scribal conventions could expand the range of clef choices. Such fun devising heuristics. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.
Wow. Thanks for all the replies. I'll answer one at a time, all below. David Kastrup wrote: I don't think so. The purpose of staff changes is to avoid help lines. In particular where they would require systems to be paced further apart. For this, the average is irrelevant, only the total range (top and bottom note lines) is of interest. A staff change is a drastic measure: one will not typically do it unless more than two help lines would otherwise occur. So it is really a matter of the total vertical extent (after considering the signature, so an f flat counts as higher as an e sharp, never mind that its pitch is lower) and not the pitch average. First, I'm sorry that I was not more accurate. I should have said average staff-position, because the actual sounding pitch (as well as any accidentals anywhere) is totally irrelevant here. Middle C can be thought of zero. D is 1, E is 2, B is -1, A is -2. Accidentals are completely ignored. So D-double-sharp is 1 and E-double-flat is 2. So the average staff-position between C and E is 1, and the average staff-position between B and E is 0.5. However, non-integer values crash the function, so they need to be rounded. The crucial specification is that if the staff-position average is between -1 and 1, but is *not* zero, than it cannot be rounded to zero. So the result of the averaging will be 1 for b e and -1 for a d. Mark Knoop wrote: I presume by help lines you mean ledger lines? But you're correct that neither the average pitch or even the average pitch of the outer notes of the chord is enough. Consider the following: d' f'8 b, f' d' f' b, f' Clearly this would be best set in the bass clef, however the average pitches (e', gis) would (probably) result in it swapping between the two staves. So it's actually the extremity of the chord in the direction of potential staff change that is of primary importance. That's interesting. But that's not quite it. You can see why if you re-do your example backwards: b, f'8 d' f' b, f' d' f' The first chord clearly goes in the bass staff. And I agree, the second chord should also go in the bass staff. But if we only look at the extremity of the chord in the direction of potential staff change, we'll end up putting the second chord in the treble staff anyway. What do you think about this: If chord1 is in the lower staff, and chord2 would normally go in the upper staff, and the highest note of chord2 is higher than the highest note of chord1, then put chord2 in the upper staff, otherwise keep chord2 in the lower staff. If chord1 is in the upper staff, and chord2 would normally go in the lower staff, and the lowest note of chord2 is lower than the lowest note of chord1, then put chord2 in the lower staff, otherwise keep chord2 in the upper staff. Is that it? Or can this still be improved? Remember, we need to be as specific as possible and devise an algorithm that works well in all the cases that we can imagine (within reason). Werner LEMBERG wrote: Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. I don't think so. The purpose of staff changes is to avoid help lines. Perhaps it makes sense to provide different `modes', depending on the purpose. That's another interesting idea. I'll try to keep that in mind, but I need to decide on a good general algorithm first. Trevor Daniels t.dani...@treda.co.uk wrote: I think this would not result in an improvement in the general case. In a passage in which the average fluctuated rapidly above and below middle C too many staff switches would be generated. The present scheme does not do this as (in a chord) you can choose to have the based on the higher or lower note depending on the order in which they appear. This probably offends your semantic sensibility though ;) Yes, I imagine that algorithmically-generated LilyPond code is not likely to appreciate the subtlety of note-entryorder. Actually a scheme based the switch on the position of either extreme of the chord would be an improvement, which extreme being specified, and would restore the correct semantics :) Would the algorithm I proposed above in response to Mark Knoop suffice? Also being able to specify a lower limit on the number of notes/chords permitted on the staff to be switched to, to prevent short runs, would also be useful. That's an excellent idea, although I don't know how easy that's going to be to implement. But once I'm at a place where I'm ready to experiment with that, I probably will. As with Werner's idea, I'll try to keep it in mind. dem...@suffolk.lib.ny.us wrote: What would make the most sense is to consider the range of the intended instrument. music for a mid-range instrument (eg classical guitar) is conventionally presented on the same suboctave G clef a tenor vocalist
Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.
dem...@suffolk.lib.ny.us writes: On Wed, Jul 22, 2009, Trevor Daniels t.dani...@treda.co.uk said: Anyway, I think that it would make a lot more sense if the staff were determined by the average pitch of the chord. And, I think I've solved this in the attached patch. What would make the most sense is to consider the range of the intended instrument. music for a mid-range instrument (eg classical guitar) is conventionally presented on the same suboctave G clef a tenor vocalist uses. Some music for low brass and winds uses c-3, c-4, and f-4 clefs. Hopefully these automatic clef changes are an optional feature, many players find any clef change annoying. I'll agree that any optionally usable clefs should be specified in advance. A clef in this respect may also consist of 8va notations. There are instrument-dependent thresholds of pain involved: singers' clefs will just not change in midpiece. I don't think that the right hand of a (non-bass) accordion would ever change clefs (even though I have a button accordion going down to deep A, needing 5 ledger lines, which is not all that untypical). The best strategy probably would be to specify badnesses for clef changes (separate for in-bar and between-bar), ledger lines (with progressive badness for the vertical arrangement and/or badness for ledger lines which actually change the system spacing), a large badness for the first clef change, another one for a repeat ending with a different clef than it begins... Look to the earliest publications of Ottaviano Petrucci (Canti C, Canti B, Odhecaton), available in facsimile at the best music libraries (and direct from Broude Brothers if you care to purchase) for examples of how rare clef changes were even when movable C clefs were the norm. What do you mean even when? We are talking about singers (with a limited range) and the movable clef was placed such that you did not need clef changes or ledger lines in midpiece. Initial clef should be chosen based on overall range, But today's available clef choice is much smaller. And quite a few instruments have a fixed clef (which you, if at all, extend using 8va notation). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
anchors in the music stream?
Hello all,
Like many Lilyponders, I break down my code into variables, e.g.
global (for time signature changes, etc.), notes, dynamics, etc. The
main irritation with this (IMO) is that each variable requires a
complete set of skips in order to keep the timing accurate.
Would it be technically feasible/possible to establish a system of
anchors instead? That is, could we declare an anchor point in the
global setup, and then refer to it in other code? e.g.
global =
{
\time 4/4 s4*4*10
\time 3/4 s4*3*5
\time 7/4 s4*7
\time 4/4 \anchor #'coda s4*4*10
\bar |.
}
tempoChanges =
{
\tempo \markup Opening tempo
\anchorTo #'coda \tempo \markup Extremely slow
}
??
Just a brainstorm from someone who doesn't understand the internals
enough to immediately see the stupidity of this idea... =)
Thanks,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anchors in the music stream?
Kieren MacMillan wrote: Like many Lilyponders, I break down my code into variables, e.g. global (for time signature changes, etc.), notes, dynamics, etc. The main irritation with this (IMO) is that each variable requires a complete set of skips in order to keep the timing accurate. Would it be technically feasible/possible to establish a system of anchors instead? That is, could we declare an anchor point in the global setup, and then refer to it in other code? Have you tried using the \tag command? http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Different-editions-from-one-source#Using-tags - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anchors in the music stream?
Hi Mark, Have you tried using the \tag command? http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Different- editions-from-one-source#Using-tags Certainly I've used \tag for filtering content, but I don't understand how \tag could help with the problem I'm describing... could you elaborate on what you're thinking? Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
inverse of unsmob_context
I'm trying to avoid code duplication as I work with fixing the beam-grouping code. I'm defining some procedures that can be called both from c++ and scheme to get grouping rules from the context property. In order to call from scheme, I need to have context be a smob. In my call from c++, I have context available as Context* I know how to go from smob to Context*: Context *myctx = unsmob_context(SCM context) But I haven't been able to find the inverse: SCM my_context = smob_context(Context *context) Does this function exist? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
autoClef ideas (was: Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.)
(creating a new thread to separate the clef stuff from the staff stuff) David Kastrup wrote: I'll agree that any optionally usable clefs should be specified in advance. A clef in this respect may also consist of 8va notations. There are instrument-dependent thresholds of pain involved: singers' clefs will just not change in midpiece. I don't think that the right hand of a (non-bass) accordion would ever change clefs (even though I have a button accordion going down to deep A, needing 5 ledger lines, which is not all that untypical). These are situations when the user would simply not use the auto- clef function. And when using the function, I think the burden should be on the user to set the allowable clefs on a case-by-case basis, not on the program. The best strategy probably would be to specify badnesses for clef changes (separate for in-bar and between-bar), ledger lines (with progressive badness for the vertical arrangement and/or badness for ledger lines which actually change the system spacing), a large badness for the first clef change, another one for a repeat ending with a different clef than it begins... These ideas sound ambitious to me, but should anyone want to try implementing them in the future, s/he can consult this post. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: inverse of unsmob_context
Carl Sorensen c_sorensen at byu.edu writes: SCM my_context = smob_context(Context *context) Does this function exist? Sorry for the noise -- I found context-self-scm() which does what I need. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: inverse of unsmob_context
On wo, 2009-07-22 at 10:56 -0600, Carl Sorensen wrote: Context *myctx = unsmob_context(SCM context) But I haven't been able to find the inverse: SCM my_context = smob_context(Context *context) SCM c = context-self_scm () ? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anchors in the music stream?
On Wed, Jul 22, 2009 at 9:05 AM, Kieren
MacMillankieren_macmil...@sympatico.ca wrote:
Hello all,
Like many Lilyponders, I break down my code into variables, e.g. global (for
time signature changes, etc.), notes, dynamics, etc. The main irritation
with this (IMO) is that each variable requires a complete set of skips in
order to keep the timing accurate.
Would it be technically feasible/possible to establish a system of anchors
instead? That is, could we declare an anchor point in the global setup, and
then refer to it in other code? e.g.
global =
{
\time 4/4 s4*4*10
\time 3/4 s4*3*5
\time 7/4 s4*7
\time 4/4 \anchor #'coda s4*4*10
\bar |.
}
tempoChanges =
{
\tempo \markup Opening tempo
\anchorTo #'coda \tempo \markup Extremely slow
}
??
Just a brainstorm from someone who doesn't understand the internals enough
to immediately see the stupidity of this idea... =)
That's a neat idea. It might be easier to do something like:
global =
{
\time 4/4 s4*4*10
\time 3/4 s4*3*5
\time 7/4 s4*7
\time 4/4 \anchor #'coda s4*4*10
\bar |.
}
\addAt #'coda \global {\tempo \markup Extremely slow}
Then the addAt function could weave the tempo in at the correct point.
Though I'm not sure how easy this would be either.
=
I've thought about something similar before and I think anchors would
be a good syntax (I don't know about the internals) to make it work:
global = {s1*4 \anchor #'place s1*4}
part = \relative c' {c1 c c c \assertAt #'place c c c c \assertEnd}
anotherPart = \relative c' {e1 e e \assertAt #'place e e e e \assertEnd} %Error
\score { \new Staff{ \global \part } \new Staff{ \global
\anotherPart } }
This would work similar to bar checks. Errors would be thrown when the
anchor and assertion don't line up. I think this might be more
complicated than the above use.
In any case I think anchors could be very useful for a variety of purposes.
-Jay
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
Reviewers: Neil Puttock, joeneeman, Message: OK, I've responded to Joe's comments. I've created a new file lily/beam-scheme.cc, and put c++ and scheme callable routines in it. Then I've used those calls from auto-beam.scm, measure-grouping-engraver.cc, and beaming-pattern.cc. I also added a new file lily/include/beam-grouping.hh to provide those functions to c++. I've never done this much mucking in the c++ code before, so please make sure I've done things right. Thanks, Carl http://codereview.appspot.com/88155/diff/3092/2039 File ly/music-functions-init.ly (right): http://codereview.appspot.com/88155/diff/3092/2039#newcode699 Line 699: (make-music 'SequentialMusic 'void #t)) On 2009/07/21 18:24:35, joeneeman wrote: I'd feel better if this were finished. At least add FIXME so it can be easily grepped for. OK -- fixed in new patch set. http://codereview.appspot.com/88155/diff/3092/2047 File scm/music-functions.scm (right): http://codereview.appspot.com/88155/diff/3092/2047#newcode546 Line 546: (define (make-default-beaming-rule context) On 2009/07/21 18:24:35, joeneeman wrote: this doesn't seem to be used... Thanks for the catch -- removed Description: New format for autobeaming rules Change autobeaming rules so they are all set in one place and they remain if the time signature is changed. Eliminates override-auto-beam-settings and revert-auto-beam-settings autoBeamSettings property changed to beamSettings property beatGrouping property eliminated (default autobeam rule is now used for beatGrouping) Please review this at http://codereview.appspot.com/88155 Affected files: M Documentation/de/user/rhythms.itely M Documentation/es/user/rhythms.itely M Documentation/fr/user/rhythms.itely M Documentation/topdocs/NEWS.tely M Documentation/user/music-glossary.tely M Documentation/user/rhythms.itely M input/lsr/automatic-beams-two-per-two-in-4-4-or-2-2-time-signature.ly M input/lsr/beam-endings-in-score-context.ly M input/lsr/beam-grouping-in-7-8-time.ly M input/lsr/chordchanges-for-fretboards.ly M input/lsr/compound-time-signatures.ly M input/lsr/conducting-signs,-measure-grouping-signs.ly M input/lsr/grouping-beats.ly M input/lsr/making-slurs-with-complex-dash-structure.ly M input/lsr/non-default-tuplet-numbers.ly M input/lsr/non-traditional-key-signatures.ly M input/lsr/reverting-default-beam-endings.ly M input/manual/fretted-headword.ly M input/mutopia/claop.py A input/new/beam-endings-in-score-context.ly A input/new/beam-grouping-in-7-8-time.ly A input/new/compound-time-signatures.ly A input/new/conducting-signs,-measure-grouping-signs.ly A input/new/grouping-beats.ly A input/new/reverting-default-beam-endings.ly M input/regression/auto-beam-beat-grouping.ly M input/regression/beam-beat-grouping.ly M lily/auto-beam-engraver.cc A lily/beam-scheme.cc M lily/beaming-pattern.cc A lily/include/beam-grouping.hh M lily/measure-grouping-engraver.cc M ly/bagpipe.ly M ly/engraver-init.ly M ly/music-functions-init.ly M python/convertrules.py M scm/auto-beam.scm A scm/beam-settings.scm M scm/c++.scm M scm/define-context-properties.scm M scm/define-music-display-methods.scm M scm/lily.scm M scm/music-functions.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: autoClef ideas (was: Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.)
2009/7/22 Mark Polesky markpole...@yahoo.com: These ideas sound ambitious to me, but should anyone want to try implementing them in the future, s/he can consult this post. I can add whatever will not be implemented soon as (a) feature request(s) in the tracker – possibly including the autochange patch, since it seems trickier than expected. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anchors in the music stream?
2009/7/22 Jay Anderson horndud...@gmail.com: In any case I think anchors could be very useful for a variety of purposes. Yaay! For one, it would simply change my life :-) I'm not sure if it is at all possible without major changes to the way Lily currently works though. I'll wait a few days to see where this discussion goes, but please nag me if I ever forget to add it as a feature request in the tracker (I'd certainly put a bounty on this one). Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anchors in the music stream?
Hello all, Jay's \addTo twist gave me a (naive) thought... If \addTo simply constructed (e.g., appended to) an ordered list of moment-event (moment-grob?) pairs, couldn't the parser simply grab the one(s) it needed at any given moment? Yaay! For one, it would simply change my life :-) Agreed. I'm not sure if it is at all possible without major changes to the way Lily currently works though. I'll wait a few days to see where this discussion goes, but please nag me if I ever forget to add it as a feature request in the tracker (I'd certainly put a bounty on this one). I'm in for $$ as well. Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: more code-cleanup patches
2009/7/21 Mark Polesky markpole...@yahoo.com:
Here are four more code-cleanup patches.
Okay to apply?
LGTM apart from a few tiny details which have caught my eye:
(0001-define-grobs.scm-Sort-interfaces.patch)
@@ -1871,10 +1870,10 @@
(X-offset . ,ly:self-alignment-interface::x-aligned-on-self)
(Y-offset . ,ly:staff-symbol-referencer::callback)
(meta . ((class . Item)
-(interfaces . (rhythmic-head-interface
-font-interface
-rhythmic-grob-interface
+(interfaces . (font-interface
note-head-interface
+rhythmic-grob-interface
+ rhythmic-head-interface
Indentation.
@@ -2142,8 +2142,8 @@
(Y-extent . ,ly:axis-group-interface::height)
(Y-offset . ,ly:side-position-interface::y-aligned-side)
(meta . ((class . Spanner)
-(interfaces . (piano-pedal-interface
- axis-group-interface
+(interfaces . (axis-group-interface
+ piano-pedal-interface
Trailing spaces.
@@ -1573,8 +1572,8 @@
(Y-extent . ,ly:axis-group-interface::height)
(Y-offset . ,ly:side-position-interface::y-aligned-side)
(meta . ((class . Spanner)
-(interfaces . (piano-pedal-interface
- axis-group-interface
+(interfaces . (axis-group-interface
+ piano-pedal-interface
Trailing spaces.
(0003-define-music-properties.scm-Sort-all-music-propertie.patch)
+ (associated-context ,string? Name of the Voice context associated with
+this @code{\\newaddlyrics} section.)
Change \\newaddlyrics to \\lyricsto.
(0004-define-music-types.scm-Sort-music-descriptions-alist.patch)
@@ -120,6 +120,13 @@ Syntax: @var{no...@code{\\breathe})
(types . (general-music event breathing-event))
))
+(ClusterNoteEvent
+ . ((description . A note that is part of a cluster.)
+ ;; not a note-event, to ensure that Note_engraver doesn't eat it.
Note_heads_engraver.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: more code-cleanup patches
Neil Puttock wrote: LGTM apart from a few tiny details which have caught my eye: (0001-define-grobs.scm-Sort-interfaces.patch) (0003-define-music-properties.scm-Sort-all-music-propertie.patch) (0004-define-music-types.scm-Sort-music-descriptions-alist.patch) Neil, Am I to assume that patch 0002 is error-free? It's not like you to accidentally skip over something, but I had to ask! - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: more code-cleanup patches
2009/7/22 Mark Polesky markpole...@yahoo.com: Am I to assume that patch 0002 is error-free? It's not like you to accidentally skip over something, but I had to ask! Yep, looks fine. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
I think this is pretty much ready to commit http://codereview.appspot.com/88155/diff/3101/4032 File lily/beam-scheme.cc (right): http://codereview.appspot.com/88155/diff/3101/4032#newcode2 Line 2: beam-scheme.cc -- Retrieving beam settings could you call this beam-grouping-scheme.cc or something like that? beam-scheme sounds like it contains routines for manipulating Beam grobs. http://codereview.appspot.com/88155/diff/3101/4032#newcode12 Line 12: LY_DEFINE (ly_beam_settings, ly:beam-settings, is this function really necessary? http://codereview.appspot.com/88155/diff/3101/4032#newcode49 Line 49: ly_grouping_rules(settings,time_signature,rule_type), formatting http://codereview.appspot.com/88155/diff/3101/4032#newcode61 Line 61: SCM settings = ly_beam_settings(context); formatting http://codereview.appspot.com/88155 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determine staff.
I've tweaked the autochange code a little more and I've been able to make some of the improvements suggested. It's still under construction, but I'm posting it so you guys can play with it. The easiest way to test it would be to just save the autochange_revised.scm and autochange.ly attachments in the same directory and then compile autochange.ly. Play around with the max-avg-deviation variable in autochange_revised.scm. Eventually I'll also add a max-deviation property which will allow fine-tuning of the staff-change algorithm. I've attached (in miniature) a png which shows the file compiled with the current setting on the left, and with my revisions on the right. I think there will always be situations that end up not looking right. One can only automate so much. But I think this is big improvement over the current function. Let me know what you guys think. - Mark attachment: autochange.png ;; autochange - fairly related to part combining. ; copied from lily-library.scm (define (sign x) (if (= x 0) 0 (if ( x 0) -1 1))) (define (notes-get-pitches notes) (map (lambda (x) (ly:event-property x 'pitch)) notes)) (define (get-avg-pitch-steps pitches) (round (apply average (map ly:pitch-steps pitches (define (get-pitch-steps-range pitches) (let ((pitch-steps (map ly:pitch-steps pitches))) (cons (apply min pitch-steps) (apply max pitch-steps (define-public (make-autochange-music parser music) ;; don't let gradually moving chords get stuck in one staff. ;; when the absolute-value of a chord's average staff-position ;; exceeds this value, allow the chord to change staves. ;; at the moment, this does not affect single notes, only chords that ;; are close together ;; TODO: max-deviation (define max-avg-deviation 2) (define (generate-split-list change-moment event-list last-profile acc) ;; acc is a reversed list of (moment . staff) pairs, ;; where staff is 1 or -1. ;; last-profile is (last-staff . last-extremity) (if (null? event-list) acc (let* ((now-tun (caar event-list)) (evs (map car (cdar event-list))) (now (car now-tun)) ; a moment (notes (filter (lambda (x) (equal? (ly:event-property x 'class) 'note-event)) evs)) (pitches (notes-get-pitches notes)) (this-avg (if (pair? notes) (get-avg-pitch-steps pitches) #f)) (this-range (if (pair? notes) (get-pitch-steps-range pitches) '(0 . 0))) (last-staff (car last-profile)) (last-extremity (cdr last-profile)) (is-single-note (= (car this-range) (cdr this-range))) (this-staff (cond ; don't change staves if this-avg is C. ((= 0 this-avg) last-staff) ;; TODO: this block could be better organized: ((or ; when to force a change during chords. (if is-single-note #f ( max-avg-deviation (abs this-avg))) ; if chord normally goes in the other staff ; and this-avg exceeds last-extremity. (and (not (= last-staff (sign this-avg))) ( (abs last-extremity) (abs this-avg)) (if is-single-note ( max-avg-deviation (abs this-avg))) #t)) (sign this-avg)) (else last-staff))) ; -1 or 1 (this-extremity (if (positive? this-staff) (car this-range) (cdr this-range))) (this-profile (cons this-staff this-extremity))) ;; tail recursive. (if (and this-avg (not (= last-staff this-staff))) (generate-split-list #f (cdr event-list) this-profile (cons (cons (if change-moment change-moment now) (sign this-avg)) acc)) (generate-split-list (if this-avg #f now) (cdr event-list) this-profile acc) (let* ((m (make-music 'AutoChangeMusic)) (m1
Re: New format for autobeaming rules
http://codereview.appspot.com/88155/diff/3101/4027
File input/new/grouping-beats.ly (right):
http://codereview.appspot.com/88155/diff/3101/4027#newcode7
Line 7: Beaming patterns may be altered with the @code{beatGrouping}
property:
new texidoc using \overrideBeamSettings
http://codereview.appspot.com/88155/diff/3101/4032
File lily/beam-scheme.cc (right):
http://codereview.appspot.com/88155/diff/3101/4032#newcode10
Line 10: #include beam-grouping.hh
swap
http://codereview.appspot.com/88155/diff/3101/4032#newcode26
Line 26: @var{rule-type} in @var{context}.)
no context arg, doc settings
http://codereview.appspot.com/88155/diff/3101/4032#newcode28
Line 28: LY_ASSERT_TYPE (ly_is_pair, time_signature, 2);
scm_is_pair
http://codereview.appspot.com/88155/diff/3101/4032#newcode30
Line 30:
type check also for settings?
http://codereview.appspot.com/88155/diff/3101/4032#newcode34
Line 34: ly_assoc_get ((scm_list_2 (time_signature, rule_type)),
excess parens
http://codereview.appspot.com/88155/diff/3101/4032#newcode43
Line 43: Return grouping for beams of @var{ beam-type} in
@var{beam-type}
http://codereview.appspot.com/88155/diff/3101/4032#newcode45
Line 45: @var{rule-type} in @var{context}.)
no context arg, doc settings
http://codereview.appspot.com/88155/diff/3101/4032#newcode46
Line 46: {
type checks?
http://codereview.appspot.com/88155/diff/3101/4032#newcode57
Line 57: {
LY_ASSERT_SMOB (Context, context, 1);
If you don't do this, then unsmob_context () will return NULL if this
function is passed invalid arguments, leading to a null dereference for
get_property (timeSignatureFraction) - segfault
http://codereview.appspot.com/88155/diff/3101/4033
File lily/beaming-pattern.cc (right):
http://codereview.appspot.com/88155/diff/3101/4033#newcode18
Line 18: #include beam-grouping.hh
sort
http://codereview.appspot.com/88155/diff/3101/4034
File lily/include/beam-grouping.hh (right):
http://codereview.appspot.com/88155/diff/3101/4034#newcode8
Line 8:
To prevent multiple includes:
#ifndef BEAM_GROUPING_HH
#define BEAM_GROUPING_HH
(+ line 14)
http://codereview.appspot.com/88155/diff/3101/4034#newcode14
Line 14:
#endif // BEAM_GROUPING_HH
http://codereview.appspot.com/88155/diff/3101/4035
File lily/measure-grouping-engraver.cc (right):
http://codereview.appspot.com/88155/diff/3101/4035#newcode14
Line 14: #include beam-grouping.hh
sort
http://codereview.appspot.com/88155/diff/3101/4035#newcode66
Line 66: SCM time_signature_fraction = get_property
(timeSignatureFraction);
move to if { } block, then it's only retrieved if required
http://codereview.appspot.com/88155/diff/3101/4038
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/88155/diff/3101/4038#newcode20
Line 20: (_i Define @@var{music} as a quotable music expression named
rogue extra @'s throughout file
http://codereview.appspot.com/88155/diff/3101/4039
File python/convertrules.py (right):
http://codereview.appspot.com/88155/diff/3101/4039#newcode2930
Line 2930: str = re.sub(\\set\w+#\'beatGrouping, \\setBeatGrouping,
str)
won't get here due to search above (and regexp is broken)
http://codereview.appspot.com/88155/diff/3101/4041
File scm/beam-settings.scm (right):
http://codereview.appspot.com/88155/diff/3101/4041#newcode48
Line 48: ;; in 3 4 time:
decided not to restore original setting?
http://codereview.appspot.com/88155/diff/3101/4041#newcode155
Line 155: Functions for overriding beam settings
indentation of function bodies
http://codereview.appspot.com/88155/diff/3101/4043
File scm/define-context-properties.scm (right):
http://codereview.appspot.com/88155/diff/3101/4043#newcode126
Line 126: (beatGrouping ,list? A list of beatgroups, e.g., in 5/8 time
remove
http://codereview.appspot.com/88155
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewriting x11-color.scm
2009/7/21 Mark Polesky markpole...@yahoo.com: I rewrote x11-color.scm so that now the color-list is generated semi-automatically. It's more organized, easier to read, and less than a quarter of its original size. But does my approach slow things down at all? Measurably? I figure the current version is probably faster because no calculations need to be made during the definition of the color-list. But I don't have a good sense of the impact of this. I'm not posting a patch here because I'm pretty sure it would be way too big for the list-server. Anyway, please comment if you can. Very nice. :) A good (but tedious) test of whether it's impacting on compile times would be to compare doc builds with and without the changes, since there are so many LilyPond invocations for the snippets. I've just done an unscientific test comparing `make test-baseline' compile times, and it actually seems to be a bit quicker (3'35'' vs 3'45''). (define (append-all arg) (let ((arg-list (string-split (string-capitalize arg) #\ ))) I'd replace the space char with #\sp (or #\space) to get rid of the nasty space before the parentheses (same in make-x11-color-handler). (define (make-x11-color-handler) (let ((x11-color-table (make-hash-table 31))) (lambda (arg) (let* ((x11-color-table (make-hash-table 31)) This resets the hash table each time x11-color is invoked, so it'll never cache any colour lookups. (if temp temp (let* ((temp-1 (assq-ref x11-color-list arg-sym)) Indentation's a bit awry here. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewriting x11-color.scm
On Thu, Jul 23, 2009 at 12:15 AM, Neil Puttockn.putt...@gmail.com wrote: 2009/7/21 Mark Polesky markpole...@yahoo.com: I rewrote x11-color.scm so that now the color-list is generated semi-automatically. It's more organized, easier to read, and less than a quarter of its original size. But does my approach slow things down at all? Measurably? I figure the current version is probably faster because no calculations need to be made during the definition of the color-list. But I don't have a good sense of the impact of this. I'm not posting a patch here because I'm pretty sure it would be way too big for the list-server. Anyway, please comment if you can. Very nice. :) A good (but tedious) test of whether it's impacting on compile times would be to compare doc builds with and without the changes, since there are so many LilyPond invocations for the snippets. It sure looks nice, but since x11-color.scm is basically dumb data, this change introduces more places where bugs could hide. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directory structure for docs and web site
On Wed, Jul 22, 2009 at 10:29:37AM +0200, John Mandereau wrote: Le mardi 21 juillet 2009 à 23:57 -0700, Graham Percival a écrit : I still think the texinfo files should be in master, but perhaps not the generated images, and not some really web-specific stuff like the htaccess. If lilypond-general (which includes examples) contains LilyPond music examples, generated images can (and probably should IMHO) be lilypond files or @lilypond blocks that are built along with the docs. I disagree; @lilypond blocks have a few problems for this case: - this is a really courageous regression test. Ok, ideally we'd never merge any patches that break any regtests, but it happens from time to time -- especially since IMO nobody is actually checking the regtest comparisons. (yes, getting this started again is a priority in GOP) It's one thing to have some bugs show up in the manual; it's another thing to have a bug resulting in ugly examples on the Introduction page! - requires lilypond (could be problems for a distinct web repo) - we DO NOT want to show the input code. - we want to show an expanded image upon click (possibly via javascript). All in all, we'd need to check the output all the time, write a special rule for @lilypond when running texi2html on the website (actually, I guess this would need to be a special-case option for lilypond-book), etc etc. And for what benefit? So that we can avoid adding 704 Kb to the git tracker? I agree that generated files shouldn't be added to source repositories as a general rule, but I really think that this is a special case that merits an exemption. We'd (and by we, I mean you ;P) need to add little quirks to so many portions of the build system, not to mention the ongoing risk or ongoing check the output on Examples task. The precise building of what's on lilypond.org should be fairly clear: it is built from the web repo, with the exception of /doc/2.x/, which is built from the relevant branch of main. This wouldn't change at all from the current web-building process. Except that HTML pages from lilypond-general are moved from /doc/2.x to /. As the Texinfo docs structure will be greatly simplified, this is an acceptable amount of hacking :-) Hmm... ok. I'm slightly concerned about the downloadable tarball (it might be nice to offer downloadable HTML and pdf tarballs). For those tarballs, we'd want to generate HTML files that point to HTML files within the tarball, whereas in the for-upload html files, we'd want to point lilypond-general links at ../../ I have no suggestions about how to do this in a nice way, but as long as you're aware of the issue, I'm sure that you can find a nicer solution than mine, anyway. :) Now it's more clear which direction we follow, I can comfortably get back to hacking makefiles and moving files. Thanks! Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewriting x11-color.scm
Han-Wen Nienhuys wrote: Neil Puttock wrote: Very nice. :) A good (but tedious) test of whether it's impacting on compile times would be to compare doc builds with and without the changes, since there are so many LilyPond invocations for the snippets. It sure looks nice, but since x11-color.scm is basically dumb data, this change introduces more places where bugs could hide. Han-Wen, What kind of bugs? Are you saying you'd definitively prefer that I leave it alone? My initial point of departure was the desire to clean up NR B.5 List of colors, which a) is organized in a way that makes it hard to look up colors, and b) contains several errors that I was intending to fix. In the course of my attempts to systematically identify all the errors in that appendix, I looked at x11-color.scm, but the dumb data was of very little help. It was very hard to look at the source and see what was going on. So I experimented with a clearer format, and I'd like to think my modifications represent an improvement. Personally, I would say my revision is flexible rather than bug-friendly. And I would say the current version is more obfuscated, even though it is technically correct. I believe that code should be transparent and easy to trust. Right now it's impossible to determine if any errors exist in the current version just by looking at it. And that's what I don't like. Ultimately, I'll accept whatever position you maintain. Anything else would presumptuous! Let me know. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
