Do we still need NR B.10 List of articulations?

2009-07-14 Thread Mark Polesky
Do we still need NR B.10 List of articulations? Now that NR B.6 The Feta font is organized a little better, the scripts are all together there, and easy enough to find, I think. B.10 is starting to feel a little redundant to me. - Mark ___

scripts.trill_element / scripts.trilelement

2009-07-14 Thread Mark Polesky
Do we need scripts.trill_element and scripts.trilelement? Is scripts.trilelement ever used? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: SVG status update

2009-07-14 Thread Patrick McCarty
On Tue, Jul 14, 2009 at 02:26:25PM +0900, Maximilian Albert wrote: Hi Patrick, So I spent a few hours today hacking on the SVG output, and here are some samples of the current output I have: [...] Great work!! Thanks! Just a random comment that occurred to me while skimming

Re: SVG status update

2009-07-14 Thread Patrick McCarty
On Mon, Jul 13, 2009 at 10:45:53PM -0700, Mark Polesky wrote: Patrick McCarty wrote: So I spent a few hours today hacking on the SVG output... What do you think? Wow. Nice work. I don't quite understand why the textual elements look rasterized, but I guess that's what you're still

using LyricHyphens in the docs

2009-07-14 Thread Mark Polesky
I think the Salve, Regína example in NR 2.8 Ancient Notation would be improved by using LyricHyphens. For example, instead of Sal- ve, Re- gí- na, use Sal -- ve, Re -- gí -- na,. Unless there's some ancient hyphen typesetting convention that I don't know about. The file involved is

Re: Broken make

2009-07-14 Thread Trevor Daniels
Carl Sorensen wrote Tuesday, July 14, 2009 5:04 AM Subject: Broken make End of the output is as follows: --init-file=/Users/Carl/lilypond-working/lilypond-texi2html.init out-www/lilypond-learning.texi ** `Updating old input files' doesn't appear in menus ** `When things don't work' is up

Re: SVG status update

2009-07-14 Thread Maximilian Albert
2009/7/14 Patrick McCarty pnor...@gmail.com: Unfortunately, this would be very difficult.  Elements are dumped into the SVG file in the order they occur in the page stencil, and (almost) every one is independently positioned as well. Ah, okay. That's what I though. Out of interest: At the

Fw: git access

2009-07-14 Thread Trevor Daniels
copied to -devel for comment Trevor - Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: Mark Polesky markpole...@yahoo.com; Graham Percival gra...@percival-music.ca Sent: Tuesday, July 14, 2009 8:33 AM Subject: Re: git access Mark, you wrote Tuesday, July 14,

Re: SVG status update

2009-07-14 Thread Patrick McCarty
On Tue, Jul 14, 2009 at 04:13:12PM +0900, Maximilian Albert wrote: 2009/7/14 Patrick McCarty pnor...@gmail.com: Unfortunately, this would be very difficult.  Elements are dumped into the SVG file in the order they occur in the page stencil, and (almost) every one is independently

Re: Fw: git access

2009-07-14 Thread Patrick McCarty
On Tue, Jul 14, 2009 at 08:35:10AM +0100, Trevor Daniels wrote: - Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: Mark Polesky markpole...@yahoo.com; Graham Percival gra...@percival-music.ca Sent: Tuesday, July 14, 2009 8:33 AM Subject: Re: git access Mark,

Re: @subsection foo should get name=foo

2009-07-14 Thread Trevor Daniels
Mark Polesky wrote Tuesday, July 14, 2009 6:54 AM I like the way the Feta font appendix page turned out, but I just assumed each @subsection foo would get name=foo. Each B.6.x item in the navbar links only to the top of the page, which is pointless IMO: B.6 The Feta font * B.6.1 Clefs

Re: Fw: git access

2009-07-14 Thread Trevor Daniels
Patrick McCarty wrote Tuesday, July 14, 2009 8:52 AM On Tue, Jul 14, 2009 at 08:35:10AM +0100, Trevor Daniels wrote: - Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: Mark Polesky markpole...@yahoo.com; Graham Percival gra...@percival-music.ca Sent: Tuesday, July

Re: scripts.trill_element / scripts.trilelement

