Re: change clef inside a grob-callback?
Joe Neeman wrote: Is there a way to change the clef from within a grob callback? Not really. You can change the clef's glyph, but you can't really change the clef's influence on the following notes. I presume you mean I can change the clef stencil, or do you mean that it's possible to change the clefGlyph context property? If that were the case, then couldn't I change clefPosition and middleCPosition and do it that way? ...Reason being, the NoteHead grobs are created around the same time as the Clef grob and their positions are fixed at that time, so unless you want to somehow iterate over and modify all the NoteHeads, it isn't really going to work. I'd suggest a music function rather than a grob override. How? I was using a music function before, but I couldn't find a way to get NoteHead staff-positions without a callback. And I get stuck with a music-function because I don't know how to test if I'm in a \relative block or not. I guess the algorithmic idea would be: *Before* staff-positions are concretely determined... 1. what would the staff-positions be if we stayed in this clef? 2. if they're within this clef's staff-range, do nothing. 3. if another clef is better (according to user), change the clef. 4. determine actual staff-positions with the updated clef info. I just don't know how to catch the process before the staff-positions are determined, if all I have is a context and a EventChord. I thought that if I could at least know whether I'm in a \relative block, I could then look at the current clef, and figure it out the long way (not that I'd want to). But I imagine there must be an easier way in. And I can't test for \relative-ness as far as I can tell anyway. Do you have any other (slightly more specific) suggestions? (: Thanks for taking a look at this. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regression test information
On Thu, Jul 16, 2009 at 10:11:50AM -0600, Carl Sorensen wrote: I'd like permission to move the information on regression testing from make test-baseline and make check from the AU to the CG (There's a placeholder there already; section 7). Any concerns about doing this? My concern is that the entire compiling is slated to move to the CG, so it would make sense to do this at once. That said, we might split up the user- and packager-oriented parts of compiling from the developer-oriented parts. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
On Thu, Jul 16, 2009 at 04:45:35PM +0200, John Mandereau wrote: Le jeudi 16 juillet 2009 à 04:46 -0700, Graham Percival a écrit : It's impossible to miss, as is INSTALL.txt in the tarball, so the masocists that want to compile from source can still find their instructions. Do you mean that all packagers are masocists? :-) Package managers are an anomoly. There's no reason for normal users to compile from source. inb4 oh, but I want to run lilypond on my netbsd-powered arm toaster. Those aren't normal users. I think this is met by my later proposal to keep a separate web/ repo, but to not edit the texinfo sources on that branch. That way, no lilypond snippet compiling will be necessary to build the website, so the hourly build will be fine. If no Texinfo/ly compilation is done on web branch, then there should be no Texinfo/ly source on web. I assume you mean this. No, I mean: master/Documentation/web.texi master/Documentation/web/*.itexi (used in GUB release web versions) web.repo/texinfo/*.itexi (exact copy of the files in master/. Nobody edits these, apart from the web person who imports the versions from master/ after verifying that they still work) web.repo/texinfo/cross-references-trickery (exact copy of whatever is done in master/Documentation) Hourly build of the website can run just fine from web/ with no ly compiling. lilypond.org doesn't even need to have texinfo installed; texi2html can run by itself. This way, building web is a lightweight, self-contained process. I don't think that having an exact copy of files in master/ in web.repo/ is a horrible idea. If you think it is, then we could go back to the idea of requring master/ to build the website. I think that's too much of a requirement. Basically, we want a bunch of texinfo files to be used in the documentation tarball compiling, and in the website. However we do things, we either need to build everything from master/ (you and Han-Wen have convinced me that's not the best idea), or require both repos in order to build the website, or keep copies of those files in both repos. I'm not certain we want to require an active internet connection. I'm against recording HTML ouptut I'm against this too. and/or a bunch of generated PNG/SVG/EPS images of music in web repository: this will clutter history a lot. I think we should have this, though. Why not? The current website does this. I think site/images/ has about 20 images of lilypond output. The thing is, we definitely *don't* want the images to be built automatically. Once in a while -- perhaps once a year -- a website person should try generating the examples/ and examine the output carefully. Are there any flaws? If so, don't update the images in Examples. If there's no flaws, then go ahead an In case there's any doubt, we're only talking about the 8-10 images in Introduction-Examples. No wait; we're doing the zoom in thing. 16-20 png images. There's no other lilypond output on the website. I suppose we might add some lilypond output for a background image or logo or something, but that's even more of a don't update this without lots of careful thought thing. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb: On 7/16/09 5:54 PM, Jonathan Kulp jonlancek...@gmail.com wrote: Carl Sorensen wrote: So, while I asked Marc to provide documentation, I didn't require it. I did, however, require regtests. As soon as we get the patch applied, we can ask one of the people who is clamoring for improved tab support on -user to get involved in writing the documentation for it, working with you to get it in proper form. I've been looking more carefully at the regtests and think that the texidoc headers might be enough to get started on the new parts of fretted-strings.itely. Would you like me to prepare a patch based on these so that it can be applied at the same time as the program code, or should we just wait? Let's wait a bit -- I'd like to see if we can get somebody in the tablature group to do it. If they don't bite, then we'll have you do it. Of course I can write a documentation, but I had the same idea as Carl - there is a group of people interested in tablature features, and when the patch is applied and the features are availabe, I'll ask them if someone wants to work on the documentation. Marc Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
On Wed, Jul 15, 2009 at 07:43:56AM -0600, Carl Sorensen wrote:
On 7/14/09 3:57 PM, n.putt...@gmail.com n.putt...@gmail.com wrote:
http://codereview.appspot.com/88155/diff/95/1147#newcode69
Line 69: section 1.2.4 Beams, for more information.
Is it possible to use @ruser{} here?
I'm not sure. I thought NEWS was supposed to be a standalone document.
Graham, you're the source of all truth about documents; what do you think?
Until now, it's been a standalone document, but perhaps that
should change. Only after the new unified doc process, unified
macros, etc, though. So just leave it as-is for now. :)
http://codereview.appspot.com/88155/diff/95/1149#newcode1743
Line 1743: Beam settings can be reverted to get back to default
behavior. This
This looks like it should be an input/new snippet.
I'm not sure I understand why you think it should it be in input/new instead
of just being in the docs. It doesn't use \set or \override. It explains
the use of a LilyPond command. That's why I thought it should be an inline
snippet.
In most doc sections, we'd move tweaking-type stuff (and I think
that \overrideBeamSettings would qualify) into snippets.
HOWEVER, certain NR sections go into more detail... my traditional
example of this is the page about changing automatic beam
settings. So I definitely think it's ok to have this inline here.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb:
On 7/16/09 9:56 AM, Carl Sorensen c_soren...@byu.edu wrote:
Marc Hohl has completed a patch for improved tablature support. It is
available for review at:
http://codereview.appspot.com/95059
Please review and comment.
Thanks,
Marc,
Here are some comments.
1) All regression tests should be \version 2.13.4 -- I'll fix that.
Thank you!
2) Your regression test for the modernTab clef:
Doc header should say four- to seven- stringed instruments, which means
instruments having four to seven strings. four to seven stringed
instruments means four to seven instruments having strings. Isn't english
fun?
Ah, I see. Yeah, english *is* fun, but sometimes I just stumble through
half-finished sentences in despite search of a missing word, but at least,
the work on lilypond seems to improve my english a bit.
You should demonstrate in the regtest that it works for four strings and
seven strings, and that it works with various staff sizes. You may want two
different regtests -- one that shows variations in string numbers and one
that shows variation in sizes.
Ok, I will provide additional regtests.
3) Is it necessary (or desirable) to have both \deadNote and
\deadNoteOn..\deadNoteOff? Unless a whole piece is to be written in
DeadNotes, I can't imagine that it's better to write
\deadNoteOn e e deadNoteOff
than
\deadNotes{e e}.
If there's no value to the On..Off pairs, then it's probably best to
eliminate them. But if there is value, we can keep them. And I'm not the
judge of value. I'm just asking the question.
Hm, I introduced the ..On/..Off pairs first, because this syntax seemed
to be
lilypondish - and easier to read, especially if there are long
passages played
palm mute- or dead note-style. The latter construct looks more like a
programming language to me (yes, in fact it is a programming language, but
as there are many users not familiar with computer programming, we should
avoid this in general - but this is rather philosophical here).
On the other hand, for a single dead note
\deadNoteOn e \DeadNoteOff
is way too complicated, and furthermore
c \deadNoteOn e \deadNoteOff g won't work, so there is need for the
second syntax.
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
I don't want to blame others here, but this piece of code was 1:1 copied
from Neil's mail.
Shall I reformat it and send a new patch, or are there other
possibilities to correct it?
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
Great! This opens the possibilitiy of drawing parentheses around chords,
isn't it?
Thank you.
Marc
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb: 2) Your regression test for the modernTab clef: Doc header should say four- to seven- stringed instruments, which means instruments having four to seven strings. four to seven stringed instruments means four to seven instruments having strings. Isn't english fun? You should demonstrate in the regtest that it works for four strings and seven strings, and that it works with various staff sizes. You may want two different regtests -- one that shows variations in string numbers and one that shows variation in sizes. Here it is - gzipped for proper line endings. The first file, modern-tab-clef.ly shows tablature for four and seven strings, while the second, modern-tab-claf-scaled.ly demonstrates the scaling. Marc additional-regtests.tar.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement framework for post-fix text (de)cresc spanners
2009/5/9 Neil Puttock n.putt...@gmail.com: I favour this version since its the least ambiguous; there's no risk of a user trying to make e.g. a 'CrescendoEvent with 'descrescendo-text. Just for the record (and the mailing list archive): this feature has now been added to our tracker as http://code.google.com/p/lilypond/issues/detail?id=817 I certainly hope it will get accepted and merged at some point! :-) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regression test information
On 7/17/09 12:57 AM, Graham Percival gra...@percival-music.ca wrote: On Thu, Jul 16, 2009 at 10:11:50AM -0600, Carl Sorensen wrote: I'd like permission to move the information on regression testing from make test-baseline and make check from the AU to the CG (There's a placeholder there already; section 7). Any concerns about doing this? My concern is that the entire compiling is slated to move to the CG, so it would make sense to do this at once. That said, we might split up the user- and packager-oriented parts of compiling from the developer-oriented parts. I think that the regression testing section doesn't make sense as part of compiling. I have never considered running the regression tests to see if compiling has succeeded. Once documentation is built, I'm satisfied that LilyPond is installed properly. Regression tests are used for testing changes to LilyPond, so separating this section out makes sense to me. OK, so now I have a new proposal: 1) Move AU 1.2.2, 1.2.3, 1.2.4 to CG 2.1 2) Move AU 1.2.5 to CG 7 3) Drop AU 1.1 -- it's on the Install page 4) Move 1.2.6 to CG 2.1 5) For now, have AU 1 just add a reference to CG. (But CG 3.3.6 makes no mention of a macro to reference to CG. Do we have one? If we don't, it will just be ordinary text.) Does this proposal pass muster? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 7/17/09 2:13 AM, Marc Hohl m...@hohlart.de wrote:
Carl Sorensen schrieb:
On 7/16/09 9:56 AM, Carl Sorensen c_soren...@byu.edu wrote:
3) Is it necessary (or desirable) to have both \deadNote and
\deadNoteOn..\deadNoteOff? Unless a whole piece is to be written in
DeadNotes, I can't imagine that it's better to write
\deadNoteOn e e deadNoteOff
than
\deadNotes{e e}.
If there's no value to the On..Off pairs, then it's probably best to
eliminate them. But if there is value, we can keep them. And I'm not the
judge of value. I'm just asking the question.
Hm, I introduced the ..On/..Off pairs first, because this syntax seemed
to be
lilypondish - and easier to read, especially if there are long
passages played
palm mute- or dead note-style. The latter construct looks more like a
programming language to me (yes, in fact it is a programming language, but
as there are many users not familiar with computer programming, we should
avoid this in general - but this is rather philosophical here).
There are actually two different lilypondish constructs. One is a
setting, the other is a function.
For example, we do \relative c' {...} and \transpose e f { ... } which are
exactly equivalent to \deadNote { ... }.
But we also have lots of settings.
On the other hand, for a single dead note
\deadNoteOn e \DeadNoteOff
is way too complicated, and furthermore
c \deadNoteOn e \deadNoteOff g won't work, so there is need for the
second syntax.
Right, so we *must* have the function mode. Do we need the setting mode as
well? I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either. I trust your judgment.
However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
I don't want to blame others here, but this piece of code was 1:1 copied
from Neil's mail.
Shall I reformat it and send a new patch, or are there other
possibilities to correct it?
This kind of judgment is somewhat subjective. You can leave it as is, or
you can reformat it. If you reformat it, please send a new patch.
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
Great! This opens the possibilitiy of drawing parentheses around chords,
isn't it?
It will, but it may yet have its own problems. It will parenthesize any
stencil. I don't know if the set of noteheads forms its own stencil
(separate from the stem) or not. If it does, we'll be home free on
parenthesizing chords. If not, we'll still have to figure out how to get
the set of noteheads for parenthesizing.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change clef inside a grob-callback?
On Thu, 2009-07-16 at 23:06 -0700, Mark Polesky wrote: Joe Neeman wrote: Is there a way to change the clef from within a grob callback? Not really. You can change the clef's glyph, but you can't really change the clef's influence on the following notes. I presume you mean I can change the clef stencil, or do you mean that it's possible to change the clefGlyph context property? If that were the case, then couldn't I change clefPosition and middleCPosition and do it that way? I mean that you can change the clef stencil. Context properties are used when creating grobs, but they disappear before any grob callback is likely to be called. ...Reason being, the NoteHead grobs are created around the same time as the Clef grob and their positions are fixed at that time, so unless you want to somehow iterate over and modify all the NoteHeads, it isn't really going to work. I'd suggest a music function rather than a grob override. How? I was using a music function before, but I couldn't find a way to get NoteHead staff-positions without a callback. And I get stuck with a music-function because I don't know how to test if I'm in a \relative block or not. I guess the algorithmic idea would be: *Before* staff-positions are concretely determined... 1. what would the staff-positions be if we stayed in this clef? 2. if they're within this clef's staff-range, do nothing. 3. if another clef is better (according to user), change the clef. 4. determine actual staff-positions with the updated clef info. I just don't know how to catch the process before the staff-positions are determined, if all I have is a context and a EventChord. I thought that if I could at least know whether I'm in a \relative block, I could then look at the current clef, and figure it out the long way (not that I'd want to). But I imagine there must be an easier way in. And I can't test for \relative-ness as far as I can tell anyway. Do you have any other (slightly more specific) suggestions? (: I don't know how to deal with \relative, but it's easy to calculate the staff-position of an absolute note in a music function: (+ (ly:pitch-steps pitch-of-the-note) middle-C-position) If you look at note-heads-engraver.cc, you'll see that the staff-position property is set there using the pitch of the NoteEvent and the middleCPosition property. So you step 4 of your algorithm above will be handled by note-heads-engraver, but only if you can figure out the new clef using only the context and the EventChord. Perhaps a music function guru can help out with the relative problem? Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement framework for post-fix text (de)cresc spanners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 17. Juli 2009 10:59:35 schrieb Valentin Villenave: 2009/5/9 Neil Puttock n.putt...@gmail.com: I favour this version since its the least ambiguous; there's no risk of a user trying to make e.g. a 'CrescendoEvent with 'descrescendo-text. Just for the record (and the mailing list archive): this feature has now been added to our tracker as http://code.google.com/p/lilypond/issues/detail?id=817 I certainly hope it will get accepted and merged at some point! :-) Me too. The main issue is how to implement the upgrade path for old scores... Graham said a while ago that he has some ideas, but he hasn't shared them yet ;-) My idea is to: - -) rename cresc etc. to deprecatedcresc etc. - -) write a conversion rule \cresc-\deprecatedcresc - -) implement the postfix crescendi with the names cresc, dim, decresc I don't see any other way to change the \cresc from prefix to postfix style in existing lilypond code, since you can't rely on a single note following immediately after the \cresc... Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKYKDXTqjEwhXvPN0RAi0fAKCoeVgzwXiKPZbtpLEtGq8x520MAACgiSYB dLDRJQ19kMoyTCwi8V3U9Lg= =Nyzc -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 15. Juli 2009 22:59:45 schrieb ArnoWaschk: Dear list, while trying to import some scores into lilypond i was given as xml export from a finale using collegue, i stumbled across some problems... by far the most common one i tried to reduce into the attached files. while the xml (correctly) contains a Vivace mark in the first bar, the .ly file resulting from musicxml2ly conversion shifts it incorrectly into the third bar, where it finds the first pitch... Yes, that's a known problem. I have had that on my todo list for quite a while, but haven't found the time yet to fix it. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKYKDqTqjEwhXvPN0RAi9fAKCzKWVzD/OdFsLNBzPrUB4opfAasQCff3CW bo4KaQP7RVCDnmPhVT5J6Nk= =oAE1 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen schrieb:
Right, so we *must* have the function mode. Do we need the setting mode as
well? I don't feel strongly about eliminating it, but I don't feel strongly
about keeping it either. I trust your judgment.
I prefer to offer both variants.
However, now that I think about it, for the function call, I would prefer
the name \deadNotes (plural) instead of \deadNote (singular), because it can
take multiple notes in its argument.
Yes, I had that before, but I decided to remove the plural s, because
in chord constructs, it works only on the next note, and in normal
contexts,
c d \deadNote e f
influences only the e (\deadNotes would imply to influence e and f, in
my opinion).
When one uses { }, \deadNote works on a group of notes, so the meaning here
is clear. So personnally, I wouldn't change it ...
4) Formatting nit on scm/tablature.scm
line 125-128: I think it would look better to put all the arguments to
ly:stencil-combine-at-edge on line 124.
line 129-131: I would like it better to have the last three arguments to
the first ly:stencil-combine-at-edge call on line 125, nested to the same
depth as the inner (ly:stencil-combine-at-edge call.
I don't want to blame others here, but this piece of code was 1:1 copied
from Neil's mail.
Shall I reformat it and send a new patch, or are there other
possibilities to correct it?
This kind of judgment is somewhat subjective. You can leave it as is, or
you can reformat it. If you reformat it, please send a new patch.
If this is the only thing to change, I will leave it as is until I had
to apply
changes (for parentheses or additional functions) - not because I'm
lasy, but because of my incomplete knowledge of git (it is still a kind
of a fight each time)
Other than that, things look good.
Oh, BTW, Thomas Morgan is currently working on a new Parenthesize markup
command that will be better than the current parentheses; it will draw the
parentheses as slurs. This may be something you want to use in the future.
Great! This opens the possibilitiy of drawing parentheses around chords,
isn't it?
It will, but it may yet have its own problems. It will parenthesize any
stencil. I don't know if the set of noteheads forms its own stencil
(separate from the stem) or not. If it does, we'll be home free on
parenthesizing chords. If not, we'll still have to figure out how to get
the set of noteheads for parenthesizing.
Ok, let's wait and see.
Marc
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regression test information
On Fri, Jul 17, 2009 at 07:09:19AM -0600, Carl Sorensen wrote: On 7/17/09 12:57 AM, Graham Percival gra...@percival-music.ca wrote: My concern is that the entire compiling is slated to move to the CG, so it would make sense to do this at once. That said, we might split up the user- and packager-oriented parts of compiling from the developer-oriented parts. I think that the regression testing section doesn't make sense as part of compiling. I have never considered running the regression tests to see if compiling has succeeded. Once documentation is built, I'm satisfied that LilyPond is installed properly. Regression tests are used for testing changes to LilyPond, so separating this section out makes sense to me. OK, so now I have a new proposal: 1) Move AU 1.2.2, 1.2.3, 1.2.4 to CG 2.1 2) Move AU 1.2.5 to CG 7 3) Drop AU 1.1 -- it's on the Install page 4) Move 1.2.6 to CG 2.1 Yes, that looks right. 5) For now, have AU 1 just add a reference to CG. (But CG 3.3.6 makes no mention of a macro to reference to CG. Do we have one? If we don't, it will just be ordinary text.) Ah, I see. I remember there being some issues when Jonathan added an @include to the CG, but there wouldn't be any problems if we just make it a link (especially with ordinary text). Ok, go ahead. This doesn't depend on having an essay or the like, so there's no point waiting like the other doc rearrangements. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
running the regression tests on ubuntu - lilypond-texi2html.init error
Hi! I have installed a virtual machine with VirtualBox on my windows machine. I have installed ubuntu and all stuff for lilypond. I obtained the sources via git. I tried to run the regression tests but obtained the following error: WARNING: Unable to load the map file Undefined subroutine main:: called at /home/bronf/lilypond/Documentation/lilypond-texi2html.init line 743. make[3]: *** [out-test/collated-files.html] Error 25 rm /home/bronf/lilypond/out/xref-maps/collated-files.xref-map make[3]: Leaving directory `/home/bronf/lilypond/input/regression' make[2]: *** [local-test] Error 2 make[2]: Leaving directory `/home/bronf/lilypond/input/regression' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/bronf/lilypond' make: *** [test-baseline] Erreur 2 Is it because I have only version 1.78 of texi2html? However this is the only version proposed by ubuntu! Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: running the regression tests on ubuntu - lilypond-texi2html.init error
On Fri, Jul 17, 2009 at 08:39:58PM +0200, Frédéric Bron wrote: Is it because I have only version 1.78 of texi2html? However this is the only version proposed by ubuntu! I believe so. Try download texi2html 1.82 http://www.nongnu.org/texi2html/ then do ./configure make sudo make install Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change clef inside a grob-callback?
Okay, I feel like I could be a lot closer. I rewrote the function using
\applyOutput and a music-function.
Everything is fine except:
1) using \ottava confuses the function, and
2) the clef changes one chord too late.
At the moment, the \ottava issue is not a problem (I'll deal with that
later), but obviously the delayed clef change *is* a problem. In the
example below, the 3rd chord should be in the bass clef already because
the average staff-position is below middle C. I'm hoping I can use the
parser argument to get around it, but I don't know how. If there's some
way I could get \applyOutput to see the previous chord...
Can someone help?
Thanks.
- Mark
_
\version 2.13.2
#(define (first-note? note-grob)
(let* ((note-column (ly:grob-parent note-grob X))
(note-grob-array (ly:grob-object note-column 'note-heads))
(first-note (ly:grob-array-ref note-grob-array 0)))
(eq? note-grob first-note)))
#(define (get-avg-staff-pos note-grob)
(let* ((note-column (ly:grob-parent note-grob X))
(note-grob-array (ly:grob-object note-column 'note-heads))
(note-count (ly:grob-array-length note-grob-array)))
;; maybe there should be a ly:grob-array-map procedure...
(let loop ((staff-pos-sum 0) (i 0))
(if (= i note-count)
(/ staff-pos-sum note-count)
(loop (+ staff-pos-sum
(ly:grob-staff-position
(ly:grob-array-ref note-grob-array i)))
(1+ i))
#(define (ly:context-set-properties! context alist)
(for-each
(lambda (prop)
(ly:context-set-property! context (car prop) (cdr prop)))
alist))
#(define (auto-clef grob grob-origin context)
(if (and (grob::has-interface grob 'note-head-interface)
(first-note? grob))
(if ( (get-avg-staff-pos grob)
(ly:context-property context 'middleCPosition))
(ly:context-set-properties! context
'((clefGlyph . clefs.F)
(clefPosition . 2)
(middleCPosition . 6)))
(ly:context-set-properties! context
'((clefGlyph . clefs.G)
(clefPosition . -2)
(middleCPosition . -6))
#(define (EventChord? music)
(eq? (ly:music-property music 'name) 'EventChord))
autoClefs =
#(define-music-function (parser location music) (ly:music?)
(music-map
(lambda (x)
(if (EventChord? x)
#{ \applyOutput #'Staff #auto-clef $x #}
x))
music))
\relative {
\autoClefs { c e b d a c g b }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: running the regression tests on ubuntu - lilypond-texi2html.init error
Graham Percival wrote: On Fri, Jul 17, 2009 at 08:39:58PM +0200, Frédéric Bron wrote: Is it because I have only version 1.78 of texi2html? However this is the only version proposed by ubuntu! I believe so. Try download texi2html 1.82 http://www.nongnu.org/texi2html/ then do ./configure make sudo make install Cheers, - Graham What Graham proposes should be simple enough, but if you have any troubles you can try the lilybuntu remix I made a while back: http://prodet.hu/bert/lilydev/lilybuntu.iso I compiled texi2html 1.82 and included it in the remix. It also has all of the other build dependencies in place. Jon -- Jonathan Kulp http://www.jonathankulp.com Having been erased, The document you're seeking Must now be retyped. --a Haiku error message from GNU ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change clef inside a grob-callback?
On Fri, Jul 17, 2009 at 6:58 PM, Mark Poleskymarkpole...@yahoo.com wrote: Okay, I feel like I could be a lot closer. I rewrote the function using \applyOutput and a music-function. Everything is fine except: This all looks very confused. There is a mechanism to make voices switch between staves automatically. I suggest you piggy-back off that, generating a list of clefs with moments when to insert the clefs, similar to scm/autochange.scm ; then translate that list into a bunch of \skip and \clef commands. -- 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
(c) does not equal copyright
Is this something to address? A lot of LP source files use (c) and not Copyright, despite this legal advice from GNU: Always use the English word “Copyright”; by international convention, this is used worldwide, even for material in other languages. The copyright symbol “©” can be included if you wish (and your character set supports it), but it's not necessary. There is no legal significance to using the three-character sequence “(C)”, although it does no harm. http://www.gnu.org/licenses/gpl-howto.html - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
changing StreamEvent to stream-event
I noticed this thread from two years ago: http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00020.html Apparently, StreamEvent should be renamed stream-event. I'm happy to do that, but is it really as simple as changing these 2 lines (lines 12-13) in scm/define-event-classes.scm? Or is there a C++ file somewhere that also needs to be changed (or something else that I wouldn't know about)? - Mark 11 (define event-classes 12 '((() . (StreamEvent)) 13 (StreamEvent . 14 (RemoveContext ChangeParent Override Revert UnsetProperty 15 SetProperty music-event OldMusicEvent CreateContext Prepare 16 OneTimeStep Finish)) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Docs: IR 3.2 Graphical Object Interfaces: Sort interfaces.
Oops - in my earlier patch... Auto-sort all-grob-properties alist for docs. http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=062046e74d6995b99bb7669e4cd6490ba8b18656 ...I mistakenly removed a sort that I shouldn't have, which affects IR 3.2 Graphical Object Interfaces -- quite noticeably! http://kainhofer.com/~lilypond/Documentation/user/lilypond-internals/Graphical-Object-Interfaces.html: 3.2.1 break-alignable-interface 3.2.2 tuplet-bracket-interface 3.2.3 ottava-bracket-interface should be: 3.2.1 accidental-interface 3.2.2 accidental-placement-interface 3.2.3 accidental-suggestion-interface I've attached another patch which (I think) restores order to the list. Can someone check it for me? Thanks. - Mark 0001-Docs-IR-3.2-Graphical-Object-Interfaces-Sort-interfa.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing StreamEvent to stream-event
On Fri, Jul 17, 2009 at 8:02 PM, Mark Poleskymarkpole...@yahoo.com wrote: I noticed this thread from two years ago: http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00020.html Apparently, StreamEvent should be renamed stream-event. I'm happy to do that, but is it really as simple as changing these 2 lines (lines 12-13) in scm/define-event-classes.scm? Or is there a C++ file somewhere that also needs to be changed (or something else that I wouldn't know about)? - Mark 11 (define event-classes 12 '((() . (StreamEvent)) 13 (StreamEvent . 14 (RemoveContext ChangeParent Override Revert UnsetProperty 15 SetProperty music-event OldMusicEvent CreateContext Prepare 16 OneTimeStep Finish)) Yes, this is the only place that needs changing. But... event is also used in various places, like in define-music-types.scm: (types . (general-music event apply-output-event)) I'm pretty sure these types correspond to the Music, Event, and ApplyOutputEvent music expressions. Also, the corresponding classes are music-event, StreamEvent, apply-output-event. And there is a comment is stream_event.cc: /* TODO: Rename Stream_event - Event */ There are a lot of things to clean up in the Internals Reference; the question is where to start? For example, the IR should separate events from music expressions, but right now everything is bundled together. All of those other C++-only events (RemoveContext, ChangeParent, etc.) should be documented too. And should they be renamed along with StreamEvent? *** Sorry for the stream of thought. This has been bugging me lately too. :-) -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing StreamEvent to stream-event
Patrick McCarty wrote: There are a lot of things to clean up in the Internals Reference; the question is where to start? For example, the IR should separate events from music expressions, but right now everything is bundled together. All of those other C++-only events (RemoveContext, ChangeParent, etc.) should be documented too. And should they be renamed along with StreamEvent? *** Sorry for the stream of thought. This has been bugging me lately too. :-) No problem. I'm happy to help, but I don't claim to understand how the C++ stuff interacts with the scheme stuff. So I can help clean some stuff up, but only if I'm given explicit instructions, since I won't always understand the implications of these types of changes. If that scares you, then I can look to other places that I can help with, where I have a better understanding of the changes I'd be making. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Docs: IR 3.2 Graphical Object Interfaces: Sort interfaces.
On Fri, Jul 17, 2009 at 8:26 PM, Mark Poleskymarkpole...@yahoo.com wrote: Oops - in my earlier patch... Auto-sort all-grob-properties alist for docs. http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=062046e74d6995b99bb7669e4cd6490ba8b18656 ...I mistakenly removed a sort that I shouldn't have, which affects IR 3.2 Graphical Object Interfaces -- quite noticeably! http://kainhofer.com/~lilypond/Documentation/user/lilypond-internals/Graphical-Object-Interfaces.html: 3.2.1 break-alignable-interface 3.2.2 tuplet-bracket-interface 3.2.3 ottava-bracket-interface should be: 3.2.1 accidental-interface 3.2.2 accidental-placement-interface 3.2.3 accidental-suggestion-interface I've attached another patch which (I think) restores order to the list. Can someone check it for me? Looks fine, Mark. The order is restored. Go ahead and push. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB3: Infinite loop in patch stage for linux-x86::linux-headers
Hello, Building darwin-ppc::lilypond-installer from scratch, I'm experiencing what appears to be an infinite loop while in the patch stage for linux-x86::linux-headers. I have no idea what's going on, but the build.log is attached. The repeating text at the tail end of the log is where the infinite loop occurs. Thanks, Patrick *** Stage: patch (linux-headers, linux-x86) invoking cd /home/pnorcks/git/gub/target/linux-x86/src/linux-headers-2.4.34 yes yes | make ARCH=i386 oldconfig symlinks include/linux/version.h rm -f include/asm ( cd include ; ln -sf asm-i386 asm) /bin/sh scripts/Configure -d arch/i386/config.in # # Using defaults found in arch/i386/defconfig # scripts/Configure: line 551: .: .config-is-not.12306: file not found * * Code maturity level options * Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [N/y/?] (NEW) * * Loadable module support * Enable loadable module support (CONFIG_MODULES) [Y/n/?] Set version information on all module symbols (CONFIG_MODVERSIONS) [Y/n/?] Kernel module loader (CONFIG_KMOD) [Y/n/?] * * Processor type and features * Processor family (386, 486, 586/K5/5x86/6x86/6x86MX, Pentium-Classic, Pentium-MMX, Pentium-Pro/Celeron/Pentium-II, Pentium-III/Celeron(Coppermine), Pentium-4, K6/K6-II/K6-III, Athlon/Duron/K7, Opteron/Athlon64/Hammer/K8, Elan, Crusoe, Winchip-C6, Winchip-2, Winchip-2A/Winchip-3, CyrixIII/VIA-C3, VIA-C3-2) [Pentium-III/Celeron(Coppermine)] defined CONFIG_MPENTIUMIII Machine Check Exception (CONFIG_X86_MCE) [Y/n/?] Toshiba Laptop support (CONFIG_TOSHIBA) [N/y/m/?] (NEW) Dell laptop support (CONFIG_I8K) [N/y/m/?] (NEW) /dev/cpu/microcode - Intel IA32 CPU microcode support (CONFIG_MICROCODE) [N/y/m/?] (NEW) /dev/cpu/*/msr - Model-specific register support (CONFIG_X86_MSR) [N/y/m/?] (NEW) /dev/cpu/*/cpuid - CPU information support (CONFIG_X86_CPUID) [N/y/m/?] (NEW) BIOS Enhanced Disk Drive calls determine boot disk (EXPERIMENTAL) (CONFIG_EDD) [N/y/m/?] (NEW) High Memory Support (off, 4GB, 64GB) [off] defined CONFIG_NOHIGHMEM Math emulation (CONFIG_MATH_EMULATION) [N/y/?] (NEW) MTRR (Memory Type Range Register) support (CONFIG_MTRR) [N/y/?] (NEW) Symmetric multi-processing support (CONFIG_SMP) [Y/n/?] Maximum number of CPUs (2-32) (CONFIG_NR_CPUS) [32] Multi-node NUMA system support (CONFIG_X86_NUMA) [N/y/?] (NEW) Multiquad (IBM/Sequent) NUMAQ support (CONFIG_X86_NUMAQ) [N/y/?] (NEW) IBM x440 (Summit/EXA) support (CONFIG_X86_SUMMIT) [N/y/?] (NEW) * * General setup * Networking support (CONFIG_NET) [Y/n/?] PCI support (CONFIG_PCI) [Y/n/?] PCI access mode (BIOS, Direct, Any) [Any] defined CONFIG_PCI_GOANY ISA bus support (CONFIG_ISA) [Y/n/?] PCI device name database (CONFIG_PCI_NAMES) [Y/n/?] EISA support (CONFIG_EISA) [N/y/?] (NEW) MCA support (CONFIG_MCA) [N/y/?] (NEW) Support for hot-pluggable devices (CONFIG_HOTPLUG) [Y/n/?] * * PCMCIA/CardBus support * PCMCIA/CardBus support (CONFIG_PCMCIA) [Y/m/n/?] CardBus support (CONFIG_CARDBUS) [Y/n/?] Databook TCIC host bridge support (CONFIG_TCIC) [N/y/?] (NEW) i82092 compatible bridge support (CONFIG_I82092) [N/y/?] (NEW) i82365 compatible bridge support (CONFIG_I82365) [N/y/?] (NEW) * * PCI Hotplug Support * Support for PCI Hotplug (EXPERIMENTAL) (CONFIG_HOTPLUG_PCI) [N/y/m/?] (NEW) Compaq PCI Hotplug driver (CONFIG_HOTPLUG_PCI_COMPAQ) [N/y/m/?] (NEW) Save configuration into NVRAM on Compaq servers (CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM) [N/y/?] (NEW) IBM PCI Hotplug driver (CONFIG_HOTPLUG_PCI_IBM) [N/y/m/?] (NEW) SHPC PCI Hotplug driver (CONFIG_HOTPLUG_PCI_SHPC) [N/y/m/?] (NEW) Use polling mechanism for hot-plug events (for testing purpose) (CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE) [N/y/?] (NEW) PCI Express Hotplug driver (CONFIG_HOTPLUG_PCI_PCIE) [N/y/m/?] (NEW) Use polling mechanism for hot-plug events (for testing purpose) (CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE) [N/y/?] (NEW) System V IPC (CONFIG_SYSVIPC) [Y/n/?] BSD Process Accounting (CONFIG_BSD_PROCESS_ACCT) [N/y/?] (NEW) Sysctl support (CONFIG_SYSCTL) [Y/n/?] Kernel core (/proc/kcore) format (ELF, A.OUT) [ELF] defined CONFIG_KCORE_ELF Kernel support for a.out binaries (CONFIG_BINFMT_AOUT) [Y/m/n/?] Kernel support for ELF binaries (CONFIG_BINFMT_ELF) [Y/n/?] Kernel support for MISC binaries (CONFIG_BINFMT_MISC) [Y/m/n/?] Select task to kill on out of memory condition (CONFIG_OOM_KILLER) [N/y/?] (NEW) Power Management support (CONFIG_PM) [Y/n/?] Advanced Power Management BIOS support (CONFIG_APM) [N/y/m/?] (NEW) Ignore USER SUSPEND (CONFIG_APM_IGNORE_USER_SUSPEND) [N/y/?] (NEW) Enable PM at boot time (CONFIG_APM_DO_ENABLE) [N/y/?] (NEW) Make CPU Idle calls when idle (CONFIG_APM_CPU_IDLE) [N/y/?] (NEW) Enable console blanking using APM (CONFIG_APM_DISPLAY_BLANK) [N/y/?] (NEW) RTC stores time in GMT (CONFIG_APM_RTC_IS_GMT) [N/y/?] (NEW) Allow interrupts during APM BIOS calls (CONFIG_APM_ALLOW_INTS)
Re: changing StreamEvent to stream-event
On Fri, Jul 17, 2009 at 8:43 PM, Mark Poleskymarkpole...@yahoo.com wrote: Patrick McCarty wrote: There are a lot of things to clean up in the Internals Reference; the question is where to start? For example, the IR should separate events from music expressions, but right now everything is bundled together. All of those other C++-only events (RemoveContext, ChangeParent, etc.) should be documented too. And should they be renamed along with StreamEvent? *** Sorry for the stream of thought. This has been bugging me lately too. :-) No problem. I'm happy to help, but I don't claim to understand how the C++ stuff interacts with the scheme stuff. So I can help clean some stuff up, but only if I'm given explicit instructions, since I won't always understand the implications of these types of changes. If that scares you, then I can look to other places that I can help with, where I have a better understanding of the changes I'd be making. I think it would be better to work on other things right now. :-) Unless someone else jumps in and explains exactly how event classes work, that is. I'll put it on my TODO list. The IR really needs to be cleaned up wrt StreamEvents and related items. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
