Hi Squad,
From the french list:
http://lilypond-french-users.1298960.n2.nabble.com/code-d-arret-1073741819-en-compilation-lilypond-td7587949.html
From the english list:
http://lilypond.1069038.n5.nabble.com/Error-message-td222543.html#none
http://lilypond.1069038.n5.nabble.com/ERROR-In-procedure-ly
Hello,
On Tue, 25 Jul 2017 10:10:44 +0200
Pierre Perol-Schneider wrote:
> I just found the correct way.
Well David did say that 'It bears repeating ...' so I wondered if we
need a doc enhancement perhaps or some warning in the doc in either
\stemDown or 'voices' or something?
If so, then let m
Pierre Perol-Schneider writes:
> Hi Bug Squad,
>
> Grace note stem direction seems to stay in the upper position:
>
> %%% snippet %%%
> \version "2.19.64"
>
> \relative c'' {
> c4 \stemDown \grace d8 c4 c
> }
> %%% end %%%
It bears repeat
I just found the correct way.
Sorry for the noise.
Cheers,
Pierre
2017-07-25 10:04 GMT+02:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:
> Hi Bug Squad,
>
> Grace note stem direction seems to stay in the upper position:
>
> %%% snippet %%%
> \version &
Hi Bug Squad,
Grace note stem direction seems to stay in the upper position:
%%% snippet %%%
\version "2.19.64"
\relative c'' {
c4 \stemDown \grace d8 c4 c
}
%%% end %%%
Cheers,
Pierre
___
bug-lilypond mailing list
bug-li
Simon Albrecht writes:
> Sorry, sent by accident…
>
> On 11.12.2015 23:56, Simon Albrecht wrote:
>> Hello,
>>
>> do you agree that in this example the stems should go up? The
>> majority of note heads sits in the lower half of the staff.
>
> \version "2.19.32"
> {
> 8[ f']
> }
>
Uhm, no? This
Sorry, sent by accident…
On 11.12.2015 23:56, Simon Albrecht wrote:
Hello,
do you agree that in this example the stems should go up? The majority
of note heads sits in the lower half of the staff.
\version "2.19.32"
{
8[ f']
}
Yours, Simon
___
b
Hello,
do you agree that in this example the stems should go up? The majority
of note heads sits in the lower half of the staff.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
On 12/11/2013 01:23 PM, Richard R. Gress wrote:
I'm not top posting.
An example of this behavior:
-
\version "2.16.2"
\relative c'' { a2 b }
-
The B should also have an upwards stem. The default is that the stem is
always down ({ c2 b } results in correct behavi
> I'm not top posting.
An example of this behavior:
-
\version "2.16.2"
\relative c'' { a2 b }
-
The B should also have an upwards stem. The default is that the stem is
always down ({ c2 b } results in correct behavior).
Per Starbäck starback.se> writes:
> but somewhat more strictly my suggestion is to first
> treat ties as beams when determining stem orientation, so no big new
> backtrack for global optimum feature.
>
> Can anyone think of an example where that would give worse results?
OK, I thought of one my
Phil Holmes philholmes.net> writes:
> Elaine Gould, in "Behind Bars" has many examples of where the stems of tied
> notes do not have the same direction, so typographically we should accept
> that it's not standard notation.
Interesting! Not having access to that book, I would be much interest
a trivial command.
Well, the art of typography is not to distract from the content. As
beamed notes (and multi-voice notations) show, people don't really rely
on a fixed relation between stem direction and pitch for reading music.
On the one hand, this means that the stem direction sw
"Per Starbäck" wrote in message
news:loom.20130926t125343-...@post.gmane.org...
I wrote:
With
\version "2.16.2"
\relative c'' {
b~ b8 a b4~ b8 c
a8 b~ b4 c8 b~ b4
}
the stems of every b goes downwards. I think it would be better if tied
notes had the same direction, to make it clearer vi
I wrote:
>> With
>>
>> \version "2.16.2"
>>
>> \relative c'' {
>> b~ b8 a b4~ b8 c
>> a8 b~ b4 c8 b~ b4
>> }
>>
>> the stems of every b goes downwards. I think it would be better if tied
>> notes had the same direction, to make it clearer visually that they belong
>> together. Then two of these
"Per Starbäck" wrote in message
news:loom.20130926t094806-...@post.gmane.org...
With
\version "2.16.2"
\relative c'' {
b~ b8 a b4~ b8 c
a8 b~ b4 c8 b~ b4
}
the stems of every b goes downwards. I think it would be better if tied
notes had the same direction, to make it clearer visually that
Per Starbäck writes:
> With
>
> \version "2.16.2"
>
> \relative c'' {
> b~ b8 a b4~ b8 c
> a8 b~ b4 c8 b~ b4
> }
>
> the stems of every b goes downwards. I think it would be better if tied
> notes had the same direction, to make it clearer visually that they belong
> together. Then two of the
With
\version "2.16.2"
\relative c'' {
b~ b8 a b4~ b8 c
a8 b~ b4 c8 b~ b4
}
the stems of every b goes downwards. I think it would be better if tied
notes had the same direction, to make it clearer visually that they belong
together. Then two of these stems should go up instead.
With beams i
Eluze writes:
> Colin Hall-3 wrote
>> Colin Hall writes:
>>
>>> Eluze writes:
>>>
>>>> with
>>>>
>>>> \relative {
>>>> \voiceOne
>>>> \grace a'8
>>>> c4 c c c
>>>>
Colin Hall-3 wrote
> Colin Hall writes:
>
>> Eluze writes:
>>
>>> with
>>>
>>> \relative {
>>> \voiceOne
>>> \grace a'8
>>> c4 c c c
>>> }
>>>
>>> the stem direction of the following not
Colin Hall writes:
> Eluze writes:
>
>> with
>>
>> \relative {
>> \voiceOne
>> \grace a'8
>> c4 c c c
>> }
>>
>> the stem direction of the following notes is wrong
>>
>> this doesn't happen if the grace is no
On Feb 13, 2013, at 2:17 AM, Colin Hall wrote:
>
> Eluze writes:
>
>> with
>>
>> \relative {
>> \voiceOne
>> \grace a'8
>> c4 c c c
>> }
>>
>> the stem direction of the following notes is wrong
>>
>> thi
Eluze writes:
> with
>
> \relative {
> \voiceOne
> \grace a'8
> c4 c c c
> }
>
> the stem direction of the following notes is wrong
>
> this doesn't happen if the grace is not the first note or by repeating
> \voiceOne after the grace.
&g
with
\relative {
\voiceOne
\grace a'8
c4 c c c
}
the stem direction of the following notes is wrong
this doesn't happen if the grace is not the first note or by repeating
\voiceOne after the grace.
I didn't find an exactly matching bug report
Eluze
--
View this mes
Eluze gmail.com> writes:
>
> I don't understand why they should - aren't you overriding the default stem
> direction for just one note??
>
Oops. Good point. Guess I jumped the gun a little submitting that here...
DR
___
ing that. %}
>
> \version "2.16.1"
> {
> \override Beam #'auto-knee-gap = #30
> \once \stemDown
> f''8[ d']
> \stemDown
> f''8[ d']
> }
I don't understand why they should - aren't you overriding the default ste
> I'm not top posting.
%{ In the example below, the two pairs of beamed eighth notes should appear
identical due to the \override command; however, it appears that the \once
command preceding the \stemDown for the first pair is preventing that. %}
\version "2.16.1"
{
\override Beam #'auto-knee-
noteworthy: not only the stem across the staves is not drawn, but the note
duration is also changed (or is it only the flag which gets cut away?)
Eluze
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/crossStaff-breaks-if-stem-direction-changes-tp137717p137795.html
Sent
"Thomas Morley" wrote in message
news:CABsfGyWjDQvLcv731XZw+wX_JWb+x3kZU5DTe=obwjs8j-o...@mail.gmail.com...
Hi,
a simple
\transpose c c'
(with changing stem-direction)
can break \crossStaff without printing a warning or error.
%%% example
\version "2.16.1&q
Hi,
a simple
\transpose c c'
(with changing stem-direction)
can break \crossStaff without printing a warning or error.
%%% example
\version "2.16.1"
\layout {
\context {
\PianoStaff
\consists #Span_stem_engraver
}
}
mI =
\new PianoStaff <<
\new S
2012/5/31 Marek Klein
> Hello,
>
> 2012/5/31 Torbjörn Björkman
>
>> When I let a voice cross over to the another staff I suddenly can't
>> specify
>> the
>> stem direction iff there are multiple voices in the staff I cross over to.
>> Trying to s
Hello,
2012/5/31 Torbjörn Björkman
> When I let a voice cross over to the another staff I suddenly can't specify
> the
> stem direction iff there are multiple voices in the staff I cross over to.
> Trying to set \voiceOne has the same lack of effect.
> I don't know if
Hello list,
When I let a voice cross over to the another staff I suddenly can't specify
the
stem direction iff there are multiple voices in the staff I cross over to.
Trying to set \voiceOne has the same lack of effect.
I don't know if this is a bug or if there is some subtlety with the
Updates:
Status: Invalid
Owner: d...@gnu.org
Comment #3 on issue 1912 by d...@gnu.org: Horizontal spacing depends on
stem 'direction
http://code.google.com/p/lilypond/issues/detail?id=1912
Closed in line with comment #2. May be reopened if evidence is brought
forward
2011/9/22 Reinhold Kainhofer :
> Am Donnerstag, 22. September 2011, 12:55:47 schrieb Janek Warchoł:
>> 2011/9/22 David Kastrup :
>> > I see James already added the message. I don't always figure out what
>> > kind of reply ends up in the tracker automatically (probably just those
>> > sent directl
Am Donnerstag, 22. September 2011, 12:55:47 schrieb Janek Warchoł:
> 2011/9/22 David Kastrup :
> > I see James already added the message. I don't always figure out what
> > kind of reply ends up in the tracker automatically (probably just those
> > sent directly by Rietveld's tracker) and what not
Updates:
Labels: Needs-evidence
Comment #2 on issue 1912 by d...@gnu.org: Horizontal spacing depends on
stem 'direction
http://code.google.com/p/lilypond/issues/detail?id=1912
Ok, so the question we should be asking is not why Lilypond makes a
different decision based on minu
lypond
>>> Essay), of _course_ its spacing depends on the stem direction. And of
>>> _course_ this implies that there will be a small borderline where page
>>> break decisions _also_ differ depending on the stem direction.
>>>
>>> A human engraver wil
"Dmytro O. Redchuk" writes:
> On Thu 22 Sep 2011, 09:40 David Kastrup wrote:
>> In my opinion, this report is invalid. Since Lilypond does optical
>> justification of noteheads (cf node "Optical Spacing" in the Lilypond
>> Essay), of _course_ its spaci
On Thu 22 Sep 2011, 09:40 David Kastrup wrote:
> In my opinion, this report is invalid. Since Lilypond does optical
> justification of noteheads (cf node "Optical Spacing" in the Lilypond
> Essay), of _course_ its spacing depends on the stem direction. And of
> _course_ t
Comment #1 on issue 1912 by pkx1...@gmail.com: Horizontal spacing depends
on stem 'direction
http://code.google.com/p/lilypond/issues/detail?id=1912
In my opinion, this report is invalid. Since Lilypond does optical
justification of noteheads (cf node "Optical Spacing" in the
"Dmytro O. Redchuk" writes:
> On Thu 08 Sep 2011, 23:57 Trevor Daniels wrote:
>> I'd class this as an engraving nitpick, but we don't have that
>> classification anymore.
>>
>> It seems the horizontal spacing is slightly dependent on th
On Thu 22 Sep 2011, 09:30 m...@apollinemike.com wrote:
> Is this a regression?
2.12.3 engraves the same output.
> If so, do you know what the last version was that made the two lines equal?
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad
On Sep 22, 2011, at 9:25 AM, lilyp...@googlecode.com wrote:
> Status: Accepted
> Owner:
> Labels: Type-Ugly
>
> New issue 1912 by brownian.box: Horizontal spacing depends on stem 'direction
> http://code.google.com/p/lilypond/issues/detail?id=1912
>
> Repor
On Thu 08 Sep 2011, 23:57 Trevor Daniels wrote:
> I'd class this as an engraving nitpick, but we don't have that
> classification anymore.
>
> It seems the horizontal spacing is slightly dependent on the stem
> direction. This can cause a score to mysteriously spread ov
Status: Accepted
Owner:
Labels: Type-Ugly
New issue 1912 by brownian.box: Horizontal spacing depends on
stem 'direction
http://code.google.com/p/lilypond/issues/detail?id=1912
Reported by Trevor Daniels,
http://lists.gnu.org/archive/html/bug-lilypond/2011-09/msg00233
ed enough about this to investigate
it further. It arose out of my investigations of Mike's
5917046 patch (which _is_ affected by the stem direction)
and threw me off the scent for quite a while. If no one
else is bothered let's just leave it.
Also strangely, no optical correction is
On Fri, 09 Sep 2011 01:34:30 -0700, Trevor Daniels
wrote:
The values of
'stem-spacing-correction in NoteSpacing and StaffSpacing
affect the spacing between the bar lines and the first
and last notes respectively, and the values and mechanisms
are different. I guess we need to understand why
Janek Warchoł wrote Friday, September 09, 2011 7:20 AM
2011/9/9 Keith OHara :
Trevor Daniels treda.co.uk> writes:
It seems the horizontal spacing is slightly dependent on the
stem
direction.
This spacing was intentional, including the spacing adjustment
between stems and bar li
2011/9/9 Keith OHara :
> Trevor Daniels treda.co.uk> writes:
>
>> It seems the horizontal spacing is slightly dependent on the stem
>> direction.
>
> This spacing was intentional, including the spacing adjustment
> between stems and bar lines :
> <http://lilypo
Trevor Daniels treda.co.uk> writes:
> It seems the horizontal spacing is slightly dependent on the stem
> direction.
This spacing was intentional, including the spacing adjustment
between stems and bar lines :
<http://lilypond.org/doc/v2.14/Documentation/essay/engraving-det
On Thu, Sep 08, 2011 at 11:57:54PM +0100, Trevor Daniels wrote:
> I'd class this as an engraving nitpick, but we don't have that
> classification anymore.
Type-Ugly.
Cheers,
- Graham
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.
I'd class this as an engraving nitpick, but we don't have that
classification anymore.
It seems the horizontal spacing is slightly dependent on the stem
direction. This can cause a score to mysteriously spread over an
extra system when a single note with stem down is changed to
uot;2.2.6"
> \include "english.ly"
> \paper{papersize = "letter"} %\layout{papersize=letter}
>
> cnotesDue = {
> \notes {
> \skip 1*7 \stemDown
> s2 c c s2
> \bar "|."}}
>
> cnotesUno = {
> \notes {\relative c {
> c4 d8 e f g a b
&
On Sunday 28 August 2005 13.37, Sven Axelsson wrote:
> Lilypond 2.7.7 Windows
>
> If the first note in the music is a grace note, a stem direction override
> will turn the grace note and not affect the normal notes. This is wrong
> since the grace notes should only be affected by
Lilypond 2.7.7 Windows
If the first note in the music is a grace note, a stem direction override
will turn the grace note and not affect the normal notes. This is wrong
since the grace notes should only be affected by using add-grace-property,
not by normal overrides.
If the override is instead
ls consequently typeset that piece of music
as stemDown, then there is in some sense a difference between lily's
behaviour and professional behaviour.
I suppose the most useful thing is to add a bunch of examples where stem
direction is incorrectly chosen, as some kind of regression test.
mise the maximal stem
> length, which may be considered good). My standpoint is not very solid
> though, if you have good arguments I might change my mind.
Not my problem.
> btw: Since a few days, there is a known clear case of incorrect stem
> direction, see beam-direction.ly in bug cvs
idered better than down stem (this might minimise the maximal stem
length, which may be considered good). My standpoint is not very solid
though, if you have good arguments I might change my mind.
btw: Since a few days, there is a known clear case of incorrect stem
direction, see beam-direction.ly
c.ly
\version "2.2.6"
\include "english.ly"
\paper{papersize = "letter"} %\layout{papersize=letter}
cnotesDue = {
\notes {
\skip 1*7 \stemDown
s2 c c s2
\bar "|."}}
cnotesUno = {
\notes {\relative c {
c4 d8 e f g a b
c e, f g a b c d
%\stemDown <-- wrong
c.ly
\version "2.2.6"
\include "english.ly"
\paper{papersize = "letter"} %\layout{papersize=letter}
cnotesDue = {
\notes {
\skip 1*7 \stemDown
s2 c c s2
\bar "|."}}
cnotesUno = {
\notes {\relative c {
c4 d8 e f g a b
c e, f g a b c d
%\stemDown <-- wrong
[EMAIL PROTECTED] writes:
> Thanks, that's much better. Except that the crescendo gets
> completely squashed in
>
> \score {
>
> \notes\relative c'' {
> \property Score.DynamicText \set #'no-spacing-rods = ##f
> \property Score.DynamicText \set #'X-extent = #'(-10 . 20)
> e_\p
Thanks, that's much better. Except that the crescendo gets
completely squashed in
\score {
\notes\relative c'' {
\property Score.DynamicText \set #'no-spacing-rods = ##f
\property Score.DynamicText \set #'X-extent = #'(-10 . 20)
e_\p \> e_\p \!
}
\paper{raggedright =
Maybe your changes haven't made it to the CVS server yet
(my ChangeLog has revision 1.1692).
No matter how I set no-spacing-rods and X-extent, the two p
overlap.
/Mats
Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] writes:
I'm sorry, but I cannot see any difference in the output compared to
whe
[EMAIL PROTECTED] writes:
> Maybe your changes haven't made it to the CVS server yet
> (my ChangeLog has revision 1.1692).
> No matter how I set no-spacing-rods and X-extent, the two p
> overlap.
Probably. Please try again now.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.x
[EMAIL PROTECTED] writes:
> I'm sorry, but I cannot see any difference in the output compared to
> when I reported the problem.
try this
\score {
\notes\relative c'' {
\property Score.DynamicText \set #'no-spacing-rods = ##f
\property Score.DynamicText \set #'X-extent = #'(-1 . 2)
I'm sorry, but I cannot see any difference in the output compared to
when I reported the problem.
/Mats
Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] writes:
you could try #'no-spacing-rods on DynamicText to force more space, and
if necessary widen it with
DynamicText \set #'X-extent = #(-10 .
[EMAIL PROTECTED] writes:
> >
> > you could try #'no-spacing-rods on DynamicText to force more space, and
> > if necessary widen it with
> >
> >DynamicText \set #'X-extent = #(-10 . 10)
> >
> > or somesuch.
>
> I already tried these, to no avail. See the following example:
I have fixed t
Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] writes:
Sorry, I plan to learn to read any year :-).
I tried some different property settings in a crowded score,
but none of them worked as I expected, so I leave the question
to others who know better.
As a workaround, you could introduce manual line
[EMAIL PROTECTED] writes:
> Ah. Thank you. I have removed Voice declarations, and now have all stems
> down. Any ideas on that?
Huh?
what did you expect? For high notes, the stems go down.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
[EMAIL PROTECTED] writes:
> Sorry, I plan to learn to read any year :-).
>
> I tried some different property settings in a crowded score,
> but none of them worked as I expected, so I leave the question
> to others who know better.
> As a workaround, you could introduce manual line breaks using
>
Sorry, I plan to learn to read any year :-).
I tried some different property settings in a crowded score,
but none of them worked as I expected, so I leave the question
to others who know better.
As a workaround, you could introduce manual line breaks using
\break in lines that look too crowded.
Hello.
> >>>
> >>>With Lilypond 2.1.0-2 on Debian Testing, I get all of my stems up
> >>>without declaring a direction. What would be the easiest way to get a
> >>>more standard stem direction scheme (i.e., in toward the majority of the
> >>>staff
.
With Lilypond 2.1.0-2 on Debian Testing, I get all of my stems up
without declaring a direction. What would be the easiest way to get a
more standard stem direction scheme (i.e., in toward the majority of the
staff unless beamed)?
That sounds very strange. You don't, by chance, use a cons
On Tue, Feb 03, 2004 at 10:12:33AM +0100, Mats Bengtsson wrote:
>
>
> Kevin C. Baird wrote:
> >Hello.
> >
[snip]
> >I also find that my dynamic markings collide horizontally. Is there an
> >easy way to mandate more horizontal space when a note has a dynamic
> >marking?
>
> If you search the m
Attached. Thank you.
On Tue, Feb 03, 2004 at 10:12:33AM +0100, Mats Bengtsson wrote:
>
>
> Kevin C. Baird wrote:
> >Hello.
> >
> >With Lilypond 2.1.0-2 on Debian Testing, I get all of my stems up
> >without declaring a direction. What would be the easiest wa
Kevin C. Baird wrote:
Hello.
With Lilypond 2.1.0-2 on Debian Testing, I get all of my stems up
without declaring a direction. What would be the easiest way to get a
more standard stem direction scheme (i.e., in toward the majority of the
staff unless beamed)?
That sounds very strange. You
Hello.
With Lilypond 2.1.0-2 on Debian Testing, I get all of my stems up
without declaring a direction. What would be the easiest way to get a
more standard stem direction scheme (i.e., in toward the majority of the
staff unless beamed)?
I also find that my dynamic markings collide
Ted Ashton <[EMAIL PROTECTED]> writes:
> Well, having gotten a build environment put together, I've spent the day
> working over the part combiner.
Thanks for looking into this. I apologise for my late reply, I have
been very busy. The part-combiner is slated for a full rewrite, but
that may no
[EMAIL PROTECTED] writes:
> fix 2 above) when set to the default.
> I would be happy to help write docs/regression tests/samples on the changes,
> but need guidance as to format/location/etc.
Sorry for the delay in answering. The part combiner is more-or-less
Jan's domain, but he is very busy
Well, having gotten a build environment put together, I've spent the day
working over the part combiner. In specific, I changed:
1) When soloADue is off, the stems of part "two" in split intervals now get
pointed down, they didn't before.
2) When one part has a long rest and the other has
= ##t
}
}
The "First" staff shows the problem. When the parts combine with soloADue off
and they need two stems (as the first dotted-eighth should, and, thanks to the
changeMoment setting, so with the sixteenth following it), the stem direction
of voice "two" needs to be
82 matches
Mail list logo
