Re: Evolutionary User Strategery
On 7/9/06, Fairchild [EMAIL PROTECTED] wrote: New scores could use new features and not have to work around the bugs of earlier versions. Older scores that have been carefully tuned, compensating for earlier bugs, would continue to produce the intended result without having to be overhauled. There would be no need to maintain multiple versions. This basically implies that all old versions of lily must be included in the new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6 and 2.4. Which means that the lilypond package grows by a factor 4. I think a better solution would be that you create a script locally, which parses the input ly file, reads the \version statement, and picks which lilypond version to use to compile your ly file. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
tetex 2.5 and lilypond 2.0
I sympathize with all the users who are just now running into the difficulties of keeping lilypond files in sync with lilypond development. I've been using lilypond since about 1.4, and it hasn't gotten any easier. I also agree with the people who've been saying that the right answer is to keep old lilypond versions installed, so that you can update a lilypond file in a minor way without going through the conversion and re-tweaking process every time. My problem is that I have several major projects that are in lilypond 2.0. Even where convert-ly performs flawlessly (which it doesn't for a number of features, like multi-verse vocal music), it would be at least hours and more likely days of work to do all the re-tweaking and repaginating to convert these books to lily 2.8. You can't just install lily 2.0 on a modern (less than a year old) linux system, because the fix for having lilypond use tetex 3.0 happened sometime in the 2.4 development cycle, and was never backported to older versions. Until last week, I was dealing with this on my Debian Unstable system by pinning tetex to 2.5. Unfortunately, last week my machine died, and I decided to put Ubuntu Dapper on the new machine. It turns out not to be possible to install tetex 2.5 directly on an Ubuntu Dapper machine. A very nice person on the ubuntu users list is attempting to walk me through building the tetex 2.5 from Ubuntu Breezy for Ubuntu Dapper, but it doesn't seem to be easy, and in any case, as a publisher I use TeX for enough things that sooner or later I'm sure I will want something that needs tetex 3.0. So I'm considering the following options: Installing Ubuntu breezy or some other distribution with tetex 2.5 on it in another partition on my giant new hard drive. I only need to change the 2.0 lily files a few times a year, so this might be the most straightforward thing for me to do. Seeing if I can run lilypond 2.0 from a TeX Live CD of the appropriate vintage. Has anyone tried to run any lilypond with any TeX Live CD and what were the results? Finding out what were the changes necessary for lilypond to run on tetex 3.0 and what's involved in backporting them to lilyond 2.0. Can anyone help with this? This would be the most straightforward answer for lilypond development in general. I'm sure I'm not the only person facing problems like this, so I'd be interested in hearing what other people are doing about them. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: tetex 2.5 and lilypond 2.0
If your new system is powerful enough (and no, I haven't any experience of this but I'm planning to do something like this myself :-) Experiment with UML (User Mode Linux) and Gentoo. There's a good chance that if you get a minimal gentoo system running, then tell it to install the packages you need such as tetex 2.5, it will hopefully work fine. The portage system *should* resolve the necessary dependencies. As I say, I haven't done this. But it's an idea to play with ... and if you can get UML running you can easily run an old setup as a program inside Dapper :-) Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] .org] On Behalf Of Laura Conrad Sent: 10 July 2006 14:14 To: lilypond-user@gnu.org Cc: [EMAIL PROTECTED] Subject: tetex 2.5 and lilypond 2.0 I sympathize with all the users who are just now running into the difficulties of keeping lilypond files in sync with lilypond development. I've been using lilypond since about 1.4, and it hasn't gotten any easier. I also agree with the people who've been saying that the right answer is to keep old lilypond versions installed, so that you can update a lilypond file in a minor way without going through the conversion and re-tweaking process every time. My problem is that I have several major projects that are in lilypond 2.0. Even where convert-ly performs flawlessly (which it doesn't for a number of features, like multi-verse vocal music), it would be at least hours and more likely days of work to do all the re-tweaking and repaginating to convert these books to lily 2.8. You can't just install lily 2.0 on a modern (less than a year old) linux system, because the fix for having lilypond use tetex 3.0 happened sometime in the 2.4 development cycle, and was never backported to older versions. Until last week, I was dealing with this on my Debian Unstable system by pinning tetex to 2.5. Unfortunately, last week my machine died, and I decided to put Ubuntu Dapper on the new machine. It turns out not to be possible to install tetex 2.5 directly on an Ubuntu Dapper machine. A very nice person on the ubuntu users list is attempting to walk me through building the tetex 2.5 from Ubuntu Breezy for Ubuntu Dapper, but it doesn't seem to be easy, and in any case, as a publisher I use TeX for enough things that sooner or later I'm sure I will want something that needs tetex 3.0. So I'm considering the following options: Installing Ubuntu breezy or some other distribution with tetex 2.5 on it in another partition on my giant new hard drive. I only need to change the 2.0 lily files a few times a year, so this might be the most straightforward thing for me to do. Seeing if I can run lilypond 2.0 from a TeX Live CD of the appropriate vintage. Has anyone tried to run any lilypond with any TeX Live CD and what were the results? Finding out what were the changes necessary for lilypond to run on tetex 3.0 and what's involved in backporting them to lilyond 2.0. Can anyone help with this? This would be the most straightforward answer for lilypond development in general. I'm sure I'm not the only person facing problems like this, so I'd be interested in hearing what other people are doing about them. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user * * This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333. * * ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Evolutionary User Strategery
Erik - Thanks for contributing to this thread. It is attempting to deal with an important unresolved issue: seamless evolutionary transitioning of ly files. Your suggested solution requires n versions residing entirely in the user's machine, which would, as you point out, increase resident code by a factor of n. The code switching option requires parallel code only for features that are interpreted differently for different versions, only marginally increasing the size of the newer versions - far less size, and hassle, than retaining several versions. Marginally increasing the single package size is not a concern. Through the generations, memory and speed have increased to accommodate applications - or maybe the other way around. The first computer I used had 2000 bi-quinary ten-digit words on a drum. Long-term memory was punched cards. It was a fantastic improvement over its predecessor, the Card Programmed Calculator. Increasing processing time is a consideration, but testing a flag to select from version-specific code segments would be barely measurable. - Bruce -Original Message- From: Erik Sandberg [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 3:12 AM To: Fairchild Cc: lilypond-user@gnu.org Subject: Re: Evolutionary User Strategery On 7/9/06, Fairchild [EMAIL PROTECTED] wrote: New scores could use new features and not have to work around the bugs of earlier versions. Older scores that have been carefully tuned, compensating for earlier bugs, would continue to produce the intended result without having to be overhauled. There would be no need to maintain multiple versions. This basically implies that all old versions of lily must be included in the new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6 and 2.4. Which means that the lilypond package grows by a factor 4. I think a better solution would be that you create a script locally, which parses the input ly file, reads the \version statement, and picks which lilypond version to use to compile your ly file. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
Bruce, sorry to be rude but: Being forced to absolute backward compatibility sucks, and having to keep compatibility with e.g. 2.4 2.6 and 2.8 sucks even more, and makes the code base bloated, less maintainable and probably a lot of #ifdefs of what not that leads to more bugs.. Put it another way, you don't want to write your .ly files in such a way that you can use whatever lilypond version to compile them and get a perfect result. The developers most certainly does not want absolute backwards compatibility, and they even bother so much as to provide convert-ly to make the transition forward easier. Whose arguments do you thing weigh more? Most developers develop lilypond in their spare time just for the fun of it for all I know.. After all, this is free software, if you like, you can make your own compatible-with-everything-even-all-the-bugs fork project.. /S On 7/10/06, Fairchild [EMAIL PROTECTED] wrote: Erik - Thanks for contributing to this thread. It is attempting to deal with an important unresolved issue: seamless evolutionary transitioning of ly files. Your suggested solution requires n versions residing entirely in the user's machine, which would, as you point out, increase resident code by a factor of n. The code switching option requires parallel code only for features that are interpreted differently for different versions, only marginally increasing the size of the newer versions - far less size, and hassle, than retaining several versions. Marginally increasing the single package size is not a concern. Through the generations, memory and speed have increased to accommodate applications - or maybe the other way around. The first computer I used had 2000 bi-quinary ten-digit words on a drum. Long-term memory was punched cards. It was a fantastic improvement over its predecessor, the Card Programmed Calculator. Increasing processing time is a consideration, but testing a flag to select from version-specific code segments would be barely measurable. - Bruce -Original Message- From: Erik Sandberg [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 3:12 AM To: Fairchild Cc: lilypond-user@gnu.org Subject: Re: Evolutionary User Strategery On 7/9/06, Fairchild [EMAIL PROTECTED] wrote: New scores could use new features and not have to work around the bugs of earlier versions. Older scores that have been carefully tuned, compensating for earlier bugs, would continue to produce the intended result without having to be overhauled. There would be no need to maintain multiple versions. This basically implies that all old versions of lily must be included in the new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6 and 2.4. Which means that the lilypond package grows by a factor 4. I think a better solution would be that you create a script locally, which parses the input ly file, reads the \version statement, and picks which lilypond version to use to compile your ly file. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Evolutionary User Strategery
I wonder if the varied opinions represented in this thread are based in differing interests and ways Lily is used. The developer's interest is in usability of the latest stable version. A composer's interest is in an elegant score presentation of a very few scores, maybe never changing when 'finished'. I have talent for neither. I'm attempting to transcribe many public domain compositions and make many of them publicly available. A set of such scores takes me months to years to complete. I expect to provide both the ly source and pdf result. Without upward compatibility, these are obsolete before they are ready for posting. Mutopia suffers from such obsolescence. I also use Lily to transpose published charts for my personal use, finding ways to improve them as they are used. So I represent a user quite different from a composer. Spending time to repetitively adapt many ly files is overly burdensome. - Bruce -Original Message- From: Simon Dahlbacka [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 10:24 AM To: Fairchild Cc: lilypond-user@gnu.org Subject: Re: Evolutionary User Strategery Bruce, sorry to be rude but: Being forced to absolute backward compatibility sucks, and having to keep compatibility with e.g. 2.4 2.6 and 2.8 sucks even more, and makes the code base bloated, less maintainable and probably a lot of #ifdefs of what not that leads to more bugs.. Put it another way, you don't want to write your .ly files in such a way that you can use whatever lilypond version to compile them and get a perfect result. The developers most certainly does not want absolute backwards compatibility, and they even bother so much as to provide convert-ly to make the transition forward easier. Whose arguments do you thing weigh more? Most developers develop lilypond in their spare time just for the fun of it for all I know.. After all, this is free software, if you like, you can make your own compatible-with-everything-even-all-the-bugs fork project.. /S On 7/10/06, Fairchild [EMAIL PROTECTED] wrote: Erik - Thanks for contributing to this thread. It is attempting to deal with an important unresolved issue: seamless evolutionary transitioning of ly files. Your suggested solution requires n versions residing entirely in the user's machine, which would, as you point out, increase resident code by a factor of n. The code switching option requires parallel code only for features that are interpreted differently for different versions, only marginally increasing the size of the newer versions - far less size, and hassle, than retaining several versions. Marginally increasing the single package size is not a concern. Through the generations, memory and speed have increased to accommodate applications - or maybe the other way around. The first computer I used had 2000 bi-quinary ten-digit words on a drum. Long-term memory was punched cards. It was a fantastic improvement over its predecessor, the Card Programmed Calculator. Increasing processing time is a consideration, but testing a flag to select from version-specific code segments would be barely measurable. - Bruce -Original Message- From: Erik Sandberg [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 3:12 AM To: Fairchild Cc: lilypond-user@gnu.org Subject: Re: Evolutionary User Strategery On 7/9/06, Fairchild [EMAIL PROTECTED] wrote: New scores could use new features and not have to work around the bugs of earlier versions. Older scores that have been carefully tuned, compensating for earlier bugs, would continue to produce the intended result without having to be overhauled. There would be no need to maintain multiple versions. This basically implies that all old versions of lily must be included in the new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6 and 2.4. Which means that the lilypond package grows by a factor 4. I think a better solution would be that you create a script locally, which parses the input ly file, reads the \version statement, and picks which lilypond version to use to compile your ly file. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tetex 2.5 and lilypond 2.0
Anthony Youngman wrote: If your new system is powerful enough (and no, I haven't any experience of this but I'm planning to do something like this myself :-) Experiment with UML (User Mode Linux) and Gentoo. There's a good chance that if you get a minimal gentoo system running, then tell it to install the packages you need such as tetex 2.5, it will hopefully work fine. The portage system *should* resolve the necessary dependencies. As I say, I haven't done this. But it's an idea to play with ... and if you can get UML running you can easily run an old setup as a program inside Dapper :-) Cheers, Wol Gentoo currently has support for Lily 2.0.3 -- in fact, that is the latest version marked stable in the Gentoo build tree! --Daniel ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Directory in Windows
Title: Directory in Windows In the version 2.8.5 installation this portion of the tree contains no files at any level: . . . \Users\lilytest\testing\gub-devel\target\mingw\install\gcc-root\usr\cross\i686-mingw32\lib\debug Anybody know why? Just curious. - Bruce ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tetex 2.5 and lilypond 2.0
On Mon, 10 Jul 2006 09:29:32 -0700, Daniel Johnson wrote Gentoo currently has support for Lily 2.0.3 -- in fact, that is the latest version marked stable in the Gentoo build tree! But AFAIK it does not even compile anymore. I'm running 2.6 on Gentoo, it works, though it has still some Problems with a4 paper sizes... I don't know what the Gentoo people did wrong there, it seems nobody else has that kind of problems. But unfortunately there seem to be much too less testers on Gentoo. :( -- MfG Jan Open WebMail Project (http://openwebmail.org) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
On 7/10/06, Fairchild [EMAIL PROTECTED] wrote: Erik - Thanks for contributing to this thread. It is attempting to deal with an important unresolved issue: seamless evolutionary transitioning of ly files. Your suggested solution requires n versions residing entirely in the user's machine, which would, as you point out, increase resident code by a factor of n. The code switching option requires parallel code only for features that are interpreted differently for different versions, only marginally increasing the size of the newer versions - far less size, and hassle, than retaining several versions. Different lily versions use different data structures and interfaces internally. If we would have n different versions of e.g. each engraver, and the interface between iterators and engravers would change a tiny bit (which it does now and then), then we would need to update n different versions of each engraver, which is n times as much work as now; it would also mean n times more testing, and n times more bugs. Keep in mind also that the .ly grammar changes between versions, so you will need to have a separate parser for each version. That said, you are of course welcome to write a patch that makes lily 2.9 support 2.4 files. My guess is that Han-Wen won't accept the patch, but if you really want the feature you can always fork the lilypond project, and start a lilypond-legacy project. BTW, if you're concerned about the extra size consumption that it requires to have n different versions, you could consider compressing your file system. If there is much code in common between lily versions, then a smart compression algorithm might detect this and reduce the extra space consumed. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: navigating web documentation
Karl Berry wrote: Sure, I suppose at least the main keyboard shortcuts could/should be in the manual. Agreed. I added info about the keyboard shortcuts to the Texinfo manual yesterday. Ignorant question: What is the relationship between the HTML manual and the TeXinfo manual? I have at times been able to do info lilypond but not currently. Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: navigating web documentation
Paul Scott wrote: Karl Berry wrote: Sure, I suppose at least the main keyboard shortcuts could/should be in the manual. Agreed. I added info about the keyboard shortcuts to the Texinfo manual yesterday. Ignorant question: What is the relationship between the HTML manual and the TeXinfo manual? I have at times been able to do info lilypond but not currently. The Texinfo manual is a manual about texinfo. That's what Karl added info to. The LilyPond manual is written using texinfo. It is compiled (what's the proper term for this?) and is presented to users in HTML, pdf, and info. If you can't do info lilypond, then look into the way you install lilypond and your info system. My guess is that the recent GUB lilypond installations don't touch info, so you'd need to tweak your info setup. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: navigating web documentation
Graham Percival wrote: Paul Scott wrote: Ignorant question: What is the relationship between the HTML manual and the TeXinfo manual? I have at times been able to do info lilypond but not currently. The Texinfo manual is a manual about texinfo. That's what Karl added info to. Aah! Thanks. The LilyPond manual is written using texinfo. It is compiled (what's the proper term for this?) and is presented to users in HTML, pdf, and info. Thanks. That's what I guessed. If you can't do info lilypond, then look into the way you install lilypond and your info system. My guess is that the recent GUB lilypond installations don't touch info, so you'd need to tweak your info setup. Any idea how? I run GUBs on Debian sid. Is it automatic on your Mac setup? Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
tuplet bracket going wrong direction
With 2.9.10 (GUB) the triplet bracket in the attached example goes the
wrong way. Any ideas?
TIA,
Paul Scott
\version 2.9.10
\relative c' { ees16[ g \times 2/3 { r16 dis cis] } c4 d e f f e d }___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: navigating web documentation
Paul Scott wrote: Graham Percival wrote: If you can't do info lilypond, then look into the way you install lilypond and your info system. My guess is that the recent GUB lilypond installations don't touch info, so you'd need to tweak your info setup. Any idea how? I run GUBs on Debian sid. Is it automatic on your Mac setup? No, I just never look at info. My guess is that you can add search directories to info; you would want to add some search directory inside the GUB installation. Consult some docs about info for more details. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
melismatic left-alignment (and extenders) with \lyricmode
Okay... Having reviewed previous pieces, I see that even lyricmode doesn't get the extenders right for every melisma, but only attaches the lyrics to a single voice and its melismata (just like \lyricsto and \addlyrics). I just didn't have a piece that showed the limitations of this situation so clearly until now. It appears to me that the only way to get left-alignment and long enough extenders for all melismata regardless of voice is to be constantly using \set associatedVoice (or some abbreviated definition thereof). If there is a better way to do this, I'd love to know about it. Please forgive me if I've missed something utterly obvious. Thank you. Fr. Panteleimon ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
