Re: [PATCHES] Re: Harp Pedals?
I've put together an oval-circle code that is less pointy than the ellipses. I've used two cubic bezier curves. I think I don't want to push the changes until I get some concurrence from Reinhard and Francisco. I've attached a png output of the new code. What do you think? Carl On 8/29/08 11:43 AM, Francisco Vila [EMAIL PROTECTED] wrote: 2008/8/29 Reinhold Kainhofer [EMAIL PROTECTED]: Am Freitag, 29. August 2008 schrieb Carl D. Sorensen: Some tests with inkscape show me that an ellipse (depending on the aspect ratio of the rectangle) could be a little too 'tall', but if the half-axes simply add a fixed amount in x and y to the width and height of the rectangle, it would leave a more controllable space in between (maybe it also would be faster to calculate) [...] I think that Reinhold's idea of x-padding and y-padding is a good idea, because it allows the user to change the aspect ratio of the ellipse if the automatically generated one is not good. I will implement that idea by tomorrow, if Reinhold has already done so. I've already implemented that last saturday with commit d462d4c7c356124edd1c0f1ef6037335669f30b5 Looking at the harp diagrams, I really did not like the ellipse, which was too high for my tast, but not wide enough,,, With different padding in x- and y-direction it looks okay now. That's what I meant: equal aspect ratios does not seem to be the goal, but an optical robustness valid for high- and low- resolutions. -- Francisco Vila. Badajoz (Spain) http://www.paconet.org harp-pedals.png Description: harp-pedals.png ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New German PO file for 'lilypond' (version 2.11.57)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/lilypond/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Feature request: German chord names
Hi, there has been every once and a while questions about German chord names on the German lilypond forum. The users would like to be able to make a minor chord print the chord name as a small letter, and a big letter for the major chord, e.g. C maj would be C and C min would be c. This has some tradition in German Lead sheet music. There hasn't been yet a solution to make this easily working. Is there somebody volunteering or could it be added to the tracker? Greetings Till ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Feature request: different shaped stems for half notes in tabulature
Hi, there has been complaints on the German lilypond forum about the stems of half notes in tabulatures: half notes and quarter notes look the same in pure tabulatur notation, if there is no traditional note line above specifying the rythms. A user posted a picture of a tabulatur featuring a half note with a triangular stem to distinguish it from the quarter note, see a picture: http://freenet-homepage.de/wwelti/123328.jpg Can this be added to the tracker? Greetings Till ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCHES] Re: Harp Pedals?
2008/8/31 Carl D. Sorensen [EMAIL PROTECTED]: I've put together an oval-circle code that is less pointy than the ellipses. I've used two cubic bezier curves. I think I don't want to push the changes until I get some concurrence from Reinhard and Francisco. I've attached a png output of the new code. What do you think? Maybe if you send a better-resolution, cropped image (which should not be too large) or a PDF, I could appreciate it better. Right now the oval looks as if it crosses over the rectangle, is this OK? But do not rely on my humble opinion... -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Consolidating command-line options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While translating the AU to German, I realized that currently our applications have similar options, but use different shortcuts for them. In particular, some converters use -V for verbose and -v for version, while others use -v for verbose and -V for version... Shouldn't we change this so that at least all applications that come together with lilypond use the same option names? While the GNU coding standard does not give any suggestions on the short option names, most command-line utilities use -v for --verbose and -V (or no short option) for --version. Thus I propose to use the following standard options consistently for lilypond, lilypond-book, *2ly, convert-ly, etc.: - -h, --help ... usage and options - -o, --output ... output file - -v, --verbose ... verbose - -V, --version ... version number - -w, --warranty ... warranty and copyright Some converters also don't have a --warranty option yet... What do you think? Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIuqz2TqjEwhXvPN0RAnRyAJ42piReSz9Ha4D5DEgPouG1bYpv8wCcC/va bbQxoFF+LH1kqbvqYmLP1EQ= =HDOp -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book in 2.11.57
I'm doing my first big project on 2.11, and I've gotten to the stage where I want to print several movements of a sonata as one pdf document. My 2.10 makefile doesnt' work, because lilypond-book no longer has a --psfonts option. So I looked at the documentation http://lilypond.org/doc/v2.11/Documentation/user/lilypond-program/Invoking-lilypond_002dbook#Invoking-lilypond_002dbook for what I'm supposed to do now, and tried both options. This is an ubuntu hardy heron system, with lilypond 2.11.57 installed as a user from the GUB. When I run lilypond-book --pdf sonate.lytex, I get: Running lilypond...GNU LilyPond 2.10.33 Fontconfig error: Cannot load default config file Note that this is the wrong version of lilypond -- 2.10.33 is installed systemwide, but the user who's installed the GUB expects to be running 2.11.57. Then it chugs for a while and says: Preprocessing graphical objects... (process:6022): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/usr/etc/pango/pango.modules' You should create this file by running: pango-querymodules '/usr/etc/pango/pango.modules' (process:6022): Pango-WARNING **: failed to find shape engine, expect ugly output. engine-type='PangoRenderFc', script='common' (process:6022): Pango-CRITICAL **: pango_fc_font_lock_face: assertion `PANGO_IS_FC_FONT (font)' failed Segmentation fault command failed: /usr/bin/lilypond --formats=ps -dbackend=eps -I /home/newlily/music/bigaglia/amin --formats=eps --pdf -dinclude-eps-fonts -dgs-load-fonts -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir /home/newlily/music/bigaglia/amin/snippet-names--1990410836.ly Child returned 139 So lilypond-book is definitely not respecting the user's path when running lilypond. There may also be other problems with the pango errors, but I can definitely say there's a bug in the way lilypond is being run here. -- Laura (mailto:[EMAIL PROTECTED] http://www.laymusic.org/ ) (617) 661-8097 233 Broadway, Cambridge, MA 02139 America, where you're free to say anything you want, and you'd better not say what you're not supposed to! Tommy Smothers, quoted by Cory Doctorow on the Boing Boing blog ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How hard is something like CADB to do?
On 8/30/08 3:49 PM, David Kastrup [EMAIL PROTECTED] wrote: David Kastrup [EMAIL PROTECTED] writes: CADB is sort of an international standard for transcribing diatonic accordion music. It consists of regular notes on one system, with basically numbers arranged according to what button to press or pull in another system below, then chords under that. An explanation of the notation can be found at URL:http://www.diato.fr/exptab2.htm. The same site has example scores, like URL:http://www.diato.fr/tablat/tab108.png. [...] So the problems boil down to a) the graphical representation (which requires fixed vertical space and not normally additional horizontal space) This is not particularly hard. Initially it could be done as a markup (like fret diagrams were). Eventually it could become a context. b) some sort of fingering engine which one can feed the necessary information for choosing its priorities This would likely be done in scheme. The tablature code is an example of this. How would one go about implementing something like that in lilypond? How would the work get structured? What would require working on the kernel, what on subsystems? How well can the subsystems be separated? To get it done with a context, you would need to write some C++ code, along with some lilypond code and some scheme code. The FretBoards context would likely serve as a template for this work, I would imagine. How much intelligence can one reasonably program into the fingering engine without having it explode in complexity? It is thinkable to tell it something like TeX's badnesses as overall penalties for changing rows, changing bellows direction, and then let it minimize over that? Hard for me to say, since I don't understand how this works. But lots of the layout decisions are made in scheme code, so I would guess this is doable. Or have a draft mode where, say, one has it pick one fingering according to explicit priorities and indicate alternative fingerings in different markup (small print, in parens or something), so that one can incrementally override bad automatically chosen fingerings until arriving at a good solution, in sort of a feedback loop? I don't see any problem with this -- but I don't know how one would calculate these things. Ok, but that's basically icing. The main question is how hard it would be to have it do the basic notation. Uh, this was not a feature request. It was a request to the people who have actually implemented stuff in Lilypond to give me a sketch of the necessary work to be done, and in what areas they would need to be done, and how well-prepared Lilypond is for doing such things. My take on this is that you will need to do the following: 1. Write some C++ code to implement a translator 2. Write some Scheme code to implement an engraver 3. If you want to add to the input syntax, make changes to the parser. But I think it's possible you can do this with just named chords in chordmode, which wouldn't require parser changes. 4. Make some changes to assorted files to tie your new code into the existing system (i.e. define grobs, grob-interfaces, etc.) 5. Make some regression tests to demonstrate that the functionality works 6. Write some documentation about how the functionality works. The job is a fairly big job, but it can be started small and worked at in manageable chunks. It was also a question about how well-prepared Lilypond is for embedding algorithms for what amounts to fingering instructions (converting to any kind of tablature has this problem: the more sparingly you can use hints for generating instrument-specific instructions, the better). LilyPond is extremely well-prepared for embedding algorithms. You will have a great deal of flexibility in implementing your tablature. The job will get bigger, though, when you need to investigate the status of slurs, etc. to get your fingering instructions. So it's basically just a minute job on some questions. They are just questions. Just fire away, no preparation needed, no code. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: German chord names
I think in this way this is a bad practice and I wouldn't call it German tradition. The best traditional practice is to use small letter and the quality mark together: hm Bert The users would like to be able to make a minor chord print the chord name as a small letter, and a big letter for the major chord, e.g. C maj would be C and C min would be c. This has some tradition in German Lead sheet music. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: German chord names
Bertalan Fodor schrieb: I think in this way this is a bad practice Well, it is also not really logical/good practice to have the major be the main function (with no modifier) and the minor then with a modifier. It is always a bit difficult to explain people that their habits are bad and they should switch to something else. In general I would agree that there is much bad practice met around the world -- on this particular example I don't have any opinion. and I wouldn't call it German tradition. So you mean it is wider spread? The best traditional practice is to use small letter and the quality mark together: hm What about giving people the possibility to use both forms? If the hm-form would be adopted, it almost demands that there first be a h-form. Bert Till The users would like to be able to make a minor chord print the chord name as a small letter, and a big letter for the major chord, e.g. C maj would be C and C min would be c. This has some tradition in German Lead sheet music. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: German chord names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 31. August 2008 schrieb Bertalan Fodor: I think in this way this is a bad practice and I wouldn't call it German tradition. The best traditional practice is to use small letter and the quality mark together: hm The German tradition is really that capital letters indicate major, small letters mean minor mode. So if you see Mass in C, it is in c major, if you see Mass in c, it's c minor. It's only natural that people, who grew up with that convention, also want to use it to denote chords. Wikipedia also says the following about major/minor chord naming (http://de.wikipedia.org/wiki/Akkordsymbol): - -) Usually, chords are notated as C and Cm - -) To some extent it is also custom to notate minor chords with small letters Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIuu/gTqjEwhXvPN0RAqPXAJ4kHavpLa18ZcLFsB3w/aZOklT/YgCeLYZe KDqopoK8kgd99OJqOxUtWds= =3SVj -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book in 2.11.57
Laura Conrad kirjoitti: snip When I run lilypond-book --pdf sonate.lytex, I get: Running lilypond...GNU LilyPond 2.10.33 Fontconfig error: Cannot load default config file Note that this is the wrong version of lilypond -- 2.10.33 is installed systemwide, but the user who's installed the GUB expects to be running 2.11.57. Hi, hardy heron here as well. In order to run 2.11.57 user installation you can put export PATH=~/bin:$PATH (notice ~/bin before the $PATH) into your ~/.bashrc This done log out and log in again. Then your ~/bin is searched first when you try to run lilypond-book --pdf sonate.lytex and you should run 2.11.xx. (At least I do.) Best wishes, Tapio ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How hard is something like CADB to do?
Ok, this provides food for thought and some initial pointers where to look further. Thanks! Carl D. Sorensen [EMAIL PROTECTED] writes: On 8/30/08 3:49 PM, David Kastrup [EMAIL PROTECTED] wrote: David Kastrup [EMAIL PROTECTED] writes: [...] So the problems boil down to a) the graphical representation (which requires fixed vertical space and not normally additional horizontal space) This is not particularly hard. Initially it could be done as a markup (like fret diagrams were). Eventually it could become a context. b) some sort of fingering engine which one can feed the necessary information for choosing its priorities This would likely be done in scheme. The tablature code is an example of this. Ok, somewhere to look. How would one go about implementing something like that in lilypond? How would the work get structured? What would require working on the kernel, what on subsystems? How well can the subsystems be separated? To get it done with a context, you would need to write some C++ code, along with some lilypond code and some scheme code. The FretBoards context would likely serve as a template for this work, I would imagine. Have to look there. How much intelligence can one reasonably program into the fingering engine without having it explode in complexity? It is thinkable to tell it something like TeX's badnesses as overall penalties for changing rows, changing bellows direction, and then let it minimize over that? Hard for me to say, since I don't understand how this works. But lots of the layout decisions are made in scheme code, so I would guess this is doable. Ok. Or have a draft mode where, say, one has it pick one fingering according to explicit priorities and indicate alternative fingerings in different markup (small print, in parens or something), so that one can incrementally override bad automatically chosen fingerings until arriving at a good solution, in sort of a feedback loop? I don't see any problem with this -- but I don't know how one would calculate these things. My take on this is that you will need to do the following: 1. Write some C++ code to implement a translator 2. Write some Scheme code to implement an engraver 3. If you want to add to the input syntax, make changes to the parser. But I think it's possible you can do this with just named chords in chordmode, which wouldn't require parser changes. I think that in general a mechanism to provide instrument/pitch specific hints would be nice, so that I can have some Lilypond input that can be made to crank out instrument-specific fingerings and tablature for different instruments and transpositions. The job is a fairly big job, but it can be started small and worked at in manageable chunks. Ok, thanks. It was also a question about how well-prepared Lilypond is for embedding algorithms for what amounts to fingering instructions (converting to any kind of tablature has this problem: the more sparingly you can use hints for generating instrument-specific instructions, the better). LilyPond is extremely well-prepared for embedding algorithms. You will have a great deal of flexibility in implementing your tablature. Good. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New French PO file for 'lilypond' (version 2.11.57)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/lilypond/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request: German chord names
and I wouldn't call it German tradition. So you mean it is wider spread? Yes, for example Hungarian note and chord names usually follows the German and I often saw this in various scores. The best traditional practice is to use small letter and the quality mark together: hm What about giving people the possibility to use both forms? If the hm-form would be adopted, it almost demands that there first be a h-form. Yes, you are right. I just wanted to point out that because in practice using C and c can be hard to read, it is better to use C and cm in Lead Sheets. Bert ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How hard is something like CADB to do?
On Sun, Aug 31, 2008 at 1:18 PM, Carl D. Sorensen [EMAIL PROTECTED] wrote: My take on this is that you will need to do the following: In general, I found that it is easiest to work backwards within the program structure. Start implementing whatever is closest to the layout, then add more and more abstraction towards the frontend of the program, to arrive at something you'd want to input. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Consolidating command-line options
On Sun, Aug 31, 2008 at 11:38 AM, Reinhold Kainhofer [EMAIL PROTECTED] wrote: - -h, --help ... usage and options - -o, --output ... output file - -v, --verbose ... verbose - -V, --version ... version number - -w, --warranty ... warranty and copyright we don't have to have short letter for options. I think both --version and --warranty do not need a short option. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Thank you.
Hello: I just wanted to thank you for this fine piece of work. I've just started exploring what lilypond can do, and I have to say I am deeply impressed. It is apparent that you not only are fine programmers, but also that you have a wonderful sense of the beauty of engraved music. That is something I have seldom heard discussed, but that I believe is important to those who read music. As you hinted, a musician can probably do with just about any old grouping of notes on a page - but the beauty of fine engraving adds to the experience. I must admit that some of the finer points you discuss are lost on me, but perhaps as I work with lilypond I'll be better able to see them. Anyway, just thank you for a wonderful program. -Baruch ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