2009-07-14 Thread Patrick McCarty
On Mon, Jul 13, 2009 at 11:25:27PM -0700, Mark Polesky wrote: Do we need scripts.trill_element and scripts.trilelement? Is scripts.trilelement ever used? The scripts.trill_element glyph is used to make the entire trill spanner line, so we definitely need that one. scripts.trilelement is not

Re: Do we still need NR B.10 List of articulations?

2009-07-14 Thread Patrick McCarty
On Mon, Jul 13, 2009 at 11:20:01PM -0700, Mark Polesky wrote: Do we still need NR B.10 List of articulations? Now that NR B.6 The Feta font is organized a little better, the scripts are all together there, and easy enough to find, I think. B.10 is starting to feel a little redundant to me.

Re: using LyricHyphens in the docs

2009-07-14 Thread Trevor Daniels
Mark Polesky wrote Tuesday, July 14, 2009 7:38 AM I think the Salve, Regína example in NR 2.8 Ancient Notation would be improved by using LyricHyphens. For example, instead of Sal- ve, Re- gí- na, use Sal -- ve, Re -- gí -- na,. Unless there's some ancient hyphen typesetting convention that I

Re: percussion and midi

2009-07-14 Thread Marc Hohl
Hello Alan, Alan Szlosek schrieb: Greetings, current Lilypond developers. I'm new here and would like some guidance. I'm interested in using Lilypond to compose music for high school drumlines. Hopefully my contributions will be useful to others. I'm not new to programming (Computer Science

Re: SVG status update

2009-07-14 Thread Maximilian Albert
Hi Patrick, Ah, okay. That's what I though. Out of interest: At the time when these elements get written into the SVG file, do they know about their mutual relationships? E.g., does a beam know which note heads it belongs to (or vice versa)? No.  The closest thing the elements possess that

Re: Do we still need NR B.10 List of articulations?

2009-07-14 Thread Trevor Daniels
Patrick McCarty wrote Tuesday, July 14, 2009 10:15 AM On Mon, Jul 13, 2009 at 11:20:01PM -0700, Mark Polesky wrote: Do we still need NR B.10 List of articulations? Now that NR B.6 The Feta font is organized a little better, the scripts are all together there, and easy enough to find, I

Re: proposal for doc rearrangement

2009-07-14 Thread Graham Percival
On Sat, Jul 11, 2009 at 12:01:22PM +0100, Trevor Daniels wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: lilypond-devel@gnu.org Sent: Saturday, July 11, 2009 11:14 AM Subject: proposal for doc rearrangement Here's my proposal for doc rearrangement

Re: @subsection foo should get name=foo

2009-07-14 Thread Trevor Daniels
Trevor Daniels wrote Tuesday, July 14, 2009 8:57 AM Mark Polesky wrote Tuesday, July 14, 2009 6:54 AM I like the way the Feta font appendix page turned out, but I just assumed each @subsection foo would get name=foo. Each B.6.x item in the navbar links only to the top of the page, which is

Re: proposal for doc+web sources

2009-07-14 Thread Graham Percival
On Sat, Jul 11, 2009 at 03:02:33PM -0600, Carl Sorensen wrote: On 7/11/09 4:21 AM, Graham Percival gra...@percival-music.ca wrote: Here's my proposal for the source/makefile view of documentation. (this is the big argument one) In general, I think these proposals are reasonable.

Re: Do we still need NR B.10 List of articulations?

2009-07-14 Thread Graham Percival
On Mon, Jul 13, 2009 at 11:20:01PM -0700, Mark Polesky wrote: Do we still need NR B.10 List of articulations? Yes, since the point is to show the \commands. Unless B.6 includes that info? I suppose that for many examples, scripts.staccato = \staccato is a safe enough assumption to make.

Re: @subsection foo should get name=foo

2009-07-14 Thread Graham Percival
On Tue, Jul 14, 2009 at 10:46:58AM +0100, Trevor Daniels wrote: Trevor Daniels wrote Tuesday, July 14, 2009 8:57 AM Yes. You can add a menu to the Feta font section and introduce each subsection with @node @subsection ... As we're in an appendix maybe this should be @node ...

