Re: Possible bug with system-count
Joe Neeman joenee...@gmail.com writes: On Tue, 2009-07-21 at 10:08 +1000, Cameron Horsburgh wrote: Hi Joe, You may already be aware of this issue, but I'll report it anyway. I'm currently typesetting a piece that should comfortably fit two systems to a page. For consistency's sake I've added system-count = 2 in the \layout block. Perhaps you intended to use systems-per-page instead of system-count? Hmm... I think I must have. I could swear I've (successfully) used system-count for this in the past, but the docs are pretty clear on what it means. Now I have to go through my old scores and see where (and if) I've used it in the past. Still, it occurs to me as odd that I get (+ 1 system-count) systems---I would have expected to get system-count systems, with the last system overflowing. Oh, and an important piece of information I apparently left off the original report---I'm using dev/jneeman , not master. Thanks for your time---sorry about the noise. -- Cameron Horsburgh Blog: http://spiritcry.wordpress.com/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths
Hello, I've uploaded a new patchset related to the SVG backend: http://codereview.appspot.com/96083/show The several examples I am using as test cases can be found on this page: http://uoregon.edu/~pmccarty/svg/ They reflect the output created with the above patchset. *** Right now, only the Emmentaler and Aybabtu fonts are supported. All other fonts are processed as plain text with text elements, so their rendering depends on the fonts you have installed on your system. Please review and comment. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB3: Infinite loop in patch stage for linux-x86::linux-headers
On ma, 2009-07-20 at 15:38 -0700, Patrick McCarty wrote: On Mon, Jul 20, 2009 at 01:41:18PM -0700, Patrick McCarty wrote: On Mon, Jul 20, 2009 at 03:09:19PM +0200, Jan Nieuwenhuizen wrote: On vr, 2009-07-17 at 21:50 -0700, Patrick McCarty wrote: cd /home/pnorcks/git/gub/target/linux-x86/src/linux-headers-2.4.34 yes yes | make ARCH=i386 oldconfig CONFIG_SHELL='/bin/bash -x' However, I believe I've come across a bug in Bash 4.0-024. As a followup, this is a situation where Bash 4.0 is more POSIX-compliant than Bash 3.2. See the bug report I posted, and the followup: http://bugs.archlinux.org/task/15606 The attached patch fixes the problem. Applied. Thanks! 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: Converting texinfo comments to HTML comments
On ma, 2009-07-20 at 21:04 -0700, Graham Percival wrote:
On Mon, Jul 20, 2009 at 02:38:13PM +0200, Reinhold Kainhofer wrote:
In our lilypond docs, we have several texinfo comments, most notably the
git
revision of the texinfo document
better done as a macro; that way, we can retain our
non-git-revision-number comments as private
It's easily done with:
@macro htmlcomment{TEXT}
@html
Sweet and simple! Just run
pytt '(?ms)\...@ignore(.*?)\...@end ignore(.*?)(\...@include macros.itexi)'
'\...@include macros.itex...@htmlcomment\1\n@end htmlComment\2' $(find . -name
'*texi' -o -name '*tely')
at your convenience.
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: GUB3: recent git changes don't work for me
On ma, 2009-07-20 at 21:24 -0700, Patrick McCarty wrote: Hi Patrick, The recent commit (e0ed3589241383db0b8d77c1c7738ad3432a4fd5) regarding the shallow cloning of non-tracking branches broke GUB on my machine. I'm running Git 1.6.3.3. I simply reverted the commit for now, so that I am able to build the darwin LilyPond installers. Great! You have been a big help, your reports help the denemo guys too (esp. as some of them are also running [into] bleeding-edge [triggered issues] :-) Attached is the relevant portion of build.log. Thanks! Fixed in master. 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: PATCH: Improved tablature support
Carl Sorensen schrieb: Wikipedia (in a poorly-cited article) uses the term ghost note for all instruments (including the string-muted and palm-muted notes). This entry seems to indicate that ghost note is a term widely used with drums. Following up on links to ghost note in the guitar world causes me to believe that ghost notes in guitar are different than ghost notes in wind instruments. So I don't think that ghost note is a good universal term either. After this little search, I'm inclined to lean toward the Virginia Tech answer -- use the false note term, since it's not used anywhere else, and point it to dead notes for guitar and ghost notes for woodwinds. The situation seems to be somewhat complicated. I didn't know the term false notes (yes, I do, but not in this case :-) but ghost notes on guitar are parenthesized notes which are played so that the can hardly be heard. The same goes for drums (I don't play very well, but my teacher once told me that ghost notes on the snare are so silent that the microphones on stage don't even transfer a signal, but you can still feel the ghost notes in the groove). I have no experience in woodwind notation, so I cannot speak for them. It is possible to use dead notes and ghost notes as aliases, but guitarists expect something else in both cases, and drummers will be confused by ghost notes, so perhaps it would be the best to stay with the term dead notes and add a line or two in the Documentation about woodwinds clarifying that dead notes can be used as a synonym for ghost notes. Another (much more complicated solution) would be do define some kind of environments for special instruments. By including guitar.ly, you'll have \deadNotes and stuff, by including woodwinds.ly, you have a command called \ghostNotes which provides the same functionality - and so on. But I don't know if this really makes sense...probably it will be more confusing rather than helping the users. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation and releasing
Hi Jean-Charles, Le lundi 20 juillet 2009 à 22:06 +0200, Jean-Charles Malahieude a écrit : Hi Mr release-master and his fellow workers, Please wait a couple of days before delivering a new release, since I'm almost (99% plus a proof-reading) of a complete reviewing of the French version of the learning manual. I'm currently moving manuals in user/ one directory up for all languages -- what a PITA, I've only done 30% of it ,`:-o,'. The last of us that will push will have to resolve conflicts, i.e. moving the last updated file from the old to the new location. BTW this is one reason for me to put documentation master branch in brain surgery mode in the next days: I want to have fewest conflicts to solve. I'll do my best to push revisions that build, but there will certainly be tons of broken HTML links, and maintenance scripts will be temporarily broken too; please don't release before we have checked there are not too many broken links. An alternative to this is freezing all documentation editing, but I'm not comfortable with this option. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation and releasing
On di, 2009-07-21 at 15:47 +0200, John Mandereau wrote: I'm currently moving manuals in user/ one directory up for all languages -- what a PITA, I've only done 30% of it ,`:-o,'. The last of us that will push will have to resolve conflicts, i.e. moving the last updated file from the old to the new location. What is so difficult here, can't this be scripted? 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: Translation and releasing
Le mardi 21 juillet 2009 à 15:56 +0200, Jan Nieuwenhuizen a écrit : What is so difficult here, can't this be scripted? If you mean solving conflicts caused by moved files, this certainly can. John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
If this were strictly a tablature issue, I'd say keep it at dead notes, since that is the guitar term. but what of citterns, ukes, banjoes and other modern plucked instruments who would (do) use tablature notation? BTW, its been several decades since I was actively consulting tutors on classical guitar (my first serious instrument), but I do not recall any mention of 'dead' notes, tho from my singing experience I am reminded of 'morire', an instruction to bring the sound volume down to nothing (but not suddenly, not quite the same as damping a string). I should think harp would have terminology for playing dampened; maybe even harpsichord/piano pedaling instructions (or organ swell shade instructions) would be relevant. My druthers would be for 'muted' over 'dead' - more professional, and a better cognate. Also, lots more instruments gonna wanna be using modern tablature than just guitar - bass guitar, uke, cittern, bozouki, banjo. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Tue, Jul 21, 2009 at 9:37 AM, dem...@suffolk.lib.ny.us wrote: If this were strictly a tablature issue, I'd say keep it at dead notes, since that is the guitar term. but what of citterns, ukes, banjoes and other modern plucked instruments who would (do) use tablature notation? BTW, its been several decades since I was actively consulting tutors on classical guitar (my first serious instrument), but I do not recall any mention of 'dead' notes, tho from my singing experience I am reminded of In classical guitar parlance, notes that are damped by the right palm as they're being played are usually designated pizzicato, since the resulting sound is similar to that of pizz on bowed string instruments. In the scores I have where this is desired, the composer writes pizz. followed by a spanner like this --| to indicate how long to keep doing it. Maybe in more modern scores it's done by different noteheads, I don't know. If I saw dead notes written, I think I'd know what to do, but I'm leaning toward muted instead. Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Possible bug with system-count
On Tue, 2009-07-21 at 16:43 +1000, Cameron Horsburgh wrote: Joe Neeman joenee...@gmail.com writes: On Tue, 2009-07-21 at 10:08 +1000, Cameron Horsburgh wrote: Hi Joe, You may already be aware of this issue, but I'll report it anyway. I'm currently typesetting a piece that should comfortably fit two systems to a page. For consistency's sake I've added system-count = 2 in the \layout block. Perhaps you intended to use systems-per-page instead of system-count? Hmm... I think I must have. I could swear I've (successfully) used system-count for this in the past, but the docs are pretty clear on what it means. Now I have to go through my old scores and see where (and if) I've used it in the past. Still, it occurs to me as odd that I get (+ 1 system-count) systems---I would have expected to get system-count systems, with the last system overflowing. Good point, that shouldn't be difficult to fix. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Directory structure for docs and web site
Hi guys, I expect comments (and even maybe votes from developers) about the directory structure, which will very soon drive an important part of the docs and web site reorganization (especially the makefiles and buildscripts :-P). I have a naive question with not so naive implications about the current shape of docs reorganization: what is the planned directory structure for the new web site? Do we want to make a clear distinction between the site and the docs in the URL, i.e. do we keep web/ and doc/v2.*/? I'm not comfortable with putting everything at the same level on the web site as a direct upload of the compiled docs would product, assuming we actually merge the web site into docs: lilypond.org web/ -- main web site learning-big-page -- Learning Manual (big page) learning/ -- Learning Manual (splitted) notation-big-page -- Notation Reference (big page) notation/ etc. I can't imagine putting the docs for development branch at toplevel: this would make them default docs, which is not acceptable. If we ever want to have docs at toplevel, it should be docs for stable branch, so the web site should be rather edited on stable/2.x Git branch. That said, if we decide to keep the current directory structure, there must be some HTML links hacking in some Python and/or Texi2html init file. I see two possible plans in this case, which have already been mentioned, but I try to explain more implications, pros and cons below. 1) Keep the full web site away from Lily main source tree, i.e. on web branch. This implies that nothing of the web site requires compilation of ly snippets, e.g. Examples should be reintegrated into Documentation as a Texinfo document. Pros: clear separation of the web site (which is for all Lily versions) and the docs (which is version-specific). Cons: more work to make possible building a site for offline browsing (although this is easily achieved by importing some Python code from master branch), the web site building process must retrieve compiled xref-maps from docs, HTML links hacking in Python scripts or Texi2HTML init file (a bit of a hassle, but I've already done this with Snippets-Documentation/user). 2) Merging the web site into LilyPond sources, with all problems of directory strucutre in mind that wouldn't happen without this merge. Pros: simple cross-references, easier use of ly snippets in the web site. Cons: merging the web site of the branch that actually hosts the web site into the other one, at least every time the latter branch is released (in order to distribute an up-to-date web site), potentially unclear distinction of what is precisely built on lilypond.org, more cluttering of Git history. Note that although this issue is not completely orthogonal to putting all Texinfo manuals in Documentation/, the latter should be done first anyway, because it will simplify cross-referencing inside documentation and between docs and the web site regardless of the web sources location. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Re: New format for autobeaming rules
I'm getting ready to push the new autobeaming code. Are there any more comments before I do so? http://codereview.appspot.com/88155 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Re: New format for autobeaming rules
On Tue, Jul 21, 2009 at 11:03 AM, Carl Sorensenc_soren...@byu.edu wrote: I'm getting ready to push the new autobeaming code. Are there any more comments before I do so? http://codereview.appspot.com/88155 Did you address Neil's last comment on the patchset, from 5 days ago? -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Re: New format for autobeaming rules
On Tue, Jul 21, 2009 at 11:06 AM, Patrick McCartypnor...@gmail.com wrote: On Tue, Jul 21, 2009 at 11:03 AM, Carl Sorensenc_soren...@byu.edu wrote: I'm getting ready to push the new autobeaming code. Are there any more comments before I do so? http://codereview.appspot.com/88155 Did you address Neil's last comment on the patchset, from 5 days ago? Never mind. :-) Sorry for the noise. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
very nice! http://codereview.appspot.com/88155/diff/3092/2039 File ly/music-functions-init.ly (right): http://codereview.appspot.com/88155/diff/3092/2039#newcode699 Line 699: (make-music 'SequentialMusic 'void #t)) I'd feel better if this were finished. At least add FIXME so it can be easily grepped for. http://codereview.appspot.com/88155/diff/3092/2047 File scm/music-functions.scm (right): http://codereview.appspot.com/88155/diff/3092/2047#newcode546 Line 546: (define (make-default-beaming-rule context) this doesn't seem to be used... http://codereview.appspot.com/88155 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
SVG backend: On-the-fly conversion of Emmentaler/Aybabtu glyphs to paths
http://codereview.appspot.com/96083/diff/1/8 File lily/pango-font.cc (right): http://codereview.appspot.com/96083/diff/1/8#newcode351 Line 351: // options. Could you please have a look at this? (after applying this patch, if you prefer). The more special cases we add for different backends, the messier this gets. http://codereview.appspot.com/96083/diff/1/9 File lily/text-interface.cc (right): http://codereview.appspot.com/96083/diff/1/9#newcode80 Line 80: if (ly_symbol2string (encoding) == latin1) isn't there some possibility that we will have an encoding other than latin1, fetaNumber or fetaDynamic? http://codereview.appspot.com/96083/diff/1/12 File scm/output-svg.scm (right): http://codereview.appspot.com/96083/diff/1/12#newcode184 Line 184: (make-regexp (string-append glyph-name=\( I think it would be helpful if you gave an example or 2 of the sort of string you expect to match here. I'm a bit worried also about the fact that you require the attributes to be in a specific order. http://codereview.appspot.com/96083 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Size of test output binaries has doubled
On 7/19/09 3:07 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jul 18, 2009 at 09:14:40PM -0600, Carl Sorensen wrote: In preparing information on regression testing for the Contributors' Guide, I happened to check the downloadable regression test results at http://lilypond.org/download/binaries/test-output/ I noticed that prior to 2.13.2 the test results were approximately 70-80 MB. For 2.13.2 and 2.13.3, the results are approximately 136 MB. Is this an intended (or understood) behavior, or is it a bug of some sort? Well, it happened when I started making releases. We /have/ been adding a lot of regtests recently, but I don't imagine that there were _that_ many between .1 and .2. My initial guesses: - GUB uses the system's convert (imagemagick) or pnmtopng or something like that, and kainhofer has a different version of those files than Han-Wen's system. (and the other version has poorer compresson) - 64-bit CPUs naturally produce larger png files. (hey, I didn't say these were all *good* guess. ;) - Seriously: GUB might be adding extra files to the tarball... maybe a make clean somewhere is failing, resulting in a bunch of intermediate files being included? I'd encourage any interested parties to compare the files in the .1 and later tarballs, and to compare the filesizes. Remote debugging from Vancouver to Germany is a pain, and in any case I'm at a music camp starting in 12 hours, so I won't be looking at this soon. (if it's still a problem in Sep, I should have a desktop computer available, so debugging GUB will be *much* easier) I've compared the difference in the output for .1 and .2. The diff file is available at http://www.et.byu.edu/~sorensen/regtest-diff.txt or http://tinyurl.com/n5zlrr The file names are the same, but some .eps files are more than 10x bigger in .2 than in .1. And I didn't see *any* .png files in the directories -- the only occurrence of png in the directory tree was ps-to-png.scm. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
\set fontSize doesn't effect beams and stems (but noteheads and flags (!) and markups)
Also in a part set to a smaller fontsize
\set fontSize = #-1 {
\mark A
r8^\markup Frage b es8.[ b16] c g8. r4 |
}
\set fontSize = #-4 {
r8^\markup Antwort b b[ b] b16 c8. r4 |
}
\set fontSize = #-1 {
\bar :| \break
}
% (With fontsize -1 in general I want to get a „less black“ paper.)
the beams and stems remain huge while noteheads, flags and markup-texts really
became smaller.
Seems to be a bug (different behavior for hooks and beams!).
greetings
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
feature request (concerning midi-output)
I'd like a feature which allows the following
(and I think, that should be the default):
\score {
\new StaffGroup
\new ChordNames
\Harmonien
\new Staff
{
\clef F
\relative c {
\Zweite
}
}
\layout {
}
\midi {
\context {
\Score
% harmonies = ##f
% (output all voices but no harmonies from chordNames!)
}
}
}
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \set fontSize doesn't effect beams and stems (but noteheads and flags (!) and markups)
Werner wrote: \set fontSize doesn't effect beams and stems It's not supposed to -- beams and stems are not part of any font, they are drawn according to calculations that happen when the program is processing your file. So changing the fontSize doesn't do anything to them. On the other hand, noteheads, flags, and (some) markups are made out of font-glyphs; these are affected by fontSize. In NR 1.7.1 Selecting notation font size, we find this paragraph: The font size of notation elements may be altered. It does not change the size of variable symbols, such as beams or slurs. http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Inside-the-staff#Selecting-notation-font-size Seems to be a bug (different behavior for hooks and beams!). It's not a bug unless it results in a crash or erroneous output. Erroneous output can include output that contradicts what would be expected after having read the documentation. What this means is that sometimes things don't do what you want them to do, but then you read the docs and you find out that they weren't designed to do what you want. Other times (as odd as this may seem), the actual bug is in the *documentation*, so bugs are often fixed by re-wording the incorrect description in the docs. Occasionally you may feel that something *ought* to behave a certain way, even if the docs say that it's not designed to do that. Usually, though, there's another, more appropriate way of doing it, and if you don't like that, you can submit a feature request, or ask on the mailing list for help writing a scheme hack. But in this case, you can either do something like this: \override Beam #'thickness = #(* 0.48 (magstep -4)) \override Stem #'thickness = #(* 1.3 (magstep -4)) Or, you can look into the \cueDuring command, which looks like what you really mean to be doing. http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Writing-parts#Formatting-cue-notes Hope this helps. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
