Re: GUB on kainhofer: still cross/gcc
Op vrijdag 05-06-2009 om 23:05 uur [tijdzone +0100], schreef Anthony W. Youngman: Hi Anthony, I think that's a pretty usual setup (most people I know have a 32bit version of Linux installed on their laptop even though their CPU is actually 64bit). Sometimes it makes sense to do what most people do, esp. if you do it as a deliberate choice :-) Just as long as you're aware of the consequences ... what most people do is usually a pretty stupid thing to do. Following the herd is fine if you don't want to stand out, but if you want to make your mark it's not an option. Yup, that's exactly what I say: consider running 64 bits, even though running 32 bits is what most people do. Is it really necessary to paraphrase that? Note also, that running 32-bit on a 64-bit system can OFTEN be a performance WIN, so you DON'T want to upgrade just because you can. I call BS. Ref please? Are you saying that 64-bit code is *inherently* more efficient than 32-bit on a 64-bit system? What I'm trying to say is: please do not spread unsupported rumours, even if they give you a warm fuzzy feeling. You state that running 32-bit on a 64-bit system can OFTEN be a performance WIN but when asked for a reference, you say I can't give an actual reference, I'm afraid ...which makes it a rumour. Please try not to spread rumours, that does not help anyone :-) Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
Graham Percival wrote Friday, June 05, 2009 11:19 AM There's a surprising amount of interest in contributing to LilyPond from Windows machines. (err, I mean, from people *with* Windows machines, not from the actual machines themselves) As I understand it, people with Windows can: - run GUB I haven't tried - I didn't realise this was possible. Has anyone done it? - get the sources with git Tick - compile the docs without examples by running texi2html manually Tick, but this is often screwed up if the version number in snippets is bumped by an LSR update, since this means they can no longer be compiled with the latest released version. - compile the docs with GUB Must try this ... - write docstrings, fix bugs, and add new features to .scm files Tick However, they cannot: - compile lilypond Correct - write bugfixes, new features, and code janitor C++ files Is the above correct? If so, is there any hope of changing the cannot-compile status? In particular, - does anybody feel like making cygwin packages for the missing software? - does anybody have VMware (commercial version) and feel like making a small Linux installation which has all the required software? Potential contributors would be able to run this in the free VMware version. - does anybody feel like making shell accounts available for windows users? (I'm not at all certain how many windows contributors would feel comfortable using such a system, but I include it here for correctness) I can't commit to helping with this in the foreseeable future, I'm afraid. I suspect that the answer to the above questions is no, so I'll write the CG / new website to make this clear. But it's worth checking first. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
On Sat, Jun 06, 2009 at 11:21:39AM +0200, Jan Nieuwenhuizen wrote: Op vrijdag 05-06-2009 om 11:18 uur [tijdzone -0700], schreef Graham Percival: Do we need a separate branch (or even repository) for web/ stuff? Branch is not helpful, a separate repo has the advantage of allowing a simple 'git clone' (like it's meant to be) to get either one, without getting 'too much'. Developers do not need to get the web pages, translators do not need to get all of lily? Translators *do* need to get all of lily. At least, they need to get the docs (they translate this after the webpages, right?). I've toyed with the idea of splitting off the docs into a separate repo, but then it becomes much harder -- new features and syntax changes would require patches to both code/ and docs/. We definitely don't want to go that way! I admit that having a tiny repo to clone is a decent way for translators to get started quicker... but given that they need to switch repos after 10-20 hours of work anyway, I don't think this is a great saving. I propose that we merge this with the main branch. PRO: + one less branch/repo to track What is it that bothers you tracking an additional repo? To be up-to-date, I need to do a git pull origin in two separate directories. New (or relatively new) contributors need to create separate directories to get all the source. Etc. This isn't a /major/ issue... although twice now, I've forgotten to update my lilypond-web dir, resulting in me re-creating patches that other people had already fixed. Also, we don't always have both dirs set up. John and I have told each other I don't have newweb/ right now, could you make this change at least half a dozen times in the past few years -- we trade it back and forth, depending on who's reinstalled their OS the most recently. :) + easier to fix typos in the web pages I do not understand this. Why is that? People who don't have newweb/ probably won't download the new git repo just to fix a typo. People who have never gotten newweb/ definitely won't download it just to fix a typo. Perfect example: Jonathan. He's currently the main small doc fix guy, but he doesn't have newweb/ and never has, so any fixes to the website waits for other people to do. I fear that it's getting easier to create tainted commits, ie, commits that do a bugfix in lily, typo in web, etc. Ideally, a commit does exactly one thing (so it can be backported, or reverted if necessary, with more predictable consequences). If you want, I could crack down on this. Massively crack down. ... Come on, tell me to crack down. You know you want to. :) Special warning: Jonathan, we need to talk. + we can direct everybody to look at the CG (no more README in the newweb/ branch) Why cannot README's info be moved to the CG now? I just figured that a repo should have its own instructions. That's not necessary, though. Wouldn't this imply, however, that developers must read/skip through translator's info and vice versa? Developers already need to skip translator info. Fortunately, this is already nicely ghettoized in the CG, so it's obvious what to skip and what not to skip. + allows better integration with the other docs (this is more a post-GOP feature) This may be a deciding argument, however. Can you elaborate on this? It's partly psychological. Since web is in a separate branch, I never considered changing it as part of GOP. This isn't just my problem; the website contains some truly ancient info (all the call for jobs stuff?), which nobody has fixed. Granted, for the past six months I've been telling people not to fix it... but that still leaves years of neglect. For the new website, I was going to build as much as possible of it with texinfo. This would let us distribute the contents on pdf and info. In particular, contents like the first-time use (i.e. all the lilypond is like a compiler, not a GUI thing stuff). Content like the typographical essay (we currently have two; that's not optimal). In general, I wanted to start thinking about the website as part of the docs -- how easy is it to find information in the combined web+docs, how do new users progress through it, how can we ensure that new users already know about the compiling nature before they download the program, etc. I'm still not certain that it's worth doing it in texinfo. Many projects these days distribute html files as docs, so we might go with a relatively small set of html files, plus the pdf/info/html general info docs (most of the current website), plus the normal docs. CON: - adds 30 megs to the main branch (including the .git dir) No problem. However, it adds 1Gb to the translator's download. Isn't that one of the biggest cons? I don't believe that 1Gb figure. My lilypond is 488 megs, with all code built, and the English docs built. My guess is that the source alone clocks in at 150-200 megs. Yes, that's still much more
Re: development on windows
On Sat, Jun 06, 2009 at 11:03:58AM +0100, Trevor Daniels wrote: Graham Percival wrote Friday, June 05, 2009 11:19 AM There's a surprising amount of interest in contributing to LilyPond from Windows machines. (err, I mean, from people *with* Windows machines, not from the actual machines themselves) As I understand it, people with Windows can: - run GUB I haven't tried - I didn't realise this was possible. Has anyone done it? Err... by run GUB, I mean generate sheet music using the downloaded .exe. Even if somebody can't do anything else, with this they can still contribute a great deal -- creating examples, sorting/extending LSR stuff, etc. Frankly, in some ways I wish that we had *more* contributors who could only run GUB. There's a lot of tasks that I consider too simple for the git-savvy people to do, so as a result they tend to remain undone. :| - compile the docs without examples by running texi2html manually Tick, but this is often screwed up if the version number in snippets is bumped by an LSR update, since this means they can no longer be compiled with the latest released version. - compile the docs with GUB Must try this ... Err, if the version number in snippet matters, then you *have* been compiling with GUB. In the compile docs without examples, I meant something like - replace @lilypond[...] with @example - replace @end lilypond with @end example - compile docs with texi2html, without lilypond-book. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
unexpected \unfoldRepeats behavior
I tried to answer a question on -user but hit a brick wall.
\unfoldRepeats failed to work when the music block was funneled from 2
separate expressions. Can someone explain this to me? Why does the
following code work for voiceA but not for voiceB?
Thanks.
- Mark
_
\version 2.13.1
voiceA = \new Voice = A \relative {
\time 1/4
\repeat volta 2 { a' }
\alternative { { b } { c } }
}
% voiceB is built from 2 separate expressions funneled into one voice,
% but otherwise ought to be identical to voiceA, it seems:
voiceBrepeats = {
\time 1/4
\repeat volta 2 { s }
\alternative { { s } { s } }
}
voiceBnotes = \relative { \time 1/4 a' b c }
voiceB = \new Voice = B { \voiceBrepeats \voiceBnotes }
% using \unfoldRepeats produces the expected MIDI output with voiceA,
% but not with voiceB. Why?
\score {
\unfoldRepeats \voiceA % change to \voiceB to test.
\midi { }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
2009/6/6 Graham Percival gra...@percival-music.ca: Err... by run GUB, I mean generate sheet music using the downloaded .exe. GUB is the builder, and it builds the released binaries. You run the builder or the released binary. I propose to call things by their names. -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
Op zaterdag 06-06-2009 om 03:14 uur [tijdzone -0700], schreef Graham Percival: Translators *do* need to get all of lily. At least, they need to get the docs (they translate this after the webpages, right?). That's a good point. I was thinking, translation of docs is an exception, but that's probably less so these days... :-) I've toyed with the idea of splitting off the docs into a separate repo, but then it becomes much harder -- new features and syntax changes would require patches to both code/ and docs/. We definitely don't want to go that way! No, surely not. I admit that having a tiny repo to clone is a decent way for translators to get started quicker... but given that they need to switch repos after 10-20 hours of work anyway, I don't think this is a great saving. Okay... What is it that bothers you tracking an additional repo? To be up-to-date, I need to do a git pull origin You should only need git pull -r please *do* use -r, otherwise our repo is full of silly Merged brange foo from .. in two separate directories. New (or relatively new) contributors need to create separate directories to get all the source. Etc. Is it so hard to git config --global url.git+ssh://git.sv.gnu.org/srv/git/.insteadof gnu: git clone gnu:lilypond git clone gnu:lilypond-web # real soon now (unless your proposal :-) ? Create new directories, I don't understand? People who don't have newweb/ probably won't download the new git repo just to fix a typo. People who have never gotten newweb/ definitely won't download it just to fix a typo. Perfect example: Jonathan. He's currently the main small doc fix guy, but he doesn't have newweb/ and never has, so any fixes to the website waits for other people to do. Okay, I see. Well, we agree that the current setup is really bad. I suppose Jonathan could be taught how to handle a separate lilypond-web repo? Another branch within the main repo, like we have now, that's really confusing and scary. If you want, I could crack down on this. Massively crack down. ... Come on, tell me to crack down. You know you want to. :) bring it on! Special warning: Jonathan, we need to talk. I just figured that a repo should have its own instructions. That's not necessary, though. Indeed, whether we have web/README in a separate repo, branch, or main repo, it should probably exist, but point to the CG? Let's do that asaftt (as soon as anyone finds the time). It's partly psychological. In general, I wanted to start thinking about the website as part of the docs This makes a lot of sense. I'm starting to agree with your proposal. I'm still not certain that it's worth doing it in texinfo. Many projects these days distribute html files as docs, so we might go with a relatively small set of html files, plus the pdf/info/html general info docs (most of the current website), plus the normal docs. ...but this choice is not necessarily bound to the one/two repo issue. One repo would enable us to experiment with using texinfo here and there... I'm not sure that would help. Although having everything texinfo might be easier for translators, and the new css seems to show most anything is possible. I don't believe that 1Gb figure. My lilypond is 488 megs, with all code built, and the English docs built. My guess is that the source alone clocks in at 150-200 megs. Yes, that's still much more than the 30 meg newweb/ by itself, but if the translators are going to end up working on the docs eventually, they might as well get it all at the beginning. Looked into this. Git has now a history horizon. 12:51:09 jann...@peder:~ $ git clone --depth=10 gnu:lilypond Initialized empty Git repository in /home/janneke/lilypond/.git/ remote: Counting objects: 158432, done. remote: Compressing objects: 100% (40495/40495), done. remote: Total 158432 (delta 133195), reused 141201 (delta 117522) Receiving objects: 100% (158432/158432), 52.62 MiB | 168 KiB/s, done. Resolving deltas: 100% (133195/133195), done. 12:57:15 jann...@peder:~ $ du -sh lilypond lilypond/.git 84M lilypond 58M lilypond/.git which means we only need to get 84 MB. Problem is, pulling from savannah only goes at ~150KB/s here... True. Although we could make the same argument about doc writers. Why is that? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
On Sat, Jun 06, 2009 at 01:34:42PM +0200, Jan Nieuwenhuizen wrote: Op zaterdag 06-06-2009 om 03:14 uur [tijdzone -0700], schreef Graham Percival: What is it that bothers you tracking an additional repo? To be up-to-date, I need to do a git pull origin You should only need git pull -r please *do* use -r, otherwise our repo is full of silly Merged brange foo from .. *sigh* That would have been very useful to know six months ago, when I wrote the first draft of the CG and asked everybody to check it. What should we do for pushing? Is git push origin ok, or should it be git push ? (I just checked, and git push works... but is that the _best_ option?) in two separate directories. New (or relatively new) contributors need to create separate directories to get all the source. Etc. Is it so hard to git config --global url.git+ssh://git.sv.gnu.org/srv/git/.insteadof gnu: git clone gnu:lilypond git clone gnu:lilypond-web # real soon now (unless your proposal :-) The initial setup isn't really a problem; currently I just blindly copypaste: mkdir lilypond; cd lilypond git init-db git remote add -f -t master -m master origin git://git.sv.gnu.org/lilypond.git/ git checkout -b master origin/master ? Create new directories, I don't understand? We recommend (and I follow) putting lilypond, web, and lilypond/translations in separate directories. It's *much* easier than messing around with branches. People -- at least, the people that are savvy enough to contribute to lilypond -- understand directories. A directory that magically contains lilypond source, website source, or translation source, is an unwelcome complication. Basically, the entire CG-git stuff is modeled around the idea that we want contributors working on lilypond stuff (docs, translations, bugfixes), *not* working on understanding git stuff. Perfect example: Jonathan. He's currently the main small doc fix guy, but he doesn't have newweb/ and never has, so any fixes to the website waits for other people to do. Okay, I see. Well, we agree that the current setup is really bad. I suppose Jonathan could be taught how to handle a separate lilypond-web repo? Of course he _could_ be... although from a functional standpoint, that's identical to the current CG-recommended setup. The problem is that we very rarely have a website fix that's important enough to warrant the bother of setting it up and learning how it's organized. Unless we specifically say ok, X, you're now in charge of fixing typos on the website, X is very likely to say nah, I'm not going to bother fixing this typo report; I'll let somebody else handle it. I know this very well, since I've been X at least half the time. :) I'm still not certain that it's worth doing it in texinfo. Many projects these days distribute html files as docs, so we might go with a relatively small set of html files, plus the pdf/info/html general info docs (most of the current website), plus the normal docs. ...but this choice is not necessarily bound to the one/two repo issue. One repo would enable us to experiment with using texinfo here and there... I'm not sure that would help. The actual experiments would be done on a separate branch -- but only the initial experiments. Basically, I want to: - merge web/ and master/ - copy the new master/ into gop/ - work on gop/ for 3-4 weeks - merge gop/ to master, then delete gop/ In the long term, we would only have a single master/ branch, plus the various temporary/private development branches. (yes, something would happen to gub-samco and lilypad-macos). True. Although we could make the same argument about doc writers. Why is that? Explaining how to use lilypond is no more technically challenging than translating an explanation into another language. Yes, to write good docs, you need to understand the material involved -- but that's quite distinct from being able to figure out texinfo, git, and the like. We *have* lost documentation writers due to our choice of texinfo as the documentation language. It's confusing, limited, and not at all friendly to learn. *shrug* I'm not saying that the people we lost were absolutely fantastic... since they never really started, I can't tell, obviously. :) And I'm definitely not saying that there's a better language that produces good pdf+html (frankly, I couldn't care less about info). I'm also not saying that a certain amount of upfront difficulty is a *bad* thing. Somebody could make the argument that if a potential contributor isn't willing to learn texinfo + git + making functional diffs + our policies, then they don't have the dedication to be a good contributor anyway. I'm *not* making this argument myself. Rather, I'd say that if somebody can't figure out the CG -- as long as we make the repositories, branches, and CG as easy to follow as possible -- then they probably would not be
#lilyp...@irc.freenode.net
I've been present for some months now on #lilypond at freenode.net, so I've decided to mention the presence of this channel at http://lilypond.org/web/about/index.html The channel is owned by Simon Plante [cc], I've just asked him for OPER so that we can make it a bit more official :-) Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
Op zaterdag 06-06-2009 om 05:08 uur [tijdzone -0700], schreef Graham Percival: That would have been very useful to know six months ago, when I wrote the first draft of the CG and asked everybody to check it. ..didn't know about this then, I'm not much of a git guru. What should we do for pushing? Is git push origin ok, or should it be git push ? (I just checked, and git push works... but is that the _best_ option?) origin should not be necessary. The initial setup isn't really a problem but it is. You said it yourself: John and I have told each other I don't have newweb/ right now. If lilypond-web were a single repo, and git came initialized in a sane way, ie, with the gnu: alias, then git clone --depth=1 gnu:lilypond-web is less than 10sec away? It is the facts that cloning it takes very long and/or has a mantra that you cannot remember, that make it easier to ask someone else than getting it. I think. We recommend (and I follow) putting lilypond, web, and lilypond/translations in separate directories. Of course. Another reason for web to be in a separate repo (or to make it a simple directory Documentation/web). Basically, the entire CG-git stuff is modeled around the idea that we want contributors working on lilypond stuff (docs, translations, bugfixes), *not* working on understanding git stuff. Yes, but that's one of the reasons that the choice for [the speed of] git still comes with a price. Unless we specifically say ok, X, you're now in charge of fixing typos on the website, X is very likely to say nah, I'm not going to bother fixing this typo report; I'll let somebody else handle it. I know this very well, since I've been X at least half the time. :) Yes, that's unfortunate. Both the general observation and the equation graham==X. I suppose we should work on changing both :-) The actual experiments would be done on a separate branch -- but only the initial experiments. Basically, I want to: - merge web/ and master/ - copy the new master/ into gop/ Do I understand these steps to be something like [the just tested over here] git checkout -b web-gop origin/web mkdir -p Documentation/web mv .gitignore * Documentation/web/ git add . # watch out for any crufty in . moved to web/ :-) git add -u . git commit -m 'Prepare web for merge, move into Documentation/web.' git checkout -b gop origin/master git merge web-gop ? There's one thing that still bothers me about this, we'd need to declare Documentation/web 'dead' for branches other than master, eg, stable/2.12, whereas the rest of Documentation/ would not be dead in stable/2.12. Would this be a problem? - work on gop/ for 3-4 weeks - merge gop/ to master, then delete gop/ In the long term, we would only have a single master/ branch, plus the various temporary/private development branches. Okay. (yes, something would happen to gub-samco and lilypad-macos). *poof* gub-samco is gone :-) Han-Wen needs to move lilypad-macos. I'm also not saying that a certain amount of upfront difficulty is a *bad* thing. Somebody could make the argument that if a potential contributor isn't willing to learn texinfo + git + making functional diffs + our policies, then they don't have the dedication to be a good contributor anyway. I'm *not* making this argument myself. Rather, I'd say that if somebody can't figure out the CG -- as long as we make the repositories, branches, and CG as easy to follow as possible -- then they probably would not be a net contributor. But if I'm going to feel good about rejecting (apparently) sincere offers of help, then I want to be maoing certain that the CG (and git repos, branches, etc) **are** as easy to follow as possible. Yes, quite agree. Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unexpected \unfoldRepeats behavior
On Sat, Jun 6, 2009 at 3:22 AM, Mark Poleskymarkpole...@yahoo.com wrote:
I tried to answer a question on -user but hit a brick wall.
\unfoldRepeats failed to work when the music block was funneled from 2
separate expressions. Can someone explain this to me? Why does the
following code work for voiceA but not for voiceB?
Thanks.
- Mark
_
\version 2.13.1
voiceA = \new Voice = A \relative {
\time 1/4
\repeat volta 2 { a' }
\alternative { { b } { c } }
}
% voiceB is built from 2 separate expressions funneled into one voice,
% but otherwise ought to be identical to voiceA, it seems:
voiceBrepeats = {
\time 1/4
\repeat volta 2 { s }
\alternative { { s } { s } }
}
voiceBnotes = \relative { \time 1/4 a' b c }
voiceB = \new Voice = B { \voiceBrepeats \voiceBnotes }
% using \unfoldRepeats produces the expected MIDI output with voiceA,
% but not with voiceB. Why?
\score {
\unfoldRepeats \voiceA % change to \voiceB to test.
\midi { }
}
This is the expected behavior. Only the spacers will be unfolded in
voiceB. The repeat needs to be around the actual notes. Use
\displayMusic and you'll see why.
If you really do want this to work you're going to need some sort of
flatten function: '\flatten \voiceBrepeats \voiceBnotes ' which
would recursively combine the contents of nested parallel sections
into one SequentialMusic section. This would be tricky. It's easiest
to just put the repeats in all voices.
--Jay
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
Bertalan Fodor (LilyPondTool) wrote: - does anybody feel like making cygwin packages for the missing software? Well, for some time I used to be the cygwin maintainer of lilypond. Was quite nightmare. - does anybody have VMware (commercial version) and feel like making a small Linux installation which has all the required software? Potential contributors would be able to run this in the free VMware version. Why VMware? There are free alternatives, like MS Virtual PC, Sun VirtualBox. There have been free versions of VMWare for some time now. www.*vmware*.com/products/server/ Paul Scott ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
Graham Percival wrote Saturday, June 06, 2009 11:18 AM On Sat, Jun 06, 2009 at 11:03:58AM +0100, Trevor Daniels wrote: Graham Percival wrote Friday, June 05, 2009 11:19 AM There's a surprising amount of interest in contributing to LilyPond from Windows machines. (err, I mean, from people *with* Windows machines, not from the actual machines themselves) As I understand it, people with Windows can: - run GUB I haven't tried - I didn't realise this was possible. Has anyone done it? Err... by run GUB, I mean generate sheet music using the downloaded .exe. Aah, right. You mean run the generated binary, not run the builder. I thought I must have misunderstood something. Even if somebody can't do anything else, with this they can still contribute a great deal -- creating examples, sorting/extending LSR stuff, etc. Indeed. Frankly, in some ways I wish that we had *more* contributors who could only run GUB. There's a lot of tasks that I consider too simple for the git-savvy people to do, so as a result they tend to remain undone. :| - compile the docs without examples by running texi2html manually Tick, but this is often screwed up if the version number in snippets is bumped by an LSR update, since this means they can no longer be compiled with the latest released version. - compile the docs with GUB Must try this ... Err, if the version number in snippet matters, then you *have* been compiling with GUB. In the compile docs without examples, I meant something like Yes, now I understand what you mean by GUB. The problem is that a too-high version number gives only a warning in LilyPond, but causes lilypond-book to terminate. There are ways round it, but they can be very messy. That's one of the reasons I've done virtually nothing on the docs for some months, as I have been unable to compile them to check my work. Now 2.13.1-2 has been released I can probably get back to knocking off some of the outstanding doc TODOs. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
On Sat, Jun 06, 2009 at 03:09:48PM +0200, Jan Nieuwenhuizen wrote: Op zaterdag 06-06-2009 om 05:08 uur [tijdzone -0700], schreef Graham Percival: The actual experiments would be done on a separate branch -- but only the initial experiments. Basically, I want to: - merge web/ and master/ - copy the new master/ into gop/ Do I understand these steps to be something like [the just tested over here] git checkout -b web-gop origin/web mkdir -p Documentation/web mv .gitignore * Documentation/web/ git add . # watch out for any crufty in . moved to web/ :-) git add -u . git commit -m 'Prepare web for merge, move into Documentation/web.' git checkout -b gop origin/master git merge web-gop Yes. (other than web-gop being out of date; I'll deal with this soon) There's one thing that still bothers me about this, we'd need to declare Documentation/web 'dead' for branches other than master, eg, stable/2.12, whereas the rest of Documentation/ would not be dead in stable/2.12. Would this be a problem? What do you mean by dead? If you mean not being updated, then stable/2.12 isn't being updated anyway. Eventually, I'd like to have docs/ docs/web/ docs/learning/ docs/reference/ docs/devel/ docs/snippets/ docs/examples/ (maybe) with the approporiate translation files in each subdir. Then input/regressions/ turns into regressions/ or maybe regtests/, and everything else in input/ is put into docs/. That way, we can tell doc people that everything is in docs/. John, if you're reading this: don't worry, I'm going to do all the build system modifications myself. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
Graham Percival wrote: On Sat, Jun 06, 2009 at 01:34:42PM +0200, Jan Nieuwenhuizen wrote: Op zaterdag 06-06-2009 om 03:14 uur [tijdzone -0700], schreef Graham Percival: What is it that bothers you tracking an additional repo? To be up-to-date, I need to do a git pull origin You should only need git pull -r please *do* use -r, otherwise our repo is full of silly Merged brange foo from .. *sigh* Ah, is this why a git status report tells me I'm like 78 commits ahead of master? I just tried git pull -r and it worked well although something in Documentation/po/es.po caused a merge conflict. Perfect example: Jonathan. He's currently the main small doc fix guy, but he doesn't have newweb/ and never has, so any fixes to the website waits for other people to do. Okay, I see. Well, we agree that the current setup is really bad. I suppose Jonathan could be taught how to handle a separate lilypond-web repo? I wasn't really paying much attention to this thread but then I saw my name. :) If you need small fixes to the web stuff I could probably handle that. I actually had the web code at one point but then I reinstalled my OS and haven't pulled it again. Hard drive space is not at a premium so I don't mind pulling more code if it would help the cause. I don't have great html skills but I know enough to go in and fix typos, broken links, and the like. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update policies, and WTM is input/new/revised/ ?
On Fri, Jun 5, 2009 at 6:12 AM, Graham Percival gra...@percival-music.cawrote:
On Thu, Jun 04, 2009 at 07:46:10PM -0500, Jonathan Kulp wrote:
I read the diff for CG when it came in this morning and the LSR stuff
looks good to me. If you want, we could also include the script I wrote
for checking all the snippets at once. Carl suggested that it go in the
docs somewhere.
Yes, please. In that new subsection would be great.
Graham, here's a patch with the script for running and checking all of the
lsr snippets. Also fixed a typo (Uptating Updating). BTW there are a bunch
of warnings when I run make doc:
** `Fixing snippets in LilyPond sources' is up for `Updating LSR to a new
version', but has no menu entry for this node
WARNING: Node 'Compiling from source' was NOT found in the map
WARNING: Node 'Downloading source code' was NOT found in the map
WARNING: Node 'Requirements' was NOT found in the map
WARNING: Node 'Requirements' was NOT found in the map
WARNING: Node 'Requirements' was NOT found in the map
WARNING: Node 'Requirements' was NOT found in the map
WARNING: Node 'Building LilyPond' was NOT found in the map
WARNING: Node 'Building LilyPond' was NOT found in the map
WARNING: Node 'Building LilyPond' was NOT found in the map
WARNING: Node 'Building LilyPond' was NOT found in the map
WARNING: Node 'Building LilyPond' was NOT found in the map
WARNING: Node 'Building documentation' was NOT found in the map
WARNING: Node 'Commands for building documentation' was NOT found in the map
WARNING: Node 'Building documentation without compiling LilyPond' was NOT
found in the map
WARNING: Node 'Testing LilyPond' was NOT found in the map
WARNING: Node 'Problems' was NOT found in the map
WARNING: Node 'Problems' was NOT found in the map
WARNING: Node 'Problems' was NOT found in the map
WARNING: Node 'Problems' was NOT found in the map
WARNING: Node 'Problems' was NOT found in the map
cp /home/jon/lilypond/Documentation/lilypond*.css out-www/contrib-guide/
texi2html -I /home/jon/lilypond/Documentation/user
--I=/home/jon/lilypond/out/xref-maps --I=. --I=./out-www -D bigpage
--output=out-www/contrib-guide-big-page.html
--init-file=/home/jon/lilypond/lilypond-texi2html.init
out-www/contrib-guide.texi
** `Fixing snippets in LilyPond sources' is up for `Updating LSR to a new
version', but has no menu entry for this node
The pdf output seems to be o.k. but the warnings aren't normal.
Jon
--
Jonathan Kulp
http://www.jonathankulp.com
From 506869c397825df0f2a6a16df6135b01d7f250e9 Mon Sep 17 00:00:00 2001
From: Jonathan Kulp j...@bashtop.(none)
Date: Sat, 6 Jun 2009 14:49:24 -0500
Subject: [PATCH] CG: add script for testing LSR snippets
---
Documentation/devel/lsr-work.itexi | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/devel/lsr-work.itexi b/Documentation/devel/lsr-work.itexi
index 033cc98..083ee64 100644
--- a/Documentation/devel/lsr-work.itexi
+++ b/Documentation/devel/lsr-work.itexi
@@ -200,7 +200,7 @@ In any case, commit all changes to Git.
@node Updating LSR to a new version
-...@subsection Uptating LSR to a new version
+...@subsection Updating LSR to a new version
To update LSR,
@@ -208,7 +208,8 @@ To update LSR,
@item
Download the latest snippet tarball, extract it, and run
-convert-ly on all files.
+convert-ly on all files. To ease the process, you may use the
+shell script that appears after this list.
@item
Copy relevant snippets (i.e. snippets whose version is equal to or
@@ -239,3 +240,28 @@ included, then delete those snippets from @file{input/new/}.
@end enumerate
+Here is a shell script to run all @code{.ly} files in a directory
+and redirect terminal output to text files, which are then
+searched for the word failed to see which snippets do not compile.
+
+...@example
+#!/bin/bash
+
+# Mac or Linux?
+OS=$(uname)
+
+# set Lilypond PATH if OS is Darwin
+if [ $OS == Darwin ] ; then
+ export PATH=$PATH:/Applications/LilyPond.app/Contents/Resources/bin/
+fi
+
+for LILYFILE in *.ly
+do
+ STEM=$(basename $LILYFILE .ly)
+ echo running $LILYFILE...
+ lilypond --format=png $LILYFILE $STEM.txt
+ rm $STEM.ps
+done
+
+grep failed *.txt
+...@end example
--
1.6.0.4
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Numbered musical notation (Jianpu)
Continuing the thread from November 2007:
(see http://www.mail-archive.com/lilypond-u...@gnu.org/msg32740.html )
Here is a Python hack that can add numbered notation (Chinese jianpu) to a line
of music. The numbered notation is added as ^\markup commands that include
appropriate EPS files. These EPS files are generated using pslatex (you need
the PostScript fonts for LaTeX, although you could substitute Computer Modern
fonts by replacing pslatex with latex but then the jianpu numbers will not match
Lilypond's other text). The music parser is extremely basic, so don't try it on
anything too complicated. Octaves must be absolute, and must be in the range c'
to b'''. However it is OK not to specify length on every note. Numbering with
1=C is assumed (although the script can easily be adapted to other numberings).
The script works well for me in Lilypond 2.10.33. However it does not work so
well in 2.12.2 because the ^\markup commands are re-positioned so much (which is
a good attempt to avoid collisions, but it often results in the jianpu numbers
being printed at different heights just because they are a little close to each
other). Does anybody know how to do it better in 2.12.2?
def makeEPS(epsFile,texString):
try: return open(epsFile) # does it exist already?
except: pass
texFile=epsFile[:-3]+tex
dviFile=epsFile[:-3]+dvi
psFile=epsFile[:-3]+ps
open(texFile,w).write(r\documentclass{article}
% we must put our title at the bottom left of
% the paper. (BoundingBox can correct for
% positioning elsewhere, but Lilypond doesn't
% seem to take the left and bottom parts of the
% boundingbox into account when doing its spacing.)
\usepackage[a4paper,lmargin=0mm,rmargin=0mm,tmargin=0mm,bmargin=0mm]{geometry}
\usepackage{color}
% \def\dash{--} % this is a bit too long
\def\dash{\footnotesize --}
\begin{document}
\pagestyle{empty}
~ \vfill \par \noindent
\textcolor{white}{\rule{0.1pt}{0.8em}} % so -E'd eps is at least that high
+texString+r\end{document}+\n)
r=os.system(pslatex +texFile+ dvips -E +dviFile+' mv '+psFile+'
'+epsFile)
assert not r, Something went wrong with TeX
import os,string,re
# ensure all notes above c' have lengths, plus rests
# (but try not to add lengths in wrong places - this is very basic)
def addLengths(dat):
ret=[] ; i=0
while ilen(dat):
ret.append(dat[i]) ; i += 1
if ord('a')=ord(dat[i-1])=ord('g') and dat[i]==':
while dat[i]==':
ret.append(dat[i]) ; i += 1
if dat[i] in string.digits:
currentLength =
j = i
while dat[j] in string.digits or dat[j]==.:
currentLength += dat[j]
j += 1
else: ret.append(currentLength)
elif dat[i-1] in rR and not dat[i-2].strip() and ((dat[i] in
string.digits and dat[i+1] in . ) or not dat[i].strip()):
if dat[i] in string.digits:
currentLength =
j = i
while dat[j] in string.digits or dat[j]==.:
currentLength += dat[j]
j += 1
else: ret.append(currentLength)
return ''.join(ret)
def addJianpu(musicWithLengths):
for duration in [8,4,2,1]:
if duration in [2,4]: toDot=[0,1]
else: toDot=[0]
for dots in toDot:
for octave in range(4):
for letter,number in zip(r c d e f g a b.split(),range(8)):
if number and not octave: continue # don't do octave 0
if octave and not number: continue # except for rests
if duration==1 and not number: continue # don't do r1's
sub = letter+('*octave)+str(duration)+(.*dots)
r = str(number)
if number:
if octave==2: r=r\.+r # dot above
elif octave==3: r=r'\'+r # 2 dots above
elif octave==0: r=r'\d'+r # dot below
if duration==8: r=r\underbar{+r+}
elif duration==4 and dots: r += .
elif duration==2:
if number: dash = \dash{}
else: dash = 0
r += dash
if dots: r += dash
elif duration==1:
if number: r += \dash{} \dash{} \dash{}
else: r += 0 0 0
epsFname=j+str(number)+str(duration)+(d*dots)+str(octave)+.eps
tieEpsFname=jT+str(duration)+(d*dots)+str(octave)+.eps
makeEPS(epsFname,r)
makeEPS(tieEpsFname,\dash{} + .join(r.split()[1:]))
for charAfter in [ ,\t,},%,\n]:
musicWithLengths = musicWithLengths.replace(sub+charAfter,
sub+r ^\markup{ \epsfile #Y #2.5
#+''+epsFname+'}'+charAfter)
musicWithLengths = re.sub(r(~[^']*''*[1-8]*\.*) ..markup. .epsfile
#Y #2.5 #+''+epsFname+'}',r\1 ^\\markup{ \\epsfile #Y #2.5
#+''+tieEpsFname+'}',musicWithLengths)
return musicWithLengths
while True:
r = raw_input(Enter some music: )
print addJianpu(addLengths(r))
Re: LSR update policies, and WTM is input/new/revised/ ?
On Sat, Jun 06, 2009 at 02:54:46PM -0500, Jonathan Kulp wrote: Graham, here's a patch with the script for running and checking all of the lsr snippets. ok. IMO, osx users should set up a lilypond shell script, as suggested in AU 2.something. Then you wouldn't need that special path-to-binary thing. But adding this as-is certainly can't hurt the next person doing the update, so that's fine. Also fixed a typo (Uptating Updating). BTW there are a bunch of warnings when I run make doc: yeah, caused from that @include compile.texi. I've taken that out; we'll revisit this after 2.14. (when AU dies and compiling will only be in this dir) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
tagging 2.13.1
Does anybody remember which commit was used for 2.13.1? We should tag that. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
On 6/5/09 12:18 PM, Graham Percival gra...@percival-music.ca wrote: Do we need a separate branch (or even repository) for web/ stuff? I propose that we merge this with the main branch. I thought that the previous discussion was actually to separate the web from the source, i.e., more, rather than less, separation. But I'm OK to move in this direction; I'm ambivalent, personally. PRO: + one less branch/repo to track + easier to fix typos in the web pages + we can direct everybody to look at the CG (no more README in the newweb/ branch) + allows better integration with the other docs (this is more a post-GOP feature) CON: - adds 30 megs to the main branch (including the .git dir) - makes translations harder? (maybe? ... I don't know if this is true, but IMO this is the only real reason to avoid doing this) Another con might be that those who might be willing to work on the web but who don't have a git repo of the source would need a much bigger git repo (i.e. all of LilyPond, instead of just the web). If we agree with this proposal, then we'll be left with: lilypond repo . master branch . individual testing branches Do we need all of the individual testing branches? I'm fairly certain that the csorensen branch is useless. I think the original idea behind the csorensen branch was that I would make changes and push them to that branch, then somebody else would cherry-pick the changes. I think that that model for fixing things has been replaced. We now have the git-cl means of having patches reviewed and then pushed; perhaps we don't need the individual branches? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tagging 2.13.1
Does anybody remember which commit was used for 2.13.1? We should tag that. Isn't it this one? http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=e49c69e6d1e507f60348fa168332175ec6d42b0a ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR update policies, and WTM is input/new/revised/ ?
Graham Percival wrote: On Sat, Jun 06, 2009 at 02:54:46PM -0500, Jonathan Kulp wrote: Graham, here's a patch with the script for running and checking all of the lsr snippets. ok. IMO, osx users should set up a lilypond shell script, as suggested in AU 2.something. Then you wouldn't need that special path-to-binary thing. But adding this as-is certainly can't hurt the next person doing the update, so that's fine. Yeah, I almost took the OSX PATH out. I used to put it in all of my lily shell scripts before I figured out that it's better to set things up as described in AU. Since you lean that direction I wouldn't mind removing it. Do you want me to make a patch or would you rather do it yourself? Also fixed a typo (Uptating Updating). BTW there are a bunch of warnings when I run make doc: yeah, caused from that @include compile.texi. I've taken that out; we'll revisit this after 2.14. (when AU dies and compiling will only be in this dir) OK. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB failing tests
I've done
make -f lilypond.make bootstrap
without problems, and
make lilypond
builds all the arches. The test output tarball is created, but it
fails the rsync test (?)
- (output from make lilypond)
make[3]: Entering directory `/home/lilypond/gub'
PYTHONPATH=/home/lilypond/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/python/out
\
python test-lily/rsync-test.py \
--version-file=/home/lilypond/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/out/VERSION
\
--output-distance=/home/lilypond/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/scripts/build/output-distance.py
\
--test-dir=uploads/webtest
uploads/lilypond-2.13.2-HEAD.test-output.tar.bz2
Traceback (most recent call last):
File test-lily/rsync-test.py, line 199, in module
main ()
File test-lily/rsync-test.py, line 193, in main
compare_test_info (options)
File test-lily/rsync-test.py, line 154, in compare_test_info
assert 0
AssertionError
make[3]: *** [unlocked-test-export] Error 1
make[3]: Leaving directory `/home/lilypond/gub'
-
The relevant lines of python are:
-
def compare_test_info (options):
...
for f in outputs:
m = re.search ('lilypond-([.0-9]+)-([0-9]+).test-output.tar.bz2', f)
if not m:
printf (f)
assert 0
-
which makes sense, since there aren't any previous test outputs on
the system. However, I can't see any special mention of this in
the README, or in make help. What should I do?
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
Hi guys, Graham Percival a écrit : Eventually, I'd like to have docs/ docs/web/ docs/learning/ docs/reference/ docs/devel/ docs/snippets/ docs/examples/ (maybe) with the approporiate translation files in each subdir. John, if you're reading this: don't worry, I'm going to do all the build system modifications myself. :) If you want to see the plan you described done before August, then it's a very good idea :-) ; fortunately, the involved changes in makefiles should not be too tricky... except for modifying dist target: it is problematic to release Lily sources with the website, so docs/web/ should be excluded from this target. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
Francisco Vila a écrit : 2009/6/6 Graham Percival gra...@percival-music.ca: Err... by run GUB, I mean generate sheet music using the downloaded .exe. GUB is the builder, and it builds the released binaries. You run the builder or the released binary. I propose to call things by their names. Agreed. We should call binaries by Lily dev team GUB binaries or whatever you like that sounds correct, but not just GUB, which is the building framework. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] should it be @code{\\addInstrumentDefinition} ?
In a patch I submitted some days ago...
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blobdiff;f=ly/music-functions-init.ly;h=1910975f7fdc81ff7e3632d766f396a631f62f06;hp=2dded22e3d77acd2b2dbcab500d6a01a5f893be9;hb=269248a11ada074066deb061d64df70ee7b4deec;hpb=53c3276a6d56cf8866f7f813d8b53f639bd6b073
I made this change in music-functions-init.ly:
-...@var{\addinstrumentdefinition}.)
+...@code{\addinstrumentdefinition}.)
Though the lilypond.org docs haven't been updated since, I see
now that the change has made it to Reinhold's docs:
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Overview-of-available-music-functions.html#index-instrumentSwitch-2
However, the \a is still showing up as a control character 0x07,
which I'm assuming means alarm? It's listed as bell here:
http://www.fileformat.info/info/unicode/char/0007/index.htm
The html source also reads (with character 0x07 after code):
codeddInstrumentDefinition/code
So, I'm sorry for the misstep, but I don't see why this happens.
By comparison, I grepped for @code{\a and found this example in
user/vocal.itely, line 168:
by the keyword @code{\lyricmode}, or by using @code{\addlyrics} or
which looks fine in the docs:
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Entering-lyrics.html#Lyrics-explained
Can someone explain why it works in one file but not in the other?
I can patch a fix, but I'm not sure the right way to do it. I'm
guessing it's as simple as this:
-...@code{\addinstrumentdefinition}.)
-...@code{\\addinstrumentdefinition}.)
And if it is, here's the patch.
Thanks.
- Mark
0001-code-addInstrumentDefinition-code-addInstrumentDefin.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unexpected \unfoldRepeats behavior
Jay Anderson wrote:
On Sat, Jun 6, 2009 at 3:22 AM, Mark Poleskymarkpole...@yahoo.com wrote:
I tried to answer a question on -user but hit a brick wall.
\unfoldRepeats failed to work when the music block was funneled from 2
separate expressions. Can someone explain this to me? Why does the
following code work for voiceA but not for voiceB?
Thanks.
- Mark
_
\version 2.13.1
voiceA = \new Voice = A \relative {
\time 1/4
\repeat volta 2 { a' }
\alternative { { b } { c } }
}
% voiceB is built from 2 separate expressions funneled into one voice,
% but otherwise ought to be identical to voiceA, it seems:
voiceBrepeats = {
\time 1/4
\repeat volta 2 { s }
\alternative { { s } { s } }
}
voiceBnotes = \relative { \time 1/4 a' b c }
voiceB = \new Voice = B { \voiceBrepeats \voiceBnotes }
% using \unfoldRepeats produces the expected MIDI output with voiceA,
% but not with voiceB. Why?
\score {
\unfoldRepeats \voiceA % change to \voiceB to test.
\midi { }
}
This is the expected behavior. Only the spacers will be unfolded in
voiceB. The repeat needs to be around the actual notes. Use
\displayMusic and you'll see why.
If you really do want this to work you're going to need some sort of
flatten function: '\flatten \voiceBrepeats \voiceBnotes ' which
would recursively combine the contents of nested parallel sections
into one SequentialMusic section. This would be tricky. It's easiest
to just put the repeats in all voices.
Which is kind of ridiculous if you're writing an ensemble piece with
many (even more than one) voices/parts. How can a midi of a multi-voice
work with any repeats be done?
I don't mind having a separate file for the midi output but not being
able to factor out the common timing and dynamics costs a lot of input
time and makes it a lot harder to make sure I haven't dropped a bar
somewhere.
Paul Scott
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tagging 2.13.1
On Sat, Jun 6, 2009 at 3:47 PM, Mark Poleskymarkpole...@yahoo.com wrote: Does anybody remember which commit was used for 2.13.1? We should tag that. Isn't it this one? http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=e49c69e6d1e507f60348fa168332175ec6d42b0a That is the commit that bumped the VERSION file. Graham wants to know which commit 2.13.1 is based on. For example, 2.13.0 was based on this commit: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=37a38d4a18943041e4d3623fb3996279f40df290 -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
On Sun, Jun 07, 2009 at 01:23:22AM +0200, John Mandereau wrote: Francisco Vila a écrit : 2009/6/6 Graham Percival gra...@percival-music.ca: Err... by run GUB, I mean generate sheet music using the downloaded .exe. GUB is the builder, and it builds the released binaries. You run the builder or the released binary. I propose to call things by their names. Agreed. We should call binaries by Lily dev team GUB binaries or whatever you like that sounds correct, but not just GUB, which is the building framework. Err... GUB stands for Grand Unified Binary. It was a play on the GUT (Grand Unified Theory) of physics. http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=GUBsubmit=Search!idxname=lilypond-develmax=10result=normalsort=date%3Aearly Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mergin web/ with master/
On Sun, Jun 07, 2009 at 01:18:41AM +0200, John Mandereau wrote: fortunately, the involved changes in makefiles should not be too tricky... except for modifying dist target: it is problematic to release Lily sources with the website, so docs/web/ should be excluded from this target. What's the problem with distributing the website source? I can't imagine this being technically challenging, and I don't think there's any security issues...? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] should it be @code{\\addInstrumentDefinition} ?
On Sat, Jun 06, 2009 at 04:41:21PM -0700, Mark Polesky wrote:
So, I'm sorry for the misstep, but I don't see why this happens.
By comparison, I grepped for @code{\a and found this example in
user/vocal.itely, line 168:
Can someone explain why it works in one file but not in the other?
Scheme docstring vs. non-macro in .itely files. I don't know
exactly how the scheme stuff is treated, but you need the extra
backslash.
grep 'code{\\' scm/*
-...@code{\addinstrumentdefinition}.)
-...@code{\\addinstrumentdefinition}.)
That's it. (with a + for the second line)
And if it is, here's the patch.
Thanks, applied.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: unexpected \unfoldRepeats behavior
On Sat, Jun 6, 2009 at 4:53 PM, Paul Scottpsl...@ultrasw.com wrote: Which is kind of ridiculous if you're writing an ensemble piece with many (even more than one) voices/parts. How can a midi of a multi-voice work with any repeats be done? I was working on a large score and originally kept the repeat structure separate from the individual parts and ran into the same unfold-not-working problem. I thought about this a bit and decided it was best just to have the repeats in each part. If you're going to make a change to the repeat structure you're almost always going to have to change each part/voice to match. Since this is the case it makes sense to have the repeat structure in each part. If for nothing else it makes it easy to find the beginnings and ends of repeats in each part. I don't mind having a separate file for the midi output but not being able to factor out the common timing and dynamics costs a lot of input time and makes it a lot harder to make sure I haven't dropped a bar somewhere. Actually I found that having the repeats in each part made it easier to notice that bars were off. Lilypond throws errors where it thinks the repeat timing problem is without having to look too much at the pdf output. -Jay ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] should it be @code{\\addInstrumentDefinition} ?
I made this change in music-functions-init.ly:
-...@var{\addinstrumentdefinition}.)
+...@code{\addinstrumentdefinition}.)
However, the \a is still showing up as a control character 0x07,
[...]
Can someone explain why it works in one file but not in the other?
Documentation in .ly files are handled by lilypond itself, this is,
the `lilypond' binary is called to produce files included by the
texinfo system. And `lilypond' needs two backslashes which are then
reduced to a single one. The same is true for Scheme files.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Numbered musical notation (Jianpu)
On Sat, Jun 6, 2009 at 1:59 PM, Silas Brownss...@cam.ac.uk wrote: Continuing the thread from November 2007: (see http://www.mail-archive.com/lilypond-u...@gnu.org/msg32740.html ) Here is a Python hack that can add numbered notation (Chinese jianpu) to a line of music. The numbered notation is added as ^\markup commands that include appropriate EPS files. These EPS files are generated using pslatex (you need the PostScript fonts for LaTeX, although you could substitute Computer Modern fonts by replacing pslatex with latex but then the jianpu numbers will not match Lilypond's other text). The music parser is extremely basic, so don't try it on anything too complicated. Octaves must be absolute, and must be in the range c' to b'''. However it is OK not to specify length on every note. Numbering with 1=C is assumed (although the script can easily be adapted to other numberings). The script works well for me in Lilypond 2.10.33. However it does not work so well in 2.12.2 because the ^\markup commands are re-positioned so much (which is a good attempt to avoid collisions, but it often results in the jianpu numbers being printed at different heights just because they are a little close to each other). Does anybody know how to do it better in 2.12.2? Have you tried \textLengthOn? See Notation Reference 1.8.1 Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tagging 2.13.1
Patrick McCarty wrote:
That is the commit that bumped the VERSION file.
Graham wants to know which commit 2.13.1 is based on.
For example, 2.13.0 was based on this commit:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=37a38d4a18943041e4d3623fb3996279f40df290
Ah, I see. Well, in that case I'm pretty sure I've
narrowed it down to these two:
Reinhold Kainhofer
Better detection which characters need to be quoted...
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=0ac32e91fab38b860ad951b8f0cd4700f79ba86a
Mark Polesky
Change wording of paper-column-interface docstring.
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=53c3276a6d56cf8866f7f813d8b53f639bd6b073
I've deduced this because the changes listed in Reinhold's
Better detection... patch show up in my 2.13.1 release,
and the changes listed in the next patch in the series, my
Typo: @var{} - @code{}. patch, do *not* appear in my
2.13.1 release. Ironically, since the Change wording...
patch only affected a C++ file, I can't tell if that made
it to 2.13.1 just by looking at the release, because the
lily folder doesn't come with the download.
If it's any help, I have an e-mail dated Monday, May 25,
2009 1:02:39 PM (GMT)from Carl Sorensen saying that he
appliedthe patch named Change wording...
Hope this helps.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
On Sat, Jun 6, 2009 at 7:06 PM, Graham Percivalgra...@percival-music.ca wrote: On Sun, Jun 07, 2009 at 01:23:22AM +0200, John Mandereau wrote: Francisco Vila a écrit : 2009/6/6 Graham Percival gra...@percival-music.ca: Err... by run GUB, I mean generate sheet music using the downloaded .exe. GUB is the builder, and it builds the released binaries. You run the builder or the released binary. I propose to call things by their names. Agreed. We should call binaries by Lily dev team GUB binaries or whatever you like that sounds correct, but not just GUB, which is the building framework. Err... GUB stands for Grand Unified Binary. It was a play on the GUT (Grand Unified Theory) of physics. http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=GUBsubmit=Search!idxname=lilypond-develmax=10result=normalsort=date%3Aearly Interesting. So did the name evolve over time? Now it appears to be called the Grand Unified Builder: http://lilypond.org/gub/ -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
2009/6/7 Graham Percival gra...@percival-music.ca: Err... GUB stands for Grand Unified Binary. It was a play on the GUT (Grand Unified Theory) of physics. http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=GUBsubmit=Search!idxname=lilypond-develmax=10result=normalsort=date%3Aearly Cheers, - Graham I hate to be annoying again, but http://lilypond.org/gub/ whete BTW it also says bin/gub - the Gub Universal Builder but also GUB starts as an effort to unify the Windows and MacOS builders... -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development on windows
2009/6/7 Patrick McCarty pnor...@gmail.com: Interesting. So did the name evolve over time? Now it appears to be called the Grand Unified Builder: http://lilypond.org/gub/ -Patrick see also http://github.com/janneke/gub or http://lilypond.org/~janneke/vc/gub.git/ -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
