8 8-> 8 } 4 } }
\score
{
\new Staff \relative c'
{
\time 6/8
\rhya c \rhyb c' |
\rhya \rhyb |
\rhyc \rhyc |
\time 5/4
\rhyd c
\rhyd e
\rhye
\time 4/4
\rhyf c \rhyf d
}
}
But it will be some time before that is available in a stable version of
LilyPond.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Likely both. We cannot really ignore problems that users will have. In
particular not when they are problems with our stock installations.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Pierre Perol-Schneider writes:
> 2014-02-15 20:14 GMT+01:00 David Kastrup :
>
>>
>> Fixing this seems tricky as measurePos no longer is advanced and cannot
>> serve as an indicator whether or not one has already bumped the bar
>> number. Ideas?
>>
>>
e(s).
Sounds like
Issue 2010: \lyricsto may turn into a voice-mangling zombie when both
parents die at the same time
http://code.google.com/p/lilypond/issues/detail?id=2010>
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
Simon Albrecht writes:
> Hello,
>
> attached you find one page of a mass setting by Palestrina. The
> vertical spacing is very uneven and seems irrational and I'm a bit at
> a loss with interpretation.
The run the the same file through with the -ddebug-skylines option
David Kastrup writes:
> Simon Albrecht writes:
>
>> Hello,
>>
>> attached you find one page of a mass setting by Palestrina. The
>> vertical spacing is very uneven and seems irrational and I'm a bit at
>> a loss with interpretation.
>
> The
uot;}\n" +
>> "\n" +
>> "\\layout {}\n" );
>>
>> I have no way of fixing this by myself... please help. :(
>>
>> Ciao,
>>
>> seba
>>
>>
> Any solution ?
Is it possible to get an example of what LilyPond is exactly called with
and what it is supposed to produce?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Pierre Perol-Schneider writes:
> 2014-03-11 13:39 GMT+01:00 David Kastrup :
>
> Is it possible to get an example of what LilyPond is exactly called with
>>
>
> => http://lsr.di.unimi.it/LSR/Browse
I meant, the command line it is getting called with. I have no idea
\markup \small { a b c d }
is the same as
\markup \line { \small a \small b \small c \small d }
which is different from
\markup \small \line { a b c d }
since the latter uses _small_ spaces while the former uses normal spaces
between small letters.
--
David Kastrup
__
Julien Rioux writes:
> On 11/01/2014 6:31 AM, Matthias Steup wrote:
>> Matthias Steup arcor.de> writes:
>>
>>>
>>> David Kastrup gnu.org> writes:
>>>
>>>>
>>>> Matthias Steup arcor.de> writes:
>>&
David Kastrup writes:
> Julien Rioux writes:
>
>> On 11/01/2014 6:31 AM, Matthias Steup wrote:
>>> Matthias Steup arcor.de> writes:
>>>
>>>>
>>>> David Kastrup gnu.org> writes:
>>>>
>>>>>
>>>>&g
Julien Rioux writes:
> On 16/03/2014 5:08 PM, David Kastrup wrote:
>> http://code.google.com/p/lilypond/issues/detail?id=3874>
>>
>> Marked as backport, tested satisfactorily, forgot to cherry-pick into
>> stable/2.18.
>>
>> Phil, hold the horses
rs at the stem end, not the notehead as Lily does it.
That music looks like it is entered in a bad order. In general, the top
voice should come first. Where it doesn't, you are dealing with an
inversion. In general, one should avoid flipping things like the slur
and the stems aroud in a temporary inversion in order not to make it
harder to figure out the voice leading.
If you are having a _permanent_ inversion, you should be thinking about
your voicing.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ew Staff { \clef bass \low } >>
Somewhat disingenuously, the last significant change to the
parallelMusic function is
commit 52c5b014116cc800bf0f1e787470fb7aa77f8f1a
Author: David Kastrup
Date: Thu Jan 17 17:15:28 2013 +0100
Let \parallelMusic deal with barchecks at arbitrary depth
ternatively, consult the documentation matching your version of
LilyPond.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> Oliver Sanftleben writes:
>
>> Hello,
>>
>> In LM 2.1.7 (german section: Andere rhythmische Aufteilungen), the
>> example is not working.
>>
>> I think"\tuplet 3/2" should be replaced by"\times 2/3"
but this is not true by default for
> fingerings and string numbers applied to the individual notes of chords."
>>
>> I'm thinking this is what you're seeing?
>>
>
> Yes, even if my example is not a chord but polyphony.
is a chord. g-2 is an individual note. fingeringOrientations
will only apply to notes in a chord.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ew lesser changes in that area, so it would not be amiss
to double-check. Don't have a copy of 2.18 on my computer currently,
and I won't put one there while bisecting.
So if anybody wants to check out the 2.18 situation, feel free to do so.
David Kastrup writes:
> Nicolas Sceaux writes:
>
>> With lilypond 2.19.3, applying a music function to a bass figure
>> causes a syntax error. At least until 2.17.24 (I have not tested
>> later versions), that was not the case.
>
> 2.19.0 is ok,
I have to tak
David Kastrup writes:
> David Kastrup writes:
>
>> Nicolas Sceaux writes:
>>
>>> With lilypond 2.19.3, applying a music function to a bass figure
>>> causes a syntax error. At least until 2.17.24 (I have not tested
>>> later versions), that was no
Nicolas Sceaux writes:
> Hi,
>
> With lilypond 2.19.3, applying a music function to a bass figure
> causes a syntax error. At least until 2.17.24 (I have not tested
> later versions), that was not the case.
http://code.google.com/p/lilypond/issues/detail?id=3898>
bStaff { \clef "moderntab" \music }
>>
}
Of course, this does not work either, but that appears to be solely the
responsibility of "Feta" being the wrong font name as well. Also
\deadNote will no longer work on an entire chord as it tweaks
exclusively in this implementation. You have to use \once\deadNotesOn
instead then.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
o use the correct filename and line number.
Yes, that's what one wants for debugging.
There is a somewhat funny way to change this behavior: just use an
argument name different from "location" for the location argument, and
#{...#} will not be able to pick it up for passing it to
tion signs wrong
here.
In short: it's not a feature, it's a bug.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ion/notation/context-layout-order#index-alignAboveContext>
explains this reasonably well.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
; \new Staff = "upper" \upper
> \new Staff = "lower" \lower
> >>
> }
Why? The above looks quite legitimate to me.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Yes, that's plausible, but your above reasoning about << >> remains
incorrect.
Things are more readable if you revert to << >> only when you indeed
want parallel voices rather than just multiple notes in a chord. But
they are valid nevertheless.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
;s expected. I could pick out
the respective manual passage, but then the weather makes me lazy.
> Both the expected ties were there, though, one on each staff.
Sure, because now you had the ties in different voices, even different
staves.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
you again you'll consider coming
back.
To the other bugsquad members: What is our current bug scooping schedule
like in consequence? Should we try recruiting replacements?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
he last year or so, as
> well. Thanks for the time and effort you have given us!
Hear, hear here too.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
James writes:
> On 02/06/14 17:38, David Kastrup wrote:
>> Yes, that's plausible, but your above reasoning about << >> remains
>> incorrect.
>>
>> Things are more readable if you revert to << >> only when you indeed
>> want parallel v
no
fixed durations and much more complex noteheads) but rather the kind of
chant approximation used in some hymnals.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht writes:
> Am 26.06.2014 13:33, schrieb David Kastrup:
>> And he's right with that as well... Have you actually tried it?
>>
> My mistake again. Sorry for being pert and not checking first. I
> wasn’t aware that your parser improvements had gone so far…
Janek Warchoł writes:
> 2014-07-08 8:11 GMT+02:00 David Kastrup :
>>
>> which has the side effect of working fine in \relative mode without the
>> need to employ make-relative. You don't want spaces to have an effect
>> here. It's not clear what th
r line
> break inbetween.
> I don’t see any problem in that with normal input, whereas in other
> cases like music functions the space might be necessary.
> What do you think?
We don't want space to be significant between separate syntactical
entities. Particularly not for
James writes:
> On 13/07/14 11:49, David Kastrup wrote:
>> Helge Kruse writes:
>>
>>> Am 13.07.2014 11:57, schrieb David Kastrup:
>>>
>>>> 4q
>>>> Well, just write the latter version.
>>> Well. this means "d
ard figuring out the proper semantics, we are leaving
the shorthand realm.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
in any style which detects immediate repetition.
So what about
{ { fis'8 r8 r4 r4 r8 fis'8 } \\ { r8 cis'8 f' r2 } } ?
Should neo-modern-voice really consider the second fis'8 a repetition of
the first one? I think that's stretching it. A lot.
--
David Kastrup
right?
>
> If so, indeed a second report. For this one, the qualification
> of bug is even more disputable. If MIDI has a way to encode
> clef information, then it's a bug.
I don't think Midi can encode clefs.
--
David Kastrup
_
Francisco Vila writes:
> El 19/07/2014 15:58, "Jan Nieuwenhuizen" escribió:
>>
>> If MIDI has a way to encode
>> clef information, then it's a bug.
>>
>
> Yes it has.
Sure? I know there is a message for encoding the
ein Notensatzprogramm, das es sich zum Ziel gemacht hat,
> Notendruck in bestmöglicher Qualität zu erstellen."
Stylistically the anthropomorphism is a groaner.
"Ziel des Notensatzprogramms LilyPond ist Notendruck in bestmöglicher
Qualität".
I am not totally
; {
>> \key g \major
>> f1~ \break
>> | f2 f2
>> }
>> The natural here appears two times in the second bar.
>>
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/l
sing separate bug reports for separate issues might be preferable.
Usually the bug squad can sort this out by filing separate issues based
on the same posting, but
a) it becomes easier to overlook one of the issues
b) if there is a followup discussion, it's harder to figure out what
issue it belongs to.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ned mandolin fretboards are loaded, so _if_ you selected a
mandolin tuning in some manner, they might get used. But something like
#mandolin-tuning
in the middle of nowhere will not get this selected.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
com/p/lilypond/issues/detail?id=3978> here.
I'll see what bisection does.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
David Kastrup writes:
> David Nalesnik writes:
>
>> On Mon, Jul 28, 2014 at 9:25 AM, Noeck wrote:
>>
>>> Your snippet produces a different output here with 2.19.8
>>> (i.e. more like what I would expect)
>>>
>>>
>> Yup--an
David Kastrup writes:
> David Kastrup writes:
>
>> David Nalesnik writes:
>>
>>> On Mon, Jul 28, 2014 at 9:25 AM, Noeck wrote:
>>>
>>>> Your snippet produces a different output here with 2.19.8
>>>> (i.e. more like what I would
no
longer fit either.
This is a mechanism that has been _advertised_ for tweaking the
positioning. It _still_ is advertised in that manner.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
ping at all) also works.
>> Is this a bug, or a feature i don't understand?
\new Voice ... implicitly creates a Staff, and \new Foo ... implicitly
creates a StaffGroup.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Jean-Charles Malahieude writes:
> One remaining occurrence of \times in texidoc:
>
> - the denominator of the argument to the @code{\\times} command.
> + the denominator of the argument to the @code{\\tuplet} command.
Wouldn't that also have to change "denominator" i
l in mid-piece work via a finalization hookThat
allows all other processing to complete before measurePosition is
adjusted. In particular, this avoids problems when multiple
parallel contexts invoke \partial and/or bar checks. Also
contains commit: Regtest for \p
David's new
> patch?
Pretty irrelevant after the patch.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
on and practice is from a different note language,
I cannot really say much about the motivation of that approach. In my
country one would never call a "cis" just "c" when talking about music,
not even informally (but then nobody wants to get caught being informal
gt; \midi{}
> }
I am not convinced. The Midi instruments together with the "instrument"
names and clefs suggest that we are talking about a bass and a tenor
voice here, with the tenor using an unmodified G clef, consequently
sounding one octave lower than actually written.
While one does not need a tenor for singing a C3, it is definitely not
unusually low.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
say anything about informal usage.
>
> The original question here was about calling, in the key of D major,
> the note c-natural by the name "c-natural".
So far the proposal was about "cn" only, not "cnatural". What would be
up with the latter?
--
David Kastr
;> notated as "cn"--if I'm understanding you correctly--doesn't make
>> sense.
>>
>> —David
>
> OK, but my general point is the same. If “x” and “xn” are not
> intended to be used interchangeably, involving the comput
\stopStaff s } }
>>
\key a\major
c4 b c2
}
However, it affects spacing somewhat curiously if you compare with the
original.
Maybe one should replace \magnifyStaff and check whether the artifacts
in either version have a longer history or not.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
-event)) >
> (independent of OS – of course, I should say)
I don't think we take responsibility for things going haywire in Scheme.
Instead of (markup ...) try using #{ \markup ... #} and you will likely
get more LilyPondish error messages.
--
David Kastrup
Simon Albrecht writes:
> Am 31.08.2014 um 14:42 schrieb David Kastrup:
>> Simon Albrecht writes:
>>
>>> Hello,
>>>
>>> yesterday I tried out make-dynamic-script and in my first attempt
>>> forgot some "":
>>> pDolce = #(make
ly the reason the second example is no longer present in
<http://lilypond.org/doc/v2.19/Documentation/usage/common-errors#an-extra-staff-appears>
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Simon Albrecht writes:
> Am 31.08.2014 um 15:14 schrieb David Kastrup:
>> Simon Albrecht writes:
>>
>>> Hello,
>>>
>>> in the following section
>>> <http://lilypond.org/doc/v2.18/Documentation/usage/common-errors#an-extra-staff-appears>
&
michel77 writes:
> Bill Monroe was one of the best mandolin players [...]
But apparently nowadays keyword spammers are fattening themselves on his
laurels. So make sure not to buy any "new" or "remastered" records.
--
David Kastrup
text
The original code from David Bellows does work after applying this
patch.
One will have to see how the patch fares with testing since it activates
functionality that was supposed to be present but never actually was.
--
David Kastrup
___
bug-lilypon
John Szwast writes:
Newsgroups: gmane.comp.gnu.lilypond.bugs
Subject: Re: lilypond-book fails when using Latex macros in options
Organization: Organization?!?
From: David Kastrup
Gcc: nnfolder+archive:sent.2014-09
--text follows this line--
John Szwast writes:
> I want to specify a lilyp
lations. My guess would be
that the whole articulation mechanism might be changed in a manner that
partcombine no longer is able to consider two articulations as
mergeable. In that case, it would likely be more than just breathings
which are affected.
--
David Kastrup
_
}
I'm not convinced enough of that to recommend it in snippet/manual
though. Behavior of \partial changed quite a bit over the last
versions. Frankly, that code seems weird anyway...
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Dan Eble writes:
> David Kastrup gnu.org> writes:
>
> Thank you. Your suggestion also has the advantage of printing a parenthesized
> bar number at the mid-measure line break. Setting measurePosition to zero
> printed a regular bar number, which I didn't notice at first
until the old time
signature happens to complete a bar".
I think that's far too strange to use as a default behavior without
warning.
Why wouldn't you print the time signature change at the end of the bar?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tue May 14 21:53:25 2013 -0700
Beams: be transparent if the first stem is transparent; issue 2866
so that \hideNotes does not hide automatic beams that could have,
but did not, start on a hidden note.
though I provided an initial version of the patch.
--
David Kastru
Torbjörn Björkman writes:
> 2014-09-14 18:34 GMT+03:00 David Kastrup :
>> TorbjörnBjörkman writes:
>>
>> > I try to hide the first stem in a beam group and expect this to keep the
>> > beam, just as happens if you hide any other stem in the group. Howev
dge
(rather than its middle) is at the center of the line because the space
between start and center of the line went missing.
Quite hard to track down, caused in an obscure place in C. Well, seems
like the warning for temporary regressions will apply to 2.19.14, with
the fix only arriving in 2.19.1
alignAboveContext = #"main"
>> \magnifyStaff #2/3
>> firstClef = ##f
>> }
>> { e4 d f e \grace { \stopStaff s } }
>> >>
>> \time 3/4
>> c4 b c
>> }
>>
> So this is no longer a 'bug'?
I think it
a larger variety of compilers and crosscompiling environments
(the cross-compiled build results are not actually tested before
distribution, but the overall track record for them tends to be quite
consistent).
--
David Kastrup
___
bug-lilypond mai
mmenting \pageBreak, adding an explicit pitch to 1~ or adding
> an explicitly pitched note *after* the \pageBreak result in no
> barcheck warnings and correct output.
> Adding an explicitly pitched note *before* the \pageBreak still gives
> the barcheck warning and wrong output.
Yup.
--
Urs Liska writes:
> Am 24.09.2014 22:11, schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Original-Nachricht
>>> Betreff:Isolated durations and \pageBreak
>>> Datum: Wed, 24 Sep 2014 19:50:33 +0200
>>> Von:D
u'd need to redo all of the horizontal spacing after stuff
like \RemoveEmptyStaves have run without changing the line breaking
again if you find out that this gives you more space to work with.
Unlikely to happen in the next few years of LilyPond development.
--
David Kastrup
__
Peter Crighton writes:
> 2014-10-05 11:15 GMT+02:00 David Kastrup :
>
>> Simon Albrecht writes:
>>
>> > Am 04.10.2014 um 23:13 schrieb Peter Crighton:
>> >> As you can see in the following code and the attached image, there
>> >> is a possib
at producing, say,
keyboard and accordion chords from the same input.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
umentation
> completely and then start? I would come back to the mailing list
> (lilypond-devel?) in case of questions. What do you think?
There is a special list for translators (also mentioned in the CG). For
technical questions particular to the translation process, it might make
mor
Federico Bruni writes:
> 2014-10-14 10:14 GMT+02:00 Phil Holmes :
>
>> It's down to me forgetting, I'm afraid.
>>
>
> Phil, what if the release announcements were made automatic through git
> hooks?
Not every announcement
benutzt werden kann, um schönen Notensatz zu erstellen.
+Dieser Artikel behandelt die Hintergründe zu LilyPonds Entstehung
+und die für seine hohe Notensatzqualität verantwortlichen
+Methoden.
So it would appear that I decided to run out of steam on that task very
early...
--
David Kastrup
_
s a small example
> http://lilybin.com/0ntmpy/1
I don't see a reasonable way to extract the code from this view.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Anyway, for the purposes of the bug list, you should formulate your
> demonstration as a very short inline code snippet.
That would be very much preferable from having to scrape some large
piece of code off an HTML page where it is embedded as some JavaScript
string inside of JavaScript code
Eugene Cormier writes:
> David Kastrup gnu.org> writes:
>
>> > Anyway, for the purposes of the bug list, you should formulate your
>> > demonstration as a very short inline code snippet.
>>
>> That would be very much preferable from having to scrape some
nd quite a while now: updating to it makes
good sense. Particularly if you want to use its documentation...
Arguably, the new syntax is simpler to use. It has also made it
possible to let user-defined music functions accept such property
paths. So even while the old override syntax still
Dan Eble writes:
>> I'm not top posting.
>
> \version "2.19.0"
> <<
> \time 9/1 f'1
>>>
Probably an artifact of LilyPond's own "Rational" implementation's
limited precision. At some poi
1
>>}
>> }
>>
>>
>
> Compiled without problem on a build from current master (Debian Linux)
You are both omitting the most relevant detail: 32bit or 64bit system?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
bably need some minimal snapping after all. Or the snapping is
triggered by the transposition, but I don't think that would be a good
idea since transpose can work even inside of chords and overrides don't
belong there. Or we need at least one manually settable property that
will cause snapping.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Devon Schudy writes:
> David Kastrup wrote:
>> My guess would be that the whole articulation mechanism might be
>> changed in a manner that partcombine no longer is able to consider two
>> articulations as mergeable. In that case, it would likely be more than
>>
David Kastrup writes:
> Thomas Morley writes:
>>
>> seems \parallelMusic can't deal anymore with music stored in a
>> variable or created by a function.
[...]
>> Also, this affects your function from
>> http://chemnitzer.linux-tage.de/2012/vortraege/900
&
or spacing
changes, but I think we don't want to wait for a "proper fix/rewrite" to
go through the complete pipeline for getting this back to normal.
It is strange that such a problem should have made it through regtests
unnoticed.
--
David Kastrup
David Kastrup writes:
> Urs Liska writes:
>
>> With a build from current master (151120c3240601fd29bbb20a315decbde681fcdb)
>>
>> compiling
>>
>> \version "2.19.16"
>>
>> {
>> c'1
>> }
>>
>> results in the a
it f299c35871038f6d0c959935dcf5f81e29372b86
Author: David Kastrup
Date: Mon Oct 24 16:03:00 2011 +0200
Improve 671b7b6... Creates convert-ly rules to destencil Flags
touching the same rules, but it only polishes the whitespace inserted
for the additional lines.
Basically the rule here is that
he } Ma -- trix? }
>>>
>
> Any objection ?
Any idea what goes wrong there?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
{ c4 c4 c8 c8 c8 }
> \context Lyrics \lyricmode {
> what4 is \shapeSC The8 \shapeNorm Ma -- trix?
> }
> >>
> \layout { raggedright = ##t }
> }
Maybe one needs a different basic font that has a small caps variant?
--
David Kastrup
_
Pierre Perol-Schneider writes:
> 2014-11-30 16:06 GMT+01:00 David Kastrup :
>> Pierre Perol-Schneider writes:
>>
>> > BTW: Original code was
>> >
>> > \version "2.14.2"
>> >
>> > shapeSC = \override LyricText #'font-sha
ime sigs:
Issue 34. I don't even need to look it up any more. Probably the
most-reported problem on the bug list. It's one of the really hard ones
deeply intertwined with the bowels and working principles of LilyPond.
--
David Kastrup
_
commend that you work on the English translation before trying the
Italian one as the English version is used as the master for most other
translation and improving stuff there is going to help all translators.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
r of some spurious rules doing too much but actually
affects the output. Better to just revert the problematic commit.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
archive/html/lilypond-devel/2011-11/msg00559.html>
There was no attempt of even making a tracker issue that time as far as
I can tell, it was strictly a sweep-under-the-rug approach.
I consider it reasonable to reduce a regtest to trigger the issue it is
intended for, bu
401 - 500 of 1554 matches
Mail list logo