Re: Syntax changes in translated documentation

2009-07-14 Thread Graham Percival
On Sat, Jul 11, 2009 at 03:36:30PM -0600, Carl Sorensen wrote: I can see perhaps two options: 1) Manually edit all of the lang/user/rhythms.itely files (aarghh!) 2) Write a convert-ly rule and manually run all of the lang/user/rhythms.itely files through convert-ly. Then I'll probably

Re: Do we still need NR B.10 List of articulations?

2009-07-14 Thread Reinhold Kainhofer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 14. Juli 2009 08:20:01 schrieb Mark Polesky: Do we still need NR B.10 List of articulations? Now that NR B.6 The Feta font is organized a little better, the scripts are all together there, and easy enough to find, I think. B.10 is

Adding note color handling to musicxml2ly

2009-07-14 Thread Bret Aarden
I've written a music search tool that exports MusicXML and colors the matching notes, and I'd like those colors to show up in LilyPond typesetting. There is no doubt a much more elegant way to do this, but the included patch works for me, and it would be great to see this functionality

Re: Syntax changes in translated documentation

2009-07-14 Thread Jean-Charles Malahieude
Le 11/07/2009 15:36, Carl Sorensen disait : OK, so I'm making syntax changes in autobeaming for LilyPond. I've worked through rhythms.itely and input/lsr (and I'll soon work through input/regression). Now my make doc is failing because of snippets in /de/user/rhythms.itely that use the old

Re: Broken make

2009-07-14 Thread Carl Sorensen
On 7/13/09 10:55 PM, Matthias Kilian k...@outback.escape.de wrote: On Mon, Jul 13, 2009 at 09:18:58PM -0700, Patrick McCarty wrote: I found this interesting link: https://savannah.cern.ch/bugs/?35556 It looks like cp -u will only work under Linux. John added the -u flag earlier this

Re: Snippets in doc compile different from stand-alone

2009-07-14 Thread Carl Sorensen
On 7/10/09 3:37 PM, Carl Sorensen c_soren...@byu.edu wrote: I'm trying to finish up the revisions to the autobeaming code. I've got it working just fine when I compile from the command line. But when snippets are included in the docs, they seem to compile different than from the

Re: New format for autobeaming rules

2009-07-14 Thread Carl Sorensen
I've posted a new patch set on Rietveld which I think is a release candidate. It has changes in all the translated rhythms.itely files so that all of the docs build properly. It has the revised snippets in input/new added to the repository. It has cleaned up all of the issues that Neil

Re: proposal for doc rearrangement

2009-07-14 Thread Trevor Daniels
Graham Percival wrote Tuesday, July 14, 2009 10:46 AM On Sat, Jul 11, 2009 at 12:01:22PM +0100, Trevor Daniels wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: lilypond-devel@gnu.org Sent: Saturday, July 11, 2009 11:14 AM Subject: proposal for doc

Re: SVG status update

2009-07-14 Thread Mark Polesky
Patrick McCarty wrote: P.S.: What's all this about text element being rasterized or converted to paths? I can edit them as regular text elements in Inkscape without problems. Now that I think about it, I'm not really sure what Mark was referring to. Possibly the low graphics quality at

Re: Adding note color handling to musicxml2ly

2009-07-14 Thread Carl Sorensen
On 7/13/09 1:35 AM, Bret Aarden bret.aar...@gmail.com wrote: I've written a music search tool that exports MusicXML and colors the matching notes, and I'd like those colors to show up in LilyPond typesetting. There is no doubt a much more elegant way to do this, but the included

Re: LM Errata

2009-07-14 Thread Trevor Daniels
Jonathans and Max Many thanks for the help on the LM. I'm applying your changes at the moment. A few comments below. I'm not sure about mesh vs. match. Mesh has a lot of other meanings which could cause confusion, so maybe there's a better term or phrase to use there. I don't like mesh

Re: LM Errata

2009-07-14 Thread Jonathan Wilkes
Automated Engraving The first lilypond example in this section is missing. Do you mean the one introduced with Here you see two chords, with accents and arpeggios? If so, it seems to be present on the kainhofer server. What symbols to engrave? The third example in this

Re: Adding note color handling to musicxml2ly

2009-07-14 Thread Reinhold Kainhofer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 14. Juli 2009 18:07:10 schrieb Carl Sorensen: On 7/13/09 1:35 AM, Bret Aarden bret.aar...@gmail.com wrote: There is no doubt a much more elegant way to do this, but the included patch works for me, [...] I saw that you had

Re: LM Errata

2009-07-14 Thread Trevor Daniels
Jonathan Wilkes wrote Tuesday, July 14, 2009 5:46 PM Automated Engraving The first lilypond example in this section is missing. Do you mean the one introduced with Here you see two chords, with accents and arpeggios? If so, it seems to be present on the kainhofer server. What symbols

Re: SVG status update

2009-07-14 Thread Patrick McCarty
On Tue, Jul 14, 2009 at 08:55:39AM -0700, Mark Polesky wrote: Patrick McCarty wrote: P.S.: What's all this about text element being rasterized or converted to paths? I can edit them as regular text elements in Inkscape without problems. Now that I think about it, I'm not really sure

Re: Broken make

2009-07-14 Thread Matthias Kilian
On Tue, Jul 14, 2009 at 09:32:16AM -0600, Carl Sorensen wrote: Just drop it. If the destination file has to be updated whenever the source file changes, let make(1) handle it. I dropped it in my local copy, and make succeeded. But I have not pushed the change to git, and won't. I don't

accessing accidentals with \tweak

2009-07-14 Thread Mark Polesky
In NR 5.3.4 The \tweak command, it says this: Notably the \tweak command cannot be used to modify stems, beams or accidentals, since these are generated later by note heads, rather than by music elements in the input stream.

Re: Patch: Delete intermediate ps files

2009-07-14 Thread Neil Puttock
2009/7/13 Maximilian Albert maximilian.alb...@googlemail.com: Thanks a lot! So does this close issue 685? Yes. What's the status about .log files being created on Windows mentioned there? Assuming this is a feature Windows users would like, it should be logged as a new issue (low priority

Re: accessing accidentals with \tweak

2009-07-14 Thread Neil Puttock
2009/7/14 Mark Polesky markpole...@yahoo.com: 1) are the results of this technique undefined? Was it just luck   that these worked? Of course not. You're just accessing the accidental indirectly. Perhaps we should amend the documentation for \tweak: it can't be used to modify stems, beams or

