Re: regressions: song-reordering.ly
Valentin Villenave [EMAIL PROTECTED] writes: 2008/1/7, Han-Wen Nienhuys [EMAIL PROTECTED]: I approved you the day before yesterday. It should work right away. Can you post what is not working? I know you approved me, and I thank you for that; it's just that for some strange reason the ssh access is still denied (I asked Graham and John but I didn't want to bother you with it ;) Here's what I wrote them: OK, I have now been added to git but I can't use it. I registered a public rsa key, a public dsa key, everything I could think of, I have followed very carefully the tutorials, such as http://savannah.gnu.org/maintenance/UsingGit _but_ when I try to push a commit: $ git push ssh+git://[EMAIL PROTECTED]/srv/git/lilypond.git/ Permission denied (publickey). fatal: The remote end hung up unexpectedly error: failed to push to 'ssh+git://[EMAIL PROTECTED]/srv/git/lilypond.git/' What the heck? Try logging in manually first. You may need to approve the host SHA1 once. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: regressions: song-reordering.ly
Valentin Villenave [EMAIL PROTECTED] writes: 2008/1/7, David Kastrup [EMAIL PROTECTED]: Try logging in manually first. You may need to approve the host SHA1 once. Thank you David. I have no idea how to manually log in, and neither do I know how to approve the SHA1 sum (where do I find it? etc). Can you be more specific? I'm a total newbie :) ssh hostname If you are a total newbie, additional possibilities are that you are messing up your private and public keys, or using the wrong files to keep them. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Support accordion with standard bass
flavors: German and American Accordion Association. The main difference is that in the German notation chords are written out, whereas AAA notation is quite closer to numbered bass notation in that a chord is written as its principal base note (discounting inversions!) with possibly a letter above (like an accidental, the letters tend not to get repeated). Letters are M for major (the default, so only needed for dissolving a previously given different letter), m for minor, 7 for seventh and d for diminuished. So the AAA notation is less cluttered (with fewer noteheads), but harder to transfer to other instruments. The principal bass note is put below the middle line from the bass clef (C position and lower), the chords on the middle line and above. This division is hard in order to make the notation unique: when transposing, one needs to wrap around the octaves. Now we come to the really fuzzy notation, the German one. Here the chords are written out in notes, and usually also with chord/bass names below the staff. The principal bass/chord division is the same, and chords are written out in the lowest place where they fit disregarding chord inversions. That is sort of a canonical notation. The fuzz comes into play since writing out the chords makes it possible to play it on other instruments, most notably a free bass accordion. And then chord inversions do matter. Since chords and bass notes are distinguishable by the number of stacked notes, their division tends to be weakened: bass lines will at times not be wrapped around, and chords may reach below the middle line when the equivalent free bass would finger them there. Whether one wants to have bass notes wrap around or chords to change to a different inversion when transposing is certainly user/writer choice. Also the writer needs to have a way to say don't move my bass notes/chords to different places while the default would likely normalize both chords and basses. Now to the Midi output: to make things even more annoying, the bass system has just 12 notes, as told. But where the wraparound in the notation occurs at C, the wraparound in the most common instrument type occurs at E (that is, E is the lowest note, Eb the highest). I think that some instruments might wrap around somewhere else, but... So if we want to cater for life-realistic Midi, we might need to wrap around against some other thresholds with regard to chords/inversions than we do in the notation. I won't vouch for all of the details, but that is the gist. Note that one can produce something like that with lilypond visually, but a) one has to code the chords manually which means that it is not trivial to produce output for, say, accordeon and piano and figured bass from the same input. b) chords and bass notes don't stay in their designated space when transposed. c) when chords are not written out, the midi output will not correspond with the actual sound. Any thoughts how much work would be involved in tackling any of those three problems, and what mechanisms that are already in place could be get used favorably? I would be willing considering to sponsor some development here but one should flesh out what is sensible here in advance, and how much work would need to get put in what area. Thanks, -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ambitus engraver should prefer its key signature
Ping? Anybody out here? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
Werner LEMBERG w...@gnu.org writes: In the incipit to the `Repeats' section, I think it should be 2 | |: 4 | instead of | 2 |: | 4 Later in the chapter there is a snippet which demonstrates this. Not sure. It would appear to me that 2 | :|: 4 | would be wrong, for example. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
Werner LEMBERG w...@gnu.org writes: In the incipit to the `Repeats' section, I think it should be 2 | |: 4 | instead of | 2 |: | 4 Later in the chapter there is a snippet which demonstrates this. Not sure. It would appear to me that 2 | :|: 4 | would be wrong, for example. Here an example from Brahms Gesamtausgabe, Haydn Variations, which demonstrates what I mean. Hm, at the ultimate beginning. Isn't it customary not to set a repeat sign at all in that case? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
Valentin Villenave v.villen...@gmail.com writes: 2009/8/8 Werner LEMBERG w...@gnu.org: Yes. By default, a meter change should be positioned before the repetition sign. This should be added to the bug tracker... Er, I got lost in the discussion. Could you sum up your report (possibly with a picture)? Meter changes should occur before an opening repeat sign. If there is a closing one immediately adjacently, opening and closing one are placed apart, and the meter change in between. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2/4 not before repeat line in incipit to `Repeats'
Hans Aberg hab...@math.su.se writes: On 9 Aug 2009, at 21:07, Bernard Hurley wrote: The default rule is really that one should have a minimum number of time signatures if the repeat construct is expanded*). That seems like a reasonable rule. But a quick look through my pile of full scores (Mostly Dover reprints of 18th and 19th century scores) shows it is not always obeyed. I.e. there are plenty of cases where the a time signature change is placed after the repeat sign even though there is no time change inside the repeat. If one of the alternatives of the repeat end in a meter different from what it begins, then if the expansion rule should prevail, there must be a time signature at the beginning of the repeat after the |:. And it is then unnecessary to have one extra before. But not even that was followed in the Bulgarian score. It looks like: 11/16 |: ... | 8/16 ... | 11/16 ... | 8/16 ... :| As a composer/arranger I always put the time change after the repeat sign! Rather than talk about the right or wrong way of doing this it should just be a user's option. I figure LilyPond might support what people want to typeset. Yes, if I tell it explicitly. Short of that, Lilypond should pick the way that best reflects the art of typesetting, as recognized by the developers. It is ok if there are manual overrides (and style overrides for a whole document), but the defaults should not require music typesetting taste and choices. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New user question - relative bowing and fingering marks
Jan Nieuwenhuizen jann...@gnu.org writes: Op maandag 07-09-2009 om 14:32 uur [tijdzone -0700], schreef John Ervin: This is rather atypical in my experience. Is there a way to have the fingering close to the note and the bowing instruction above that? It looks like you may have found a bug. LilyPond should format stuff correctly, if she produces atypical results we should check our references and teach her, rather than look for tweaks. So...looking for references on this is not so easy. Stone doesn't say anything, Reed doesn't, Ross merely states that probably no two experienced engravers will always [place fingering in the same spot], but notes that when accents are used [] with fingerings, the accents take their normal positions and fingerings are placed either abover or below [] according to the available space. Now...are bowing instructions accents? For the purposes of typesetting, I think they are. Except that in the order of accents, they are usually placed outermost IIRC. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond's error column printer confuses bytes and characters
I'm not top-posting The following input file: bad.ly Description: Binary data leads to the following error output (which hacks an utf-8 character into pieces, replaced by printable octal sequences to make this transfer better via mail): GNU LilyPond 2.13.4 Processing `bad.ly' Parsing... bad.ly:4:16: error: syntax error, unexpected MUSIC_IDENTIFIER Määä A\342\231 \257 B♭ \break error: failed files: bad.ly Apparently, the error column is being tracked by counting characters, but is displayed by counting bytes. The indicator appears too early because of that (which caused me to look for the wrong bug in an input file of mine). -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Lost bug reports?
Hi, neither on gmane nor on mail-archive.org can I find a copy of my report URL:http://lists.gnu.org/archive/html/bug-lilypond/2009-10/msg00049.html. So what happened? Did the recent gmail outage lose reports for good on most channels that people actually use? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Bad dimensions for \bracket
I am not topposting
\version 2.13.6
\layout { ragged-right = ##t }
% \bracket appears to correctly bracket an entire construct, but
% calculate its overall dimension just from its last part
\markup { \bracket \center-column { left x }
\bracket \center-column { right y } }
inline: bug.png
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond's error column printer confuses bytes and characters
I am not topposting I reported this bug once already, but its distribution was haphazard (never got to gmane) and nobody entered it into the bug tracker. The following input file: bin2jX8eDNUTu.bin Description: Binary data leads to the following error output (which hacks an utf-8 character into pieces, replaced by printable octal sequences to make this transfer better via mail): GNU LilyPond 2.13.4 Processing `bad.ly' Parsing... bad.ly:4:16: error: syntax error, unexpected MUSIC_IDENTIFIER MÃÃÃ A\342\231 \257 Bâ \break error: failed files: bad.ly Apparently, the error column is being tracked by counting characters, but is displayed by counting bytes. The indicator appears too early because of that (which caused me to look for the wrong bug in an input file of mine). -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond's error column printer confuses bytes and characters
-Eluze elu...@gmail.com writes:
David Kastrup wrote:
The following input file:
… which is a .bin file and should be a .ly file - but downloaded its content
looks like
\markup{
Määä A♯ B♭ \break
}
now, if i comment the \break (or omit it), the file compiles quite well -
did i miss something?
The subject line and the problem description?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond's error column printer confuses bytes and characters
-Eluze elu...@gmail.com writes: David Kastrup wrote: -Eluze elu...@gmail.com writes: now, if i comment the \break (or omit it), the file compiles quite well - did i miss something? The subject line and the problem description? ahhh! i see now - i thought you were looking for a solution… however, with version 2.13.3 (under windows vista) i get the following error message: Analysieren... bad.ly:4:23: Fehler: syntax error, unexpected MUSIC_IDENTIFIER Määä A♯ B♭ \break which to me looks correct! Yes. Since Analysieren looked German to me, I checked with the German locale de_DE.UTF-8 (had to install language-pack-de for it to work properly, though, since otherwise ä ist not accepted as text). No better luck: same bombout. My normal locale is en_US.UTF-8. It is conceivable that people will see this bug (on POSIXy systems) only when a valid UTF-8 locale is selected. If you don't see it with 2.13.3 under Windows, either the Windows behavior is different, or something went wrong between 2.13.3 and now. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond's error column printer confuses bytes and characters
Patrick McCarty pnor...@gmail.com writes:
On 2009-10-18, David Kastrup wrote:
GNU LilyPond 2.13.4
Processing `bad.ly'
Parsing...
bad.ly:4:16: error: syntax error, unexpected MUSIC_IDENTIFIER
MÃÃÃ A\342\231
\257 Bâ \break
error: failed files: bad.ly
Apparently, the error column is being tracked by counting characters,
but is displayed by counting bytes. The indicator appears too early
because of that (which caused me to look for the wrong bug in an input
file of mine).
This patch seems to correct the issue, but I don't know if it's the
correct fix (or if there are any side effects I'm unaware of).
The code before states:
while (left 0)
{
/*
FIXME, this is apparently locale dependent.
*/
#if HAVE_MBRTOWC
wchar_t multibyte[2];
size_t thislen = mbrtowc (multibyte, line_chars, left, state);
#else
size_t thislen = 1;
#endif /* !HAVE_MBRTOWC */
The question is what we do about locales. I think that in this case
behavior is arguably correct since we are talking about column numbers
on the terminal/locale, and even when Lilypond is using utf-8, those
will correspond with the interpretation of the locale.
Or something.
Anyway, it seems like this change would cause the surrounding function
to behave more consistently. It works in my case.
By the way: when I switch into POSIX locale, the error message will
occur before the first Umlaut which is then no longer considered text
apparently. So we already have some built-in locale dependencies
elsewhere.
My vote is on getting it merged, but it probably would do no harm if
somebody checked this on Windows where the old version purportedly
worked.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond's error column printer confuses bytes and characters
Patrick McCarty pnor...@gmail.com writes:
On 2009-10-18, David Kastrup wrote:
GNU LilyPond 2.13.4
Processing `bad.ly'
Parsing...
bad.ly:4:16: error: syntax error, unexpected MUSIC_IDENTIFIER
MÃÃÃ A\342\231
\257 Bâ \break
error: failed files: bad.ly
Apparently, the error column is being tracked by counting characters,
but is displayed by counting bytes. The indicator appears too early
because of that (which caused me to look for the wrong bug in an input
file of mine).
This patch seems to correct the issue, but I don't know if it's the
correct fix (or if there are any side effects I'm unaware of).
The code before states:
while (left 0)
{
/*
FIXME, this is apparently locale dependent.
*/
#if HAVE_MBRTOWC
wchar_t multibyte[2];
size_t thislen = mbrtowc (multibyte, line_chars, left, state);
#else
size_t thislen = 1;
#endif /* !HAVE_MBRTOWC */
The question is what we do about locales. I think that in this case
behavior is arguably correct since we are talking about column numbers
on the terminal/locale, and even when Lilypond is using utf-8, those
will correspond with the interpretation of the locale.
Or something.
Anyway, it seems like this change would cause the surrounding function
to behave more consistently.
As to consistency: when I switch into POSIX locale, the error message
will occur before the first Umlaut which is then no longer considered
text apparently. So we already have some built-in locale dependencies
elsewhere.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Graham Percival gra...@percival-music.ca writes: On Sun, Oct 25, 2009 at 02:16:27PM +0100, David Kastrup wrote: Valentin Villenave v.villen...@gmail.com writes: 2009/10/24 Frédéric Bron frederic.b...@m4x.org: 1. can somebody feed the bug tracker with this bug? Sorry, I got lost in the discussion. Can you help me updating the bug report? Is it necessary to ask for bug report database updates? I filed several bug reports to this list which as far as I can tell mostly got ignored, to the degree where they did not only not get an answer, but also were not filed into the database. It should not be necessary. The Bug Meister should respond within a week, either asking for more information, or informing you of the issue number. (ideally with a direct link, but a simple thanks, added as 1234 is also ok) Of course, as with everything else in open source projects, the Bug Meister position is a volunteer job, so we take what we can get. If anybody thinks they can do a better job than the current person (including any of my jobs), I would encourage them to offer to take over the work. Or at least to work as an assistant. The documentation states: If you have discovered a bug which is not listed, please help us by sending an input file which demonstrates the problem to the bug-lilypond list. Unfortunately there is a strict “no top-posting” check on gmane; to avoid this, add I'm not top posting. (you must include the ) to the top of your bug report. Please DO NOT add bug reports directly to the bug tracker. Once an issue has been added to the tracker, feel free to add more information to that report. It also gives elaborate details about what constitutes a good bug report. There is no mention about what happens with bugs on the bug report list. A reasonable expectation is that an automatism or moderation stage will pick up a good bug report within a day. A response time of a week is a sign that the mechanism is not working out. Things like weeding out duplicates can happen at a slower time span. It is also possible to put a bug into a database with a state pending, unverified or similar. That gives a better impression than a black hole. For one of the bugs I reported, a patch has been sent to the list already by Patrick McCarty. Neither the bug report nor the patch have seemingly been registered. The patch has not been merged or commented on. The exclusivity of bug tracker access does not apparently make a good match with the current workflow of the development crew. The results are not encouraging to contributors. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Graham Percival gra...@percival-music.ca writes: On Mon, Oct 26, 2009 at 01:43:59PM +0100, David Kastrup wrote: A response time of a week is a sign that the mechanism is not working out. We *don't* have a response time of a week. Currently the only person who has shown the slightest bit of interest doing this job does it an average of once every two weeks. So the mechanism is not working out. Things like weeding out duplicates can happen at a slower time span. It is also possible to put a bug into a database with a state pending, unverified or similar. That gives a better impression than a black hole. I do not agree with making the issue tracker open to everybody. We'll get tons of uninformed users posting non-bugs. So the idea of the current setup is actually to keep the number of users posting bug reports down? Why? If you feel you should be able to ignore bug reports by uninformed users, tell your issue tracker view to omit showing unverified issues. Sure, if everybody does that, the unverified issues will start piling up, but at some point of time somebody who _does_ see the reports _might_ engage in a burst of activity sorting them. The current workflow favors just letting issues get lost on the mailing list. The results are not encouraging to contributors. Maybe you didn't notice the above note. I WOULD ENCOURAGE ANYBODY TO OFFER TO HELP WITH THE WORK. Anybody would be in a better situation to help with the work if it were visible as unverified in the bug tracker, and if it was not reduced to the personal responsibility of a single person to do something. It is easier to get people to do a bit of work when they are in the mood rather than get somebody who volunteers to be _responsible_ until further notice. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: automatic accidental style voice: too many written accidentals
Frédéric Bron frederic.b...@m4x.org writes:
Since the \key command still works at the Staff level (both
technically in LilyPond and musically, since there's no notation
available to specify separate key signatures for separate voices
within a stave), I clearly see it as a bug if the Staff key isn't
seen by each Voice.
What if, at the point a voice is instanciated, we automatically set
its key signature to that of its parent staff context. That would
solve this issue.
In general, that is a mistake: accidentals are typeset per staff. Now
this is about an accidental-style 'voice for which we have
As a result, accidentals from one voice do not get canceled in
other voices, which is often an unwanted result: in the following
example, it is hard to determine whether the second `a' should be
played natural or sharp. The `voice' option should therefore be
used only if the voices are to be read solely by individual
musicians. If the staff is to be used by one musician (e.g., a
conductor or in a piano score) then `modern' or
`modern-cautionary' should be used instead.
Under this premise, I think it makes sense to inherit the key signature.
Now if we have _within_ a voice { xxx } \\ { yyy } , what does this
mean? Since the purpose of voice accidental style is to write stuff
that several different people read, this corresponds to splitting a
tenor voice (for example). This means that the split voices should not
just inherit the key signature, but also already preexisting accidentals
of the father voice since obviously the same persons are singing tenor
1 and tenor 2 that have been singing tenor previously. Also, any
accidental changes within xxx and yyy need to be consolidated into the
following rejoined voice: if there are different accidentals in xxx and
yyy for a note, a recurrence of the note after the split needs a
cautionary accidental.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
Valentin Villenave v.villen...@gmail.com writes: On Sun, Oct 18, 2009 at 2:34 PM, David Kastrup d...@gnu.org wrote: % \bracket appears to correctly bracket an entire construct, but % calculate its overall dimension just from its last part Thanks, but the actual bug doesn't even need to involve brackets: http://code.google.com/p/lilypond/issues/detail?id=882 (not even sure it's a bug, actually) In the case of the brackets, it clearly is. The brackets form a new total object, and the resulting object dimensions do not correspond to what the brackets have encased. This is a discrepancy. Which of the discrepancy parts you call a non-bug is up to you. Bug 882 may or may not be related, and may or may not be a bug, but this discrepancy in the context of brackets _is_ a bug. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
Valentin Villenave v.villen...@gmail.com writes: On Thu, Oct 29, 2009 at 11:08 PM, Neil Puttock n.putt...@gmail.com wrote: This bug looks like #807, which has a patch pending. Indeed. But what about #882 then? Sounds like somebody should apply the patch and reevaluate all related bugs given their sample code. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bad dimensions for \bracket
Graham Percival gra...@percival-music.ca writes: On Fri, Oct 30, 2009 at 11:15:45AM +0100, David Kastrup wrote: Valentin Villenave v.villen...@gmail.com writes: On Thu, Oct 29, 2009 at 11:08 PM, Neil Puttock n.putt...@gmail.com wrote: This bug looks like #807, which has a patch pending. Indeed. But what about #882 then? Sounds like somebody should apply the patch and reevaluate all related bugs given their sample code. I think we could figure that out by ourselves. Unless you're volunteering to do this testing, pointing this out only serves to aggravate developers. Well, the patch does fix the bug I reported (at the posting at the top of the thread). It has no effect on #882 or #732. Hardly surprising since the proposed patch for #807 touches _only_ the bracket code, and #882 and #732 don't involve brackets. Since _all_ of them involve centered columns and their dimensions, I can't rule out that the proposed patch has been made to work just by trial-and-error. BUT the braces before _and_ after patch _properly_ enclose the centered column. So my guess is that brace calculations are _impervious_ to the bug in #882/#732 (since the braces properly enclose their _contents_ in all the tested cases, either before or after the #807 patch), and the patch only affects the _outside_ of the braces, making them apparently occupy the right amount of space. So from my testing the patch is unrelated to #882/#732, and the bug in #882/#732 does not apparently affect the test case for #807 either which way. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Some Cheat cheet nitpicks
Graham Percival gra...@percival-music.ca writes: On Wed, Dec 16, 2009 at 2:02 PM, Werner LEMBERG w...@gnu.org wrote: The best solution is probably to add a new command line option `--default-left-padding' to lilypond-book (which is then used in the Makefile with value 0mm to override the default setting of 3mm), and adding a snippet option `left-padding' to the lilypond environments (within lilypond-book) to override the default left padding if necessary. No. We're not adding that option to 90% of the snippets in the docs. It can't be done automatically, and it's way too much work to do it manually. ??? I've just suggested the `--default-left-padding' option to exactly avoid that! Ideally, we would simply change the default value of lilypond-book's `--left-padding' option to 0mm, but this breaks backwards compatibility. Thus my suggestion to have a means to control the default value instead. If the makefile sets it to 0mm, then what happens for longer examples with bar numbers? Presumably somebody needs to go through all the docs to find multi-line examples, then add [left-padding=3mm] to those examples. This is too much work for not enough payoff. Especially since (I think) a one-line patch to the C file that Sven identified would render this work unnecessary. It is common to have the first line of multiple lines indented and adjusted (they look like paragraphs essentially), but it makes little sense to indent single lines. In particular if you interchange single lines with text, or treat them as inline material. So it might be nice to be able to specify special padding/adjustment for single-line formatting. If there was a way to find out post-fact what kind of formatting was actually employed for any snippet, this might also be nice. But one can probably guess somewhat reliably by checking the width of the result. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Enhancement request: make-markup-command cleanup and docs
The current state of make-markup-command is less than satisfactory since make-markup-command and make-builtin-markup-command have different syntaxes and semantics, making the latter an insider command that complicates the transition from advanced user to Lilypond contributor. There has been work done on unifying the syntax at URL:http://codereview.appspot.com/160048. The last changes of those patch sets have eliminated make-builtin-markup-command completely, and one has been adding a command line option that stops indexing for make-builtin-markup-command (and the respective markup list command) completely. The latter will make only sense if the effect of this option is made to extend to further commands not related to markup. So there remains a technical decision pending about the accepted scope of the proposed changes (from none at all to the last change set). This decision needs to be done by somebody with commit privileges and the required authority. Once this has been done, the changed (or unchanged) state needs further documentation in the CG (the in-code documentation for all variants appears par for the course to me). If the decision is no change at all, the patch set at URL:http://codereview.appspot.com/157133 improves the CG documentation. It also forms an excellent starting point if the decision is to incorporate more of the first-mentioned patch, or otherwise change the commands of make-markup flavor. With the mentioned sources of input, the improvement of the contributor's guide would appear to be a task at frog level once a decision about the scope of code changes has been made. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Enhancement request: make-markup-command cleanup and docs
Valentin Villenave v.villen...@gmail.com writes:
On Sun, Dec 20, 2009 at 11:01 AM, David Kastrup d...@gnu.org wrote:
The current state of make-markup-command is less than satisfactory since
make-markup-command and make-builtin-markup-command have different
syntaxes and semantics, making the latter an insider command that
complicates the transition from advanced user to Lilypond contributor.
Thanks, added as http://code.google.com/p/lilypond/issues/detail?id=941
It appears that Nicolas dived in and did all of the listed job. As a
somewhat related cleanup, independent documentation has become simpler.
After checking for disappearance of the described features in the code
with grep, I came up with the following cleanup. If there is need for a
more elaborate form (git commit message, reviewable patch on Rietveld)
or similar, please holler. This was just easiest to do right now.
diff --git a/Documentation/contributor/programming-work.itexi b/Documentation/contributor/programming-work.itexi
index 936057d..f9e8c60 100644
--- a/Documentation/contributor/programming-work.itexi
+++ b/Documentation/contributor/programming-work.itexi
@@ -1250,37 +1250,26 @@ foo = 1
@end example
@noindent with @code{\paper}, @code{\midi} and @code{\header} being
-nested scope inside the .ly file-level scope. @w...@code{foo = 1}} is
-translated in to a scheme variable definition.
+nested scope inside the @file{.ly} file-level scope. @w...@code{foo = 1}}
+is translated in to a scheme variable definition.
This implemented using modules, with each scope being an anonymous
module that imports its enclosing scope's module.
-The reason to put some functions (@qq{builtin}) outside the .ly level,
-is that in case of
+Lilypond's core, loaded from @file{.scm} files, is usually placed in the
+...@code{lily} module, outside the @file{.ly} level. In the case of
@example
lilypond a.ly b.ly
@end example
@noindent
-we want to reuse the built-in definitions, without changes
-effected in a.ly leaking into the processing of b.ly.
-
-Maintaining this scoping when one .ly file can be included in another
-.ly file can be challenging. A @code{define-public-toplevel} macro
-has been created in order to handle a difficulty caused by the modules
-being not the same when a .ly file is included into another.
-This provided a way to define all markup commands in the same module.
-At this time, we have found no easier way to define a function in a given
-module (not the current one) than to define this macro.
-
-With this architecture, the guile module system is not bypassed:
-module-define!, module-export! and module-ref are all guile module
-primitives.
-
-A second reason for using this current architecture is to avoid memory
-leaks that could occur when running multiple files if toplevel
-functions were registered permanently.
-
-
+we want to reuse the built-in definitions, without changes effected in
+user-level @file{a.ly} leaking into the processing of @file{b.ly}.
+
+The user-accessible definition commands have to take care to avoid
+memory leaks that could occur when running multiple files. All
+information belonging to user-defined commands and markups is stored in
+a manner that allows it to be garbage-collected when the module is
+dispersed, either by being stored module-locally, or in weak hash
+tables.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 898 in lilypond: Enhancement: rests should be taken into account when determining beaming intervals
David Kastrup d...@gnu.org writes:
lilyp...@googlecode.com writes:
Comment #4 on issue 898 by v.villenave: Enhancement: rests should be
taken into account when determining beaming intervals
http://code.google.com/p/lilypond/issues/detail?id=898
David, could you elaborate on that (and send a more complete report on
the list,
possibly demonstrating the requested behavior)? There's not much for
me to open a
proper request page, but I'll happily do so if you can provide me with
more material.
Here is an example:
\relative c' {
% This is how it is
c8 c r c c c c c |
% This is how it should (could) be
c8[ c r c] c c c c |
}
Ping?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug team
Graham Percival gra...@percival-music.ca writes: We have a problem, though: what should we call you guys? Part of me wants to suggest The Buggers, but that word unfortunately has a rude meaning in the UK. :( (Valentin: it's much ruder than frogs) At the moment, the best I can come up with is the generic Bug Team. Suggestions appreciated. Bug squad. URL:http://www.girlgeniusonline.com/comic.php?date=20060315 shows one of them in action. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug team
Francisco Vila paconet@gmail.com writes: 2010/2/1 Graham Percival gra...@percival-music.ca: At the moment, the best I can come up with is the generic Bug Team. Suggestions appreciated. Flysprayers :-) You would not want to poison the frogs. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug team
James Bailey derhindem...@googlemail.com writes: I think I'm going to agree with bug squad although being fully aware of the meaning of buggers, I think it's awesome. buggers is an informal name for people _planting_ electronic eavesdropping devices. A suitable name for people _removing_ them would be _debuggers_. However, that name happens to be already a _proper_ computing related name for the task within Lilypond, and thus is no longer suitable as an informal one. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug team
Patrick McCarty pnor...@gmail.com writes: On 2010-02-01, Graham Percival wrote: So where does that leave us? Insectoids, Insectors, Bug team, Bug squad, etc? I like the sound of bug squad. squad is quite close to squash. Which is comforting in this instance. It's obviously my favorite, having proposed it, and I have been appalled by buggers. However, I have not seen that I could have added anything to the discussion that had not already been said and considered. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1009 in lilypond: \transpose causes crash (std::logic_error)
lilyp...@googlecode.com writes:
Comment #2 on issue 1009 by Carl.D.Sorensen: \transpose causes crash
(std::logic_error)
http://code.google.com/p/lilypond/issues/detail?id=1009
disis (without the comma) causes terminate to be called the same as
disis, (with the comma)
aisis, bisis, disis, and eisis all cause terminate to be called.
cisis, fisis, and gisis do not cause terminate to be called.
I have a hard time picturing what transposing { a b c d } from disis to
c should result in. A scale in disis contains
disis eisis fisisis gisis aisis bisis cisisis disis
c in this scale would transpose to beseses in a c scale. There is no
such thing as beseses. Incidentally, there is no such thing as cisisis
either, but Lilypond should only balk when it has to produce something
impossible, not just think about it.
Since transposition does not just deal with absolute pitches but with
enharmonicity as well, there is no way to properly transpose this in the
demanded manner. Aborting is the sanest choice.
Now let's look at the other scales/transforms
aisis: { a b c d } - { ceses beses eseses deses }
bisis: { a b c d } - { beseses ceses deseses eseses }
cisis: { a b c d } - { aeses beses ceses deses }
disis: { a b c d } - { geses aeses beseses ceses }
eisis: { a b c d } - { feses geses aeseses beseses }
fisis: { a b c d } - { eses fes geses aeses }
gisis: { a b c d } - { deses eses feses geses }
You'll see that Lilypond only balks at those transforms which contain
impossible notes.
There are no notes Lilypond could produce. Aborting is the right
choice. The best thing you can hope to do is to produce a nicer error
message.
The notation manual contains under Transpose a snippet that transposes
using minimal accidentals. It is conceivable that employing this
snippet will avert the abort.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Room to improvement for polyphonic rests
Han-Wen Nienhuys hanw...@gmail.com writes: On Thu, Feb 18, 2010 at 7:20 AM, Francisco Vila paconet@gmail.com wrote: Rests are not centered with noteheads in other voices. This is intentional; only whole-measure rests should be centered. (Please provide scans of publications if you think otherwise) Whole-measure rests are centered in the _bar_, not with other noteheads. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
make info has failed for more than one day.
The error message from make info is LANG= makeinfo --enable-encoding -I /usr/local/tmp/lilypond/Documentation -I. -I./out-www --output=out-www/lilypond-learning.info out-www/learning.texi /usr/local/tmp/lilypond/Documentation/out-www//learning/fundamental.texi:2211: warning: @image file `lilypond/pictures/context-example.txt' (for text) unreadable: No such file or directory. LANG= makeinfo --enable-encoding -I /usr/local/tmp/lilypond/Documentation -I. -I./out-www --output=out-www/lilypond-notation.info out-www/notation.texi out-www/notation.texi:83: @include `notation/notation-appendices.texi': No such file or directory. out-www/notation.texi:83: @include `notation/cheatsheet.texi': No such file or directory. ./out-www/notation.texi:86: Prev reference to nonexistent node `Cheat sheet' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/changing-defaults.texi:13: Next reference to nonexistent node `Notation manual tables' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/changing-defaults.texi:4941: Cross reference to nonexistent node `The Feta font' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/changing-defaults.texi:4940: Cross reference to nonexistent node `Text markup commands' (perhaps incorrect sectioning?). 929: Cross reference to nonexistent node `The Feta font' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/changing-defaults.texi:2684: Cross reference to nonexistent node `Text markup commands' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/input.texi:1808: Cross reference to nonexistent node `MIDI instruments' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/ancient.texi:840: Cross reference to nonexistent node `Note head styles' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:1598: Cross reference to nonexistent node `Common chord modifiers' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:1597: Cross reference to nonexistent node `Chord name chart' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:1260: Cross reference to nonexistent node `Chord name chart' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:844: Cross reference to nonexistent node `Common chord modifiers' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:839: Cross reference to nonexistent node `Common chord modifiers' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:483: Cross reference to nonexistent node `Common chord modifiers' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/chords.texi:332: Cross reference to nonexistent node `Common chord modifiers' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/wind.texi:152: Cross reference to nonexistent node `List of articulations' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/wind.texi:95: Cross reference to nonexistent node `List of articulations' (perhaps incorrect sectioning?). /usr/local/tmp/lilypond/Documentation/out-www//notation/wind.texi:91: Cross reference to nonexistent node `List of articulations' (perhaps incorrect sectioning?). [...] And so forth and so on. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: make info has failed for more than one day.
Neil Puttock n.putt...@gmail.com writes: On 8 April 2010 19:24, David Kastrup d...@gnu.org wrote: And so forth and so on. I've pushed a compile fix which should sort this out for you. Thanks. Appears to work here. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Sustain pedal at end of piece
Phil Holmes m...@philholmes.net writes: At the end of a piece of music, a text Pedal down marking (from \sustainOn) should automatically be marked with a Pedal up marking, Why? but isn't. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New Essay:nitpicking
Jonathan Wilkes jancs...@yahoo.com writes: Hi Alexander, On your point about technical restrictions: I would just say that by the time a musician becomes a professional he/she has read thousands of scores with rounded notes, non-pointy angles, heavy dynamics font, etc. [...] playing music, which I obviously love, and less time doing what amounts to bookkeeping-- clearing up ambiguities/misprints, adjusting my eyes to a weird font, trying not to be distracted by stems that are too heave/light, squinting at hair-thin lines, etc. Hair-thin lines are not for squinting. They are used, for example, in the modern font families for producing closed letter aesthetics with an open lead of the serif line. The idea of a vertical hair line is exactly to _not_ disturb the base line of lead fortified by serifs. You need good printing resolution to bring that intent to fruition. One reason to make music fonts low-res friendly is that scores, much more than most other materials, are likely to be photocopied. They are a musician's work material. Also, you often have just an angle of your sight to spare for them. The conductor will thank the typesetters if the score does not require the full focus of the musicians. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: PATCH: Lyrics break estimation of vertical spacing
Boris Shingarov b...@shingarov.com writes: What makes me really depressed about the situation with pure-height, is that we have fixed a number of reasonable bugs in this area (intersystem begin/rest, overridden stem length, deprecated space, padding of markup -- these are the ones that I did in the immediate past, -- the slur fix from Joe yesterday, and I also recall a bunch of other fixes in this area in the last few months), but we are not only not closer to having reasonable trouble-free page layout, but starting to look at page overfill/underfill problems which are very deeply rooted in the nature of pure-height estimation. So much so that I am starting to think that sacrificing the benefit of linebreaking/pagebreaking integration in the sake of always running real (non-pure) height, would be the path to having a reasonable layout for our book. That is, calculate the line breaks disregarding page breaking; calculate tallness of all lines; then run the page breaking algorithm. In case the line breaking algorithm is TeX-like, namely using a shortest graph traversal algorithm (Viterbi), it would be a considerable improvement if the first pass did not establish the optimal breaks, but rather the maximum and minimum heights of material. Then the page breaker would pick its goals (avoid widows, avoid extra pages and so on), and the line breaking would be done again, this time using optimal breaks while keeping the page break goals focused. A complete separation of line- and page breaking makes it infeasible to avoid things like widows and clubs (single lines on one page) by picking better line breaks. That actually is a rather severe limitation with TeX: while TeX has penalties for widows and clubs (and hyphens at the end of a page), they come into play only once line breaking is already completed. With a rigid layout, there is nothing you can do to fix the previous bad decision. You can only call it foul and have TeX emit a warning. I think we need to be better than that. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
define-markup-command and define-markup-list-command have limited signatures
define-markup-command and define-markup-list-command accept only a very limited set of argument lists. There is patch available as Issue number: 969046 (http://codereview.appspot.com/969046) but it does not meet the requirements for Lilypond contributions. Someone would need to bring it into a shape acceptable for committing, and the original contributor has lost interest. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
What's the deal with this programming error?
When compiling
\new Voice \with {\consists Ambitus_engraver}
{\new Voice { c } s { c } }
I get the following two programming errors. What's up?
lilypond /tmp/junk.ly
GNU LilyPond 2.13.23
Processing `/tmp/junk.ly'
Parsing...
/tmp/junk.ly:0: warning: no \version statement found, please add
\version 2.13.23
for future compatibility
Interpreting music...
Preprocessing graphical objects...
programming error: note column without heads and stem
continuing, cross fingers
/tmp/junk.ly:2:26: programming error: note-column has no direction
{\new Voice { c } s {
c } }
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 678 in lilypond: Enhancement: Add option to make moll chords small
lilyp...@googlecode.com writes: Comment #9 on issue 678 by Carl.D.Sorensen: Enhancement: Add option to make moll chords small http://code.google.com/p/lilypond/issues/detail?id=678 I think that James Bailey is working on verifying this issue. It needs to have a regression test added, and perhaps some documentation. It is my opinion that an implementation needing to touch define-context-properties.scm for every new chord naming scheme again is a mistake. A different (or tweaked) _naming_ scheme is something that should be achievable with pure user-level code without requiring deep surgery. Meddling with define-context-properties.scm or other code that is a part of Lilypond may be needed _now_ to get there. But it should be done in a way that does not require reopening an issue whenever somebody needs a new naming scheme for some piece of typography. Nor should it be a global setting. I attach a scan from a quite standard accordion score: Scanned Document.pdf Description: Adobe PDF document You see that it is customary to use a standard piano chord naming scheme for the harmonies _above_ the top staff, and a scheme with _upper case_ bass notes and _lower case_ chord names for the chord buttons in the lower staff. It would not do to just use textual markup here since textual markup is not transposable. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
Uh, am I by now in everybody's killfile, or do people just enjoy having
me throw a fit for every contribution? If it is the latter, I am afraid
that I am currently hospitalized because of my blood pressure and I sort
of think that my doctors would disapprove. Tough luck. Maybe next
time.
Anyway, I should think that this bug description including a list of
relevant examples should warrant being recorded by the bug squad.
All the best.
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
I get the following two programming errors. What's up?
A simpler test case is
\new Voice \with {\consists Ambitus_engraver} { \new Voice { c'' } }
The key point appears to be that the music written in the inner voice
apparently is sufficient for triggering some processing that would
require the c'' to be actually in the voice with the Ambitus_engraver.
The error occurs even if there are any notes after the inner voice. It
does not occur when any music (including just s) is placed before the
inner voice. This seems to depend on both timing as well as notes:
\new Voice \with {\consists Ambitus_engraver} { s4 \new Voice { c''4 } }
creates no error.
\new Voice \with {\consists Ambitus_engraver} { c4*0 \new Voice { c''4 } }
creates no error.
\new Voice \with {\consists Ambitus_engraver} { s4*0 \new Voice { c''4 } }
creates the above errors.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
Dmytro O. Redchuk brownian@gmail.com writes:
On Wed 09 Jun 2010, 16:52 David Kastrup wrote:
Anyway, I should think that this bug description including a list of
relevant examples should warrant being recorded by the bug squad.
i simply can not understand (tm) what's the problem (tm):
The error messages?
On Thu 03 Jun 2010, 14:34 David Kastrup wrote:
When compiling
\new Voice \with {\consists Ambitus_engraver}
{\new Voice { c } s { c } }
I get the following two programming errors. What's up?
programming error: note column without heads and stem
note column is _really_ without heads and stem...
At the point of time that the bug is reported. But that time is
premature since respective ambitus data arrives later.
continuing, cross fingers
/tmp/junk.ly:2:26: programming error: note-column has no direction
{\new Voice { c } s {
c } }
... well, i can easily believe it _really_ has no direction.
See above.
Sorry, i _really_ could not catch the idea. So i waited (as usually)
for some discussion of the topic. And still waiting, be sure .)
The problem is that the ambitus engraver barfs because of a lack of data
that is going to arrive later.
It appears that there are some measures in the engraver that avoid those
messages for some of the simplest cases (see in particular the examples
I gave that _don't_ throw errors), but they don't seem to do the job
properly.
The ambitus engraver tries evaluating something at a time when it does
not work. Whether or not that is convenient or the only way to do it,
it should not be able to cause errors until the voice actually ends.
And then the error should not be something utterly bewildering, but
clearly pointing to the lack of collected ambitus data.
Does this make the problem clearer?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
Graham Percival gra...@percival-music.ca writes: PS note that the new email checklist does *not* contain an item for ignore the email and hope that somebody else handles it. If you can't reject the report for having no Tiny example, no version number, not being able to reproduce it, etc., then you MUST move on to the final point, namely adding it to the tracker. I should think that asking for the missing information (with copy on the bug list so that other members of the squad might be aware of the response) should be a valid option as well. For the sake of not eventually getting swamped by leftovers, add it to the tracker would likely be a better choice over make a mental note to ask for more information Real Soon Now (TM). And of course, adding more information is done _automatically_ when someone responds to the tracked report. So adding to the tracker with a canned phrase Small example, and error symptom still missing might well be a safe choice in any case. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \quoteDuring at the beginning
Reinhold Kainhofer reinh...@kainhofer.com writes:
Am Montag, 14. Juni 2010, um 10:54:27 schrieb Christian Hitz:
\quoteDuring does not quote when used at the beginning of a piece.
Result: No Notes are quoted.
Expected Result: Quoting the beginning of the quoted voice.
You need to create the voice explicitly, as implicit voice generation
does not work with things like quotes (or tempo marks inside
triplets):
\new Voice {
\relative c'' {
\quoteDuring #part { s4 }
}
}
Is there a good reason to have implicit voice generation not work in
such circumstances?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \quoteDuring at the beginning
Reinhold Kainhofer reinh...@kainhofer.com writes:
Am Montag, 14. Juni 2010, um 12:28:48 schrieb David Kastrup:
Reinhold Kainhofer reinh...@kainhofer.com writes:
You need to create the voice explicitly, as implicit voice generation
does not work with things like quotes (or tempo marks inside
triplets):
\new Voice {
\relative c'' {
\quoteDuring #part { s4 }
}
}
Is there a good reason to have implicit voice generation not work in
such circumstances?
Yes, lack of developers ;-) (Just like the old grace note bug will probably
not get fixed for a long time)
Seriously, this issue goes very deep, dealing with the very internals of
lilypond. Thus, it is quite intricate to get right, and there are not so many
developers who understand what is going on exactly...
Hm. Is there any situation where mechanically substituting \quoteDuring
with \context Voice \quoteDuring is going to cause trouble?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: q notation for repeated chords should also copy \harmonic...?
Neil Puttock n.putt...@gmail.com writes: On 22 June 2010 19:17, Arno Waschk hamama...@gmx.de wrote: this time not being sure whether it's a bug, feature or possible enhancement, i wanted to mention that in a situation like: c f\harmonic1 q the second chord is missing the harmonic not head (here, i. e. 2.13.25 git from yesterday). It's intended behaviour. If you want to change it, you can redefine the repetition function to include articulations inside or outside the chord (see ly/chord-repetition-init.ly for more info): A harmonic is not an articulation. Regardless how it is implemented inside of Lilypond. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Broken crescendo hairpin snippet in Expressive marks is broken
The Broken crescendo hairpin snippet in Expressive marks makes space for a dynamics mark which is placed above the staff after all. That is for the current development version and can be seen on the web page at URL:http://www.lilypond.org/doc/v2.13/Documentation/snippets/expressive-marks#broken-crescendo-hairpin inline: lily-74fc53ae.png -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Broken crescendo hairpin snippet in Expressive marks is broken
Trevor Daniels t.dani...@treda.co.uk writes: Hi David I think the snippet is behaving as intended. It is not a bug. It would not make sense to position a pp dynamic mark in the gap created in a hairpin which goes from mf to sff, would it? The hairpin relates to the lower of the two voices, with the gap in the hairpin corresponding to the rest in that voice. In that gap the upper voice has a single note, which is to played pp. That makes sense. I would not actually interrupt the hairpin at all in that case (or at least continue it with dashed lines). Maybe the accompanying text can be amended so that the intent becomes clearer? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 687 in lilypond: Enhancement: inequal MIDI quantization of equal durations (swing, rubato)
lilyp...@googlecode.com writes: Comment #14 on issue 687 by chicagogrooves: Enhancement: inequal MIDI quantization of equal durations (swing, rubato) http://code.google.com/p/lilypond/issues/detail?id=687 Here is a prototype scheme-based implementation which works for streams of notes/rests which are quarter-note length or less: http://music.chicagogrooves.com/lilypond-swing-dev.zip A couple of things I wish I had when doing this: 1. A way to simply add to the duration of a note - instead of needing call ly:compress-music with some clever ratio - I just want to add or subtract 1/6 of a quarter note and be done with it Doesn't the function ly:moment-add a b do that for you? 2. A way of iterating which tells me not just the duration of the current event, but the amount of time in moments since the beginning. ly:context-current-moment maybe? 3. An understanding of why I need (begin ) blocks and what they do.. They execute all inner forms in sequence, and are just a single form on the outside. The Lisp equivalent would be (progn ...). 4. A REPL for testing out scheme stuff lilypond -e '(top-repl)' -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: repeating identical tempos
Xavier Scheuer x.sche...@gmail.com writes: It is indeed maybe correct from a dev point of view... But now as what user expects! If I have one Allegro and then another Allegro I want *both* to be printed! I don't care if the MIDI tempo is not changed. What if the second Allegro is only there because of being in the inside of \repeat unfold? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: repeating identical tempos
Dmytro O. Redchuk brownian@gmail.com writes: So, there are some workarounds, so i'm still not sure that issue report is necessary. The need of a workaround is an issue. Having a workaround may reduce its urgency, but as long as the workaround is indeed a workaround and requires more cleverness than a straight approach to the problem, I don't see how it could not be an issue. Lilypond is supposed to be a tool for typesetting music, not some contraption which we can cleverly trick into typesetting music. If we wanted that, we would still be using TeX. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: I don't find lilypond in my computer
Javi javid...@hotmail.com writes: I installed Ubuntu 10.04 LTS two weeks ago in my computer. I went to the download space (in german synaptic-paketverwaltung) and I downloaded lilypond, but I looked for the program in my computer and I didn't find it. Normally there's a place, where you can find all the programs that you download, but lilypond is not in this list. You probably mean the application menu. Lilypond is not an application, it is a compiler. You need to call it from the command line _after_ preparing your source file. You'll find the details in the lilypond documentation that need to get installed separately as lilypond-doc and will likely unpack into /usr/share/doc/lilypond-doc where you can browse through them with your browser. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Trevor Daniels t.dani...@treda.co.uk writes: Mark Polesky wrote Sunday, September 19, 2010 2:37 AM Gardner Read, ch.14, NOTATIONAL PRACTICES, p.253: The general rule is, of course, altered should there be inadequate room because of elements [...] related to the staff just below, or when different dynamic markings affect two voices written on one staff... We have to be careful to interpret this correctly. None of these writers were familiar with the use of voice in the computer engraving sense. By voice these writers mean parts that are on one staff but are to be played or sung by independent musicians. I disagree. Baroque polyphony is commonly executed on single instruments, as composed. The principal selling point of the pianoforte (hammer piano) was that it allowed playing several dynamics at once without being confined to working with registers. More than a single dynamic is even needed for executing Bach violin solo pieces, for multiple voices executed sequentially (via multi-string bowing patterns) or in parallel (via skewed bow pressure on multiple strings). And of course, the principal polyphonic string instrument, the lute, was also employed with voices differentiated in articulation and dynamics. But it makes no sense to separate the dynamics of individual voices in music that is intended to be played by a single musician, such as guitar or piano music[1]. You can even differentiate dynamics of different voices on an accordion (where every reed sounds off the same bellow, the principal control of dynamics) by working with articulation, variations of button depression, psychoacoustical masking (a loud onset masks volume variations of a continued note) and using registration (where available, to differentiate between left and right hand). Indeed, in piano music LilyPond provides facilities for combining the dynamics from two staves. Not necessarily desired. In pieces or passages where common dynamics are desired, it might be convenient to enter them just in one voice (and have them propagate across all voices, also in Midi). But the dynamics would then not be specified in varying locations. In general, I think that dynamics should be present in every voice entry, just like articulations. And it would usually be the task of the engraver to merge the dynamics when identical. One result of the current mishmash is that the dynamics performer just fiddles with global volume rather than key velocity, propagating dynamics across voices in that manner. More or less accidentally, like we currently do visually. This bug report is just one more outcome of Lilypond having no clean concept of dynamics related to voices rather than merely to current time. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Mark Polesky markpole...@yahoo.com writes:
Are you saying that, in a 2-voice 1-staff setting, it makes
no sense to separate the dynamics when they both voices are
at the same dynamic? Like this:
\relative c'' {
{ c2\p } \\ { a2\p }
}
Okay, I suppose I might be able to agree with that. The
first note of Beethoven's 2nd symphony has 5 such instances
of a combined dynamic, though that's not what you're
referring to since those instances are not each played by
single musicians. Besides, compile that fragment --
LilyPond prints 2 p's anyway.
And it makes *every* sense to separate the dynamics for a
single player when the dynamics are different. And please
don't make me place all of these manually, or you might as
well ask me to manually place every articulation, slur, tie,
etc. IIUC, \voiceOne already implies the following:
\dotsUp
\phrasingSlurUp
\slurUp
\stemUp
\tieUp
\tupletUp
[... also articulations, fermatas, etc. go up]
So why doesn't it also imply \dynamicUp ?
Because that will be startling for basically homophonic voicing with
only short not-actually-a-voice-but-we-need-to-write-it-such passages.
As I said: the right thing to me seems to put the dynamics in every
voice (and let the performers work from that), and give the dynamics
engraver options to funnel them off to a common place as long as they
can be unified (like in the middle of a piano stuff).
\relative c'' {
{ c2\f } \\ { a2\p }
}
In my mind, this is so obviously a bug, I'm surprised by all
this resistance. I mean, what legitimate code would
possibly break by changing this?
\relative c'' {
{ c2\f } \\ { a2 }
}
Namely code that makes use of the fact that a dynamic specification in a
single voice contaminates all other voices (and the Midi) by default.
If all other dynamic specifitions end up below the staff, you'll be
surprised at this one.
I consider it bad style to write like this, but there have not been
convincing alternatives yet, have they?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1043 in lilypond: Cross-staff beams confuse skyline calculations
lilyp...@googlecode.com writes: Comment #11 on issue 1043 by k-ohara5...@oco.net: Cross-staff beams confuse skyline calculations http://code.google.com/p/lilypond/issues/detail?id=1043 Now I see that placement of outside-staff grobs uses a series of skyline calculations. Knowing that, the 'Summary:' makes sense. Sorry for my objection earlier. I would categorize the behavior: 2) Cross-staff beams do not expand skylines. This makes sense so these beams do not push the staves apart, but then these beams can overlap outside-staff grobs, notably dynamics. Same as issue 439, and issue 36; see also issue 721. How would cross-staff beams push staves apart when their respective stems apparently don't? The thing that I can imagine is that the cross-staff beam is part of both skylines, and Lilypond tries pushing it away from itself. Is it something like that? 1) An automatic beam ending just before a staff change fails to expand skylines, resulting in similar collisions. Explicit [ ] beams are a workaround. First described in this issue, comments 2 and following. That sounds like something that could be addressed without something else caving in. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead toGhostscripterror in latest git
Trevor Daniels t.dani...@treda.co.uk writes: Phil Holmes wrote Sunday, September 26, 2010 6:26 PM - Original Message - From: Trevor Daniels t.dani...@treda.co.uk BTW, please don't reply to messages in newsgroups. I don't subscribe to any and that makes them very messy for me to reply to. Tricky. I _only_ use a newsreader for bugs and devel and so can't reply by mail to send it to the group and the original poster. Well, I had to copy out the message and reenter appropriate email addresses to reply to yours. Can't you do the same? With Emacs, it is a matter of doing C-c C-t after F . The followup will then be both sent to the nntp server as well as to the poster, marked as a courtesy copy. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1240 in lilypond: Music overflows page: #'((space . N) (stretchability . 0)) and nothing more with spacings
lilyp...@googlecode.com writes:
Comment #5 on issue 1240 by k-ohara5...@oco.net: Music overflows page:
#'((space . N) (stretchability . 0)) and nothing more with spacings
http://code.google.com/p/lilypond/issues/detail?id=1240
Maybe this was known, but piano staves can overflow the page with no
overrides -- for example:
% In 2.13.24 this overflows the page by 41.4
% (two and one-half systems off the bottom of the page)
% 2.12.3 sets this on two pages
%
{
\new Staff{
\clef bass
\repeat unfold 12 {s1 \break}
}
\new Staff {
\clef bass
\repeat unfold 12 {s1 \break}
} }
Hm. Initial skyline estimate does not take into account the systems
themselves and/or the clef?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's with the spacing code?
Phil Holmes m...@philholmes.net writes:
[Please don't write anything important below your signature, as mail
clients will cut this away on reply].
If you think this is all fine, take out the markup from the example and
get a really _tight_ fit in contrast.
The current spacing is not a matter of too tight or too loose. It
is a matter of too unpredictable.
And if you really want to see some hot action, just write
\score { c }
as often as you want. Regardless of how much of those you put into the
file, the outcome will be just a single page.
All this is rather erratic.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's with the spacing code?
Phil Holmes m...@philholmes.net writes:
David Kastrup d...@gnu.org wrote in message
news:87vd5nny58@lola.goethe.zz...
Phil Holmes m...@philholmes.net writes:
[Please don't write anything important below your signature, as mail
clients will cut this away on reply].
Apologies. I have to cut and paste my sig to the bottom and I already
had something ready to paste, so forgot.
If you think this is all fine, take out the markup from the example and
get a really _tight_ fit in contrast.
Wasn't saying it was fine - just that it's not a regression between
13.34 and 13.35 - it's a change, but compared to 12.3, 13.34 was too
tight. Using the test file you provided, 12.3 took 7 pages. .31 and
.34 (and probably others - I don't have a full set) took 5.5 pages and
leave no room for markup. .35 takes 10.5 pages and leaves too much
room for markup.
I have to disagree with your assessment: the behavior of 12.3 made sense
under the constraints the code worked with. It was a result of its
design decisions. The result of 13.35 does not make sense. As you can
easily see by removing the markup, it is not a result of a generally
wider spacing decision.
If you think different, how about the following:
test = { c'^\markup { \column { x y z } } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
\score { \repeat unfold 48 { \test } }
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's with the spacing code?
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
I have to disagree with your assessment: the behavior of 12.3 made sense
under the constraints the code worked with. It was a result of its
design decisions. The result of 13.35 does not make sense. As you can
easily see by removing the markup, it is not a result of a generally
wider spacing decision.
If you think different, how about the following:
[...]
It is particularly educational to look at the distances used in the last
page. They don't particularly look like the general spacing is intended
to be on the loose side.
Here a shorter recipe:
\score { \repeat unfold 480 { c'^\markup { \column { x y z } } } }
Again, compare the last page with the other pages.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's with the spacing code?
David Kastrup d...@gnu.org writes: I have to disagree with your assessment: the behavior of 12.3 made sense under the constraints the code worked with. It was a result of its design decisions. The result of 13.35 does not make sense. As you can easily see by removing the markup, it is not a result of a generally wider spacing decision. If you think different, how about the following: [...] It is particularly educational to look at the distances used in the last page. They don't particularly look like the general spacing is intended to be on the loose side. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1286 in lilypond: Output flows off bottom of page
lilyp...@googlecode.com writes: Comment #1 on issue 1286 by joeneeman: Output flows off bottom of page http://code.google.com/p/lilypond/issues/detail?id=1286 This is a bug in Paper_column_engraver::finalize which triggers if the last bar of a score is incomplete (so if you change c to c1 then it breaks just fine). Oh. Wow. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Skyline compaction is going overboard sometimes.
Check the first two systems on the second page of the following score:
\repeat unfold 80 { c'''-1 e'''-3 g'''-5 c' c,-1 e,-3 g,-5 c' }
Perhaps skylines should not be taken as literally as that, but padded
out somewhat.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming errors: Object is not a markup. and I am not spanned!
Wilbert Berendsen lily...@xs4all.nl writes:
Op donderdag 30 september 2010 schreef Marnix:
L.S.,
For the following file
\version 2.12.4
{ R\breve\fermata }
use R\breve-\fermataMarkup (see the docs about full measure rests).
Even more alarming-looking,
\version 2.12.4
{ R2 }
results in a (correct) barcheck failed warning, but also in an I am not
spanned! error:
R2 does not fill the measure that's why the MultiMeasureRest complains.
No LilyPond bugs as far as I can tell.
Incomprehensible error messages count as bugs.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
More layout problems
Check the output of the following:
test = { c-1-^ r f-2-^ r c-3-^ r f-4-^ r c-1-^ r f-2-^ r c-3-^ r }
\score {
\repeat unfold 8 { \test \test r
\transpose c c''' \test \transpose c c''' \test r }
\layout { ragged-bottom = ##t }
}
It is clear that on the first page, the \layout parameter ragged-bottom
is ignored (or the first page would have, well, a ragged bottom and a
vertical spacing similar to the packed last page).
It is also clear on the second page that the vertical spacing is going
overboard in compressing the page, partly intermingling the systems.
Since it does not make sense to compress only the last page like that,
the vertical spacing should, when ragged-bottom is not ##t (to get a
valid regression test independent from the first problem, remove the
layout line), not compress the resulting page beyond its page-breaking
estimate, in order to get output spacing consistent with the layout of
the previous pages.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: More layout problems
Phil Holmes m...@philholmes.net writes:
David Kastrup d...@gnu.org wrote in message
news:87mxqvcsvr@lola.goethe.zz...
Check the output of the following:
test = { c-1-^ r f-2-^ r c-3-^ r f-4-^ r c-1-^ r f-2-^ r c-3-^ r }
\score {
\repeat unfold 8 { \test \test r
\transpose c c''' \test \transpose c c''' \test r }
\layout { ragged-bottom = ##t }
}
It is clear that on the first page, the \layout parameter ragged-bottom
is ignored (or the first page would have, well, a ragged bottom and a
vertical spacing similar to the packed last page).
It is also clear on the second page that the vertical spacing is going
overboard in compressing the page, partly intermingling the systems.
Since it does not make sense to compress only the last page like that,
the vertical spacing should, when ragged-bottom is not ##t (to get a
valid regression test independent from the first problem, remove the
layout line), not compress the resulting page beyond its page-breaking
estimate, in order to get output spacing consistent with the layout of
the previous pages.
--
David Kastrup
David,
It would seem that there are a number of spacing issues with 2.13.35
and as a result I opened
http://code.google.com/p/lilypond/issues/detail?id=1285. Joe has
responded to that to say that he's reverted the git code to the
2.13.34 behaviour. Will this fix your issues?
Uh, the above test case _is_ for the current git version.
If so, we don't need to worry further. If not, it would be helpful to
produce a summary of the issue and test material so that a further
issue can be raised.
What is wrong with the above?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: More layout problems
Phil Holmes m...@philholmes.net writes: David Kastrup d...@gnu.org wrote in message news:8762xjcltg@lola.goethe.zz... What is wrong with the above? Nothing. It's just that it's one of many you've posted, and I wanted to know which you felt best illustrated the issue. There is more than one issue. When I post a different description, it is likely a different issue. Should bugs in the current git version (not yet released) be raised only on lilypond-devel? If you say that you can't register a bug for an unregistered version, that would seem like the sanest course. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming errors: Object is not a markup. and I am not spanned!
Dmytro O. Redchuk brownian@gmail.com writes:
On Sun 03 Oct 2010, 03:12 David Kastrup wrote:
Wilbert Berendsen lily...@xs4all.nl writes:
Op donderdag 30 september 2010 schreef Marnix:
L.S.,
For the following file
\version 2.12.4
{ R\breve\fermata }
use R\breve-\fermataMarkup (see the docs about full measure rests).
Even more alarming-looking,
\version 2.12.4
{ R2 }
results in a (correct) barcheck failed warning, but also in an I am not
spanned! error:
R2 does not fill the measure that's why the MultiMeasureRest complains.
No LilyPond bugs as far as I can tell.
Incomprehensible error messages count as bugs.
Please, can you tell what lilypond should output in this case?
We currently get
/tmp/junk2.ly:1:2: warning: barcheck failed at: 1/2
{
R2 }
Preprocessing graphical objects...
programming error: Multi_measure_rest::get_rods (): I am not spanned!
continuing, cross fingers
programming error: Object is not a markup.
continuing, cross fingers
This object should be a markup: ()
programming error: Multi_measure_rest::get_rods (): I am not spanned!
continuing, cross fingers
Instead, the message better be either
Warning: multimeasure rest fails bar check
(in case that its length _is_ a full bar multiple)
or
Error: multimeasure rest size not a multiple of bar size
(in case that it could not work out anyway).
In case of a warning, error recovery needs to result in something
reasonably sensible. If that is not feasible, one needs to create an
error instead.
A warning implies that Lilypond is going to do continue with reasonable
results.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 95, Issue 5
Keith E OHara k-ohara5...@oco.net writes:
On Sun, 03 Oct 2010 03:12:38 -0700, bug-lilypond-request wrote:
Check the first two systems on the second page of the following score:
\repeat unfold 80 { c'''-1 e'''-3 g'''-5 c' c,-1 e,-3 g,-5 c' }
Perhaps skylines should not be taken as literally as that, but padded
out somewhat.
Do you mean padded out sideways, or vertically?
How about diagonally? In case of doubt, horizontally. The problem is
that if we have toothed skylines, opposing teeth might just fit into
one another like cog wheels. Padding sideways would, at one particular
threshold, completely unlock the teeth. A smoother transition from
locked to unlocked would appear to make sense, hence the suggestion to
pad diagonally, where the sum of adjacent horizontal and vertical
distances should not fall below a given limit.
Another option would be Euclidian.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 95, Issue 11
Carl Sorensen c_soren...@byu.edu writes: On 10/5/10 5:50 PM, Keith E OHara k-ohara5...@oco.net wrote: If \cadenzaOff turns autobeaming on, then what about scores that turn off autobeaming for the whole piece, but then (mis-)use short cadenzas? The CHANGES file informs the user that they will need to turn off autobeaming manually after the cadenza, as does the notation reference. I think this is the right thing to do. I think a revert would be more appropriate. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 95, Issue 11
Dmytro O. Redchuk brownian@gmail.com writes: On Wed 06 Oct 2010, 07:44 David Kastrup wrote: Carl Sorensen c_soren...@byu.edu writes: On 10/5/10 5:50 PM, Keith E OHara k-ohara5...@oco.net wrote: If \cadenzaOff turns autobeaming on, then what about scores that turn off autobeaming for the whole piece, but then (mis-)use short cadenzas? The CHANGES file informs the user that they will need to turn off autobeaming manually after the cadenza, as does the notation reference. I think this is the right thing to do. I think a revert would be more appropriate. Please, why?.. Not a revert of the commit. A \revert to the setting before the cadenza. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Funny Bug or feature?. instrumentNames rendered in reverse order than music
Francisco Vila paconet@gmail.com writes: Hello. This makes figures attached to notes to be printed in the expected (ascending) order, but instrument names in reverse (descending) order. Another exciting case later below. I don't see what the problem is. Lilypond does not, as far as I can see, guarantee any particular order of evaluation here. This is neither a bug nor a feature as far as I can see. There is nothing that guarantees this will be different, there is nothing that guarantees that it will stay like this. There is nothing that guarantees you'll get the same behavior on two different runs even. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Voicename not recognised in music function
Marten Visser msvis...@planet.nl writes:
I'm not top posting.
A voicename not is recognised in a music function.
In the example below, I'd expect to get two documents with the same
content. However, in the error document, no lyrics are typeset, and
an error is sent into the logfile. Why?
\score {
\new Voice = melody { \relative c'' { d cis b a } }
\new Lyrics \lyricsto melody \lyricmode { An ex
-- am -- ple. }
}
vs.
MusFunc = #(define-music-function (parser location) ()
#{
\new Voice = melody { \relative c'' { d cis b a } }
\new Lyrics \lyricsto melody \lyricmode { An ex -- am --
ple. }
#} )
\book {
\bookOutputSuffix Error
\score {
\MusFunc
}
Music functions return sequential music by default, not a sequence of
partial music expressions folded into an upper syntactical construct.
So the lower is the equivalent of
\score {
{
\new Voice = melody { \relative c'' { d cis b a } }
\new Lyrics \lyricsto melody \lyricmode { An ex
-- am -- ple. }
}
}
if I am not mistaken.
It is likely that you can return a parallel music expression explicitly
using Scheme.
Perhaps it would be nice to allow # instead of #{ as a shortcut for
creating a music expression returning parallel music.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 503 in lilypond: schleifer articulation requested
lilyp...@googlecode.com writes: Updates: Status: Fixed Owner: v.villenave Comment #1 on issue 503 by v.villenave: schleifer articulation requested http://code.google.com/p/lilypond/issues/detail?id=503 A workaround has been suggested on the LSR: http://lsr.dsi.unimi.it/LSR/Item?id=720 I have some problems reconciling Fixed with workaround. workaround corresponds to categories Wontfix or Postponed or a priority Low. But Fixed and workaround seem like an odd match. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: enhancement request, page-breakers account for requested system spacing
Keith E OHara k-ohara5...@oco.net writes: Dear but list, Current behavior (2.12 and 2.13) is to populate pages with as many systems as will fit with tight spacing, meaning that only the last page has enough space to honor the requested system-system-spacing #'space. Oh, by the way: it would be nice to have an option to let Lilypond use the same space stretching on the last page (in case it fits) than on the last non-ragged-bottom page. It really does not make much aesthetical sense to have just the last page tighter than the rest if the gained bottom space is not actually required for anything. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1290 in lilypond: Skyline compaction is going overboard sometimes
Keith E OHara k-ohara5...@oco.net writes: On Mon, 25 Oct 2010 05:38:24 -0700, bug-lilypond-requ...@gnu.org wrote: 2) write better docs for this particular [skyline-horizontal-padding] tweak I talked around my point but didn't make a conclusion. Docs for the correct way to solve this, system-system-spacing, are already good. One might ask : Why not increase, or document, skyline-horizontal-padding ? When skylines are padded, they make a nice cushion shape (image attached) like David was asking for. The cushion does not extend vertically, but that is what the various 'padding properties are for. However, skyline-horizontal-padding consistently pads skylines *wherever* they are used, and I found more places where I would not want even half a note-width of padding (attached piano music images are with and without). I was never suggesting to pad individual objects. The horizontal padding would need to be applied to the skyline of the whole _system_, not the skyline of individual objects while the system is being assembled. In the example that opened the issue, I think it is the fact that the notes are logically unrelated that makes their interleaving so objectionable. Therefore the response should be tied to the fact that they are from different systems, so bump system-system-spacing back up. But that affects the vertical spacing of _any_ system, not just systems with interleaving parts. I am afraid that you are trying to evaluate my proposal by tweaking existing knobs. The existing knobs are no use for a reasonable automatic resolution of the problem. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: enhancement request, page-breakers account for requested system spacing
Valentin Villenave valen...@villenave.net writes: On Fri, Oct 29, 2010 at 9:56 AM, David Kastrup d...@gnu.org wrote: Greetings David, Oh, by the way: it would be nice to have an option to let Lilypond use the same space stretching on the last page (in case it fits) than on the last non-ragged-bottom page. It really does not make much aesthetical sense to have just the last page tighter than the rest if the gained bottom space is not actually required for anything. Added as http://code.google.com/p/lilypond/issues/detail?id=1377 (An example of a score where disabling ragged-last-bottom produces unnecessarily tight spacing would be nice to illustrate this request, though. -- I'm sure it's just me, but I had to read your proposal a number of times before beginning to understand what you were suggesting.) Uh, your description of the example does not make me confident that you did understand what I have been trying to say. If I take the artistic liberty of using the horizontal whitespace in a line to symbolize the vertical filling of the page, the objectionable (default) behavior is system system system|(end of page 1) system system system|(end of page 2) system system |(end of page 3) -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1376 in lilypond: Ambitus engraver progerror when a same pitch has different accidentals
lilyp...@googlecode.com writes:
Status: Accepted
Owner:
Labels: Type-Defect Priority-Medium Warning
New issue 1376 by v.villenave: Ambitus engraver progerror when a same
pitch has different accidentals
http://code.google.com/p/lilypond/issues/detail?id=1376
% The following example compiles fine, but produces a programming error:
% infinity or NaN encountered while converting Real number
\version 2.13.38
\new Voice \with {
\consists Ambitus_engraver
} {
cis' c'
% uncommenting this note fixes the problem:
% d
}
Uh, can you define compiles fine? It produces output that is not in
any manner a sensible representation of the input.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite { ... } \\ { ... } construct
Xavier Scheuer x.sche...@gmail.com writes:
Dear LilyPond developers,
Kieren,
We have had a discussion one year ago about a project to rewrite the
{ ... } \\ { ... }
so it behaves exactly like
{
% continuation of the main Voice from outside the polyphony
\voiceOne
...
}
\context Voice = 2 {
\voiceTwo
...
}
\oneVoice
That would kinda solve the issue that what is inside the
{ ... } \\ { ... } construct is in different voices than
the non-polyphonic voice from outside, thus forbidding slurs etc.
from outside to inside the polyphonic passage.
Slurs, ties etc from outside to the second voice would still be
forbidden. The problem really is that Lilypond's notion of continuity
(we have that also in repeat alternatives, codas and similar) is too
naive.
This is not well understood by users and it would really help if
this could be solved.
The above would not solve it. Some things would work, some things would
not. Depending on the voice they happen in.
So don't get your expectations too high about what gains can be expected
from implementing that proposal.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1391 in lilypond: Enhancement: warning message when an property is set in the wrong context
lilyp...@googlecode.com writes:
Status: Accepted
Owner:
Labels: Type-Enhancement Priority-Medium Warning
New issue 1391 by v.villenave: Enhancement: warning message when an
property is set in the wrong context
http://code.google.com/p/lilypond/issues/detail?id=1391
This feature was suggested by Werner:
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00229.html
It would be very helpful to many users that when typing e.g.
{
...
\override BarLine #'stencil = ##f
...
}
instead of (in the appropriate context):
\override Staff.BarLine #'stencil = ##f
A warning message would be printed, possibly along the lines of
overriding property `stencil' for grob `BarLine' has no effect in
context `Voice'
I would like to state that I consider that a step in the wrong
direction. If we make Lilypond smart enough to figure out what is
wrong, we should use that smartness for doing the right thing instead of
educating the user.
Lilypond once had subvoices (threads?). They have been eliminated, as
far as I understand, because they were causing more confusion than good,
and an elemental part of that confusion was that they made it harder to
figure out just what context you wanted to be setting your properties
for.
If we give Lilypond that knowledge, then we should make it pick the
right context itself.
That way, one could, if one wanted, reintroduce subvoice contexts
without changing the meaning of existing valid sources (namely sources
that don't fiddle with non-working properties in the wrong context).
And we _have_ snippets fiddling with typesetting stuff two times, using
transparent parts for each pass, that would work much more elegant with
the equivalent of subvoices.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1391 in lilypond: Enhancement: warning message when an property is set in the wrong context
Graham Percival gra...@percival-music.ca writes: On Wed, Nov 10, 2010 at 01:18:49PM +0100, Werner LEMBERG wrote: I would like to state that I consider that a step in the wrong direction. If we make Lilypond smart enough to figure out what is wrong, we should use that smartness for doing the right thing instead of educating the user. Hmm. You mean that a user should never need to specify the context of a grob, and lilypond should be able to automatically walk over all contexts to find the right one? This sounds useful. More like if a user specifies a context (whether explicitly, or implicitly by using the current one) not supporting a particular grob/property, then Lilypond will walk through the parents until finding one that does it. Or put differently: where a context does not support a particular grob/property on its own, it inherits the respective grobs from its parenting context. It's not possible in all cases -- consider trying to set the staff name to Violins for the staffgroup containing violin 1 and violin 2 -- but it could be done for most cases. The real question is whether it's worth doing for most cases, and whether the automatic method might increase confusion. The automatic method has the advantage that we can introduce layers of rather lightweight contexts without affecting existing semantics. Chords can be formed in a subcontext of their own, and manipulated accordingly. Subvoices can be used for tasks now done using multiple versions pasted over each other using transparency and disabling collision detection. I mean, ugh. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite { ... } \\ { ... } construct
Graham Percival gra...@percival-music.ca writes:
On Mon, Nov 08, 2010 at 01:26:41PM +0100, Xavier Scheuer wrote:
On 8 November 2010 13:05, Valentin Villenave valen...@villenave.net wrote:
Please repost your mail as a comment there, I think it will be more
appropriate, useful and (possibly) efficient :-)
Actually I'm sad when I see this issue is tagged Type-Enhancement
and Priority-Postponed.
From a user point of view it is really a HIGH annoyance issue, since
Then offer a bounty, or start investigating how to fix it
yourself.
Let me just point out that if ties are resolved at the voice level, and
\\ introduces subvoices/threads/whatever (presumably one level above
chord level which would be responsible for the stemming), then we
would not be losing our voice when entering a { \\ } construct.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1396 in lilypond: Enhancement: an option to turn unterminated ties into slurs
lilyp...@googlecode.com writes: Comment #2 on issue 1396 by v.villenave: Enhancement: an option to turn unterminated ties into slurs http://code.google.com/p/lilypond/issues/detail?id=1396 Well, one could make the opposite argument: what's the point in *not* treating a~b as a slur? (At least, from a lax user's point of view, as Johan mentioned in his first email.) (FTR: As I explained on the list, *I* am not convinced that this is needed at all. But some people, including David, seemingly agreed that it would be a nice feature to have.) Uh, David is so bad at expressing his opinions that you should be wary of rephrasing him. Basically, I objected to a) the availability of tiewaitfornote being an obstacle to making a~b behave as a slur b) having a~b produce a slur be standard behavior c) a mode where a~b both produces a slur as well as a warning That is, I analyzed in what manner a~b producing slurs could be made an option in Lilypond without producing a total mess. That does not mean that I consider it a good idea. But I can tolerate bad ideas if they are switched off by default. As long as they don't clutter the code all too badly. In this case, I have the feeling that they might. But without any prospective code, I can't judge that aspect. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Boris Shingarov b...@shingarov.com writes: My work on Lilypond development has been temporarily put on the back burner. Right now, we are concentrating on something slightly different: we are working to secure a very large Lilypond-based contract, for a major series of critical editions by a major publisher (I'm not allowed to divulge any details yet including who the publisher is, but I am sure everyone on this list is familiar with the name). IF we are successful, it will mean a radical breakthrough in acceptance for Lilypond. Some time ago, I was talking about how I wanted to transform Lilypond from a volunteer project with limited resources (Graham's definition), into a professional open-source project where at least some of the core people can afford to spend non-trivial amounts of time on their passion. I'll come back as soon as I have something to announce (either good or bad). Well, one nice thing with free software development is that you can't really announce something bad (except perhaps for your personal plans). If everything goes wrong with your endeavour, the project is not worse off than before. In commercial settings, stagnation often means death. With free software, stagnation mostly means stagnation. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1333 in lilypond: Enhancement: beamed acciaccaturas should be printed with a slash
lilyp...@googlecode.com writes: Comment #2 on issue 1333 by x.scheuer: Enhancement: beamed acciaccaturas should be printed with a slash http://code.google.com/p/lilypond/issues/detail?id=1333 Hi! I just wanted to make sure that slashed beamed acciaccaturas won't become the default behaviour. I hope this would require a \set slashedBeamedAcciaccatura = ##t % default is ##f or something like that to be activated. Why? There is no sense to use the same notation as an appoggiatura by default since both duration and onset of the two are different. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
Phil Holmes m...@philholmes.net writes: The PC is unusable when it's running - all the Ghostscript command line interfaces get in the way. Huh? If you see Ghostscript command line interfaces, you are calling the wrong version of Ghostscript, or using the wrong options. For X, there is some executable called gsnd or so (Ghostscript no display), but you should not really need it if the devices are already set on the command line. For Windows, something like gswin32c is needed (the c is important). -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.13.40 regtests
Phil Holmes m...@philholmes.net writes: David Kastrup d...@gnu.org wrote in message news:87y68dmy2e@lola.goethe.zz... Phil Holmes m...@philholmes.net writes: The PC is unusable when it's running - all the Ghostscript command line interfaces get in the way. Huh? If you see Ghostscript command line interfaces, you are calling the wrong version of Ghostscript, or using the wrong options. For X, there is some executable called gsnd or so (Ghostscript no display), but you should not really need it if the devices are already set on the command line. For Windows, something like gswin32c is needed (the c is important). It's not me that calls Ghostscript, it's LilyPond. Then it shouldn't. File a bug report and feel free to include the above hint. I don't have Windows available, so I can't make a proper report. I know that preview-latex had to do something like the above in order to drive Ghostscript as a hidden PostScript converter. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
\center-column sometimes appears not to reserve space.
Take a look at the following:
\markup { \concat { \center-column { Ooh ah }
\center-column { Ah oooh }
\center-column { Ooh ah }
} }
It would appear that the middle column has no horizontal size at all.
I think that's a regression in comparison to the last stable version.
inline: junk.preview.png
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \center-column sometimes appears not to reserve space.
David Kastrup d...@gnu.org writes:
Take a look at the following:
\markup { \concat { \center-column { Ooh ah }
\center-column { Ah oooh }
\center-column { Ooh ah }
} }
It would appear that the middle column has no horizontal size at all.
I think that's a regression in comparison to the last stable version.
Well, that's a mischaracterization. Comment out the middle column, and
you arrive at
inline: junk.preview.png
Which does not make all too much sense, except that the second Oh
apparently starts right in the center of the first one (or the first one
ends in the center of the second one).
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \center-column sometimes appears not to reserve space.
Reinhold Kainhofer reinh...@kainhofer.com writes:
Am Mittwoch, 15. Dezember 2010, um 15:43:42 schrieb David Kastrup:
Take a look at the following:
\markup { \concat { \center-column { Ooh ah }
\center-column { Ah oooh }
\center-column { Ooh ah }
} }
It would appear that the middle column has no horizontal size at all.
I think that's a regression in comparison to the last stable version.
No. The issue is rather that center-column has an alignment point at
the center, so the center of the column is placed where the left edge
should be. As a result, for each center-column, the left half
collides with the previous markups.
A long while ago, I created a patch, but that caused severe problems
with fret diagrams.
Would that be because the patch had problems, or because fret diagrams
rely on buggy behavior?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Your existing list of transposing instruments may not be complete.
Martine Zwerling mart...@theriver.com writes: Consider adding the GUITAR to you list of instruments transposing one octave lower than written. Nowadays usually indicated by using an ottava G clef (like that used nowadays for tenors). So for current music practice, it is written at pitch. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Phil Holmes m...@philholmes.net writes:
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef tenor c
}
Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting? Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.
Now to your comment:
It's doing what I would expect from reading the regtest - i.e. - when
there is a clef change, the accidentals are reset to that which you'd
expect from the key. Therefore, in your example we return to C major,
and so there's no need to print the accidental. I'd welcome other
thoughts as to whether this is correct, though.
I don't think it is correct. If you set the above with \key g\major,
you will notice that the key signature is _not_ repeated with a clef
change. So there is no visual or logical reason to assume accidentals
are reset. If that was the underlying assumption for a clef change,
the key signature would be repeated.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Phil Holmes m...@philholmes.net writes:
David Kastrup d...@gnu.org wrote in message
news:87ei92oxo3@lola.goethe.zz...
Phil Holmes m...@philholmes.net writes:
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef tenor c
}
Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting? Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.
Apologies. As you're probably aware, I'm a Windows man, and some
postings don't quote properly using my mailreader.
I am sure that there are sensible configurations available also for
Windows mailreasers.
As a result, If I want all the signs there, I have to put them in by
hand. In this case, I didn't bother.
You should at the very least delete the signature marker (-- on a
line of its own).
Now to your comment:
It's doing what I would expect from reading the regtest - i.e. - when
there is a clef change, the accidentals are reset to that which you'd
expect from the key. Therefore, in your example we return to C major,
and so there's no need to print the accidental. I'd welcome other
thoughts as to whether this is correct, though.
I don't think it is correct. If you set the above with \key g\major,
you will notice that the key signature is _not_ repeated with a clef
change. So there is no visual or logical reason to assume
accidentals are reset. If that was the underlying assumption for a
clef change, the key signature would be repeated.
So I'm confused as to what the regtest text cited means. It
(accidental-clef-change.ly) says Accidentals are reset for clef
changes.
Which is likely the intent. It is still not proper in my opinion. I
would suppose that a conservative approach would be to mark all
non-signature accidentals in force at the time of the clef change in a
manner that will cause a (sometimes cautionary) accidental to be printed
regardless of whether the next note on the previously
accidental-equipped is in-signature or not.
That's sort of a half-reset of accidentals: it sets all non-signature
accidentals basically to unknown.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Dienstag, 28. Dezember 2010, um 14:23:14 schrieb Phil Holmes: David Kastrup d...@gnu.org wrote in message I don't think it is correct. If you set the above with \key g\major, you will notice that the key signature is _not_ repeated with a clef change. So there is no visual or logical reason to assume accidentals are reset. If that was the underlying assumption for a clef change, the key signature would be repeated. So I'm confused as to what the regtest text cited means. It (accidental-clef-change.ly) says Accidentals are reset for clef changes. I would be great, though, if anyone can find a published example of such a situation (most likely in e.g. cello/bassoon parts/scores, which frequently switch between bass and tenor clef). Edition Peters, piano excerpt by Brissler from Mozart Requiem, Confutatis. The g in the corni di bassotto entry is not even in the same octave, and still gets a natural. confutatis.pdf Description: Adobe PDF document -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Accidental and clef change issue
Phil Holmes m...@philholmes.net writes: David Kastrup d...@gnu.org wrote in message news:87aajqowbn@lola.goethe.zz... Phil Holmes m...@philholmes.net writes: Apologies. As you're probably aware, I'm a Windows man, and some postings don't quote properly using my mailreader. I am sure that there are sensible configurations available also for Windows mailreasers. Hey - you're talking about M$ software here! (FWIW I use the same software for mail and news, - partly since the lilypond newsgroups are also mailing lists. I don't want to change). URL:http://oe-faq.de teaches German people how to stop annoying everybody else even while using OE or its successor Windows Mail. I should be surprised if similar advice would not be available for English-speaking people (anybody here on the list able to offer a similar link?). I don't understand how I get a crappy configuration shipped by factory and know it is supposed to imply It's ok if I don't bother changing it. If you like the software you get from Microsoft and want to stay with it, it is a one-time investment configuring it to behave sanely. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Oodles of bugs
Is there a prize for the maximum amount of errors in one measure of a
real-world piece? The following is the the next to last measure of the
two violins of The Air™, first typeset with the part engraver, then by
simple stacking.
So what do we get? The part combiner messes with the beaming in a
manner that does not look like an improvement (arguably by design), and
it starts off a spontaneous Solo on the last note from violin 1 that
is not quite called for since violin 2 is not yet finished.
We have ties crossing notes, and we have a beam crossing a notehead on a
flagged note. And that even though I am testing Mike's patch right now.
vi = \relative c'' { cis16 e g4 b,8 a e'16 fis32 g ~ g16 fis8 e16 }
vii = \relative c'' { g8 b e4 ~ e16 d cis b a8 b }
{ \key d\major
\partcombine \vi \vii |
\vi \\ \vii }
inline: bug.preview.png
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Oodles of bugs
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Samstag, 8. Januar 2011, um 22:25:51 schrieb David Kastrup: So what do we get? The part combiner messes with the beaming in a manner that does not look like an improvement (arguably by design), The problem with beaming is that the chord (cis e16) on the second 8th of the third beat is placed in a different voice than the previous eighth and the following 16th and 32th... The part-combiner uses three different voices: One for combined melodies (like a2, solo, solo 2 and chords), and two for separate melodies. As lilypond lacks any way for cross-voice beaming/slurin/tieing, there is no chance to get what you want without forcing the two voices to be apart for basically the whole measure Or making the partcombiner refrain from splitting beam structures. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Oodles of bugs
Reinhold Kainhofer reinh...@kainhofer.com writes: Am Samstag, 8. Januar 2011, um 23:30:21 schrieb David Kastrup: Reinhold Kainhofer reinh...@kainhofer.com writes: Am Samstag, 8. Januar 2011, um 22:25:51 schrieb David Kastrup: So what do we get? The part combiner messes with the beaming in a manner that does not look like an improvement (arguably by design), The problem with beaming is that the chord (cis e16) on the second 8th of the third beat is placed in a different voice than the previous eighth and the following 16th and 32th... The part-combiner uses three different voices: One for combined melodies (like a2, solo, solo 2 and chords), and two for separate melodies. As lilypond lacks any way for cross-voice beaming/slurin/tieing, there is no chance to get what you want without forcing the two voices to be apart for basically the whole measure Or making the partcombiner refrain from splitting beam structures. Actually, it's the other way round: the part-combiner has some code to prevent combining the voices if a manual beam, slur or tie (or even a hairpin) is active (and the ties/slurs of the two voices do not match exactly). So it should try keeping around uncombined voices in all cases, and have a separate engraver running after the autobeaming that checks whether the autobeamed version in the uncombined voices should take preference over the combined version. [Add more handwaving here] -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Oodles of bugs
Reinhold Kainhofer reinh...@kainhofer.com writes: Because the part-combiner does not check how long notes are... It just checks onsets of notes. That can't be the whole story since the spurious solo does not occur throughout when one voice is syncopated, just at its end. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
