Do we still need NR B.10 List of articulations?
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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
scripts.trill_element / scripts.trilelement
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
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 through your samples: When moving individual elements (like note heads, staff lines, beams, etc.) with the mouse, I noticed that they all moved individually because they are all at the toplevel of the SVG file. Would it be possible to group elements belonging together (visually or conceptually), like the staff lines, note heads with their stems and beams, etc.? I have no clue how Lilypond's SVG output works internally so this may be highly nontrivial (for example, I noticed that the final bar line in bach-schenker is split into three parts, which indicates that these are not drawn in one go, perhaps even at very different time steps). But if it's simple to achieve it might be a good addition. 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. Some of the related stencils are dumped consecutively (e.g. the horizontal StaffSymbol lines), but I imagine this would require some postprocess optimization, which is an interesting feature request. I'll add this to the wiki. Anyway, thanks again for your excellent work on this. I'm happy to be working on it, and I'm glad you appreciate it. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
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 working on. Not having studied too much SVG, I use the poor man's SVG test: crank up the page zoom to full blast! That's because the textual elements *are* rasterized. :-) I'm only working on the on-the-fly conversions for the SVG fonts (Emmentaler and Aybabtu). I can imagine on-the-fly conversions for everything else happening eventually, but right now, the rendering for normal text will depend on the fonts you have installed on your system. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
using LyricHyphens in the docs
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 input/manual/ancient-headword.ly. There may be others, but I just noticed it there. Anyone care to comment on that? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken make
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 for `Updating old input files', but has no menu entry for this node ** No node following `Updating old input files' in menu, but `Troubleshooting (taking it all apart)' follows in sectionning WARNING: Unable to load the map file WARNING: Unable to find node 'Updating old files' in book . *** Unknown node in menu entry `Updating old files' (in out-www/working.texi l. 684) cp -u /Users/Carl/lilypond-working/Documentation/lilypond-blue.css /Users/Carl/lilypond-working/Documentation/lilypond-ie-fixes.css /Users/Carl/lilypond-working/Documentation/lilypond-mccarty.css /Users/Carl/lilypond-working/Documentation/lilypond.css out-www/lilypond-learning/ cp: illegal option -- u usage: cp [-R [-H | -L | -P]] [-fi | -n] [-pvX] source_file target_file cp [-R [-H | -L | -P]] [-fi | -n] [-pvX] source_file ... target_directory make[4]: *** [out-www/lilypond-learning/index.html] Error 64 make[3]: *** [WWW-2] Error 2 make[2]: *** [WWW-2] Error 2 make[1]: *** [WWW-2] Error 2 make: *** [doc] Error 2 Carl There is an earlier error from texi2html about missing menu entries which looks suspicious. I added a new subsection Common errors to LM 5.2 When things don't work recently in working.itely. The update has made it sucessfully to kainhofer, but seems to be giving you trouble. Maybe working.itely is corrupt in your branch? Trevor ___ 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: SVG status update
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 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)? Some of the related stencils are dumped consecutively (e.g. the horizontal StaffSymbol lines), but I imagine this would require some postprocess optimization, which is an interesting feature request. I'll add this to the wiki. Following my question above, here is another random idea: Would it be possible to (perhaps optionally) set the id attributes of the elements to something meaningful from which at least the function of this element could be deduced, like staffline01 or barline42 or something similar? This could be a first step to enable some postprocessing. BTW, I'm not saying that you should implement this. I'm just interested whether it would be possible. I'm happy to be working on it, and I'm glad you appreciate it. Yes, I do (and apparently I'm not alone). :-) Max 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: git access
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, 2009 5:50 AM Trevor Daniels wrote: Next try a push with --dry-run. Enter: git push --dry-run -v ssh+git://sv/srv/git/lilypond.git/ $ gt push --dry-run -v ssh+git://sv/srv/git/lilypond.git/ warning: You did not specify any refspecs to push, and the current remote warning: has not configured any push refspecs. The default action in this warning: case is to push all matching refspecs, that is, all branches warning: that exist both locally and remotely will be updated. This may warning: not necessarily be what you want to happen. warning: warning: You can specify what action you want to take in this case, and warning: avoid seeing this message again, by configuring 'push.default' to: warning: 'nothing' : Do not push anything warning: 'matching' : Push all matching branches (default) warning: 'tracking' : Push the current branch to whatever it is tracking warning: 'current' : Push the current branch Pushing to ssh+git://sv/srv/git/lilypond.git/ To ssh+git://sv/srv/git/lilypond.git/ = [up to date] master - master Everything up-to-date So far so good? Yes, I think so. I've never seen this sequence of warning messages, even though I do not have an entry for push.default in git config. You will have a more recent version of git than I do, so maybe this warning is a recent addition. I'm on 1.5.4.2.1161.g1a6f0. Yes, I just checked; push.default seems to have been added around 1.6. Do you recommend setting 'push.default' to 'nothing'? No; you don't really want to have to specify source and destination on every push. In the simple git arrangement used by LilyPond the default matching is probably the best option. But as I'm not an expert, and don't have git 1.6, I'll copy to -devel for comment. This is exciting (and a little scary)! When you're ready to push for real, try making a small change to the text of a doc file first. Anything you do can always be reverted, so no need to worry. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
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 positioned as well. 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 relates to this is their *grob cause*. For example the NoteHead grob is often the grob cause for the noteheads.s2 glyph. Some of the related stencils are dumped consecutively (e.g. the horizontal StaffSymbol lines), but I imagine this would require some postprocess optimization, which is an interesting feature request. I'll add this to the wiki. Following my question above, here is another random idea: Would it be possible to (perhaps optionally) set the id attributes of the elements to something meaningful from which at least the function of this element could be deduced, like staffline01 or barline42 or something similar? This could be a first step to enable some postprocessing. BTW, I'm not saying that you should implement this. I'm just interested whether it would be possible. That's possible, but it would be much easier to insert comments based on the grob cause mentioned above. It would look something like !-- NoteHead -- path transform=translate(...) scale(...) d=... / Would that be reasonable? 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 100% zoom in Firefox. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: git access
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, you wrote Tuesday, July 14, 2009 5:50 AM Trevor Daniels wrote: Next try a push with --dry-run. Enter: git push --dry-run -v ssh+git://sv/srv/git/lilypond.git/ $ gt push --dry-run -v ssh+git://sv/srv/git/lilypond.git/ warning: You did not specify any refspecs to push, and the current remote warning: has not configured any push refspecs. The default action in this warning: case is to push all matching refspecs, that is, all branches warning: that exist both locally and remotely will be updated. This may warning: not necessarily be what you want to happen. warning: warning: You can specify what action you want to take in this case, and warning: avoid seeing this message again, by configuring 'push.default' to: warning: 'nothing' : Do not push anything warning: 'matching' : Push all matching branches (default) warning: 'tracking' : Push the current branch to whatever it is tracking warning: 'current' : Push the current branch Pushing to ssh+git://sv/srv/git/lilypond.git/ To ssh+git://sv/srv/git/lilypond.git/ = [up to date] master - master Everything up-to-date So far so good? Yes, I think so. I've never seen this sequence of warning messages, even though I do not have an entry for push.default in git config. You will have a more recent version of git than I do, so maybe this warning is a recent addition. I'm on 1.5.4.2.1161.g1a6f0. Yes, I just checked; push.default seems to have been added around 1.6. Yes, no need to worry. This giant warning was added in 1.6.3. When I first tried to push with no arguments, I got this warning too. Do you recommend setting 'push.default' to 'nothing'? No; you don't really want to have to specify source and destination on every push. In the simple git arrangement used by LilyPond the default matching is probably the best option. But as I'm not an expert, and don't have git 1.6, I'll copy to -devel for comment. I set 'push.default' to 'nothing' but it's really personal choice. Since pushing to master is (IMO) a relatively serious thing, I would rather type the more verbose version: $ git push origin master than accidentally type git push when I meant to type git pull. This way, I can differentiate between pushing and pulling more easily, and it provides a safeguard in that $ git push will no longer work. HTH, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @subsection foo should get name=foo
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 * B.6.2 Time Signatures * B.6.3 Numbers Is there an easy way to improve that? Yes. You can add a menu to the Feta font section and introduce each subsection with @node @subsection ... But it's easy to make mistakes in doing this. Are you able to check texinfo syntax and refs? If not, send any patch to me (or someone who can compile the docs for checking) before pushing. A broken doc breaks all LP compiles! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: git access
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 14, 2009 8:33 AM Subject: Re: git access Mark, you wrote Tuesday, July 14, 2009 5:50 AM Trevor Daniels wrote: Next try a push with --dry-run. Enter: git push --dry-run -v ssh+git://sv/srv/git/lilypond.git/ $ gt push --dry-run -v ssh+git://sv/srv/git/lilypond.git/ warning: You did not specify any refspecs to push, and the current remote warning: has not configured any push refspecs. The default action in this warning: case is to push all matching refspecs, that is, all branches warning: that exist both locally and remotely will be updated. This may warning: not necessarily be what you want to happen. warning: warning: You can specify what action you want to take in this case, and warning: avoid seeing this message again, by configuring 'push.default' to: warning: 'nothing' : Do not push anything warning: 'matching' : Push all matching branches (default) warning: 'tracking' : Push the current branch to whatever it is tracking warning: 'current' : Push the current branch Pushing to ssh+git://sv/srv/git/lilypond.git/ To ssh+git://sv/srv/git/lilypond.git/ = [up to date] master - master Everything up-to-date So far so good? Yes, I think so. I've never seen this sequence of warning messages, even though I do not have an entry for push.default in git config. You will have a more recent version of git than I do, so maybe this warning is a recent addition. I'm on 1.5.4.2.1161.g1a6f0. Yes, I just checked; push.default seems to have been added around 1.6. Yes, no need to worry. This giant warning was added in 1.6.3. When I first tried to push with no arguments, I got this warning too. Do you recommend setting 'push.default' to 'nothing'? No; you don't really want to have to specify source and destination on every push. In the simple git arrangement used by LilyPond the default matching is probably the best option. But as I'm not an expert, and don't have git 1.6, I'll copy to -devel for comment. I set 'push.default' to 'nothing' but it's really personal choice. Since pushing to master is (IMO) a relatively serious thing, I would rather type the more verbose version: $ git push origin master than accidentally type git push when I meant to type git pull. This way, I can differentiate between pushing and pulling more easily, and it provides a safeguard in that $ git push will no longer work. Sounds sensible; I have quite different methods for push and pull too. Mark, seems like nothing is the best choice. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scripts.trill_element / scripts.trilelement
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 used, but IMO, it's a bad idea to be removing a glyph from a font (unless it's being replaced by a superior alternative). -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do we still need NR B.10 List of articulations?
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. I'm okay with removing it. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using LyricHyphens in the docs
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 don't know about. The file involved is input/manual/ancient-headword.ly. There may be others, but I just noticed it there. Anyone care to comment on that? I know essentially nothing about ancient music, but as these examples were set by experts I assume they know what should be done. I doubt that ancient music was ever typeset using modern lyric spacing hyphens, not least because the ligatures are conventionally grouped closely together, and the syllable (with the hyphen) almost always sits neatly under them. Trevor ___ 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: percussion and midi
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 major), but am new to the C++ Scheme setup in use here. My first task is to make accent marks translate into a dynamic step up in the MIDI output. I would assume that I need to do some work at the iteration stage, as well as the MIDI translation stage. Does an \accent get turned into an articulation somehow by ly/script-init.ly http://script-init.ly? I'm probably wrong ... I imagine I'll also have to do a check for whether we're dealing with drummode, and conditionally modify some node with extra dynamic information. Can anyone point me in a more clear direction? Thanks. I don't know much about MIDI in lilypond, but there has been some discussion about articulation and MIDI on the lilypond-user mailing list, perhaps the following link might help you? http://lists.gnu.org/archive/html/lilypond-user/2009-06/msg00029.html Marc -- Alan Szlosek :: http://www.greaterscope.net ___ 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: SVG status update
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 relates to this is their *grob cause*. For example the NoteHead grob is often the grob cause for the noteheads.s2 glyph. OK, thanks for the explanation. I seem to remember that some time ago I was in a similar situation, where I wanted to find out some elements' parent(s) from my code but was unable to, probably for precisely this reason. Do you happen to know at what stage of the engraving process elements are aware of their mutual relationships, just in case I stumble across this problem again in the future? That's possible, but it would be much easier to insert comments based on the grob cause mentioned above. It would look something like !-- NoteHead -- path transform=translate(...) scale(...) d=... / Would that be reasonable? Sure. But as I said, as far as I'm concerned you don't need to spend time on this right now (you've got lots of other things to do, I suppose). It may even be the case that some people don't want the comments in their files because they blow up the file size. But in case we want to have automatic grouping in the future (either natively or via some postprocessing) it's good to know that inserting comments like this is an option. Cheers, Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do we still need NR B.10 List of articulations?
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 think. B.10 is starting to feel a little redundant to me. I'm okay with removing it. I am too, but note all the index entries in B.10 -- they must be relocated to the appropriate part of B.6. Also the subheading for that section of B.6 should be renamed to something like Scripts and articulations, Scripts for articulations,..., so someone searching for articulations can find it. There may be refs to B.10 that will need adjusting too. And deleting script-chart.ly will break the docs and compiling unless the same change has been applied in all languages. Trevor Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc rearrangement
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 from a doc writer's perspective. ( - minus, + plus ) LM - background essay - about the docs(nobody reads it there, anyway) I'd still like to see some sort of overview of the available documentation early in the LM. Perhaps just the About the Learning Manual section with a reworked list like About the documentation, perhaps renamed Other documention. For the sake of argument, assume that users always see the new website Manuals page. What else should users see? - I agree that we should encourage them to click on HTML images, but that's done in the tutorial. - I'm not certain if we should mention that the mailist archives are a for of documentation, but if you think that's important, I don't mind keeping that somewhere. I might make it more prominent on the web Community-Contact page, though. - init files: this is only applicable to tweaking, but IIRC that's in the LM already. Basically, I think that LM 1.2 wasn't a success. Either because users didn't notice it (since the jumping in point was LM 2), or because it included *too much* information. Nobody could get a sense of the docs at glance. + expand 2.1.1 Compiling a file into: + LM 1.1 Compiling with LilyPond and LilyPad Do we want anyone to use LilyPad? If we still ship it, then we should describe it. For Windows and OSX; the linux version just has the command-line. Don't like to use Compiling in a heading. It will not be understood by computer-non-literati. I'm fine with changing the title. My hope is that they'll have read Text Input before they see the LM, but you're right that we shouldn't assume they have any info before they read the LM. + LM 1.2 Alternate editors Not a suitable name if setup stuff is coming here. The OS-specific setup (which IIRC is only for osx) is going on the Download page, so this section really _will_ be for alternate editors. - (possibly) Working on LilyPond Projects Quite a bit of the material here is suitable for the LM, but the organisation is poor. (We didn't get to this during GDP). I think we might need to dissect it, with bits staying and bits going to the AU. Ok, that's fine with me. I'm also thinking that the LM could use a short conclusion (mainly pointing out the other parts of the docs that should be consulted next), so we could keep a short LM 5 with some old material and a conclusion. AU - install, compile. (that'll be in the CG and available as INSTALL.txt in source) Should not the simple instructions for installing GUB-built binaries remain? IMO, that deserves to be on the website on the Download pages (again, assuming that it's available in pdf+info forms for those who prefer such formats). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @subsection foo should get name=foo
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 pointless IMO: B.6 The Feta font * B.6.1 Clefs * B.6.2 Time Signatures * B.6.3 Numbers Is there an easy way to improve that? 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 ... @appendixsubsec ... ? Graham ? But it's easy to make mistakes in doing this. Are you able to check texinfo syntax and refs? If not, send any patch to me (or someone who can compile the docs for checking) before pushing. A broken doc breaks all LP compiles! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc+web sources
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. Actually, giving it some more thought, there *is* some tension between the release cycles of the main source tree and the website. That said, I still think we should distribute some of the website info along with the release-specific docs. What about having the texinfo in *both* places, but don't edit them in the web/ branch? Basically, it would work vaguely like LSR. The main website texinfo files would be in main/, but a dedicated website person would import those files into a web/ branch (or repo) from time to time? This way, - we can include a snapshot of the website in the doc build from main/. Texinfo cross-references and the like work easily, so the docs (user information) will be more coherent. - doc writers and translators only work on main/ (or translations) - we retain a house of sober second thought (sorry, Canadian political joke there... although AFAIK it would work in any country with a distinct second layer of representative, such as the US Senate or the UK House of Lords) ... let me try this again: The online website won't get screwed up if somebody makes a mistake in the main/ branch. The dedicated website person will check the website before importing altered texinfo files from main/ to the web/ repo. - really website-specific material, such as the google analytics stuff, would only be stored in the web/ repo. - if desired, we could even alter the texi2html tweaking, css file, or even alter the main texinfo file, depending on whether it was the online website or a local snapshot for distribution with the release. I'm not certain if we'd want to change the CSS at all (a different color scheme for the local copy?), but it could well be a good idea to change the Download page. I mean, if somebody's downloaded a lilypond-doc package in debian or whatever, they probably already have lilypond package. So maybe we'd omit those pages... also, the Search box won't do much good. etc. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do we still need NR B.10 List of articulations?
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. However, I don't think there's any \ufermata command, nor a \circlus. Umm, so it's not a safe assumption to make. :) Now, there might be a way to automatically generate B.10, in which case we could alter that to fit inside B.6... but this might require looking at the parser. I'm not certain how this part of the internals fits together. Anyway, if that could be done, that would be quite nice. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @subsection foo should get name=foo
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 ... @appendixsubsec ... ? I believe it should be @node @unnumberedsubsec You can use them inside an @appendicsec, and since the html pages are split based on numbers, we want an @unnumbered... there. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax changes in translated documentation
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 still have to manually edit all of the rhythms.itely, because the rule will be a NOT_SMART rule. I think I favor option 2 (although I haven't written the rule yet). Yes, #2. And if you ever add a NOT_SMART rule, you should immediately write a NEWS entry. (a change like the autobeaming stuff deserves a NEWS entry anyway, but as a general rule fit for adding to the CG, any change requiring a NOT_SMART rule needs a NEWS entry) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Do we still need NR B.10 List of articulations?
-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 starting to feel a little redundant to me. Actually, there is one really huge difference: NR B.6 shows the glyph names, while NR B.10 shows the actual lilypond commands to bet the corresponding articulation! So, from the feta chart alone, you only see that you can get e.g. nice espressivo, but you don't see how to obtain it in your lilypond code. B.6 shows scripts.espr, while the actual lilypond command is \espressivo... Similarly, up/down versions are shown as two glyphs in B.6, while they are just one lilypond command that automatically selects the correct glyph. Thus, I don't think that B.10 can be removed. 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) iD8DBQFKXHCRTqjEwhXvPN0RAhE3AKCLXNgUBg8+j8MhUr64+aIUDsUE0wCglJiQ ixFOC6WHG2k71Aezbu+OFnw= =ys16 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Adding note color handling to musicxml2ly
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
added to the musicxml2ly distribution.
-Bret.
From d861198ea6a58696ce52cfe17f63dd8aeee6ed58 Mon Sep 17 00:00:00 2001
From: Bret Aarden aar...@bret-aarden-2.local
Date: Mon, 13 Jul 2009 03:17:00 -0400
Subject: [PATCH] Added code to musicxml2ly.py and musicexp.ly to handle color
overrides on notes.
---
python/musicexp.py | 22 --
scripts/musicxml2ly.py |2 ++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/python/musicexp.py b/python/musicexp.py
index 9ebdb70..5f88818 100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -100,7 +100,17 @@ class Output_printer:
return
self.unformatted_output (str)
-
+
+def print_note_color (self, object, rgb=None):
+if rgb:
+str = (\override %s #'color = #(rgb-color %s %s %s) %
+ (object, rgb[0], rgb[1], rgb[2]))
+else:
+str = \\revert %s #'color % object
+self.newline()
+self.add_word(str)
+self.newline()
+
def add_word (self, str):
if (len (str) + 1 + len (self._line) self._line_len):
self.newline()
@@ -1436,6 +1446,10 @@ class NoteEvent(RhythmicEvent):
def print_ly (self, printer):
for ev in self.associated_events:
ev.print_ly (printer)
+if hasattr(self, 'color'):
+printer.print_note_color(NoteHead, self.color)
+printer.print_note_color(Stem, self.color)
+printer.print_note_color(Beam, self.color)
if self.pitch:
self.pitch.print_ly (printer)
printer (self.pitch_mods ())
@@ -1443,7 +1457,11 @@ class NoteEvent(RhythmicEvent):
printer (self.drum_type)
self.duration.print_ly (printer)
-
+if hasattr(self, 'color'):
+printer.print_note_color(NoteHead)
+printer.print_note_color(Stem)
+printer.print_note_color(Beam)
+
class KeySignatureChange (Music):
def __init__ (self):
Music.__init__ (self)
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index ba7be37..1e31e8f 100644
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -1846,6 +1846,8 @@ def musicxml_note_to_lily_main_event (n):
if event:
event.duration = musicxml_duration_to_lily (n)
+if hasattr(n, 'color'):
+event.color = hex_to_color(n.color)
noteheads = n.get_named_children ('notehead')
for nh in noteheads:
--
1.6.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax changes in translated documentation
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 syntax and have, in many cases, been removed from rhythms.itely. What shall I do? 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 still have to manually edit all of the rhythms.itely, because the rule will be a NOT_SMART rule. I think I favor option 2 (although I haven't written the rule yet). Any hints from the devel team as to how to best accomplish this? I looked in the CG (thanks, Graham ;) but couldn't find anything describing how to deal with this circumstance. Thanks, Carl Hi Carl, Sorry to bother with this : I pushed on Saturday evening a fully translated rhythms.itely into French. It resides only on the lilypond/translation branch in order to be proof-read before merged into master. I might try, though I consider it /not so smart/, to apply your your changes to this updated version. Let me know what is your preference in this matter... I'm going back to updating the web branch. Cheers Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken make
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 month to avoid some error messages (likely different from yours). So, we can either remove the -u flag or find a different solution that still provides the fix John made. 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 have enough confidence that I know the build process well to be sure I'm not breaking something. I'll let John Mandereau get to it when he has the time. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
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 command line.
I'll take a snippet that's in the docs (not one that's included as a file),
copy it to a .ly file, wrap it in \relative c''{}, and everything works
fine.
But when I compile the docs with make doc, the snippet doesn't work.
Is there a different version of LilyPond called when make doc is running? I
can't figure out what the story is. Any clues would be appreciated.
I finally discovered what was going on. The snippet was being replaced with
the version from one of the translated documents. I actually fought with
this last December, and Neil gave me this answer:
On 12/15/08 1:49 PM, Neil Puttock n.putt...@gmail.com wrote:
Hi Carl,
The make web choked on trying to run a lilypond snippet. I looked at the
snippet, and the reason that lilypond choked was because the snippet was the
*old* version of the snippet, not the new version of the snippet. So the
last lines of the make web output aren't likely to be helpful. If there are
helpful lines in the output, they would be likely to show up somewhere
above, where snippets are extracted from the .itely files.
The old snippets were in the translations; running update-snippets.py
copied the syntax changes over from user.
Thanks, Neil. I suspected that they were in the translations, but I had no
idea how to get them over.
Carl
Neil,
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?
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
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 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). Please review and let me know of any further issues. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc rearrangement
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 rearrangement Here's my proposal for doc rearrangement from a doc writer's perspective. ( - minus, + plus ) LM - background essay - about the docs(nobody reads it there, anyway) I'd still like to see some sort of overview of the available documentation early in the LM. Perhaps just the About the Learning Manual section with a reworked list like About the documentation, perhaps renamed Other documention. For the sake of argument, assume that users always see the new website Manuals page. What else should users see? Is this always guaranteed? Actually, all I'm suggesting is that something like the information on the Manuals page could sensibly be in the LM, (and in the other manuals too, for that matter). Readers can then see where they should go if the manual they are reading does not contain what they are seeking. - I agree that we should encourage them to click on HTML images, but that's done in the tutorial. - I'm not certain if we should mention that the mailist archives are a for of documentation, but if you think that's important, I don't mind keeping that somewhere. I might make it more prominent on the web Community-Contact page, though. - init files: this is only applicable to tweaking, but IIRC that's in the LM already. Basically, I think that LM 1.2 wasn't a success. Either because users didn't notice it (since the jumping in point was LM 2), or because it included *too much* information. Nobody could get a sense of the docs at glance. I think it was the latter. + expand 2.1.1 Compiling a file into: + LM 1.1 Compiling with LilyPond and LilyPad Do we want anyone to use LilyPad? If we still ship it, then we should describe it. For Windows and OSX; the linux version just has the command-line. Seems at the moment we don't ;) But you're right. We need to describe it, and its limitations. Don't like to use Compiling in a heading. It will not be understood by computer-non-literati. I'm fine with changing the title. My hope is that they'll have read Text Input before they see the LM, but you're right that we shouldn't assume they have any info before they read the LM. + LM 1.2 Alternate editors Not a suitable name if setup stuff is coming here. The OS-specific setup (which IIRC is only for osx) is going on the Download page, so this section really _will_ be for alternate editors. Ah, OK. It wasn't clear in your original note. - (possibly) Working on LilyPond Projects Quite a bit of the material here is suitable for the LM, but the organisation is poor. (We didn't get to this during GDP). I think we might need to dissect it, with bits staying and bits going to the AU. Ok, that's fine with me. I'm also thinking that the LM could use a short conclusion (mainly pointing out the other parts of the docs that should be consulted next), so we could keep a short LM 5 with some old material and a conclusion. I'm happy with that. AU - install, compile. (that'll be in the CG and available as INSTALL.txt in source) Should not the simple instructions for installing GUB-built binaries remain? IMO, that deserves to be on the website on the Download pages (again, assuming that it's available in pdf+info forms for those who prefer such formats). Well, OK. It's not an important point. Cheers, - Graham Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
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 100% zoom in Firefox. I've attached 2 PNGs, one at 100% zoom and one at 300%. The graphics quality for the musical elements is excellent but the text comes out pixellated. Using Firefox 3.0.11 on Windows XP. I guess the text output depends on the installed fonts that Firefox sees on my system, but I wonder if that's a good idea. I'm thinking that svg output can be used for web apps (like wikipedia for instance), and I wouldn't want musical examples to suffer from such user dependencies. Though my understanding of the issues involved is rather limited, so I might just be missing the point. Thanks. - Mark attachment: rasterized-text_100.pngattachment: rasterized-text_300.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adding note color handling to musicxml2ly
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 patch works for me, and it would be great to see this functionality added to the musicxml2ly distribution. I saw that you had provision in print_note_color for reverting color. But I never saw any code elsewhere that called print_note_color with no rgb value to call that reversion. I would recommend that you consider replacing \override with \once \override, and junk the \revert. But I'm certainly not an expert in MusicXML. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM Errata
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 or match, so I changed the sentence to: The C++ language forces a certain method of grouping rules that cannot readily be applied to formatting music notation. 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 section is missing. Again, it is there on kainhofer. How are you viewing these graphics? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM Errata
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 section is missing. Again, it is there on kainhofer. How are you viewing these graphics? Trevor I'm viewing from the web. Both show up on ie explorer but not on firefox (winxp sp3). -Jonathan ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adding note color handling to musicxml2ly
-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 provision in print_note_color for reverting color. But I never saw any code elsewhere that called print_note_color with no rgb value to call that reversion. I would recommend that you consider replacing \override with \once \override, and junk the \revert. 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. To make sure things really work, you should create a regression test file input/regression/musicxml/59a-NoteColor.xml (see http://kainhofer.com/~lilypond/input/regression/musicxml/collated-files.html for the full regression test suite). That regression test should have: - -) a colored note (at the very beginning, so you see if it works right at the first note, too) - -) a following differently colored note - -) a following colored note with the same color - -) a following rest (should probably not be colored) - -) a colored note - -) a non-colored note. - -) A colored note with some articulation and e.g. a non-default notehead (which uses an \override, too, so you check whether the combination of multiple settings for one note doesn't break) I would suggest this order, because then you have all different types of sequences (two differently colored notes; rests after/before notes; uncolored notes). if rests can be colored, too, you should probably also add some combination of colored/uncolored rests and notes. For some more comments on the patch, see below: Am Dienstag, 14. Juli 2009 01:41:34 schrieb Bret Aarden: +def print_note_color (self, object, rgb=None): +if rgb: +str = (\override %s #'color = #(rgb-color %s %s %s) % + (object, rgb[0], rgb[1], rgb[2])) I suppose this should be \\override (i.e. escape the backslash). +else: +str = \\revert %s #'color % object +self.newline() +self.add_word(str) +self.newline() I'm not sure that you really want TWO newlines. Won't this insert a blank line between two color directives in the lilypond code? I'm not even sure that I want a newline before/after the override at all. This would result in each note of a piece taking ~4 lines in the lilypond file! At least with almost all other note-attached overrides that I implemented, I don't write out any newlines. The rest looks okay. 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) iD8DBQFKXLZrTqjEwhXvPN0RAlhsAJ4wWhdfKq+YdBEct6Zf28wKFl8CZwCfaLVg nLW9gtw5DHxhlLtH9qPJjGA= =6ESx -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM Errata
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 to engrave? The third example in this section is missing. Again, it is there on kainhofer. How are you viewing these graphics? Trevor 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 see them on kainhofer in a day or so. Thanks again for your help. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
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 what Mark was referring to. Possibly the low graphics quality at 100% zoom in Firefox. I've attached 2 PNGs, one at 100% zoom and one at 300%. The graphics quality for the musical elements is excellent but the text comes out pixellated. Using Firefox 3.0.11 on Windows XP. I guess the text output depends on the installed fonts that Firefox sees on my system, but I wonder if that's a good idea. I'm thinking that svg output can be used for web apps (like wikipedia for instance), and I wouldn't want musical examples to suffer from such user dependencies. I agree that it looks bad. I'll add a feature request to the wiki. Though my understanding of the issues involved is rather limited, so I might just be missing the point. My understanding is a bit limited too. But I know this task would be *much* more difficult than extracting glyph paths from a plain-text SVG font with regular expressions. The advantage of PostScript is that binary font embedding is allowed. Maybe we could ship the default text fonts (Century Schoolbook) as SVG fonts too? Then this might be possible. I don't know if there are any licensing issues though. I just tried converting the bold face to an SVG font, and it worked fine. At least, it would give me motivation to try converting these too. But a big downside of converting everything to paths is that the text can no longer be *edited* directly as text (in Inkscape, for example). The SVG format is more suitable for editing than PostScript or PDF are, so more users will be tempted to fire up Inkscape and try editing the plain text if they find an SVG file. If we decide to take this route, we should have a command-line switch, like -dsvg-glyphs-to-paths I'll write all of this down so that it's not forgotten. Thanks for bringing up this issue. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken make
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 have enough confidence that I know the build process well to be sure I'm not breaking something. I'll let John Mandereau get to it when he has the time. Yep, it may be helpful to know *what* he was trying to fix with cp -u. Ciao, Kili -- Automake and autoconf deserve to wither and die, but unfortunately noone at GNU seems to make much of an effort to euthanasize them. -- Han-Wen Nienhuys, on Lilypond-devel mailing list ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
accessing accidentals with \tweak
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.
http://kainhofer.com/~lilypond/Documentation/user/lilypond/The-tweak-command.html
But I *am* able to abuse the notehead's stencil property to tweak
the accidental:
\version 2.13.2
#(define (color-accidental grob)
;; notehead stencil callback
(let ((stil (ly:note-head::print grob))
(accidental (ly:grob-object grob 'accidental-grob)))
(ly:grob-set-property! accidental 'color red)
stil))
#(define (suppress-accidental grob)
;; notehead stencil callback
(let ((stil (ly:note-head::print grob))
(accidental (ly:grob-object grob 'accidental-grob)))
(ly:grob-suicide! accidental)
stil))
\relative {
c! \tweak #'stencil #color-accidental e! g!
c! \tweak #'stencil #suppress-accidental e! g!
}
Questions:
1) are the results of this technique undefined? Was it just luck
that these worked?
2) This seems so kludgy. I presume I can only access the
NoteHead's 'accidental-grob property through its standard
settings (duration-log, stem-attachment, stencil, X-offset, and
Y-offset). I wish I could do something like this instead (this
of course doesn't work) ---
#(define (color-accidental grob)
;; notehead foo callback
(let ((accidental (ly:grob-object grob 'accidental-grob)))
(ly:grob-set-property! accidental 'color red)
#t))
\relative {
c! \tweak #'foo #color-accidental e! g!
}
This would imply that I could make up my own dummy property and
it would (magically) have access to the note-head-interface
internal properties. Then I wouldn't have to bother making sure
I return the correct value for whatever standard setting I'm
abusing (stencil in the above case). Besides, I'd want to be
able to tweak that standard setting independently. As a
compromise, I considered the possibility of actually
implementing a 'dummy property, but I don't think that would
work either, because each subsequent call to \tweak #'dummy
would override the previous one (for a given note).
This bizarre approach might solve a lot of problems for me, but I
don't like abusing properties like this. What do you guys think?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
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 enhancement I'd imagine). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accessing accidentals with \tweak
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 accidentals *directly*. 2) This seems so kludgy. I presume I can only access the NoteHead's 'accidental-grob property through its standard settings (duration-log, stem-attachment, stencil, X-offset, and Y-offset). I wish I could do something like this instead (this of course doesn't work) --- You can use any property which NoteHead supports (via its interfaces). This would imply that I could make up my own dummy property and it would (magically) have access to the note-head-interface internal properties. Then I wouldn't have to bother making sure I return the correct value for whatever standard setting I'm abusing (stencil in the above case). Besides, I'd want to be able to tweak that standard setting independently. As a compromise, I considered the possibility of actually implementing a 'dummy property, but I don't think that would work either, because each subsequent call to \tweak #'dummy would override the previous one (for a given note). 'before-line-breaking 'after-line-breaking For accidentals, you'll have to use 'before-line-breaking, so it catches them before space has been reserved. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch: Delete intermediate ps files
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 like, it should be logged as a new issue (low priority enhancement I'd imagine). If the Windows user is invoking LP by double-clicking a .ly file the only way to see the console output is via the log file. It is essential for this mode of working. Most Windows users would do this, at least at the start, when it is essential that they see the error messages. The alternative is to use an editor which can launch a compilation and capture the console output (that's what I do), or to invoke LP from the command line DOS box (not natural for most Windows users) Regards, Neil Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG status update
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 note heads it belongs to (or vice versa)? No. The closest thing the elements possess that relates to this is their *grob cause*. For example the NoteHead grob is often the grob cause for the noteheads.s2 glyph. OK, thanks for the explanation. I seem to remember that some time ago I was in a similar situation, where I wanted to find out some elements' parent(s) from my code but was unable to, probably for precisely this reason. Do you happen to know at what stage of the engraving process elements are aware of their mutual relationships, just in case I stumble across this problem again in the future? I don't know for sure, but I would guess that these relationships are set in the engraving/acknowledging step, and that they lose the relationships after they have been converted to stencils (the post page-breaking step, I think). HTH, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken make
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 from a mobile phone, I'm back online tomorrow, still very busy but with more time for Lily John 2009/7/14, Matthias Kilian k...@outback.escape.de: 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 have enough confidence that I know the build process well to be sure I'm not breaking something. I'll let John Mandereau get to it when he has the time. Yep, it may be helpful to know *what* he was trying to fix with cp -u. Ciao, Kili -- Automake and autoconf deserve to wither and die, but unfortunately noone at GNU seems to make much of an effort to euthanasize them. -- Han-Wen Nienhuys, on Lilypond-devel mailing list ___ 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: Broken make
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 multiple css file copy issue and other ones will have gone. Done! Thanks for the guidance. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accessing accidentals with \tweak
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 stream.
http://kainhofer.com/~lilypond/Documentation/user/lilypond/The-tweak-command.h
tml
But I *am* able to abuse the notehead's stencil property to tweak
the accidental:
\version 2.13.2
#(define (color-accidental grob)
;; notehead stencil callback
(let ((stil (ly:note-head::print grob))
(accidental (ly:grob-object grob 'accidental-grob)))
(ly:grob-set-property! accidental 'color red)
stil))
#(define (suppress-accidental grob)
;; notehead stencil callback
(let ((stil (ly:note-head::print grob))
(accidental (ly:grob-object grob 'accidental-grob)))
(ly:grob-suicide! accidental)
stil))
\relative {
c! \tweak #'stencil #color-accidental e! g!
c! \tweak #'stencil #suppress-accidental e! g!
}
Questions:
1) are the results of this technique undefined? Was it just luck
that these worked?
This is well-defined. If you do a \displayMusic of your expression, you'll
see that the
procedure gets put into the parse tree.
(make-music
'EventChord
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'force-accidental
#t
'pitch
(ly:make-pitch -1 0 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'tweaks
(list (cons (quote stencil) color-accidental))
'force-accidental
#t
'pitch
(ly:make-pitch -1 2 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'force-accidental
#t
'pitch
(ly:make-pitch -1 4 0))
(make-music
'SlurEvent
'span-direction
1)))
So color-accidental is going to get evaluated and the result passed as the
stencil of the note.
2) This seems so kludgy. I presume I can only access the
NoteHead's 'accidental-grob property through its standard
settings (duration-log, stem-attachment, stencil, X-offset, and
Y-offset). I wish I could do something like this instead (this
of course doesn't work) ---
#(define (color-accidental grob)
;; notehead foo callback
(let ((accidental (ly:grob-object grob 'accidental-grob)))
(ly:grob-set-property! accidental 'color red)
#t))
\relative {
c! \tweak #'foo #color-accidental e! g!
}
This would imply that I could make up my own dummy property and
it would (magically) have access to the note-head-interface
internal properties. Then I wouldn't have to bother making sure
I return the correct value for whatever standard setting I'm
abusing (stencil in the above case). Besides, I'd want to be
able to tweak that standard setting independently. As a
compromise, I considered the possibility of actually
implementing a 'dummy property, but I don't think that would
work either, because each subsequent call to \tweak #'dummy
would override the previous one (for a given note).
This bizarre approach might solve a lot of problems for me, but I
don't like abusing properties like this. What do you guys think?
If you look at the IR, you'll see three dummy grob properties that are used
to trigger callbacks.
What if a property like tweak-callback were added, whose job is just to
trigger the grob callback necessary for what you want to do?
Then you could have
\relative {
c! \tweak #'tweak-callback #color-accidental e! g!
}
I think you could have multiple calls to #'tweak-callback, because
all of the tweaks are stored in a list, and would all be executed.
\displayMusic
\relative {
c
\tweak #'color #red
\tweak #'color #yellow
d
}
gives
(make-music
'RelativeOctaveMusic
'element
(make-music
'SequentialMusic
'elements
(list (make-music
'EventChord
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'pitch
(ly:make-pitch 0 0 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'tweaks
(list (list (quote color) 1.0 0.0 0.0)
(list (quote color) 1.0 1.0 0.0))
'pitch
(ly:make-pitch 0 1 0)))
Personally, I think this is a cool idea!
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Re: New format for autobeaming rules
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, for more information.
Is it possible to use @ruser{} here?
http://codereview.appspot.com/88155/diff/95/1149
File Documentation/user/rhythms.itely (right):
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.
http://codereview.appspot.com/88155/diff/95/1155
File input/lsr/conducting-signs,-measure-grouping-signs.ly (right):
http://codereview.appspot.com/88155/diff/95/1155#newcode77
Line 77: }
missing %begin verbatim
http://codereview.appspot.com/88155/diff/95/1155#newcode88
Line 88: } % begin verbatim
rogue %begin verbatim
http://codereview.appspot.com/88155/diff/95/1170
File lily/measure-grouping-engraver.cc (right):
http://codereview.appspot.com/88155/diff/95/1170#newcode71
Line 71: scm_list_2 (time_signature_fraction,
same line as ly_assoc_get (
http://codereview.appspot.com/88155/diff/95/1170#newcode72
Line 72: ly_symbol2scm (end)),
indentation
http://codereview.appspot.com/88155/diff/95/1170#newcode75
Line 75: grouping_rules, SCM_EOL);
indentation
http://codereview.appspot.com/88155/diff/95/1177
File scm/c++.scm (right):
http://codereview.appspot.com/88155/diff/95/1177#newcode30
Line 30: (define-public (pair-or-symbol? x)
also unused
http://codereview.appspot.com/88155
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Consolidate autobeaming to one property that controls it
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 reliably go in reverse. It looks like the matching process works by generating an equivalent music expression then comparing it with the input (see define-music-display-methods.scm, from line 971). I imagine part of the reason it doesn't work is that you've removed the setting for beatGrouping. I guess I'm not *too* concerned that \displayLilyMusic return exactly what what entered into it. As long as it returns valid music expressions, then I think it's probably OK. OK, perhaps a TODO in the file will suffice for now, Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
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 stumbled across it for the compile fix in December that it's mainly for use by translators. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accessing accidentals with \tweak
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 5.5 Advanced tweaks. Anyone up for writing this, once the technique has crystallised? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
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 Baerenreiter Bach 'cello suite example shows how it should be (though it's got manual beaming just to make sure). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippets in doc compile different from stand-alone
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 mentioned in CG (in passing), but I got the impression when I stumbled across it for the compile fix in December that it's mainly for use by translators. Hmm -- I read through the CG and missed it. Now that I know what I'm looking for, I see where it is. I'll add something to the CG. I think that somehow we need to get it to be used by others besides tranlators. I need to use it because I can't push a patch until I verify make doc works. I could just verify that make doc works properly in a subdirectory (e.g. Documentation/user), and then I know that the new english manuals work properly. But if I've changed syntax, and the translated manuals will no longer work properly, then I break compilation if I push a patch. So in the case of a syntax change that needs a NOT_SMART convert-ly rule, we should have some procedure in place to avoid future occurences of this problem, it seems to me. I'm not sure exactly what is the best method of doing this, however. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM Errata
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 see them on kainhofer in a day or so. I've upgraded Firefox to 3.0.11, and those sections I mentioned are still empty. Still looks fine in IE. Also, everything looks fine on a mac, so I'm not sure what could be causing that behavior. -Jonathan ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Markup commands \left-brace and \right-brace
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 available here: http://codereview.appspot.com/8874/show I've moved the binary search and added a few checks for invalid point sizes. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Consolidate autobeaming to one property that controls it
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 \time 3/4 to \set Timing), but I don't know any way to reliably go in reverse. It looks like the matching process works by generating an equivalent music expression then comparing it with the input (see define-music-display-methods.scm, from line 971). Oh, I wasn't thinking that it was set up as a set of specific pattern matching examples. I'll fix the patterns to make them work right. I imagine part of the reason it doesn't work is that you've removed the setting for beatGrouping. I guess I'm not *too* concerned that \displayLilyMusic return exactly what what entered into it. As long as it returns valid music expressions, then I think it's probably OK. OK, perhaps a TODO in the file will suffice for now, No, now that you've shown this to me, I won't be able to let it rest. It will require some changing to my current code, as well as changes to define-music-display-methods.scm, but I'll do it. Neil, I'm totally impressed with your comprehension of the LilyPond code base. How do you do it? I consider myself a pretty smart guy, but I feel like I'm walking around in a fog compared to you. Thanks for being my lighthouse! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-devel Digest, Vol 80, Issue 53
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 \once command. That's very useful. To make sure things really work, you should create a regression test file input/regression/musicxml/59a-NoteColor.xml (see http://kainhofer.com/~lilypond/input/regression/musicxml/collated-files.html for the full regression test suite). That regression test should have: - -) a colored note (at the very beginning, so you see if it works right at the first note, too) - -) a following differently colored note - -) a following colored note with the same color - -) a following rest (should probably not be colored) - -) a colored note - -) a non-colored note. - -) A colored note with some articulation and e.g. a non-default notehead (which uses an \override, too, so you check whether the combination of multiple settings for one note doesn't break) OK, I put one together and attached it to this email. +def print_note_color (self, object, rgb=None): +if rgb: +str = (\override %s #'color = #(rgb-color %s %s %s) % + (object, rgb[0], rgb[1], rgb[2])) I suppose this should be \\override (i.e. escape the backslash). Well, it's been a while since I've worked with Python in depth, but it seems to work fine without it. I'm not sure that you really want TWO newlines. Won't this insert a blank line between two color directives in the lilypond code? I'm not even sure that I want a newline before/after the override at all. This would result in each note of a piece taking ~4 lines in the lilypond file! At least with almost all other note-attached overrides that I implemented, I don't write out any newlines. OK, I took those out and condensed the code a little. I've attached a new patch file. Thanks for the comments! -Bret. ?xml version=1.0 encoding=UTF-8? !DOCTYPE score-partwise PUBLIC -//Recordare//DTD MusicXML 1.0 Partwise//EN http://www.musicxml.org/dtds/partwise.dtd; score-partwise movement-titleColored Notes/movement-title identification miscellaneous miscellaneous-field name=description8 note elements: a blue quarter note (G4), 2 red eighth notes (A4, B4), an uncolored half rest, a green quarter note (C5), an uncolored quarter note (D5), a staccato cyan quarter note (E5), and a magenta 'x' notehead quarter note (F5). /miscellaneous-field /miscellaneous /identification part-list score-part id=P1 part-nameMusicXML Part/part-name /score-part /part-list !--=-- part id=P1 measure number=1 attributes divisions2/divisions key fifths0/fifths modemajor/mode /key time symbol=common beats4/beats beat-type4/beat-type /time clef signG/sign line2/line /clef /attributes note color=#FF pitch stepG/step octave4/octave /pitch duration2/duration voice1/voice typequarter/type /note note color=#FF pitch stepA/step octave4/octave /pitch duration1/duration voice1/voice typeeighth/type beam number=1begin/beam /note note color=#FF pitch stepB/step octave4/octave /pitch duration1/duration voice1/voice typeeighth/type beam number=1end/beam /note note rest / duration4/duration voice1/voice typehalf/type /note /measure !--===-- measure number=2 note color=#00FF00 pitch stepC/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type /note note pitch stepD/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type /note note color=#00 pitch stepE/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type notations articulations staccato placement=above/ /articulations /notations /note note color=#FF00FF pitch stepF/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type noteheadx/notehead /note barline location=right bar-stylelight-heavy/bar-style /barline /measure /part !--=-- /score-partwise From
Re: Adding note color handling to musicxml2ly
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 want \once\override. Ah, I had forgotten about the \once command. That's very useful. To make sure things really work, you should create a regression test file input/regression/musicxml/59a-NoteColor.xml (see http://kainhofer.com/~lilypond/input/regression/musicxml/collated-files.html for the full regression test suite). That regression test should have: - -) a colored note (at the very beginning, so you see if it works right at the first note, too) - -) a following differently colored note - -) a following colored note with the same color - -) a following rest (should probably not be colored) - -) a colored note - -) a non-colored note. - -) A colored note with some articulation and e.g. a non-default notehead (which uses an \override, too, so you check whether the combination of multiple settings for one note doesn't break) OK, I put one together and attached it to this email. +def print_note_color (self, object, rgb=None): +if rgb: +str = (\override %s #'color = #(rgb-color %s %s %s) % + (object, rgb[0], rgb[1], rgb[2])) I suppose this should be \\override (i.e. escape the backslash). Well, it's been a while since I've worked with Python in depth, but it seems to work fine without it. I'm not sure that you really want TWO newlines. Won't this insert a blank line between two color directives in the lilypond code? I'm not even sure that I want a newline before/after the override at all. This would result in each note of a piece taking ~4 lines in the lilypond file! At least with almost all other note-attached overrides that I implemented, I don't write out any newlines. OK, I took those out and condensed the code a little. I've attached a new patch file. Thanks for the comments! -Bret. ?xml version=1.0 encoding=UTF-8? !DOCTYPE score-partwise PUBLIC -//Recordare//DTD MusicXML 1.0 Partwise//EN http://www.musicxml.org/dtds/partwise.dtd; score-partwise movement-titleColored Notes/movement-title identification miscellaneous miscellaneous-field name=description8 note elements: a blue quarter note (G4), 2 red eighth notes (A4, B4), an uncolored half rest, a green quarter note (C5), an uncolored quarter note (D5), a staccato cyan quarter note (E5), and a magenta 'x' notehead quarter note (F5). /miscellaneous-field /miscellaneous /identification part-list score-part id=P1 part-nameMusicXML Part/part-name /score-part /part-list !--=-- part id=P1 measure number=1 attributes divisions2/divisions key fifths0/fifths modemajor/mode /key time symbol=common beats4/beats beat-type4/beat-type /time clef signG/sign line2/line /clef /attributes note color=#FF pitch stepG/step octave4/octave /pitch duration2/duration voice1/voice typequarter/type /note note color=#FF pitch stepA/step octave4/octave /pitch duration1/duration voice1/voice typeeighth/type beam number=1begin/beam /note note color=#FF pitch stepB/step octave4/octave /pitch duration1/duration voice1/voice typeeighth/type beam number=1end/beam /note note rest / duration4/duration voice1/voice typehalf/type /note /measure !--===-- measure number=2 note color=#00FF00 pitch stepC/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type /note note pitch stepD/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type /note note color=#00 pitch stepE/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type notations articulations staccato placement=above/ /articulations /notations /note note color=#FF00FF pitch stepF/step octave5/octave /pitch duration2/duration voice1/voice typequarter/type noteheadx/notehead /note barline location=right bar-stylelight-heavy/bar-style /barline /measure /part
