Jean Abou Samra wrote:
Thanks for the report. Now that you are a Git expert, how about submitting a
merge request to fix this? :-)
Thanks for the friendly invite, but you are way off the mark.
I wasn't reading CG 3, and I didn't even peek inside the book.
I was just wading through ten-year
Hallo there
On [1] the 'Book about Git' link leads to a francophone news magazine.
The link originally pointed to the first edition of that book. A few
years later it started redirecting to [2], which nowadays redirects to
[3], the second edition.
It looks like the progit.org domain change
On 21.03.2022 13:18, Jean Abou Samra wrote:
Allow me to disagree: "vertical position on the page at which each new
system will render" does not specify which refpoint in the system is
aligned to the given offset. I don't see that the documentation is
inaccurate.
In this reading it is incomplet
Hallo there
In the Notation Reference for v2.12 through to (currently) v2.23, the
section 'Explicit staff and system positioning' says:
Note that line-break-system-details takes an associative list
of potentially many values, but that we set only one value here.
Note, too, that the Y-offset pr
skoop...@web.de wrote:
Hello,
is there meanwhile an easy way to write polychords as a chord name? I found a
request on this topic, but no working solution.
The ChordNames context works like a vending machine:
- your chosen coffee appears in a single paper cup.
The selection and dispensing
On 04.10.2021 19:42, Jean Abou Samra wrote:
This is just something I noticed, not of any direct importance to me,
but thought you might like to know. I checked convert-ly does not alter
the file.
This is registered as issue #4826,
https://gitlab.com/lilypond/lilypond/-/issues/4826
As an a
Kevin Barry wrote:
I don't think LilyPond guarantees a particular
order of events occuring at the same moment, but I agree that wrapping
them should not change the order.
An issue has been created to track this
Thanks.
But the regression test script-stack-order.ly is quite explicit about
t
Hallo there
I noticed this while trying to make an MWE for a different problem.
Maybe it counts as a limitation rather than a bug?
Cheers,
Robin
% MWE for post-event ordering via event-function and wrapper
\markup #(lilypond-version)
ts-first-second =
#(define-event-function () ()
#{ -"1st
Hallo again
In the meantime it has occurred to me that moving the gratuitous magstep
scaling from baseline-skip over to thickness is perhaps not the answer.
Since the triangle is applied mainly as a glyph it should not respond to
overrides on those two properties. Consider squashing a vertic
Hallo there
The markup command \triangle has been around since 2005.
The ChordName code guarantees its regular use as a major-seventh option.
This command has a severe bug, as demonstrated by the following code:
% same behaviour from 2.8.8 to 2.22.0
\
Come on, just do it ;-)
Werner Lemberg has just done it.
This thread was never assigned an issue corresponding to its subject.
This code is now riding piggyback on his Issue 5468.
https://sourceforge.net/p/testlilyissues/issues/5468/
Thanks, Werner.
Cheers,
Robin
___
Simon Albrecht wrote:
> Please let us know if you’d be willing to do this.
Thanks for the kind invitation, but I'm surely not as high-powered as
you seem to think I am.
Getting up to a reasonable speed with that CG stuff looks to me like a
steeper learning curve than for LilyPond itself. Bu
Palmer Ralph wrote:
The issue has been entered as Issue #5245 markuplist not documented well.
Thanks.
And by the way, this was all with split HTML, if that makes a difference.
I kept this purely user-oriented, leaving implementation unconsidered;
that was quite easy, seeing that I still don'
Thomas Morley wrote:
I've no clue how this _could_ be fixed.
I failed to identify the code responsible for dropping one dot either.
In 2.18.2 this is note-collision.cc, which comments:
> when merging identical heads, dots on the down-stem head disappear
Further down, dot_wipe_head triggers su
On 23.01.2016 19:39, Chris Yate wrote:
On 23 January 2016 at 18:26, Thomas Morley wrote:
2016-01-23 19:21 GMT+01:00 Chris Yate :
> Does anyone else on this list use Windows, who could reproduce the
problem?
>
> I appreciate that you need a reproducible error to fix it, but just
because
> it do
On 05.10.2015 11:23, Urs Liska wrote:
Am 05.10.2015 um 11:18 schrieb Federico Bruni:
>> ...
"Custom protocol handlers aren't supported by Adobe Reader X and later
for security reasons."
https://forums.adobe.com/message/5593888#5593888
Is this definitive?
My last _abandoned_ attempt at gett
Federico Bruni wrote:
If you compile the following example, the systems are not horizontally
centered.
Bug or I'm missing something?
\version "2.19.13"
\layout {
line-width = 160\mm
I presume line-width is a \paper variable which
is only effective in a \paper block.
http://www.lilypond.
On 15.02.2014 20:28, Pierre Perol-Schneider wrote:
Wrong type (expecting pair): ()
Any idea ?
Well, you can get a bit further by wrapping the single
notes in angle brackets, putting them inside an
EventChord like they used to be (implicitly).
But this workaround is no good for rests,
so you
On 14.02.2014 18:46, Pierre Perol-Schneider wrote:
I cannot find where the problem comes from.
Me neither; convert-ly doesn't rearrange anything.
If you move the "cue" voice down past the other
(anonymous) voice, then \lyricsto can find it.
But surely you shouldn't have to do that?
Cheers,
On 14.02.2014 20:05, Pierre Perol-Schneider wrote:
[...] ask him how
he would see his snippet upgraded ?
http://lsr.dsi.unimi.it/LSR/Item?id=651
If you are referring to the horizontal distortion,
this is cured by prefixing the extra-spacing-width
override with "Staff.".
Cheers,
Robin
__
Colin Hall wrote:
However there is no documentation that describes common errors for new
users and their solutions
For common errors, see
http://lilypond.org/doc/v2.14/Documentation/usage/common-errors
Cheers,
Robin
___
bug-lilypond mailing lis
Reinhold Kainhofer wrote:
The example had both \larger and \smaller in the same markup.
Maybe a copy/paste typo?
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=07f53dbc18c8a8903fc8796029faa3ec3c0e707f
Cheers,
Robin
___
bug-li
Marek Klein wrote:
Is this a bug report?
One view:
This is about a bug in the making, not yet available in an unstable version.
So CG says you should relay this to dev (to which I am not subscribed).
Another view:
Ian's empty-markup patch passed the reg tests.
This in itself is a regres
In http://code.google.com/p/lilypond/issues/detail?id=2026#c32
Ian Hulin wrote:
This is fixed if we move the definition of the \null markup to the
before the empty-markup declaration and change empty-markup to
(define-public (empty-markup)
make-null-markup))
...
It's built the docs successfu
Try replacing the current LSR377 demo code as in the attachment.
This file (visible.ly) includes a linebreak+leftBracket combination,
and thus exercises the custos trick.
When the break alignment override is corrected the bracket at the
start of the second line moves to the right of the key si
In http://lists.gnu.org/archive/html/bug-lilypond/2011-04/msg00148.html
Phil Holmes wrote:
to my eye it looks OK.
If there is still a problem, could you be explicit about what it is?
See http://lists.gnu.org/archive/html/lilypond-user/2012-01/msg00183.html
To make the problem _visible_,
en
**lost**
Only lower case because a very peripheral concern.
But this reminder has had NO RESPONSE.
(Should I have done something differently?)
http://lists.gnu.org/archive/html/bug-lilypond/2011-01/msg00480.html
Cheers,
Robin
___
bug-lilypond m
Hu Haipeng wrote:
this doesn't work at all.
The hidden breathe sign strangely leaves an apostrophe like sign
This apostrophe is the breathe glyph; so I suppose the #'transparent
override wasn't being effective. My workaround did work for your snippet
(as my attachment for sighted read
Hu Haipeng wrote:
the arpeggio sign collides with the a'4 natural of the treble
It is as if the arpeggio code doesn't notice the staff change.
Here is a workaround which doesn't prevent a collision but disguises it.
Insert a transparent breathing sign after s2 in the right hand:
Neil Puttock wrote:
Works fine here
Thanks a lot! This is very easy to apply.
Cheers,
Robin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Neil Puttock commented on issue 1543:
If we really need to control the line breaks printed in drafts made with
skipTypesetting, we can insert a \grace s8 to define the timing.
A simpler method would be to unset forbidBreak.
I can't get this to work.
I would be interested in a simpl
Without skipTypesetting the following snippet delivers three lines.
With skipTypesetting it used to deliver two,
skipping the forced break at the dashed barline.
Since 2.13.43 it delivers only one line, skipping *both* forced breaks.
See http://lists.gnu.org/archive/html/lilypond-user/201
Neil Puttock wrote quite some time ago
http://lists.gnu.org/archive/html/bug-lilypond/2009-09/msg00039.html
Thanks, I'll sort this out.
I have just noticed that LSR 377 is still suffering from the
convert problem (re issue 97) described in
http://lists.gnu.org/archive/html/lilypond-devel/200
Patrick McCarty wrote:
I will try to see what's going on.
See here for an overview
http://lists.gnu.org/archive/html/bug-lilypond/2010-02/msg00124.html
Cheers,
Robin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/
Chord names entered in note mode are annotated in the pdf with a link
leading to the corresponding position in the ly source file.
But chord names entered in chord mode get either
a link with an invalid position (versions <= 2.13.7 say line0 column0).
or no link at all.
This seems to be b
Robin Bannister wrote:
This of course also applies to the issue(s) I referenced in my followup
http://lists.gnu.org/archive/html/bug-lilypond/2009-10/msg00294.html
I am unsuccessful again. I will just spell out the main point:
The collision snippet which is registered as issue 821
http
\paper { ragged-right = ##t }
{% seen with versions 2.12.1, 2.10.33, 2.8.8
<< b'1 \\ s1 \\ 1 \arpeggio >> % arpeggio collides with voice1
}% unless there is an accidental (in any voice)
Cheers,
Robin
___
bug-lilypond mailing list
bug-lilypond@gnu
\paper { ragged-right = ##t }
teeny = \set fontSize = #-3
<< % seen with versions 2.12.1, 2.10.33, 2.8.8
a'2
\\
% \once \override NoteHead #'X-extent = #'(0 . 1.3) % crude workaround to avoid
\teeny a'4 % voice2 colliding with larger voice1
It looks like the collision avoidance is pos
Seeing the issues in the priority/type table format made me realise
how important it is to get these categories right.
This thread (span arpeggio and single notes)
supplied the collision snippet which is registered as issue 880
http://code.google.com/p/lilypond/issues/detail?id=880
No collis
Valentin Villenave wrote:
While waiting for acknowledgement,
I have come across several online examples of this.
Yes, I suspect these issues have the same underlying cause (though I
opened multiple issues since I'm not sure what that cause might be).
Well, that was my point
Going by the list of Scheme functions (2.12 NR B.15, 2.13 NR A.16)
it seems that there are two basic graphical transformations available:
- translation, e.g ly:stencil-translate
- rotation, e.g. ly:stencil-rotate
I feel that these two should be complemented by a third tr
\version "2.12.1" % regression: 2.10.33 and 2.8.8 are ok
dense = #(define-music-function (parser location mus) (ly:music?)
#{ s2 $mus $mus $mus $mus 4 \noBreak #})
\score { \transpose c c' {
\stemDown
\dense e'16
\dense d'16
\dense c'16 % collision
\dense b 16 % collision
\dense a 16 %
While waiting for acknowledgement,
I have come across several online examples of this.
Their severity depends on how dense the local layout is.
Neighboring things may push the faulty arpeggio that bit too far.
And less severe cases may go unnoticed, e.g. the Ravel;
the tight layout may look appro
>
\version "2.12.1" % regression: 2.10.33 and 2.8.8 are ok
{
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio \mark "never"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio
\bar "||"
\laissezVibrer \arpeggio
\laissezVibrer \arpeggio \mark "sometimes"
\laissezVibrer \ar
> Nice :-)
I think this deserves a NEWS entry.
Cheers,
Robin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
When the connectArpeggios mode includes an arpeggio on a single note,
the resultant span arpeggio may collide with a previous note.
%%
\version "2.12.1"
d = { d'16 d'16 d'16 d'16 d'4 \arpeggio } % single note
sdf = { s4 4 \arpe
>
Convert rule 2.11.23 replaces _any_ break-align-symbol and its symbol
with a break-align-symbols list containing just that symbol.
This is reported in the NEWS as a syntax change.
So presumably break-align-symbols is no more than a generalisation
of break-align-symbol, simply catering
>
Alex Shanin wrote:
> The workaround recommended therein doesn't help.
It probably only worked for collisons with notes, like in the first case,
and not for collisions with things like time signatures and clefs.
You could override the time signature like
\once \override Staff.TimeS
>
flamingspinach wrote:
> would it be possible for lilypond to just
> recklessly try to modify the file
I imagine it was Risto's post
http://lists.gnu.org/archive/html/lilypond-devel/2008-06/msg00051.html
which tipped the balance in favour of inaction on windows.
I work differently now w.
>
\version "2.12.1"
\paper { ragged-right = ##t }
{
4. s8 \small 4. s8 4. s8 4. s8
}
% The augmentation dots are not shifted away from some chords
% when the notehead size is reduced
% this is a regression error (2.10.33 is ok)
Cheers,
Robin
_
>
\version "2.12.1"
workaround = \override Arpeggio #'positions =
#(lambda (grob) (interval-widen (ly:arpeggio::calc-positions grob) 0.5))
{
\override Arpeggio #'arpeggio-direction = #DOWN
4 \arpeggio 4 \arpeggio
% \workaround
4 \arpeggio 4 \arpeggio % arrow too long for one wiggle
}
Joe Neeman wrote:
> so we move "still more text" below "more text"
By all means extend the regression test if it is incomplete
with regard to "still more text".
But how is this relevant?
Your illustration shows "text" and "more text" ordered in the same
way as "inner up" and "outer up" of th
>
Here is the regression test script-stack-order.ly
in a slightly lengthened version.
\version "2.12.1"
\relative c'' { c4^"inner up"^"outer up"_"inner down"_"outer down"
\repeat unfold 2 c4 }
The assertion "Objects specified first are closest to the note."
Trevor Danielswrote:
I prefer to use "Unicode hexadecimal value".
There are too many sorts of Unicode hexadecimal values
for this to be reliably unambiguous.
I think the "hexadecimal" bit is a red herring
and only needs mentioning once, as in:
where is the hexadecimal code for the cha
Trevor Daniels wrote:
> I prefer to use "Unicode hexadecimal value".
There are too many sorts of Unicode hexadecimal values
for this to be reliably unambiguous.
I think the "hexadecimal" bit is a red herring
and only needs mentioning once, as in:
> where is the hexadecimal code for the c
Francisco Vila wrote:
> Does \char accept full hex Unicode code points
> or rather variable-length utf-8 multibyte characters?
In the source for 2.12.1
the \char markup definition at define-markup-commands.scm line 2423
calls ly:wide-char->utf-8 at general-scheme.cc line 271.
This routine is
Francisco Vila. wrote:
> the right googleable word is Unicode, do you agree?
Well, not fully.
When I google for > unicode arabic percent
I certainly end up at a relevant place
http://www.fileformat.info/info/unicode/char/066a/index.htm
But I am not done.
I need to collect whatever it is \cha
>
Where NR 3.3.3 is talking about \char it says
> The following example shows UTF-8 coded characters being used
which got me typing in a UTF-8 byte pair after the ##x.
But, of course, it is more like UTF-32.
In fact, referring to UTF-32 would make it easier
to google for these high code point
>
This can be seen in NR B.3, but the C/F/G snippet (sourcefileline 782)
in NR 2.4.1. / Predefined fret diagrams is suitable for regression testing.
Starting with doc tarball version 2.12.1-2 the C/F/G diagrams have
neither their fingering nor their first frets aligned.
It is as if there were a
> 148 millimeters, the height of a6 paper in landscape orientation
says v2.12 NR 4.6.1.
Readers are not told what size a point is;
they have to work it out from the example given.
So it is important to get this right: 105 mm
Cheers,
Robin
___
bu
Christian Keil wrote:
> and what follows is ... only achieved with single angle brackets.
> Using double brackets results in three staffs with the corresponding notes.
Try putting something up front, as in:
{ s4 <> }
You have tripped up over one of those inconsistencies caused by automagic.
I
In the (latest) docs (both online and download)
I see no navigation menu bars.
These were present in 2.11.60.
And you can see them at kainhofer.com (pre 2.11.62).
Cheers,
Robin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.
In the (latest) online docs
there are three examples [1]
- typography-demo
- wilhelmus
- bach-schenker
where the png link is wrong.
My IE6 gets given the midi file instead of the picture.
The download 2.11.60-1 documentation seems OK.
[1]http://lilypond.org/doc/v2.11/examples
Cheers,
Ro
If you change the pitch of one of the notes of a correctly tied pair,
but forget to delete the tilde
A: the graphic output looks ok (pitch changed, curve removed)
B: there is no warning
C: midi is messed up
I have got used to the A/B behaviour (B is annoying, but A makes it harmless).
Now I ha
64 matches
Mail list logo