Re: Patch: Delete intermediate ps files

2009-07-14 Thread Trevor Daniels
Neil Puttock wrote Tuesday, July 14, 2009 9:34 PM 2009/7/13 Maximilian Albert maximilian.alb...@googlemail.com: Thanks a lot! So does this close issue 685? Yes. What's the status about .log files being created on Windows mentioned there? Assuming this is a feature Windows users would

Re: SVG status update

2009-07-14 Thread Patrick McCarty
On Tue, Jul 14, 2009 at 2:27 AM, Maximilian Albertmaximilian.alb...@googlemail.com wrote: Hi Patrick, Ah, okay. That's what I though. Out of interest: At the time when these elements get written into the SVG file, do they know about their mutual relationships? E.g., does a beam know which

Re: Broken make

2009-07-14 Thread John Mandereau
Please junk (without blindly reverting) those -u flags I added. I've started offline cleaning up translated docs generation, one planned feature is HTML and PDF output of translations directly in Documentation/user, so this multiple css file copy issue and other ones will have gone. Greetings

Re: Broken make

2009-07-14 Thread Carl Sorensen
On 7/14/09 3:33 PM, John Mandereau john.mander...@gmail.com wrote: Please junk (without blindly reverting) those -u flags I added. I've started offline cleaning up translated docs generation, one planned feature is HTML and PDF output of translations directly in Documentation/user, so this

Re: accessing accidentals with \tweak

2009-07-14 Thread Carl Sorensen
On 7/14/09 2:15 PM, Mark Polesky markpole...@yahoo.com wrote: In NR 5.3.4 The \tweak command, it says this: Notably the \tweak command cannot be used to modify stems, beams or accidentals, since these are generated later by note heads, rather than by music elements in the input

