Re: maintaining advanced power-user Scheme functions
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Thomas Morley thomasmorle...@gmail.com Cc: lilypond-user lilypond-user@gnu.org; Phil Hézaine philippe.heza...@free.fr; David Nalesnik david.nales...@gmail.com; LilyPond Developmet Team lilypond-de...@gnu.org Sent: Sunday, August 18, 2013 9:46 PM Subject: Re: maintaining advanced power-user Scheme functions After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and upload images. This is another significant benefit. I could elaborate on this topic, but as i don't have time to actually do something about it it probably wouln't make sense (unless someone wanted to lead such a change - then i would gladly help). best, Janek It doesn't need much changing - the main problem is maintaining the web site. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've just checked and made a couple commits using that web interface. Plain and simple, *with* all the advantages of git underneath. Of course i may be biased, so i invite you to check this with me. I believe that i will be able to explain everything that's needed in 5-10 minutes. Would you like to try? Actually, i believe that it would be good to have lilypond repository on github, so that new contributors would be able to create patches easily. They wouldn't have to install a virtual machine with Lilydev. Found a typo in documentation? Create a fix and submit it in *2 minutes.* Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and upload images. This is another significant benefit. I'm not sure if i understand. Does LSR compile snippets every time i open its webpage? Anyway, i'm not saying that LSR shouldn't be able to run LilyPond, just that it should not require this for operation. I could elaborate on this topic, but as i don't have time to actually do something about it it probably wouln't make sense (unless someone wanted to lead such a change - then i would gladly help). It doesn't need much changing - the main problem is maintaining the web site. What if the things i pointed out make it hard to maintain? I'd just like to point this out: - with current system, i know that i'm not going to help with updating LSR. If i had more time, i'd gladly do that, but i don't have. However, if it was independent from LilyPond version - i.e. updating one snippet means that the update becomes instantly visible, because updating isn't an all-or-nothing deal - i would gladly update some snippets from time to time, if it could be done via git. - i have some valuable snippets and templates myself, and i'd like to share them, but i don't see how they could fit with current LSR system. - i have 79 emails marked valuable snippet. Adding them to LSR (the way it works currently) would require a lot of work, and i don't have time for this. But if the LSR worked another way, i could do something about it. If you'd like to discuss this more, i think IRC could be a good idea (it's faster) - i'm logged in. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
One thing I'd definitely support about this is making LSR somewhat version independent to allow one to have snippets requiring new lily versions. Maybe providing several lily versions (not necessarily _all_ of course) and use an appropriate one to compile the snippets. This would also allow us to keep 'old' snippets without updating all to current lily syntax before being able to upgrade the whole LSR. Maybe something like running convert-ly over all snippets when a new stable release comes out and leave snippets that can't be upgraded automatically for older versions? Urs PS: I'd also second the idea of hosting lilypond on a more accessible server (if that doesn't imply complicated side-effects). It is so easy to create a fork and open a pull request, I'm sure such a step would increase the number of contributions by people who can't or won't go through some undefined and possibly complex process of 'becoming a developer' Janek Warchoł janek.lilyp...@gmail.com schrieb: 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've just checked and made a couple commits using that web interface. Plain and simple, *with* all the advantages of git underneath. Of course i may be biased, so i invite you to check this with me. I believe that i will be able to explain everything that's needed in 5-10 minutes. Would you like to try? Actually, i believe that it would be good to have lilypond repository on github, so that new contributors would be able to create patches easily. They wouldn't have to install a virtual machine with Lilydev. Found a typo in documentation? Create a fix and submit it in *2 minutes.* Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and upload images. This is another significant benefit. I'm not sure if i understand. Does LSR compile snippets every time i open its webpage? Anyway, i'm not saying that LSR shouldn't be able to run LilyPond, just that it should not require this for operation. I could elaborate on this topic, but as i don't have time to actually do something about it it probably wouln't make sense (unless someone wanted to lead such a change - then i would gladly help). It doesn't need much changing - the main problem is maintaining the web site. What if the things i pointed out make it hard to maintain? I'd just like to point this out: - with current system, i know that i'm not going to help with updating LSR. If i had more time, i'd gladly do that, but i don't have. However, if it was independent from LilyPond version - i.e. updating one snippet means that the update becomes instantly visible, because updating isn't an all-or-nothing deal - i would gladly update some snippets from time to time, if it could be done via git. - i have some valuable snippets and templates myself, and i'd like to share them, but i don't see how they could fit with current LSR system. - i have 79 emails marked valuable snippet. Adding them to LSR (the way it works currently) would require a lot of work, and i don't have time for this. But if the LSR worked another way, i could do something about it. If you'd like to discuss this more, i think IRC could be a good idea (it's faster) - i'm logged in. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org
Re: maintaining advanced power-user Scheme functions
One thing I'd definitely support about this is making LSR somewhat version independent to allow one to have snippets requiring new lily versions. Maybe providing several lily versions (not necessarily _all_ of course) and use an appropriate one to compile the snippets. This would also allow us to keep 'old' snippets without updating all to current lily syntax before being able to upgrade the whole LSR. Maybe something like running convert-ly over all snippets when a new stable release comes out and leave snippets that can't be upgraded automatically for older versions? Urs PS: I'd also second the idea of hosting lilypond on a more accessible server (if that doesn't imply complicated side-effects). It is so easy to create a fork and open a pull request, I'm sure such a step would increase the number of contributions by people who can't or won't go through some undefined and possibly complex process of 'becoming a developer' Janek Warchoł janek.lilyp...@gmail.com schrieb: 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've just checked and made a couple commits using that web interface. Plain and simple, *with* all the advantages of git underneath. Of course i may be biased, so i invite you to check this with me. I believe that i will be able to explain everything that's needed in 5-10 minutes. Would you like to try? Actually, i believe that it would be good to have lilypond repository on github, so that new contributors would be able to create patches easily. They wouldn't have to install a virtual machine with Lilydev. Found a typo in documentation? Create a fix and submit it in *2 minutes.* Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and upload images. This is another significant benefit. I'm not sure if i understand. Does LSR compile snippets every time i open its webpage? Anyway, i'm not saying that LSR shouldn't be able to run LilyPond, just that it should not require this for operation. I could elaborate on this topic, but as i don't have time to actually do something about it it probably wouln't make sense (unless someone wanted to lead such a change - then i would gladly help). It doesn't need much changing - the main problem is maintaining the web site. What if the things i pointed out make it hard to maintain? I'd just like to point this out: - with current system, i know that i'm not going to help with updating LSR. If i had more time, i'd gladly do that, but i don't have. However, if it was independent from LilyPond version - i.e. updating one snippet means that the update becomes instantly visible, because updating isn't an all-or-nothing deal - i would gladly update some snippets from time to time, if it could be done via git. - i have some valuable snippets and templates myself, and i'd like to share them, but i don't see how they could fit with current LSR system. - i have 79 emails marked valuable snippet. Adding them to LSR (the way it works currently) would require a lot of work, and i don't have time for this. But if the LSR worked another way, i could do something about it. If you'd like to discuss this more, i think IRC could be a good idea (it's faster) - i'm logged in. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org
Re: maintaining advanced power-user Scheme functions
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: Thomas Morley thomasmorle...@gmail.com; lilypond-user lilypond-user@gnu.org; Phil Hézaine philippe.heza...@free.fr; David Nalesnik david.nales...@gmail.com; LilyPond Developmet Team lilypond-de...@gnu.org Sent: Monday, August 19, 2013 11:02 AM Subject: Re: maintaining advanced power-user Scheme functions 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've just checked and made a couple commits using that web interface. Plain and simple, *with* all the advantages of git underneath. Of course i may be biased, so i invite you to check this with me. I believe that i will be able to explain everything that's needed in 5-10 minutes. Would you like to try? I've never used the web interface, but I'm prepared to believe it's quick and easy if you say it is. However, my other opposition to git for this purpose is that it's intended as a Version Control system, which is completely unnecessary for the LSR - that's just a simple database of text, with no version control needed. Actually, i believe that it would be good to have lilypond repository on github, so that new contributors would be able to create patches easily. They wouldn't have to install a virtual machine with Lilydev. Found a typo in documentation? Create a fix and submit it in *2 minutes.* And completely bu**er the make doc in the process. That's what the issue tracker is for and why the patch control system exists. Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and upload images. This is another significant benefit. I'm not sure if i understand. Does LSR compile snippets every time i open its webpage? Anyway, i'm not saying that LSR shouldn't be able to run LilyPond, just that it should not require this for operation. It compiles the snippets every time one is changed, and stores the resultant images in clickable form. Can git do that? It also exports the snippets so that they can be imported into the documents - which git can't do. I could elaborate on this topic, but as i don't have time to actually do something about it it probably wouln't make sense (unless someone wanted to lead such a change - then i would gladly help). It doesn't need much changing - the main problem is maintaining the web site. What if the things i pointed out make it hard to maintain? I'd just like to point this out: - with current system, i know that i'm not going to help with updating LSR. If i had more time, i'd gladly do that, but i don't have. However, if it was independent from LilyPond version - i.e. updating one snippet means that the update becomes instantly visible, because updating isn't an all-or-nothing deal - i would gladly update some snippets from time to time, if it could be done via git. - i have some valuable snippets and templates myself, and i'd like to share them, but i don't see how they could fit with current LSR system. - i have 79 emails marked valuable snippet. Adding them to LSR (the way it works currently) would require a lot of work, and i don't have time for this. But if the LSR worked another way, i could do something about it. If you would actually try the LSR, you'll see it's equally quick to enter snippets - each takes a few seconds or a minute at most. All
Re: maintaining advanced power-user Scheme functions
I think making it version independent might be easier to wish for than to provide! I believe the source code is available if you'd like to try getting it running on alternative infrastructure and updating it: http://lsr.dsi.unimi.it/download/ -- Phil Holmes - Original Message - From: Urs Liska To: Janek Warchoł ; Phil Holmes Cc: LilyPond Developmet Team ; Thomas Morley ; David Nalesnik ; lilypond-user Sent: Monday, August 19, 2013 11:21 AM Subject: Re: maintaining advanced power-user Scheme functions One thing I'd definitely support about this is making LSR somewhat version independent to allow one to have snippets requiring new lily versions. Maybe providing several lily versions (not necessarily _all_ of course) and use an appropriate one to compile the snippets. This would also allow us to keep 'old' snippets without updating all to current lily syntax before being able to upgrade the whole LSR. Maybe something like running convert-ly over all snippets when a new stable release comes out and leave snippets that can't be upgraded automatically for older versions? Urs PS: I'd also second the idea of hosting lilypond on a more accessible server (if that doesn't imply complicated side-effects). It is so easy to create a fork and open a pull request, I'm sure such a step would increase the number of contributions by people who can't or won't go through some undefined and possibly complex process of 'becoming a developer' Janek Warchoł janek.lilyp...@gmail.com schrieb: 2013/8/19 Phil Holmes m...@philholmes.net:- Original Message - From: Janek WarchołAfter some thinking, i came to the conclusion that LSR should beredesigned.Fristly, it should be a git repository, to make collaboration easy -when something's a git repository, i have a habit of contributingstuff there on every opportunity, because even if i do something wrongi can undo this.I'd guess you're in a minority of about 1% of users who would prefer usinggit to using a web interface. The current web interface allows you tocopy-and-paste code directly in, or alternatively to type it directly in.Both are simple and quick. To use git propoerly requires installing a newprogram and learning how to use it. Remember yesterday when you recommendeda whole book about how it's used? If that doesn't put off casualcontributors, nothing will. I started work on LilyPond by adding regteststo the LSR. If git had been required, I wouldn't have done so.A valid concern, but i have a counterargument: there is a webinterface for git that allows you to copy-and-paste code directly in,or alternatively to type it directly in. Both are quite simple andquick. This doesn't require installing a new program and learning howto use it.It's github.I've just checked and made a couple commits using that web interface.Plain and simple, *with* all the advantages of git underneath. Ofcourse i may be biased, so i invite you to check this with me. Ibelieve that i will be able to explain everything that's needed in5-10 minutes. Would you like to try?Actually, i believe that it would be good to have lilypond repositoryon github, so that new contributors would be able to create patcheseasily. They wouldn't have to install a virtual machine with Lilydev.Found a typo in documentation? Create a fix and submit it in *2minutes.*Secondly, i think that it shouldn't depend on any particular lilypondversion - in fact, it shouldn't actually run any lilypond in myopinion. I believe that LSR should hold both snippets' code and theiroutput, with lilypond version clearly stated, and thus allow to postsnippets for any lilypond version. It would just be a collection ofsnippets.The benefit of it running LilyPond is that it shows the result of the codeon the fly - no need to create and upload images. This is anothersignificant benefit.I'm not sure if i understand. Does LSR compile snippets every time iopen its webpage?Anyway, i'm not saying that LSR shouldn't be able to run LilyPond,just that it should not require this for operation.I could elaborate on this topic, but as i don't have time to actuallydo something about it it probably wouln't make sense (unless someonewanted to lead such a change - then i would gladly help).It doesn't need much changing - the main problem is maintaining the website.What if the things i pointed out make it hard to maintain?I'd just like to point this out:- with current system, i know that i'm not going to help with updatingLSR. If i had more time, i'd gladly do that, but i don't have.However, if it was independent from LilyPond version - i.e. updatingone snippet means that the update becomes instantly visible, becauseupdating isn't an all-or-nothing deal - i would gladly update somesnippets from time to time, if it could be done via git.- i have some valuable snippets and templates myself, and i'd like toshare them, but i don't see how they could fit with
Re: maintaining advanced power-user Scheme functions
Am 19.08.2013 12:25, schrieb Phil Holmes: - Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: Thomas Morley thomasmorle...@gmail.com; lilypond-user lilypond-user@gnu.org; Phil Hézaine philippe.heza...@free.fr; David Nalesnik david.nales...@gmail.com; LilyPond Developmet Team lilypond-de...@gnu.org Sent: Monday, August 19, 2013 11:02 AM Subject: Re: maintaining advanced power-user Scheme functions 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've just checked and made a couple commits using that web interface. Plain and simple, *with* all the advantages of git underneath. Of course i may be biased, so i invite you to check this with me. I believe that i will be able to explain everything that's needed in 5-10 minutes. Would you like to try? I've never used the web interface, but I'm prepared to believe it's quick and easy if you say it is. However, my other opposition to git for this purpose is that it's intended as a Version Control system, which is completely unnecessary for the LSR - that's just a simple database of text, with no version control needed. Version control _can_ be useful for a collection like the LSR. Think of providing snippets for more than one LilyPond version. If I'm using 2.16 I will download a different snippet than for 2.17.24 ... Actually, i believe that it would be good to have lilypond repository on github, so that new contributors would be able to create patches easily. They wouldn't have to install a virtual machine with Lilydev. Found a typo in documentation? Create a fix and submit it in *2 minutes.* And completely bu**er the make doc in the process. That's what the issue tracker is for and why the patch control system exists. That's not quite right. Github offers the concept of pull requests for exactly this purpose. Opening a pull request on Github could have the same function like uploading a patch for review. Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and upload images. This is another significant benefit. I'm not sure if i understand. Does LSR compile snippets every time i open its webpage? Anyway, i'm not saying that LSR shouldn't be able to run LilyPond, just that it should not require this for operation. It compiles the snippets every time one is changed, and stores the resultant images in clickable form. Can git do that? It also exports the snippets so that they can be imported into the documents - which git can't do. _Git_ can be used for all this too. But I doubt you could make Github work in this way. I think in order to design a Git driven LSR variant you'd have to create a new web application on top of a self-hosted Git installation. So I'm afraid this isn't an option currently (as I don't see who would be willing and able to dive into one more project right now). I could elaborate on this topic, but as i don't have time to actually do something about it it probably wouln't make sense (unless someone wanted to lead such a change - then i would gladly help). It doesn't need much changing - the main problem is maintaining the web site. What if the things i pointed out make it hard to maintain? I'd just like to point this out: - with current system, i know that i'm not going to help with updating LSR. If i
Re: maintaining advanced power-user Scheme functions
2013/8/19 Urs Liska u...@openlilylib.org: PS: I'd also second the idea of hosting lilypond on a more accessible server (if that doesn't imply complicated side-effects). It is so easy to create a fork and open a pull request, I'm sure such a step would increase the number of contributions by people who can't or won't go through some undefined and possibly complex process of 'becoming a developer' /moving/ main lilypond repository from savannah to github would probably be a big nuisance and can possibly have lots of side-effects. However, nothing prevents us from creating a fork on github (acually i have one already). The thing is, would it be maintained? That could probably be done with some scripts. I'd gladly help if there's interest. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
Am 19.08.2013 12:38, schrieb Phil Holmes: I think making it version independent might be easier to wish for than to provide! I believe the source code is available if you'd like to try getting it running on alternative infrastructure and updating it: http://lsr.dsi.unimi.it/download/ -- Phil Holmes I've downloaded it. Java isn't my first language. But I will have a look at it. It should be possible to realize such a thing, parsing the source for a version string, identifying an appropriate LilyPond version and use _that_ to compile the snippet. Urs - Original Message - *From:* Urs Liska mailto:u...@openlilylib.org *To:* Janek Warcho? mailto:janek.lilyp...@gmail.com ; Phil Holmes mailto:m...@philholmes.net *Cc:* LilyPond Developmet Team mailto:lilypond-de...@gnu.org ; Thomas Morley mailto:thomasmorle...@gmail.com ; David Nalesnik mailto:david.nales...@gmail.com ; lilypond-user mailto:lilypond-user@gnu.org *Sent:* Monday, August 19, 2013 11:21 AM *Subject:* Re: maintaining advanced power-user Scheme functions One thing I'd definitely support about this is making LSR somewhat version independent to allow one to have snippets requiring new lily versions. Maybe providing several lily versions (not necessarily _all_ of course) and use an appropriate one to compile the snippets. This would also allow us to keep 'old' snippets without updating all to current lily syntax before being able to upgrade the whole LSR. Maybe something like running convert-ly over all snippets when a new stable release comes out and leave snippets that can't be upgraded automatically for older versions? Urs PS: I'd also second the idea of hosting lilypond on a more accessible server (if that doesn't imply complicated side-effects). It is so easy to create a fork and open a pull request, I'm sure such a step would increase the number of contributions by people who can't or won't go through some undefined and possibly complex process of 'becoming a developer' Janek Warcho? janek.lilyp...@gmail.com schrieb: 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warcho? After some thinking, i came to the conclusion that LSR should be redesigned. Fristly, it should be a git repository, to make collaboration easy - when something's a git repository, i have a habit of contributing stuff there on every opportunity, because even if i do something wrong i can undo this. I'd guess you're in a minority of about 1% of users who would prefer using git to using a web interface. The current web interface allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are simple and quick. To use git propoerly requires installing a new program and learning how to use it. Remember yesterday when you recommended a whole book about how it's used? If that doesn't put off casual contributors, nothing will. I started work on LilyPond by adding regtests to the LSR. If git had been required, I wouldn't have done so. A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've just checked and made a couple commits using that web interface. Plain and simple, *with* all the advantages of git underneath. Of course i may be biased, so i invite you to check this with me. I believe that i will be able to explain everything that's needed in 5-10 minutes. Would you like to try? Actually, i believe that it would be good to have lilypond repository on github, so that new contributors would be able to create patches easily. They wouldn't have to install a virtual machine with Lilydev. Found a typo in documentation? Create a fix and submit it in *2 minutes.* Secondly, i think that it shouldn't depend on any particular lilypond version - in fact, it shouldn't actually run any lilypond in my opinion. I believe that LSR should hold both snippets' code and their output, with lilypond version clearly stated, and thus allow to post snippets for any lilypond version. It would just be a collection of snippets. The benefit of it running LilyPond is that it shows the result of the code on the fly - no need to create and
new to lilypond
Hi all, I am new to lilypond and have a few basic questions. 1) are there other blind lilypond users? 2) how do i write accidentals in english. Steph ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
Urs Liska u...@openlilylib.org writes: Version control _can_ be useful for a collection like the LSR. Think of providing snippets for more than one LilyPond version. If I'm using 2.16 I will download a different snippet than for 2.17.24 ... But that's not what version control is for. Version control does not fundamentally work with a series of codependent equally active HEADs, but rather has one principal HEAD of development, and historic references (quite likely containing _inferior_ code, and inferior for reasons that are often only marginally related to the LilyPond version). -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
Well, one question may be whether git could be an alternate interface into the LSR. In a limited manner, it already is (snippets migrate back from LilyPond git repository into the LSR). Actually, I like the idea of using git for the LSR *as the storage*. Experienced cann access it directly, and maybe a simple HTML interface can be added. Using git for managing snippets corresponding to different versions of LilyPond is likely a tool mismatch. git is more slated for maintaining a development of improvements. Do you know something better? On the other hand, branches are very cheap in git, and having separate branches for different lilypond versions is straightforward, I think. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
Stephanie sim.musicsch...@gmail.com writes: Hi all, I am new to lilypond and have a few basic questions. 1) are there other blind lilypond users? I know about three who have occasionally posted to the list. I don't think any of them is a regular reader of the list, probably because managing the high volume is even harder when you are blind. 2) how do i write accidentals in english. Try the link URL:http://www.lilypond.org/doc/v2.16/Documentation/notation/writing-pitches#note-names-in-other-languages hopefully you have a web browser delivering a useful rendition of that link. If not, report back. Basically, you tack on s for sharp and ss or x for double sharp, and f for flat and ff for double flat. Note that the default note language is _not_ English but rather Dutch. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
Greetings, \language "english Then -s for sharp and -f for flat. [Leave out the dashes.] Interestingly, myself and I know many others, prefer the Nederlands -es and -is. See the manual section 1.1.1. I think there are some other blind users on the list... Andrew Stephanie 19 August 2013 10:30 PM Hi all, I am new to lilypond and have a few basic questions. 1) are there other blind lilypond users? 2) how do i write accidentals in english. Steph ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
2013/8/19 Stephanie sim.musicsch...@gmail.com: Hi all, I am new to lilypond and have a few basic questions. Hi Stephanie, welcome! 1) are there other blind lilypond users? Yes 2) how do i write accidentals in english. Try one of this settings in your file: \language english or \include english.ly Steph Cheers, Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
- Original Message - From: Stephanie sim.musicsch...@gmail.com To: lilypond-user@gnu.org Sent: Monday, August 19, 2013 1:30 PM Subject: new to lilypond Hi all, Hi, Stephanie, I am new to lilypond and have a few basic questions. 1) are there other blind lilypond users? We have had a number of other blind users, who have been active on the user list in the past, but I've not seen contributions from them recently. 2) how do i write accidentals in english. Steph I think a lot of us simply use the Dutch standard of es for a flat and is for a sharp - I certainly do. According to the Notation Reference, f is a flat in English and s is a sharp (makes sense). -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Stanza is displaying at bottom of score
In the following minimal example, a repeated stanza is showing up
under the PianoStaff. Of course, I would need it to be under the
first stanza, above the PianoStaff. Am I missing some setting,
how can I fix this? Any help much appreciated :)
Kind regards,
Jethro
Screenshot:
http://jethro.be/upload/sc_stanzas.png
Minimal example:
\version 2.17.24
\score {
\new Staff {
\new Voice = melody {
\relative c'' {
a4 a a a
\repeat volta 2 { b4 b b b }
}
}
}
\new Lyrics \lyricsto melody {
Not re -- peat -- ed.
{ The first time words. }
\new Lyrics {
\set associatedVoice = melody
Sec -- ond time words.
}
}
\new PianoStaff
{
{ a b c d c d e f } { a b c c c d e f }
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
David Kastrup d...@gnu.org schrieb: Urs Liska u...@openlilylib.org writes: Version control _can_ be useful for a collection like the LSR. Think of providing snippets for more than one LilyPond version. If I'm using 2.16 I will download a different snippet than for 2.17.24 ... But that's not what version control is for. Version control does not fundamentally work with a series of codependent equally active HEADs, but rather has one principal HEAD of development, and historic references (quite likely containing _inferior_ code, and inferior for reasons that are often only marginally related to the LilyPond version). I think developing input files to keep up with LilyPond versions _is_ natural to Git. Snippet versions which are compatible to a certain older version of LilyPond are legitimate 'historic references'. Accessing them in parallel isn't natural, that's right. But it could be made manageable. On Github for example you can access files on different branches through different url paths. I don't want to say that it's dead easy, though ... Urs -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Stanza is displaying at bottom of score
- Original Message -
From: Jethro Van Thuyne p...@jethro.be
To: lilypond-user@gnu.org
Sent: Monday, August 19, 2013 2:25 PM
Subject: Stanza is displaying at bottom of score
In the following minimal example, a repeated stanza is showing up
under the PianoStaff. Of course, I would need it to be under the
first stanza, above the PianoStaff. Am I missing some setting,
how can I fix this? Any help much appreciated :)
You need to adjust it like this:
\new Lyrics = FirstVerse \lyricsto melody {
Not re -- peat -- ed.
{ The first time words. }
\new Lyrics \with { alignBelowContext = #FirstVerse } {
\set associatedVoice = melody
Sec -- ond time words.
}
}
This is in the NR, a little further on from the place you presumably got the
first bit of code.
If you'd used different rhythms in the piano and voice, it would have
given the clue that it was a placement issue, not relating to the note
rhythms.
--
Phil Holmes
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Stanza is displaying at bottom of score
Perfect, thank you so much!
Jethro
Phil Holmes (19 Aug 2013 @ 15:36)
- Original Message - From: Jethro Van Thuyne
p...@jethro.be
To: lilypond-user@gnu.org
Sent: Monday, August 19, 2013 2:25 PM
Subject: Stanza is displaying at bottom of score
In the following minimal example, a repeated stanza is showing up
under the PianoStaff. Of course, I would need it to be under the
first stanza, above the PianoStaff. Am I missing some setting,
how can I fix this? Any help much appreciated :)
You need to adjust it like this:
\new Lyrics = FirstVerse \lyricsto melody {
Not re -- peat -- ed.
{ The first time words. }
\new Lyrics \with { alignBelowContext = #FirstVerse } {
\set associatedVoice = melody
Sec -- ond time words.
}
}
This is in the NR, a little further on from the place you presumably
got the first bit of code.
If you'd used different rhythms in the piano and voice, it would
have given the clue that it was a placement issue, not relating to
the note rhythms.
--
Phil Holmes
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
[no subject]
Hello to all,
here's a minimal code:
%%
\version 2.16.2
\relative c {
\clef bass
\key c \major
\cadenzaOn
c,2
^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
^\markup {\small { Corno in Fa } }
c' \clef treble g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c
\cadenzaOff \bar ||
}
\layout {
\context {
\Staff \remove Time_signature_engraver
}
}
%%
The quarter notes marked with '-' are waning, quarter notes marked with ''
are increasing. What is the correct way to indicate it? I tried to draw the
arrows, but I could not do it.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Enter correctly flat and sharp notes
Hello to all,
here's a minimal code:
%%
\version 2.16.2
\relative c {
\clef bass
\key c \major
\cadenzaOn
c,2
^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
^\markup {\small { Corno in Fa } }
c' \clef treble g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c
\cadenzaOff \bar ||
}
\layout {
\context {
\Staff \remove Time_signature_engraver
}
}
%%
The quarter notes marked with '-' are flat, quarter notes marked with ''
are sharp. What is the correct way to indicate it? I tried to draw the
arrows, but I could not do it.
Ciao
Tommaso
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
How to avoid that it appears the new key with a key change at the end of stave
Hello to all, I would like to avoid that the new key appears when I have a key change at the end of the staff. I tried it in the documentation, but I could not find what I need. Can you help me? Ciao Tommaso ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:
http://lilypond.org/doc/v2.16/Documentation/learning/accidentals-and-key-signatures.it.html
--
Phil Holmes
- Original Message -
From: Tommaso Gordini
To: lilypond-user@gnu.org
Sent: Monday, August 19, 2013 2:51 PM
Hello to all,
here's a minimal code:
%%
\version 2.16.2
\relative c {
\clef bass
\key c \major
\cadenzaOn
c,2
^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
^\markup {\small { Corno in Fa } }
c' \clef treble g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4-- bes-+
b2 c
\cadenzaOff \bar ||
}
\layout {
\context {
\Staff \remove Time_signature_engraver
}
}
%%
The quarter notes marked with '-' are waning, quarter notes marked with ''
are increasing. What is the correct way to indicate it? I tried to draw the
arrows, but I could not do it.
--
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 Werner LEMBERG w...@gnu.org: Well, one question may be whether git could be an alternate interface into the LSR. In a limited manner, it already is (snippets migrate back from LilyPond git repository into the LSR). Actually, I like the idea of using git for the LSR *as the storage*. Experienced cann access it directly, and maybe a simple HTML interface can be added. That's what i meant - store LSR data in a repository, and have some interface for accessing it, similar to current one. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to avoid that it appears the new key with a key change at the end of stave
Am 19.08.2013 15:56, schrieb Tommaso Gordini:
Hello to all,
I would like to avoid that the new key appears when I have a key change at
the end of the staff. I tried it in the documentation, but I could not find
what I need.
do you mean:
\layout {
\context {
printKeyCancellation = ##f
}
}
Eluze
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to avoid that it appears the new key with a key change at the end of stave
2013/8/19 Tommaso Gordini illinguista1...@gmail.com:
Hello to all,
I would like to avoid that the new key appears when I have a key change at
the end of the staff. I tried it in the documentation, but I could not find
what I need.
Can you help me?
Ciao
Tommaso
See:
http://lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects.it.html#special-considerations
Example:
\version 2.16.2
% Better put the commands in layout
\layout {
\context {
\Staff
\override KeySignature #'break-visibility = ##(#f #t #t)
\override KeyCancellation #'break-visibility = ##(#f #t #f)
explicitKeySignatureVisibility = #'#(#f #t #t)
}
}
\relative c' {
\key cis\major
cis'1
\break
\key ces\major
ces'1
}
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
Hi, some things were already answered by other people 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've never used the web interface, but I'm prepared to believe it's quick and easy if you say it is. However, my other opposition to git for this purpose is that it's intended as a Version Control system, which is completely unnecessary for the LSR - that's just a simple database of text, with no version control needed. Someone once said if you have a project and it will take you more than an hour to recreate it from scratch, it should be under version control. It may not be apparent why this is so, but the experience confirms it. What if the things i pointed out make it hard to maintain? I'd just like to point this out: - with current system, i know that i'm not going to help with updating LSR. If i had more time, i'd gladly do that, but i don't have. However, if it was independent from LilyPond version - i.e. updating one snippet means that the update becomes instantly visible, because updating isn't an all-or-nothing deal - i would gladly update some snippets from time to time, if it could be done via git. - i have some valuable snippets and templates myself, and i'd like to share them, but i don't see how they could fit with current LSR system. - i have 79 emails marked valuable snippet. Adding them to LSR (the way it works currently) would require a lot of work, and i don't have time for this. But if the LSR worked another way, i could do something about it. If you would actually try the LSR, you'll see it's equally quick to enter snippets - each takes a few seconds or a minute at most. All that you need to do is type the snippet (or paste it) and a description - you can't do _less_ with any other system. Can i do it offline? What do you find so time-consuming? with current system, as far as i know, i would have to check all these snippets to make sure that they compile with required LilyPond version, and also i don't know of a way to add 'experimental' snippets. For example, i'm doing something and i find an interesting solution, but it only works with current git master and is somewhat hackish - but still useful, at least for advanced users. I'd like to be able to add it under some draft or experimental category. This isn't related to git, actually - although using git makes everything more maintainable in my experience. For example, i could have my own branch containing some private snippets, and easily merge them when they're ready. Also, assume that i grab all these snippets from my emails and paste them into one big chaos here folder (i believe that it's better to have unfinished stuff saved somewhere - just clearly separated from the clean stuff - rather than don't have it at all). Having git underneath would be a safety net if someone decides that this wasn't actually a good idea to paste all that stuff there. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to avoid that it appears the new key with a key change at the end of stave
Eluze wrote
Am 19.08.2013 15:56, schrieb Tommaso Gordini:
Hello to all,
I would like to avoid that the new key appears when I have a key change
at
the end of the staff. I tried it in the documentation, but I could not
find
what I need.
do you mean:
\layout {
\context {
printKeyCancellation = ##f
}
}
Eluze
sorry, forgot to add the context \Staff above
anyway, this will only suppress the cancellation of keys - see Harms
solution for suppressing the whole key at the end of line
Eluze
___
lilypond-user mailing list
lilypond-user@
https://lists.gnu.org/mailman/listinfo/lilypond-user
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/How-to-avoid-that-it-appears-the-new-key-with-a-key-change-at-the-end-of-stave-tp149454p149460.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: Thomas Morley thomasmorle...@gmail.com; lilypond-user lilypond-user@gnu.org; Phil Hézaine philippe.heza...@free.fr; David Nalesnik david.nales...@gmail.com; LilyPond Developmet Team lilypond-de...@gnu.org Sent: Monday, August 19, 2013 3:17 PM Subject: Re: maintaining advanced power-user Scheme functions Hi, some things were already answered by other people 2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchol A valid concern, but i have a counterargument: there is a web interface for git that allows you to copy-and-paste code directly in, or alternatively to type it directly in. Both are quite simple and quick. This doesn't require installing a new program and learning how to use it. It's github. I've never used the web interface, but I'm prepared to believe it's quick and easy if you say it is. However, my other opposition to git for this purpose is that it's intended as a Version Control system, which is completely unnecessary for the LSR - that's just a simple database of text, with no version control needed. Someone once said if you have a project and it will take you more than an hour to recreate it from scratch, it should be under version control. It may not be apparent why this is so, but the experience confirms it. The LSR is not a project, it's a collection of text objects. A simple database is the best place for a collection of text objects. If you would actually try the LSR, you'll see it's equally quick to enter snippets - each takes a few seconds or a minute at most. All that you need to do is type the snippet (or paste it) and a description - you can't do _less_ with any other system. Can i do it offline? You can't update any remote system offline - git or the LSR. What do you find so time-consuming? with current system, as far as i know, i would have to check all these snippets to make sure that they compile with required LilyPond version, and also i don't know of a way to add 'experimental' snippets. For example, i'm doing something and i find an interesting solution, but it only works with current git master and is somewhat hackish - but still useful, at least for advanced users. I'd like to be able to add it under some draft or experimental category. This isn't related to git, actually - although using git makes everything more maintainable in my experience. For example, i could have my own branch containing some private snippets, and easily merge them when they're ready. Also, assume that i grab all these snippets from my emails and paste them into one big chaos here folder (i believe that it's better to have unfinished stuff saved somewhere - just clearly separated from the clean stuff - rather than don't have it at all). Having git underneath would be a safety net if someone decides that this wasn't actually a good idea to paste all that stuff there. What you've described there is a set of odd bits of code that are badly structured and with no clear idea of what they do (chaos here is not good documentation practice). Putting them in a git repo would not make them any more suitable for our documentation system than putting them in the LSR. For your own use - fine. The LSR is intended to allow non-power users the ability to contribute lilypond code to other users and potentially our documentation. As such, it performs a useful service. I cannot imagine why you want to go to all the work of reimplmenting something that fundamentally works using completly different technology. It would be a massive waste of time. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 David Kastrup d...@gnu.org: Urs Liska u...@openlilylib.org writes: Version control _can_ be useful for a collection like the LSR. Think of providing snippets for more than one LilyPond version. If I'm using 2.16 I will download a different snippet than for 2.17.24 ... But that's not what version control is for. Version control does not fundamentally work with a series of codependent equally active HEADs, but rather has one principal HEAD of development, and historic references (quite likely containing _inferior_ code, and inferior for reasons that are often only marginally related to the LilyPond version). That's true. However, i think that it ultimately /makes sense/ with LSR. Look at it this way: 1) let's say Lilypond 2.18 is released and all snippets are upgraded to work with it. This is the master branch (what's visible by default via the web interface), and it gets a tag state as of 2.18 release. 2) LilyPond is continues to be developed in 2.19 series. People occasionally write new snippets that require 2.19 (or update existing ones from 2.18 to 2.19) - commits doing this do to a separate develop branch, and are not visible by default via the web interface, but advanced users can easily access them. This is the improvement part, as one upgrades a snippet to 2.19 precisely because it will work better. 3) at the same time, new snippets that work with the 2.18 release are added (and some snippets are improved), and this goes to the master branch. 4) when lilypond 2.20 is released, master and develop branches are merged. 5) the circle starts again. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
Phil Holmes mail at philholmes.net writes: I think a lot of us simply use the Dutch standard of es for a flat and is for a sharp - I certainly do. I'll be bold and disagree. G-flat is ges in Dutch (3 characters) and gf in English (2 characters). If you're typesetting a piece in D-flat major, the 33% redundancy for every black-key note in Dutch will add up quickly. I've been dealing with repetitive strain injuries for more than half my life now, so I have a rather strong aversion toward extra symbols, such as the s in -es and -is, which are identical between flats and sharps and thereby do nothing to distinguish them. They take up space but don't /do/ anything in return for the extra finger effort. If I were forced to type them, I would seek another input method. Fortunately I can just set the language to English and then enjoy more efficient input. (For longer keywords, Frescobaldi's auto-completion is a lifesaver.) hjh ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 Janek Warchoł janek.lilyp...@gmail.com: 2013/8/19 David Kastrup d...@gnu.org: Urs Liska u...@openlilylib.org writes: Version control _can_ be useful for a collection like the LSR. Think of providing snippets for more than one LilyPond version. If I'm using 2.16 I will download a different snippet than for 2.17.24 ... But that's not what version control is for. Version control does not fundamentally work with a series of codependent equally active HEADs, but rather has one principal HEAD of development, and historic references (quite likely containing _inferior_ code, and inferior for reasons that are often only marginally related to the LilyPond version). That's true. However, i think that it ultimately /makes sense/ with LSR. Look at it this way: 1) let's say Lilypond 2.18 is released and all snippets are upgraded to work with it. This is the master branch (what's visible by default via the web interface), and it gets a tag state as of 2.18 release. 2) LilyPond is continues to be developed in 2.19 series. People occasionally write new snippets that require 2.19 (or update existing ones from 2.18 to 2.19) - commits doing this do to a separate develop branch, and are not visible by default via the web interface, but advanced users can easily access them. This is the improvement part, as one upgrades a snippet to 2.19 precisely because it will work better. 3) at the same time, new snippets that work with the 2.18 release are added (and some snippets are improved), and this goes to the master branch. 4) when lilypond 2.20 is released, master and develop branches are merged. 5) the circle starts again. There's one thing to realize: we wouldn't need to have a branch for every Lilypond version there. We would just need two branches: current stable and stuff that is ahead of current stable. Very much like how various projects are developed. And still, if someone needed to access a version of the snippet meant for a parrticular verison of lilypond, it would be easy to do this thanks to git. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
Urs Liska u...@openlilylib.org writes: David Kastrup d...@gnu.org schrieb: Urs Liska u...@openlilylib.org writes: Version control _can_ be useful for a collection like the LSR. Think of providing snippets for more than one LilyPond version. If I'm using 2.16 I will download a different snippet than for 2.17.24 ... But that's not what version control is for. Version control does not fundamentally work with a series of codependent equally active HEADs, but rather has one principal HEAD of development, and historic references (quite likely containing _inferior_ code, and inferior for reasons that are often only marginally related to the LilyPond version). I think developing input files to keep up with LilyPond versions _is_ natural to Git. Snippet versions which are compatible to a certain older version of LilyPond are legitimate 'historic references'. Accessing them in parallel isn't natural, that's right. But it could be made manageable. On Github for example you can access files on different branches through different url paths. Ok, so we have a branch for version 2.17.2, a branch for 2.17.3, a branch for 2.17.4, a branch for 2.17.5 ... Now I update a snippet for the 2.17.4 branch. How will the update percolate to the branches 2.17.5...2.17.25? Basically, an automatic procedure would try to run convert-ly repeatedly and check everything in that has not been superseded by a manual checkin: after all, if I have replaced the snippet in 2.17.20, the replacement should most likely stick around. Or not: might be worth to flag an update conflict and wait for human resolution like a rebase does. I don't want to say that it's dead easy, though ... Yup. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchoł janek.lilyp...@gmail.com 2013/8/19 Phil Holmes m...@philholmes.net: However, my other opposition to git for this purpose is that it's intended as a Version Control system, which is completely unnecessary for the LSR - that's just a simple database of text, with no version control needed. Someone once said if you have a project and it will take you more than an hour to recreate it from scratch, it should be under version control. It may not be apparent why this is so, but the experience confirms it. The LSR is not a project, it's a collection of text objects. A simple database is the best place for a collection of text objects. Nonsense. I have a collection of lilypond scores (more than a hundred) in a git repository and it's working perfectly, and i have actually used version control features on that collection of scores. I.e. i did things that would be impossible to do without version control. Besides, look at Mutopia (it's a collection of text objects as well - i mean, the pieces are independent from each other). Or ask power users such as Nicolas, who has his scores under version control. What you said would be true if the snippets were so simple that they never change. But they do change. If you would actually try the LSR, you'll see it's equally quick to enter snippets - each takes a few seconds or a minute at most. All that you need to do is type the snippet (or paste it) and a description - you can't do _less_ with any other system. Can i do it offline? You can't update any remote system offline - git or the LSR. but with git i can do everything that matters offline - add new stuff, fix stuff, search old versions, etc. Then i just press a button and it does the rest. Imagine that i'm working on a big project w/o internet access (because i'm on holidays) and i create a few snipets. Do you think i'll remember them when i get back online? Definitely no! I will only care to add them to the repository when i'm actually working on the stuff, not a week later. What do you find so time-consuming? with current system, as far as i know, i would have to check all these snippets to make sure that they compile with required LilyPond version, and also i don't know of a way to add 'experimental' snippets. For example, i'm doing something and i find an interesting solution, but it only works with current git master and is somewhat hackish - but still useful, at least for advanced users. I'd like to be able to add it under some draft or experimental category. This isn't related to git, actually - although using git makes everything more maintainable in my experience. For example, i could have my own branch containing some private snippets, and easily merge them when they're ready. Also, assume that i grab all these snippets from my emails and paste them into one big chaos here folder (i believe that it's better to have unfinished stuff saved somewhere - just clearly separated from the clean stuff - rather than don't have it at all). Having git underneath would be a safety net if someone decides that this wasn't actually a good idea to paste all that stuff there. What you've described there is a set of odd bits of code that are badly structured and with no clear idea of what they do (chaos here is not good documentation practice). Putting them in a git repo would not make them any more suitable for our documentation system than putting them in the LSR. For your own use - fine. What's funny is that this description fits out issue tracker quite accurately. It's a set of odd bits of code, usually with no clear idea what they do (i mean, usually we can see that the output is wrong, but we don't know what actually happens inside - if we knew, many more bugs would be fixed instantly after submitting). And they are not structured in any way. Yet we keep them, because they contain some valuable information and it's better to have some information rather than none at all. Moreover, we have a policy to add issues to the tracker quite freely, i mean - when someone posts something wrong, we don't analyze it trying to find connections with other issues, but we just throw it in. It may be marked as duplicate later. Yet this system seems to work quite well. The LSR is intended to allow non-power users the ability to contribute lilypond code to other users and potentially our documentation. As such, it performs a useful service. I cannot imagine why you want to go to all the work of reimplmenting something that fundamentally works using completly different technology. It would be a massive waste of time. Well, as for completely different technology, that's not necessarily what i propose. Using git as the tool to manage the actual *content* doesn't have to mean changing thee tools that operate on that content. Why do i want to do this? Because
Re:
Sorry, I meant increasing and waning harmonics :-)
Ciao
Tommaso
Il giorno lunedì 19 agosto 2013, Tommaso Gordini illinguista1...@gmail.com
ha scritto:
Hello to all,
here's a minimal code:
%%
\version 2.16.2
\relative c {
\clef bass
\key c \major
\cadenzaOn
c,2
^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
^\markup {\small { Corno in Fa } }
c' \clef treble g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c
\cadenzaOff \bar ||
}
\layout {
\context {
\Staff \remove Time_signature_engraver
}
}
%%
The quarter notes marked with '-' are waning, quarter notes marked with
'' are increasing. What is the correct way to indicate it? I tried to draw
the arrows, but I could not do it.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 Phil Holmes m...@philholmes.net: This will be my last post on this. - Original Message - From: Janek Warchol janek.lilyp...@gmail.com 2013/8/19 Phil Holmes m...@philholmes.net: However, my other opposition to git for this purpose is that it's intended as a Version Control system, which is completely unnecessary for the LSR - that's just a simple database of text, with no version control needed. Someone once said if you have a project and it will take you more than an hour to recreate it from scratch, it should be under version control. It may not be apparent why this is so, but the experience confirms it. The LSR is not a project, it's a collection of text objects. A simple database is the best place for a collection of text objects. Nonsense. I have a collection of lilypond scores (more than a hundred) in a git repository and it's working perfectly, and i have actually used version control features on that collection of scores. I.e. i did things that would be impossible to do without version control. Besides, look at Mutopia (it's a collection of text objects as well - i mean, the pieces are independent from each other). Or ask power users such as Nicolas, who has his scores under version control. What you said would be true if the snippets were so simple that they never change. But they do change. Hardly ever. I maintain the current LSR and the changes are so infrequent I often forget to check whether there are any. This is part of the problem with your proposing changes - you admit you don't use the LSR, don't know how it works, don't know how to do simple updates, but you're proposing wholescale change. Please try the current system before trying to make large changes to it. If you would actually try the LSR, you'll see it's equally quick to enter snippets - each takes a few seconds or a minute at most. All that you need to do is type the snippet (or paste it) and a description - you can't do _less_ with any other system. Can i do it offline? You can't update any remote system offline - git or the LSR. but with git i can do everything that matters offline - add new stuff, fix stuff, search old versions, etc. Then i just press a button and it does the rest. Imagine that i'm working on a big project w/o internet access (because i'm on holidays) and i create a few snipets. Do you think i'll remember them when i get back online? Definitely no! I will only care to add them to the repository when i'm actually working on the stuff, not a week later. You could consider a text editor to create the snippets offline, giving them sensible names in a directory you can remember, and pasting them when you're online. What you've described there is a set of odd bits of code that are badly structured and with no clear idea of what they do (chaos here is not good documentation practice). Putting them in a git repo would not make them any more suitable for our documentation system than putting them in the LSR. For your own use - fine. What's funny is that this description fits out issue tracker quite accurately. It's a set of odd bits of code, usually with no clear idea what they do (i mean, usually we can see that the output is wrong, but we don't know what actually happens inside - if we knew, many more bugs would be fixed instantly after submitting). And they are not structured in any way. Yet we keep them, because they contain some valuable information and it's better to have some information rather than none at all. Moreover, we have a policy to add issues to the tracker quite freely, i mean - when someone posts something wrong, we don't analyze it trying to find connections with other issues, but we just throw it in. It may be marked as duplicate later. Yet this system seems to work quite well. Because it's designed to work as a way of remembering odd bits of information, not as a way of documenting how LilyPond works. The LSR is part of the LilyPond documentation system that users can access and read. It must be an accurate set of information and that's how it currently works. The LSR is intended to allow non-power users the ability to contribute lilypond code to other users and potentially our documentation. As such, it performs a useful service. I cannot imagine why you want to go to all the work of reimplmenting something that fundamentally works using completly different technology. It would be a massive waste of time. Well, as for completely different technology, that's not necessarily what i propose. Using git as the tool to manage the actual *content* doesn't have to mean changing thee tools that operate on that content. Why do i want to do this? Because the current system is limited: we don't have support for more than one lily version, upgrading is inconvenient, and there are no convenient ways to add some valuable stuff there. Fine. If you want to waste your time, feel
Re: new to lilypond
Greetings, James Harkins 20 August 2013 12:31 AM I'll be bold and disagree. G-flat is ges in Dutch (3 characters) and gf in English (2 characters). If you're typesetting a piece in D-flat major, the 33% redundancy for every black-key note in Dutch will add up quickly. Avoid D flat major. :-) They take up space but don't /do/ anything in return for the extra finger effort. But they _do_ do something in Nederlands for people whose language it is. Each to his own - the beauty of lilypond. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:
2013/8/19 Tommaso Gordini illinguista1...@gmail.com:
Sorry, I meant increasing and waning harmonics :-)
Ciao
Tommaso
Do you mean:
\version 2.16.2
\new Staff {
\key g\major
fis'
fis'?
fis'!
}
?
-Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
On Mon, Aug 19, 2013 at 11:36 AM, Andrew Bernard andrew.bern...@gmail.comwrote: Greetings, James Harkins jamshar...@gmail.com 20 August 2013 12:31 AM I'll be bold and disagree. G-flat is ges in Dutch (3 characters) and gf in English (2 characters). If you're typesetting a piece in D-flat major, the 33% redundancy for every black-key note in Dutch will add up quickly. Avoid D flat major. :-) Or write in C and use a \transpose command, which is what I typically do in that situation. compose-unknown-contact.jpg___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:
Or do you mean bends? Glissandi? Key change, even? Could you maybe send (or
point to) an example?
It seems unclear what you mean with crescente/calante in harmonics (as
opposed to dynamics) ...
-
Von meinem Fliewatüüt gesendet.
On 19 Aug 2013, at 17:19, Tommaso Gordini illinguista1...@gmail.com wrote:
Sorry, I meant increasing and waning harmonics :-)
Ciao
Tommaso
Il giorno lunedì 19 agosto 2013, Tommaso Gordini illinguista1...@gmail.com
ha scritto:
Hello to all,
here's a minimal code:
%%
\version 2.16.2
\relative c {
\clef bass
\key c \major
\cadenzaOn
c,2
^\markup { \tiny { Serie armonica del fa (+: crescente; -: calante) } }
^\markup {\small { Corno in Fa } }
c' \clef treble g' c e g \stemUp bes4-- \stemDown c2 d e f4-+ g2 a4--
bes-+ b2 c
\cadenzaOff \bar ||
}
\layout {
\context {
\Staff \remove Time_signature_engraver
}
}
%%
The quarter notes marked with '-' are waning, quarter notes marked with ''
are increasing. What is the correct way to indicate it? I tried to draw the
arrows, but I could not do it.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:
Robert Schmaus robert.schm...@web.de writes: Or do you mean bends? Glissandi? Key change, even? Could you maybe send (or point to) an example? It seems unclear what you mean with crescente/calante in harmonics (as opposed to dynamics) ... I believe that the intended meaning is Here are the notes of the harmonic series that can be played on the horn. The notes marked with a plus tend to sound sharp, and the notes marked with a minus tend to sound flat. -- David R ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Writing a fingering chart for French Horn
Hi Tommaso, 2013/8/18 Tommaso Gordini illinguista1...@gmail.com: Thank you, now everything works perfectly! I still have three demands. 1. It is possible to center the whole notes in the bar? Yes. See attached file. 2. It is possible to determine the distance of the first row of numbers from the first line of the pentagram? I wish that all the numbers were in line below the staff. For example, not 1 2 3 2 21 2-3 but 1 2 2 3 21 2-3 Here I don't know what you want. Doesn't the attached file gives you want you desire? 3. How do you get the line bar even in the white space between staves? Do you mean SpanBars? If yes, use StaffGroup. Again see attached file. Grazie e ciao Tommaso HTH, Harm tommaso-01.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:
Here are the notes of the harmonic series that can be played on the horn. The notes marked with a plus tend to sound sharp, and the notes marked with a minus tend to sound flat. Yes, exactly! :-) I was wondering if there is a typographically correct to report it. Maybe it could be done with the arrows up or down over the quarter notes? But I have not been able to draw them :-( Ciao Tommaso 2013/8/19 David Rogers davidandrewrog...@gmail.com Robert Schmaus robert.schm...@web.de writes: Or do you mean bends? Glissandi? Key change, even? Could you maybe send (or point to) an example? It seems unclear what you mean with crescente/calante in harmonics (as opposed to dynamics) ... I believe that the intended meaning is Here are the notes of the harmonic series that can be played on the horn. The notes marked with a plus tend to sound sharp, and the notes marked with a minus tend to sound flat. -- David R ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: maintaining advanced power-user Scheme functions
2013/8/19 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchol What you said would be true if the snippets were so simple that they never change. But they do change. Hardly ever. I maintain the current LSR and the changes are so infrequent I often forget to check whether there are any. Well, they need to be convert-ly'ed. Besides, i have some snippets that do change moderately often. This is part of the problem with your proposing changes - you admit you don't use the LSR, don't know how it works, don't know how to do simple updates, but you're proposing wholescale change. Please try the current system before trying to make large changes to it. ok, that's a valid point. I hope to have some time to actually try working with LSR. As for now, maybe i'll just start some LSR-esque public git repository to show that my approach is valid. You can't update any remote system offline - git or the LSR. but with git i can do everything that matters offline - add new stuff, fix stuff, search old versions, etc. Then i just press a button and it does the rest. Imagine that i'm working on a big project w/o internet access (because i'm on holidays) and i create a few snipets. Do you think i'll remember them when i get back online? Definitely no! I will only care to add them to the repository when i'm actually working on the stuff, not a week later. You could consider a text editor to create the snippets offline, giving them sensible names in a directory you can remember, and pasting them when you're online. Well, i could draw all my scores in Inkscape as well. The LSR is part of the LilyPond documentation system that users can access and read. It must be an accurate set of information and that's how it currently works. I've already said that, but i probably didn't make myself clear: i don't want to mix accurate and official snippets with chaotic ones. They would be labeled so that users will know if they're looking at official snippet or some weird hack that may be unsupported. The LSR is intended to allow non-power users the ability to contribute lilypond code to other users and potentially our documentation. As such, it performs a useful service. I cannot imagine why you want to go to all the work of reimplmenting something that fundamentally works using completly different technology. It would be a massive waste of time. Well, as for completely different technology, that's not necessarily what i propose. Using git as the tool to manage the actual *content* doesn't have to mean changing thee tools that operate on that content. Why do i want to do this? Because the current system is limited: we don't have support for more than one lily version, upgrading is inconvenient, and there are no convenient ways to add some valuable stuff there. Fine. If you want to waste your time, feel free to propose to change a perfectly adequate database for a completely different technology. please don't say perfectly adequate unless you show that the current system is capable of solving the problems i outlined. Nevertheless, thanks for the discussion; you're right that i should start by looking at current LSR and that maybe my ideas would be too much effort. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re:
2013/8/19 Tommaso Gordini illinguista1...@gmail.com:
Here are the notes of the
harmonic series that can be played on the horn. The notes marked with a
plus tend to sound sharp, and the notes marked with a minus tend to
sound flat.
Yes, exactly! :-) I was wondering if there is a typographically correct to
report it. Maybe it could be done with the arrows up or down over the
quarter notes? But I have not been able to draw them :-(
Ciao
Tommaso
2013/8/19 David Rogers davidandrewrog...@gmail.com
Robert Schmaus robert.schm...@web.de writes:
Or do you mean bends? Glissandi? Key change, even? Could you maybe
send (or point to) an example?
It seems unclear what you mean with crescente/calante in harmonics
(as opposed to dynamics) ...
I believe that the intended meaning is Here are the notes of the
harmonic series that can be played on the horn. The notes marked with a
plus tend to sound sharp, and the notes marked with a minus tend to
sound flat.
--
David R
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Hi,
how about the coding below.
It shows two possibilities.
a) Simple TextScript
b) Hijacking StringNumber. (I suppose it will not be needed for French Horn.) :)
\version 2.16.2
stringNumberSettings =
\layout {
\context {
\Voice
\override StringNumber #'Y-extent =
#(ly:make-unpure-pure-container
ly:grob::stencil-height
(lambda (grob start end) (ly:grob::stencil-height grob)))
stringNumberOrientations = #'(right)
\override StringNumber #'padding = 0
}
}
showTune =
#(define-event-function (parser location dir)(number?)
#{
\tweak #'stencil
#(lambda (grob)
(let* ((layout (ly:grob-layout grob))
(staff-space (ly:output-def-lookup layout 'staff-space))
(raise (cond ((= dir 1)
staff-space)
((= dir -1)
(* -2.8 staff-space))
(else 0)))
(rotate (if (= dir -1)
-90
0)))
(grob-interpret-markup grob
#{ \markup { \combine \null \raise #raise \rotate #rotate ↗ } #})))
\0
#})
\layout {
%% Only needed if \showTune is used
\stringNumberSettings
}
\relative c'' {
% Using TextScript
c_\markup ↗
c^\markup \rotate #-90 ↗
% (Ab)using StringNumber
c-\showTune #up
c-\showTune #down
}
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Henle piano template
2013/8/7 David Rogers davidandrewrog...@gmail.com: I just printed it and compared them side-by-side at the piano. Unfortunately I have to guess a little bit about absolute sizes, because I don't have any paper in the house except Letter size. With all due respect for Kieren's skill and work, which I cannot hope even to match let alone improve on, I really believe (taking the stated goals of Kieren's project literally) that only detail tweaks have so far been accomplished, and the general basic appearance is still very very LilyPond. What I notice is stuff that (to me) sounds like a mixture of easy things and difficult things: - The whole notation font needs to be replaced with a Henle-look-alike. At the very least, LP's notehead size is much too small for Henle; but everything else (quarter rests, fermatas, sharps flats, and clefs stand out in this example) looks very LilyPond as well. - The staff lines, ledger lines, and note stems need to be lightened a lot. - The beams may need to be darkened. (Or maybe they already match, after lightening the staff lines and stems.) - Slurs need to be thinner at the ends and thicker in the middle. - The accidentals need to be significantly closer to their noteheads. (I'm on version 2.17.22 - did something change? I'm getting excessive white-space between each accidental and its note, in this template.) I also wish that accidental spacing would improve - see the resources i've gathered here http://code.google.com/p/lilypond/issues/detail?id=2142 Unfortunately that's not going to happen very soon. One thing we could do for the sake of better Lilypond engraving is to move forward with Tie crusade. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sharing: Capone, by Rachael [pdf]
Hi Rachael, 2013/7/9 Rachael Thomas Carlson rachael.thomas.carl...@gmail.com: Hello All: I finished my first transcription with Lilypond a couple of days ago. I am proud of it. I have realized a couple of flaws since finishing it but since I do not feel like writing another 5K lines of code for this piece I have decided that it is done. Congratulations on finishing the score! I have found this community extraordinarily helpful. I am excited to continue working with all of you! And I must say, I have used Finale in the past but Lilypond surpasses it in almost every way. I have talked with a fellow fingerstyle buddy of mine who also does transcriptions (with Finale, though) and he gripes about some of the same stuff but because he is not able to manipulate how Finale interprets what he is attempting to tell it he ends up spending many hours attempting to input something that could be input within an hour with Lilypond (and emacs/vim). Thanks for your kind words! I have one question: in measure 36 (lower staff), there are two eight notes followed by a half-note chord. One eight note is connected with the chord using a tie, and the other one using a slur. Shouldn't both use ties? I don't see any rearticulation in the tablature. cheers, JAnek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
getting LedgerLineSpanner props from a NoteHead callback?
I'm trying to retrieve the value of LedgerLineSpanner.length-fraction from within a NoteHead callback, and I can't figure it out. Is there a way? Thanks. - Mark ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: getting LedgerLineSpanner props from a NoteHead callback?
2013/8/19 Mark Polesky markpole...@yahoo.com:
I'm trying to retrieve the value of
LedgerLineSpanner.length-fraction from within a NoteHead
callback, and I can't figure it out. Is there a way?
Thanks.
- Mark
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Hi Mark,
a quick shot, seems to work, though:
\version 2.17.24
#(define (look-up-for-parent name-symbol axis grob)
Return the parent of @var{grob}, specified by it's @var{name-symbol} in
axis @var{axis}.
If not found, look up for the next parent.
(let* ((parent (ly:grob-parent grob axis))
(grob-name (lambda (x) (assq-ref (ly:grob-property x 'meta) 'name
(cond
((not (ly:grob? parent))
(ly:error
(_Perhaps typing error for \~a\ or \~a\ is not in the parent-tree.)
name-symbol name-symbol))
((not (equal? name-symbol (grob-name parent)))
(look-up-for-parent name-symbol axis parent))
(else parent
#(define (read-out l1 l2)
(define (helper ls1 ls2 ls3)
Filters all elements of ls1 from ls2 by their grob-name and
appends it to ls3
(let ((grob-name-proc (lambda (x) (assq-ref (ly:grob-property x
'meta) 'name
(if (null? ls1)
ls3
(helper
(cdr ls1)
ls2
(append ls3 (filter (lambda (x) (eq? (car ls1)
(grob-name-proc x))) ls2))
(helper l1 l2 '()))
foo =
\override NoteHead.before-line-breaking =
#(lambda (grob)
(let* ((sys (look-up-for-parent 'System X grob))
(all (ly:grob-array-list (ly:grob-object sys 'all-elements)))
(llsp (read-out '(LedgerLineSpanner) all))
(l-f (ly:grob-property (car llsp) 'length-fraction)))
(display l-f)
))
{
\foo
a'
}
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
[Schikkers-List]: demo feedback
Nice progress on Schikkers list! It seems like it is coming along well. One thing that is counter-intuitive (maybe you're already aware of this), is that selecting a different note duration from the palette changes the currently selected note. My expectation was that it would only apply to newly entered notes, and that to change an already-entered note to a new duration, I would have to click on it again. Also, I prefer having the LilyPond text box below the staff instead of side-by-side, since that would provide more horizontal space for viewing the staff. I noticed an audio bug where a note would repeatedly play for some reason. (using Chrome 27) Ok, those are just a few thoughts for your consideration. Great work so far! -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
On Aug 19, 2013 11:36 PM, Andrew Bernard andrew.bern...@gmail.com wrote:
They take up space but don't /do/ anything in
return for the extra finger effort.
But they _do_ do something in Nederlands for people whose language it is.
Sure, but I was responding to a comment from a native English speaker who
uses Dutch input because... he likes more typing? :-P
Kidding... the real issue is the trade-off between readability and
concision. Actually, despite my complaints about extra keystrokes, in my
SuperCollider coding, I'm coming to favor readability: naming a variable
pitchClass rather than pc, or compare these ways to make an array of random
numbers:
{ 10.rand } ! 20 // !? What's that?
vs
// Even if I don't know anything about SC,
// this is obviously about arrays so I know
// where to look in the help
Array.fill(20, { 10.rand })
In the latter case, SC's code editor has nice auto-completion features, so
the finger cost is not as high as the character count.
For accidentals, df and des are both abbreviations -- favoring concision --
but one is more concise than the other, and neither is inherently more
readable. Of course it's valuable to let users enter notes in the way that
looks comfortable to them, but I think here, there's a rational argument to
be made that the gain in ease of reading is small.
But anyway, with Frescobaldi, I can type \inc RET SPC eng RET so, easy
enough.
If we wanted efficiency and global readability, we might try db and d#, but
I guess the # would confuse the parser.
hjh
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: getting LedgerLineSpanner props from a NoteHead callback?
Thomas Morley wrote: I'm trying to retrieve the value of LedgerLineSpanner.length-fraction from within a NoteHead callback, and I can't figure it out. Is there a way? Hi Mark, a quick shot, seems to work, though: Harm, that was great; thanks for that! It was the System.all-elements property that I didn't know about. That's the trick. Thanks so much. - Mark ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems trying to write a conditional \transpose
David Kastrup wrote:
I'm trying to write a conditional version of the \transpose
function, that would work something like this...
input = {
c c
\conditionalTransposition c c' { c c }
}
\input
= { c c c c }
\processConditionalTransposition \input
= { c c c' c' }
conditionalTransposition =
#(define-music-function (parser location from to music)
(ly:pitch? ly:pitch? ly:music?)
(set! music #{ \transpose c' c' #music #})
(set! (ly:music-property 'from-to music) (cons from to))
music)
processConditionalTransposition =
#(define-music-function (parser location music) (ly:music?)
(map-some-music
(lambda (m)
(and (music-is-of-type? m 'transposed-music)
(pair? (ly:music-property m 'from-to music))
#{ \transpose #(car (ly:music-property m 'from-to-music))
#(cdr (ly:music-property m 'from-to-music))
#(ly:music-property m 'element)
#}))
music))
David,
sorry for the delayed response. Your solution is excellent!
I'm learning so much from you.
Thanks again.
- Mark
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: new to lilypond
James Harkins jamshar...@gmail.com writes: For accidentals, df and des are both abbreviations -- favoring concision -- but one is more concise than the other, and neither is inherently more readable. Uh, no? df is an abbreviation, but des is a proper pronouncable name (if you are Dutch/German, that's the name you use when talking about music). As such, it has a letter combination that is natural to scan. Indeed, English has both dflat as well as df, while Dutch/German has only des and nothing else. The multi-word equivalent to d flat would be d mit einem b-chen but that's kid talk. No musician would use that. Now if you use ds and df often enough, they'll become more than abbreviations to you, but you still can't easily pronounce them as non-abbreviations. If we wanted efficiency and global readability, we might try db and d#, but I guess the # would confuse the parser. You could use d♭ and d♯ but they are rather cumbersome to type. And actually, they are not considerably more readable since they are half name, half symbol. While one uses them for chord names, for single notes they seem sort of unusuable. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems trying to write a conditional \transpose
Mark Polesky markpole...@yahoo.com writes:
David Kastrup wrote:
I'm trying to write a conditional version of the \transpose
function, that would work something like this...
input = {
c c
\conditionalTransposition c c' { c c }
}
\input
= { c c c c }
\processConditionalTransposition \input
= { c c c' c' }
conditionalTransposition =
#(define-music-function (parser location from to music)
(ly:pitch? ly:pitch? ly:music?)
(set! music #{ \transpose c' c' #music #})
(set! (ly:music-property 'from-to music) (cons from to))
music)
processConditionalTransposition =
#(define-music-function (parser location music) (ly:music?)
(map-some-music
(lambda (m)
(and (music-is-of-type? m 'transposed-music)
(pair? (ly:music-property m 'from-to music))
#{ \transpose #(car (ly:music-property m 'from-to-music))
#(cdr (ly:music-property m 'from-to-music))
#(ly:music-property m 'element)
#}))
music))
David,
sorry for the delayed response. Your solution is excellent!
I'm learning so much from you.
The code is written in a manner that does not make it obvious, but I
should have mentioned why I stored a pitch pair rather than a single
pitch difference: this was in order not to have an outer \transpose
affect the pitch difference information: music properties containing a
single pitch are converted by \transpose. A pitch pair is left alone.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
