Center a number above a measure - Issue 2445
David, I saw that Colin had opened a tracker for your *ly file http://code.google.com/p/lilypond/issues/detail?id=2445 I'm not a code developer, however I think it might be better to also open a Rietveld issue so that it gets a proper review, from my own experience, it is more likely to be looked at there than in the google tracker - simply because it is easier to read and comment inline. I don't know if you are familiar with that process, then if you are serious about getting this into the LilyPond code, you can work on it here and post the suggested changes etc. I fear otherwise it will stagnate *just* an attachment on a tracker. You can use git-cl to ease the process of uploading and updating both Rietveld and the tracker at the same time. http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers It doesn't mean that it has to compile necessarily or be perfect from the 'start' (for instance Mike Solomon often throws up 'concept' patches or 'work in progress' patches/code to Rietveld for comment. Sometimes they die there but more often than not they get improved very quickly simply because of the way to compare and share information in Rietveld. regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: templates and a little bit more
Hello list, if someone has loaded and tried my files on a windows machine, they probably didn't compile. So I uploaded a new version, which should compile on windows - well it did not on an old W2k machine, I could use to test ... and so I changed some things regarding the scheme-function (getcwd). http://www.xn--schne-noten-tfb.de/lalily.tgz Cheers, Jan-Peter On 10.04.2012 13:52, Jan-Peter Voigt wrote: On 06.04.2012 13:17, Janek Warcho? wrote: On Thu, Apr 5, 2012 at 7:37 PM, Jan-Peter Voigtjp.vo...@gmx.de wrote: Dear community, I bundled some extensions in a little package to try out. Some of these ideas might be interesting to include in lily. Here is a start of some docs, but just a little bit. I am working on it ... http://www.xn--schne-noten-tfb.de/?tabs=3,1 I'm sorry that i don't have time to dig deeper, but my first impression is that it's somewhat similar to OrchestralLily: http://lac.linuxaudio.org/2010/papers/25.pdf http://reinhold.kainhofer.com/orchestrallily/A-simple-example.html#A-simple-example - it may give you some inspiration. Yes, my template mechanism has a similar intention. And I think OrchestraLily is a great tool. But here are two points I wanted to solve differently: 1.: Orchestralily uses normal lilypond-variables to store and organize the music. An advantage is a quite simple input. But a question, I had and read several times on this list remains, why and how to deal with the strict naming rules for lily-vars. So I started storing music in scheme variables, to be able to use vars with a name verse1. Then I thought about the tree-like structure of music - Reinhold Kainhofer made a nice figure about this in his paper. 2.: I want to use normal music-functions for templates, so anything that fits in a music template, fits in a template. The JSON-like template syntax for oly is not my taste ;-) The music is stored in a hash-tree-structure, wich uses a goops-class tree (found in lascm.scm): --snip-- ; ... (define-class tree () (children #:accessor children #:init-thunk make-hash-table) (key #:accessor key #:init-keyword #:key #:init-value 'node) (value #:accessor value #:setter set-value! #:init-value #f) ) (define-method (tree-set! (tree tree) (path list) val) (if (= (length path) 0) (set! (value tree) val) (let* ((ckey (car path)) (cpath (cdr path)) (child (hash-ref (children tree) ckey)) ) (if (not (is-a? child tree)) (begin (set! child (make tree #:key ckey)) (hash-set! (children tree) ckey child) )) (tree-set! child cpath val) )) val) ; ... (define-method (tree-get-tree (tree tree) (path list)) (if (= (length path) 0) tree (let* ((ckey (car path)) (cpath (cdr path)) (child (hash-ref (children tree) ckey)) ) (if (is-a? child tree) (tree-get-tree child cpath) #f) ))) (define-method (tree-get (tree tree) (path list)) (let ((ctree (tree-get-tree tree path))) (if (is-a? ctree tree) (value ctree) #f))) ; ... --snip-- Hidden in a module '(lalily store) is a tree, to which music is stored with the \putMusic command. Also there is a current music folder var - I call it folder, because the term context is already reserved in lily, and this tree forms a file-system-like structure: \getMusic resolves the music stored in the tree in the given path relative to the current folder. A template is music-function with a defined signature also stored in a tree: \registerTemplate #'(generic) #(define-music-function (parser location piece options)(list? list?) ; location parameter for error messages, if music is not found (get-music piece location)) This tree-like structure allows several music pieces side by side. A collection of songs might lead to a tree: chor/alta-trinita/music/sop chor/alta-trinita/text/sop chor/alta-trinita/music/alt chor/alta-trinita/text/alt ... chor/horianna/music/sop chor/hosianna/text/sop ... Then, when calling a template for satb-choral music, you give paths '(chor alta-trinita) and '(chor hosianna). This will fetch the music from the store as needed. If a template is called with \callTemplate, the current folder and the current template are set accordingly on a path-stack and reset when the template-function returns. So writing a template means writing a scheme-function. That is not simplifying input in the first place. And storing music means using a scheme-list as a path. This also is not simplifying the input - in the first shot. But it divides input in storing music and calling a template. This is an advantage for automation and it simplifies input, if one can input scheme-values, which are used in several places in lily (e.g. pairs in markup-overrides). And a template can loop over the music - I use this in the choral-lied templates to create a Lyrics-context for each verse.
Re: Staging/Master Merge - James' Patchy
David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: If I could have worked out how to split them, while at the same time being able to keep track of what changes were still needed, I would have done. However, doing things like having a screech-boink.ly in new, with a screech-and-boink.ly in snippets, and remembering to keep checking that the docs were all up to date and the one in new could be deleted was too much for my brain. The problem was that I believe I needed to get them into a single patch for the benefit of patchy, You don't. What makes you think that? but I had them in six patches on my system. I git apply-ed each patch, but didn't remember to git add the files. Your mistake is that you bypass any operation working within git, and instead juggle with patches on the work directory exclusively. If you want to conflate 5 commits into a single patch for whatever reason (it is _not_ necessary for working with patchy, and I have no idea why you would think so), you can do something like git rebase -i HEAD~5 and do it. Very, very simply. Of course, you might want to do git checkout -b my-squishy-branch before in order not to change the original branch with 5 commits. For any non-trivial change, I tend to have about a dozen iterations of git rebase -i before everything is one coherent and organized sequence of commits. TBH that seems a duff aspect of git. No, it isn't. git apply _only_ touches the work directory, so whatever happens, git does not remember anything about it. Use git apply --index if you want git to also _register_ the changes. In short: it is a duff aspect of your workflow _bypassing_ git. How do you expect git to deal with things you don't even tell it, and which you choose to do outside of git's control? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, April 11, 2012 10:46 AM Subject: Re: Staging/Master Merge - James' Patchy David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: If I could have worked out how to split them, while at the same time being able to keep track of what changes were still needed, I would have done. However, doing things like having a screech-boink.ly in new, with a screech-and-boink.ly in snippets, and remembering to keep checking that the docs were all up to date and the one in new could be deleted was too much for my brain. The problem was that I believe I needed to get them into a single patch for the benefit of patchy, You don't. What makes you think that? The patches were interdependent. I was working on the assumption that it was possible I'd push the first. Then start the commands to push the next, but in the meantime patchy had been running and had pulled staging with only my first patch in it. It would therefore fail? I'm also not sure whether it pulls all staging in one go, or a commit at a time. TBH that seems a duff aspect of git. No, it isn't. git apply _only_ touches the work directory, so whatever happens, git does not remember anything about it. Use git apply --index if you want git to also _register_ the changes. In short: it is a duff aspect of your workflow _bypassing_ git. How do you expect git to deal with things you don't even tell it, and which you choose to do outside of git's control? My comment relates to the need to git add as a separate step. If I modify a file and commit, the modified file is updated in the repo. If I add a file to the source tree and commit, it isn't, and I need to do a separate step. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
On Wed, Apr 11, 2012 at 12:50:16PM +0200, David Kastrup wrote: My comment relates to the need to git add as a separate step. You _only_ need to use git add if you made your changes _manually_ in the work directory instead of going through git. I had to read David's email a few times, and I'm still not certain that I understood this. Here's my understanding: 1. when you (or makelsr.py) adds a new snippets, you must run git add SNIPPET-NAMES Note that makelsr.py tells you to do this; all you need to do is copypaste the command that makelsr.py gives you. 2. for all other changes, doing git commit -a will save all changes to the repo. Now the problem comes when you do git format-patch foo.patch patch -p1 foo.patch git commit -a ; even if you follow the above commands, it will *not* include any new files that were added to the git repo in step 1. That sequence of commands comes from me and my previous unfamiliarity with git branches. I'm certain that I've told either you or James (or both) to use that workflow... and now that I think about it, lily-git.tcl somewhat encourages that workflow as well. To counter-act my previous bad advice, I urge you to read the git for the impatient section of the CG, and start using git branches for everything. I know that branches are a bit unintuitive and frankly scary, but it's worth it. I've tried to boil down the branch stuff to a minimum in that page. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Wednesday, April 11, 2012 11:50 AM Subject: Re: Staging/Master Merge - James' Patchy Phil Holmes m...@philholmes.net writes: From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, April 11, 2012 10:46 AM Subject: Re: Staging/Master Merge - James' Patchy David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: If I could have worked out how to split them, while at the same time being able to keep track of what changes were still needed, I would have done. However, doing things like having a screech-boink.ly in new, with a screech-and-boink.ly in snippets, and remembering to keep checking that the docs were all up to date and the one in new could be deleted was too much for my brain. The problem was that I believe I needed to get them into a single patch for the benefit of patchy, You don't. What makes you think that? The patches were interdependent. I was working on the assumption that it was possible I'd push the first. Then start the commands to push the next, but in the meantime patchy had been running and had pulled staging with only my first patch in it. It would therefore fail? Why would you push two times instead of one time? Oh yeah. Good point. I'm also not sure whether it pulls all staging in one go, or a commit at a time. All staging in one go. It is, you are right, a good idea not to have intermediate commits that don't check out: that's bad news when you use git bisect for trying to find a commit introducing a particular bug. No way to sort the patches in a manner where they work out at every step? It may well have been, but it would have taken far more effort than compressing them into a single commit. At that point, my brain was already hurting. TBH that seems a duff aspect of git. No, it isn't. git apply _only_ touches the work directory, so whatever happens, git does not remember anything about it. Use git apply --index if you want git to also _register_ the changes. In short: it is a duff aspect of your workflow _bypassing_ git. How do you expect git to deal with things you don't even tell it, and which you choose to do outside of git's control? My comment relates to the need to git add as a separate step. You _only_ need to use git add if you made your changes _manually_ in the work directory instead of going through git. If I modify a file and commit, the modified file is updated in the repo. No, it isn't. You need to use git add in order to add it to the index. You can abbreviate some use cases by using git commit -a (guess what the -a option stands for), but you need to add _every_ change to the index before committing. If I add a file to the source tree and commit, it isn't, and I need to do a separate step. You _always_ need to add what you are going to commit. I repeat: if you choose to juggle around manually by applying patches on the work directory instead of using git commands like git rebase -i which work directly with the repository, git has no way to guess which changes in the work directory are to be committed and which not. If you work with commit -a, the assumption is that changes of registered files are to be committed. OK. Understood a bit better now. I use lily-git for convenience to commit, so this is done automagically. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
Graham Percival gra...@percival-music.ca writes: On Wed, Apr 11, 2012 at 12:50:16PM +0200, David Kastrup wrote: My comment relates to the need to git add as a separate step. You _only_ need to use git add if you made your changes _manually_ in the work directory instead of going through git. I had to read David's email a few times, and I'm still not certain that I understood this. Here's my understanding: 1. when you (or makelsr.py) adds a new snippets, you must run git add SNIPPET-NAMES Note that makelsr.py tells you to do this; all you need to do is copypaste the command that makelsr.py gives you. 2. for all other changes, doing git commit -a will save all changes to the repo. Wrong. git commit -a will update files it sees already in the index (because they were put there by a checkout or a git add). It never adds _any_ new file it can't already see in the index. Now the problem comes when you do git format-patch foo.patch patch -p1 foo.patch git commit -a ; even if you follow the above commands, it will *not* include any new files that were added to the git repo in step 1. patch -p1 is _really_ the wrong tool to use as it is not git-aware. There is no reason not to use git apply instead (which obviously knows all about the patches git generates), and almost always you want to add the --index option so that any changes are already put into the index without the need to add them via git add or (partly) with commit -a. And juggling with patches is _totally_ braindead anyway. Use git cherry-pick or even better git rebase -i for that sort of thing. Did I mention git rebase -i already? You don't need a separate branch to work with it. You can just use it to streamline an uncoordinated sequence of commits wherever you committed it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
Phil Holmes m...@philholmes.net writes:
No way to sort the patches in a manner where they work out at every
step?
It may well have been, but it would have taken far more effort than
compressing them into a single commit. At that point, my brain was
already hurting.
_Please_ check out git rebase -i. For rearranging the last five
commits, you call
git rebase -i HEAD~5
and the rest explains itself. And in case you mess up royally for
whatever reason,
git reset --hard HEAD@{5 minutes ago}
will put you back to where you started 5 minutes ago.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
- Original Message - From: David Kastrup d...@gnu.org To: Graham Percival gra...@percival-music.ca Cc: Phil Holmes m...@philholmes.net; lilypond-devel@gnu.org Sent: Wednesday, April 11, 2012 1:12 PM Subject: Re: Staging/Master Merge - James' Patchy Did I mention git rebase -i already? You don't need a separate branch to work with it. You can just use it to streamline an uncoordinated sequence of commits wherever you committed it. -- David Kastrup Just so you're aware, I think James and I follow a similar development workflow.: Make changes and test they work. Commit with lily-git Make patch with lily-git Save patch somewhere where I can't lose it. Put patch for review Reset git to abandon all changes with lily-git Go and do something else. Get patch push agreement checkout staging git am patch push. I'm sure branches would be more efficient and more git-like, but last time I tried multiple branches, I forgot what state each was in. With patches I can open them in an editor and look at them. And I am aware of gitk, but this system just works for me at present. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staging/Master Merge - James' Patchy
Phil Holmes m...@philholmes.net writes: I'm sure branches would be more efficient and more git-like, but last time I tried multiple branches, I forgot what state each was in. With patches I can open them in an editor and look at them. git log -p some_branch_name And I am aware of gitk, but this system just works for me at present. If it worked well, we would not have had this thread. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond bug 2368
On Wed, Apr 11, 2012 at 8:33 PM, Karol Majewski karol.majew...@gmail.com wrote: OK, thanks for explanation! Actually, I've menaged to solve my problem by entering hidden notes with unHidden slur in separate voice. Now the tie refers to the right notes and appeals to my sense of aesthetic - despite colliding with an accidental (take a look at the attachment). I see additional dots, you may want to hide them as well. As for the tie, a perfect solution would involve not only avoiding accidental, but also moving the augmentation dot a bit... there's a lot of work to be done on ties. Janek, I'm not a student of Politechnika Warszawska - neither former nor present. I'm a former student of Akademia Muzyczna w Gdańsku :) Ah :) I found a Karol-Majewski-Elka-student on the net and thought it may be you. Nice to see people from Poland! Are you interested in becoming a contributor? ;) BTW, i will take the opportunity for an obvious self-promotion: see how i represent our country in LilyPond newsletter http://news.lilynet.net/?The-LilyPond-Report-25 ! best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoiding tie/prall collision
Helge, On 11 April 2012 13:02, Helge Kruse helge.kruse-nos...@gmx.net wrote: Am 11.04.2012 19:24, schrieb James: Well it requires that any changes I do in the English document are picked up and translated by the trasnaltors. The assumption is that those that do the German Translating see my checkins and make the same changes in the german doc. They do for the Spanish and French, but I think that is simply because the two or three that do that are always looking for it. Virtually all the checkins I do are for doc only and so the translators can easily see what I have done and if they need to make the changes in their docs too. But the translations are handled separately from the English documents, so it is very likely the different translations are not always consistent. Patches are always welcome :) often I see the German translation gets 'left behind' compared to the Spanish, French and Japanese versions. The two sentences in German would be something like this: In mehrstimmiger Musik ist es im Allgemeinen besser, die Stimme explizit mit voice auszuwählen anstatt die Ausrichtung einzelner Objekte zu ändern. Für weitere Informationen siehe: Multiple voices. But this may differ in style from the original translators. I am not in the team yet. I don't know if there is a need for additional translation support. Further I don't know how to see this checkins. Does it make sense to learn how to see this and to add annotations/additions? I could give it a try. Or did I missed just one cycle? http://lilypond.org/doc/v2.15/Documentation/contributor/translating-the-documentation.html Start here. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