Re: New format for autobeaming rules

2009-07-14 Thread n . puttock
Carl, I haven't commenting on them directly, but there are quite a few indentation errors in the .scm files. http://codereview.appspot.com/88155/diff/95/1147 File Documentation/topdocs/NEWS.tely (right): http://codereview.appspot.com/88155/diff/95/1147#newcode69 Line 69: section 1.2.4 Beams,

Re: PATCH: Consolidate autobeaming to one property that controls it

2009-07-14 Thread Neil Puttock
2009/7/12 Carl Sorensen c_soren...@byu.edu: I don't know.  I didn't write displayLilyMusic; that was Nicolas IIRC.  I do know that \time 3/4 executes those functions.  It's really easy to go forward in the parse tree (i.e. from \time 3/4 to \set Timing), but I don't know any way to

Re: Snippets in doc compile different from stand-alone

2009-07-14 Thread Neil Puttock
2009/7/14 Carl Sorensen c_soren...@byu.edu: Can we get something in the CG about this problem, and how to run update-snippets.py to fix things, or at least a statement about the easiest way to solve the problem? It's already mentioned in CG (in passing), but I got the impression when I

Re: accessing accidentals with \tweak

2009-07-14 Thread Trevor Daniels
Neil Puttock wrote Tuesday, July 14, 2009 9:54 PM Perhaps we should amend the documentation for \tweak: it can't be used to modify stems, beams or accidentals *directly*. I've done this, but it would be better to be able to refer to a description of how to use Mark's neat technique in NR

Re: New format for autobeaming rules

2009-07-14 Thread Neil Puttock
2009/7/14 Carl Sorensen c_soren...@byu.edu: It has cleaned up all of the issues that Neil identified, with the exception of default autobeaming for 3/4 time.  I never got any concurrence for setting it back to (3), so it's left at (1 1 1). I think (3) is preferable, at least for quavers. The

Re: Snippets in doc compile different from stand-alone

2009-07-14 Thread Carl Sorensen
On 7/14/09 4:11 PM, Neil Puttock n.putt...@gmail.com wrote: 2009/7/14 Carl Sorensen c_soren...@byu.edu: Can we get something in the CG about this problem, and how to run update-snippets.py to fix things, or at least a statement about the easiest way to solve the problem? It's already

Re: LM Errata

2009-07-14 Thread Jonathan Wilkes
I'm viewing from the web. Both show up on ie explorer but not on firefox (winxp sp3). They look fine here with both IE and Firefox (3.0.11) on Vista.  Anyway, it doesn't seem to be a problem with the docs, so I'll go ahead and push the changes you suggested. You should be able to

Re: [PATCH] Markup commands \left-brace and \right-brace

2009-07-14 Thread Neil Puttock
2009/4/25 Neil Puttock n.putt...@gmail.com: 2009/4/23 Jan Nieuwenhuizen janneke-l...@xs4all.nl: I don't really care about that, but it would be nice to split-out the (find-brace lambda to a generic function. OK, I'll farm it out to lily-library.scm and upload a new patch. A new patch set is

Re: PATCH: Consolidate autobeaming to one property that controls it

2009-07-14 Thread Carl Sorensen
On 7/14/09 4:08 PM, Neil Puttock n.putt...@gmail.com wrote: 2009/7/12 Carl Sorensen c_soren...@byu.edu: I don't know.  I didn't write displayLilyMusic; that was Nicolas IIRC.  I do know that \time 3/4 executes those functions.  It's really easy to go forward in the parse tree (i.e. from

Re: lilypond-devel Digest, Vol 80, Issue 53

2009-07-14 Thread Bret Aarden
I was about to suggest the same. The \revert is never inserted. But then, you don't want an \override anyway, because the setting should only apply to that one note, which has the color attribute, not to all following ones. So, you really want \once\override. Ah, I had forgotten about the

Re: Adding note color handling to musicxml2ly

2009-07-14 Thread Bret Aarden
Ah, drat, I used the wrong subject. Here it is again. I was about to suggest the same. The \revert is never inserted. But then, you don't want an \override anyway, because the setting should only apply to that one note, which has the color attribute, not to all following ones. So, you really