On Wed, 17 Apr 2024 at 21:53, Pierre-Luc Gauthier
wrote:
>
> Hi there,
>
> Is this a known bug ?
>
> The \showStaffSwitch indication seems uneasy about page breaks.
Hello,
It might be another instance of #6684, which itself is apparently a
duplicate of #6551.
https://g
Hello!
An easy fix, and that makes perfect sense. In other words, it /was/
something I did! :)
Thank you Jean and Kieren for your prompt responses.
Best wishes,
Jakob
On 06.02.2024 23.48, Jean Abou Samra wrote:
It's not a bug — by default, LilyPond forbids line breaks on a bar
line when
It's not a bug — by default, LilyPond forbids line breaks on a bar line when
there are notes straddling on that bar line. You can change this with
```
\layout {
\context {
\Voice
\remove Forbid_line_break_engraver
}
}
```
Best,
Jean
signature.asc
Description
Well, yes and no. The original ignores barlines here and there. Bars
25-27 in T1 have 12 beats total, they are just distributed oddly against
the 2/2 time.
/Jakob
On 06.02.2024 22.59, Kieren MacMillan wrote:
Hi Jakob,
In m25, T1 has 5 beats. Is that correct?
– Kieren
Hi Jakob,
In m25, T1 has 5 beats. Is that correct?
– Kieren
Hello again,
following the Changes to Notename - topic, I have another question. Using
printAccidentalNames seems to override the printNotesLanguage property by
reverting it to the document language. Try the following example and
comment out one of the two lines. Expected result would be to get
Second time sending this, but this time via "Reply all" for the list.
Pardon the spam.
How's this?
\version "2.25.8"
\relative c'' {
\mergeDifferentlyHeadedOn
\once \omit Staff.TimeSignature
<<
{2}
\\
{<
\tweak duration-log #1
c e>8[ g' g, g']}
>>
}
On Mon, 25
Hi everyone!
as the code mentioned below, when i try to engraving, the root note of the
chord are not same as upper note. how to solve this problem?
the aim:
problem:
code:
\relative c'' {
\mergeDifferentlyHeadedOn
\time 4/8
<<
{2}
\\
{8 [g'8]}
>>
}
best regards!
To: Paul Hodges
Sent: 09/09/2023 0:05
Subject: Re: Bug
Sorry for taking your time, but what should I do? Whith python zip which is in
bin folder! Should I unziped it as well?
On Sat, Sep 9, 2023, 4:20 AM Vishal Ghule wrote:
I need that software to open right !? so when I use
directories. In bin you will find 20 files
(including the dll files you got error messages about) - run lilypond.exe in
that directory.
Paul
From: Vishal Ghule
To: Paul Hodges
Sent: 08/09/2023 19:38
Subject: Re: Bug
No I did it
On Fri, Sep 8, 2023, 11:57 PM Paul Hodges wrote
it, and then run
Lilypond from there.
Paul
From: Vishal Ghule
To:
Sent: 08/09/2023 19:08
Subject: Bug
version 2.24.2 mingw×86_64
Installing error
Code execution cannot proceed because lobintl.8.dll was not found
The code execution cannot proceed libgilb-2.0.0.0.doll
version 2.24.2 mingw×86_64
Installing error
Code execution cannot proceed because lobintl.8.dll was not found
The code execution cannot proceed libgilb-2.0.0.0.doll was not found
The code execution cannot proceed because libgio-2.0-0.dill not found
The code execution cannot proceed because
Graham King writes:
> I'm late to this thread, and I might be missing some crucial aspect of the
> problem, but if you just want to integrate lilypond scores and fragments into
> a LaTeX document, and you're able to choose to use Luatex, the lyluatex and
> lilyglyphs packages work beautifully
I'm late to this thread, and I might be missing some crucial aspect of the
problem, but if you just want to integrate lilypond scores and fragments into a
LaTeX document, and you're able to choose to use Luatex, the lyluatex and
lilyglyphs packages work beautifully with the latest Lilypond
Le jeudi 13 juillet 2023 à 08:33 +0200, Dr. Arne Babenhauserheide a écrit :
> This is the lilypond-file in questoin:
> https://hg.sr.ht/~arnebab/draketos-songbook/browse/delfini-tune.ly?rev=tip
>
> Converted to PNG in a two step process:
> lilypond -dbackend=eps -dno-gs-load-fonts
Ihor Radchenko writes:
> "Dr. Arne Babenhauserheide" writes:
>
>> I typically use it directly, but if the maintenance burden is
>> manageable, I could offer maintenance here, too (once I have the papers
>> in place).
>
> I have recently seen https://masto.ai/@rfc1149/110674961710491363 that
>
"Dr. Arne Babenhauserheide" writes:
> Ihor Radchenko writes:
>
>> "Dr. Arne Babenhauserheide" writes:
>>
>>> I typically use it directly, but if the maintenance burden is
>>> manageable, I could offer maintenance here, too (once I have the papers
>>> in place).
>>
>> I have recently seen
>> Le dimanche 21 mai 2023 à 12:09 +0100, Graham King a écrit :
>>
>>> In the following code, I would expect the tie between the final two notes
>>> to be dotted. The actual output is a solid tie. Not sure whether this is
>>> a bug or just my doing some
tes to
>> be dotted. The actual output is a solid tie. Not sure whether this is a
>> bug or just my doing something wrong...
>>
>> \version "2.25.0"
>>
>> { c''2
>> \once \tieDotted
>> \set melismaBusyProperties = #'()
>>
Le dimanche 21 mai 2023 à 12:09 +0100, Graham King a écrit :
> In the following code, I would expect the tie between the final two notes to
> be dotted. The actual output is a solid tie. Not sure whether this is a bug
> or just my doing something wrong...
>
> ```
> \version
In the following code, I would expect the tie between the final two notes to be
dotted. The actual output is a solid tie. Not sure whether this is a bug or
just my doing something wrong...
\version "2.25.0"
{ c''2
\once \tieDotted
\set melismaBusyProperties = #'()
1 ~ 2
I could have thought of that... Thanks David for the tip and Jean for
opening the issue. I'll use the workaround until then...
Le vendredi 13 janvier 2023 à 14:03, David Wright a écrit :
> On Fri 13 Jan 2023 at 19:30:29 (+), nitra...@posteo.net wrote:
> > I was talking about the first note of
Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
Regardless of that, it is indeed a severe bug: No need to ever align
key signatures vertically, AFAIK. Simply left-align them.
I have opened an issue for this:
https://gitlab.com/lilypond/lilypond/-/issues/6520
OpenPGP_signature
Description
On Fri 13 Jan 2023 at 19:30:29 (+), nitra...@posteo.net wrote:
> I was talking about the first note of each measures after the Key Signature.
> But you were right, it is the default spacing.
>
> About the distance between different accidentals, consider the example
> bellow. You can see a
ance between a natural and a sharp, or between a natural
> > and a flat).
>
> Can you be specific about which symbols you're referring to: can you
> give the staff and measure number for the ones you're comparing.
>
> > Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a
23 à 12:02, Jean Abou Samra a écrit :
> > Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > > which wasn't in the previous version.
> > > > What previous version did you t
a natural and a sharp, or between a natural
and a flat).
Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a écrit :
> Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > which was
Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
I just discovered this huge bug in the recent release of 2.24.0
which wasn't in the previous version.
What previous version did you test this with? For me, the output is
the same in 2.22 and in 2.18.2.
Regardless of that, it is indeed a severe
You're right, I worked for my last score on 2.22.0 and the bug was there and I
didn't notice it... So it isn't specific to 2.22.4 as written in the
subject.
Le vendredi 13 janvier 2023 à 09:17, Jean Abou Samra a écrit :
> Le 13/01/2023 à 09:34, nitra...@posteo.net a écrit :
> > Hi all,
&
>> I just discovered this huge bug in the recent release of 2.24.0
>> which wasn't in the previous version.
>
> What previous version did you test this with? For me, the output is
> the same in 2.22 and in 2.18.2.
Regardless of that, it is indeed a severe bug: No n
Le 13/01/2023 à 09:34, nitra...@posteo.net a écrit :
Hi all,
I just discovered this huge bug in the recent release of 2.24.0 which
wasn't in the previous version.
What previous version did you test this with? For me, the output is the
same in 2.22 and in 2.18.2.
Best,
Jean
Hi all,
I just discovered this huge bug in the recent release of 2.24.0 which
wasn't in the previous version. Placement of key signatures on multiple
staves with transposed instrument behaves very poorly. Consider this
example :
\version "2.24.0"
music = \relative c' {
\key es\major
Hi Jean,
> I think this would handle quite a number of cases without
> the user thinking about it, while still avoiding ambiguity
> at all times.
That would certainly be an improvement over the status quo!
Kieren.
l. However, the use cases in
which people write bug reports about it are largely the same: the
events involved are mostly \clef, \time and \key.
As a limited special heuristic, there could be no warning and an
automatic move to before graces if all the zero-length events
are of this category. (
Le 07/01/2023 à 18:43, David Kastrup a écrit :
Well, this was sort of saying that there may be no silver bullet, but we
may have to pick between chrome and aluminum ones.
Sometimes there is a solution that blends better into human expectations
than strict logic.
That's possible.
In my
Le 07/01/2023 à 18:32, Kieren MacMillan a écrit :
David’s interpretation of my idea isn’t correct. I never suggested letting the
second Staff start after the grace note, simply that decisions for that Staff
should be made independently of the Staff that contains the grace music.
Here’s a set
Hi all,
>> That would presumably lead to
>>
>> {
>> \once \override NoteHead.color = ...
>> \once \override Staff.NoteHead.color = ...
>> ...
>> }
>>
>> getting the events reordered so that the Staff.NoteHead override
>> starts before graces and the NoteHead one starts after, which I
>>
Jean Abou Samra writes:
> Le 07/01/2023 à 17:58, David Kastrup a écrit :
>>> In that case, the NoteHead one has no effect, because \once applies to
>>> the next time step only, and the next time step is for a grace note
>>> another voice.
>> The recovery action of \once should likely occur after
Hi David,
> Then I will wait until I see your actual implementation instead of
> reading any meaning into your words.
“Non-implemented” and “implemented” are not the only two possible states in the
development of computer code.
I look forward to any discussion, with any developers, of possible
Hi all,
> You cannot let the second Staff start after the grace note.
David’s interpretation of my idea isn’t correct. I never suggested letting the
second Staff start after the grace note, simply that decisions for that Staff
should be made independently of the Staff that contains the grace
Le 07/01/2023 à 17:58, David Kastrup a écrit :
In that case, the NoteHead one has no effect, because \once applies to
the next time step only, and the next time step is for a grace note
another voice.
The recovery action of \once should likely occur after the next _local_
timestep.
OK, that
Kieren MacMillan writes:
> Hi David,
>
>> That's just wild hand-waving. You cannot let the second Staff start
>> after the grace note. That would look like
>
> You have inferred things about my suggested implementation which I
> neither stated nor implied.
> (These kinds of discussions always
Hi David,
> That's just wild hand-waving. You cannot let the second Staff start
> after the grace note. That would look like
You have inferred things about my suggested implementation which I neither
stated nor implied.
(These kinds of discussions always go better when people don’t make
Kieren MacMillan writes:
> Hi David (et al.),
>
>>> In that case, the NoteHead one has no effect, because \once applies to
>>> the next time step only, and the next time step is for a grace note
>>> another voice.
>>
>> The recovery action of \once should likely occur after the next _local_
>>
Hi David (et al.),
>> In that case, the NoteHead one has no effect, because \once applies to
>> the next time step only, and the next time step is for a grace note
>> another voice.
>
> The recovery action of \once should likely occur after the next _local_
> timestep.
>
>> Do they occur after?
Kieren MacMillan writes:
> Hi Jean,
>
>> Um, that is exactly the current default. And it is what makes
>>
>> \version "2.24.0"
>>
>> <<
>> \new Staff { \grace c'8 c'1 }
>> \new Staff {
>> \clef bass % zero-length => after graces
>> c'1
>> }
>> >>
>>
>> return output that most
p.s.
> In this case (as with so many!) the problem isn't moment-bleed, it's
> context-bleed: the grace music doesn’t apply to the lower staff, and thus
> shouldn’t be included in decision-making there; likewise, the clef doesn’t
> apply to the upper staff, and so shouldn’t be included in the
Kieren MacMillan writes:
> Hi Jean,
>
>> That sounds like you want to make all zero-length events happen
>> before the grace by default, but that is not always desirable,
>> as \once \set/\override shows.
>
> I would say the exact opposite: by default, all zero-length events
> should happen
Hi Jean,
> Um, that is exactly the current default. And it is what makes
>
> \version "2.24.0"
>
> <<
> \new Staff { \grace c'8 c'1 }
> \new Staff {
> \clef bass % zero-length => after graces
> c'1
> }
> >>
>
> return output that most users are not expecting.
In this case (as
Jean Abou Samra writes:
> Le 07/01/2023 à 17:11, Kieren MacMillan a écrit :
>> Could you explain this a bit more, please? This is a position I’ve
>> never quite understood about Issue #34: I would love to see an input
>> where I can’t determine the output with certainty just from the
>> input.
>
Le 07/01/2023 à 17:50, Kieren MacMillan a écrit :
Hi Jean,
That sounds like you want to make all zero-length events happen
before the grace by default, but that is not always desirable,
as \once \set/\override shows.
I would say the exact opposite: by default, all zero-length events should
Hi Jean,
> That sounds like you want to make all zero-length events happen
> before the grace by default, but that is not always desirable,
> as \once \set/\override shows.
I would say the exact opposite: by default, all zero-length events should
happen between the grace music and the
Hi Jean,
> Just take the example I gave earlier and remove the grace skips.
>
> \version "2.24.0"
> <<
> \new Staff { \grace { c'8 d'8 } c'1 }
> \new Staff {
> \once \override Staff.TimeSignature.color = "red"
> \once \override NoteHead.color = "red"
> c'1
> }
> >>
> Do the
Le 07/01/2023 à 17:17, David Kastrup a écrit :
I disagree. We have grace fixups in sequential music that do this
(zero-length events before grace music are executed before the grace)
and the same reasonably could be done with simultaneous music. That's
more complex, but not terribly so. Some
Le 07/01/2023 à 17:11, Kieren MacMillan a écrit :
Could you explain this a bit more, please? This is a position I’ve never quite
understood about Issue #34: I would love to see an input where I can’t
determine the output with certainty just from the input.
Just take the example I gave
cept of 0-cycles, that can be allowed to execute in
>>> order for decisions to be made at the end of the timestep once all
>>> the 0-cycles have completed, seems like a good idea.
>> That might even be a liminal space in which the infamous Grace Music
>> Bug™ could be handled gr
Hi Jean,
>> That might even be a liminal space in which the infamous Grace Music Bug™
>> could be handled grace-fully…?
> Actually, that is what originally made me muse about this ...
“Great minds think alike…” ;)
> Issue #34 is, in my opinion, a perfectly unsolvable probl
estep once all the 0-cycles have
completed, seems like a good idea.
That might even be a liminal space in which the infamous Grace Music Bug™ could
be handled grace-fully…?
Actually, that is what originally made me muse about this ...
Issue #34 is, in my opinion, a perfectly unsolvable proble
have
> completed, seems like a good idea.
That might even be a liminal space in which the infamous Grace Music Bug™ could
be handled grace-fully…?
Cheers,
Kieren.
I would not call the current Staff_symbol_engraver behavior a bug,
but a feature.
You will see that your engraver prevents this from working:
{
c'1
\stopStaff
\once \override Staff.StaffSymbol.color = "red"
\startStaff
c'1
}
Ok, this one could be handled by restarting th
Le 06/01/2023 à 00:37, Lukas-Fabian Moser a écrit :
The Staff_symbol_engraver is not really equipped to deal with multiple
\startStaff / \stopStaff events at the same point of time.
I would not call the current Staff_symbol_engraver behavior a bug,
but a feature.
You will see that your
Hi Tomasz,
Am 05.01.23 um 13:16 schrieb Tomasz Bauć:
I also checked version without the Scheme:
\stopStaff
\repeat unfold 9 {s8}
\startStaff
\stopStaff
\repeat unfold 3 {s8}
\startStaff
\stopStaff
\repeat unfold 11 {s8}
\startStaff
(Please always give
Hi,
I wrote a simple function to make and fill empty bars without staff
engraver.
It follows:
nbar = #(define-music-function (number) (integer?)
#{ \stopStaff
\repeat unfold #number {s8}
\startStaff #})
There is a problem when I've got to empty bars next to. The
to markup.
I hope that it is not a bug, but that I may have got something wrong.
But if it is one, the example is unusable as a global model.
Could someone here, please, with more experience than I have, help me?
Otherwise I am stuck with my project for the moment... I attach a
minimal example
Staff.timeSignatureFraction = x/x
did not work, and I have no idea what is wrong here. To make things
worse: when I fiddle with the NR example and add a line with not all
the same values in 9/8, the same thing happens, too (see the added
third line there), and it even reacts to markup.
I hope that it is not a bug
HI Jean;
Thank you for finding the problem due to my not using repeat volta
consistently among all the parts! Problem solved!
Ken
On Fri, Oct 21, 2022 at 2:33 AM Jean Abou Samra wrote:
>
> Le 21/10/2022 à 00:54, Kenneth Wolcott a écrit :
> > Hi Jean and Adrian;
> >
> >I attached the
Le 21/10/2022 à 00:54, Kenneth Wolcott a écrit :
Hi Jean and Adrian;
I attached the wrong files! So sorry! Let me try again.
Thanks!
Listen to the MIDI, or change the score with \midi to use \layout too,
and you will find something funnier than just bar check errors: there
is one staff
>
> -- Forwarded message --
> From: Kenneth Wolcott
> To: Lily Pond
> Cc:
> Bcc:
> Date: Thu, 20 Oct 2022 15:01:05 -0700
> Subject: bar check bug in Lilypond 2.22.2 ??
> Hi;
>
> bar check bug in Lilypond 2.22.2 ??
>
> I must be doing so
Le 21/10/2022 à 00:01, Kenneth Wolcott a écrit :
Hi;
bar check bug in Lilypond 2.22.2 ??
I must be doing something dumb!
I am not able to find the cause of a bar check warning occurring at
the same bar (#85) in all five parts.
time is 4/4
Workaround was to disable bar checks at bar #85
. Sorry, I didn't notice at first that you had attached the
original.
On measure 15, the top staff in your original has a bug, it's missing a
rest. The measure has 4 8th notes + 1 half note = 1 whole note, while it
should have 1 whole note and a half. Judging from the other staves,
there should
I have found a strange corner case which partCombine doesn't handle
correctly. I ran into it setting a complex orchestral score, but I've
narrowed down the demonstration to something more reasonably sized.
In this example, I have to do the known workaround in bar 2 of adding
invisible grace notes
>> How did you do that? Sorry to rain on your parade, but I would not
>> want you to put a lot of work in it if it will not be of mergeable
>> quality.
>
> Attached. In the end the necessary modifications were surprisingly
> minor. Please comment, there is certainly room for improvements.
>> Attached. In the end the necessary modifications were surprisingly
>> minor. Please comment, there is certainly room for improvements.
>
> Thanks. This is a bit what I feared: in this state, there is
> potential for things going wrong with other after-line-breaking
> callbacks. Those are
Le 14/04/2022 à 18:18, Werner LEMBERG a écrit :
How did you do that? Sorry to rain on your parade, but I would not
want you to put a lot of work in it if it will not be of mergeable
quality.
Attached. In the end the necessary modifications were surprisingly
minor. Please comment, there is
Hi all,
On 4/6/22 20:17, Jean Abou Samra wrote:
> Le 06/04/2022 à 14:33, Werner LEMBERG a écrit :
>> Is someone taking care of bugs in the magnetic snapping lyrics
>> engraver? Here is an example where it fails to position lyrics
>> correctly (see last system in the image).
>>
>>
>> Werner
> How did you do that? Sorry to rain on your parade, but I would not
> want you to put a lot of work in it if it will not be of mergeable
> quality.
Attached. In the end the necessary modifications were surprisingly
minor. Please comment, there is certainly room for improvements.
Werner
Le 14/04/2022 à 17:39, Werner LEMBERG a écrit :
There is a problem with ligatures at the syllable boundaries (and
kerning). [...] it is not sufficient to shift the right syllable
in a syllable pair to the left. Instead, the following should be
done. [...]
Meanwhile I could implement this
> There is a problem with ligatures at the syllable boundaries (and
> kerning). [...] it is not sufficient to shift the right syllable
> in a syllable pair to the left. Instead, the following should be
> done. [...]
Meanwhile I could implement this :-)
I will submit a MR soon.
Werner
>> This is ingenious :-) Thanks *a lot* for this solution. In my
>> tests it seems to work fine
>
> You're welcome.
I spoke too soon :-) There is a problem with ligatures at the syllable
boundaries (and kerning). While this can be considered an ugliness in
languages based on the latin script,
On Thu, Apr 7, 2022 at 10:04 AM Kieren MacMillan <
kie...@kierenmacmillan.info> wrote:
> Hi Werner (et al.),
>
> > This is ingenious :-) Thanks *a lot* for this solution.
>
> +1 (x2)
>
> > * I *strongly* vote for polishing and documenting this so that it can
> > be added to LilyPond. It's an
Hi Werner (et al.),
> This is ingenious :-) Thanks *a lot* for this solution.
+1 (x2)
> * I *strongly* vote for polishing and documenting this so that it can
> be added to LilyPond. It's an invaluable feature IMHO, greatly
> enhancing Lyrics.
YES PLEASE!!
If anyone is interested in
Le 07/04/2022 à 11:44, Werner LEMBERG a écrit :
Did I miss something?
Whoops, big problem at line breaks ...
This is ingenious :-) Thanks *a lot* for this solution. In my tests
it seems to work fine
You're welcome.
Two comments.
* I *strongly* vote for polishing and documenting this so
>> Did I miss something?
>
> Whoops, big problem at line breaks ...
This is ingenious :-) Thanks *a lot* for this solution. In my tests
it seems to work fine.
Two comments.
* I *strongly* vote for polishing and documenting this so that it can
be added to LilyPond. It's an invaluable
> The second bug is super hard to fix: when you tell LilyPond about
> spacing constraints between lyrics, before line breaking, you need
> to assume a lyric syllable won't be moved to the left by
> 'magnetism', because if you do, the spacer might think it can space
> its righ
Le 06/04/2022 à 20:17, Jean Abou Samra a écrit :
Did I miss something?
Whoops, big problem at line breaks ...
\version "2.23.7"
#(define (Left_hyphen_pointer_engraver context)
(let ((hyphen #f)
(text #f))
(make-engraver
(acknowledgers
((lyric-syllable-interface
Hi Jean,
> To be honest, I don't know why the snippet is so complicated.
Perhaps a corollary to Clarke's Law?
“Every sufficiently primitive technology is indistinguishable from garbage.” ;)
[No offence to the wonderful coders who wrote the existing snippet! Just a
funny observation re:
e #5 syl -- la -- bic
\markup \bold \underline ver -- \markup \italic bi -- age
\markup {
\stencil #(make-circle-stencil 0.5 0 #f)
}
}
Which seems to work, and doesn't have your first bug.
Did I miss something?
The second bug is super hard to fix: when you tell LilyPond a
> Here is an example where it fails to position lyrics correctly (see
> last system in the image).
And while we are at it: Here is another bug, already reported in
https://lists.gnu.org/archive/html/lilypond-user/2020-03/msg00289.html
I've slightly sharpened the test to e
Is someone taking care of bugs in the magnetic snapping lyrics
engraver? Here is an example where it fails to position lyrics
correctly (see last system in the image).
Werner
PS: I've attached a version of `magnetic-lyrics.ily` that actually
works with the current development version
Hi Knute,
thanks for the info. Because the discussion of the links I provided took place
in 2019 I was wondering if it was something still under consideration since
then. It could be that no official bug report was ever made. I'll have to
investigate and make
This is a good place to start if you have patched a bug:
https://lilypond.org/bug-reports.html
or
https://lilypond.org/help-us.html
--
Knute Snortum
On Fri, Mar 11, 2022 at 3:29 AM Martín Rincón Botero
wrote:
>
> Hi all,
>
> I stumbled into this bug
> https://marc.info/?
Hi all,
I stumbled into this bug
https://marc.info/?l=lilypond-user=142300498620076=2 which I solved
with this patch https://marc.info/?l=lilypond-user=142477756707049=2
(the line numbers seem to be different nowadays). I'm using Lilypond 2.22.
Is there any chance that this small patch gets
Hello Thomas,
in your case using a with block is definitely the best option. One can also
solve such issues by adding a skip column before the main beat like this
\new Staff << {\set Staff.instrumentName = #"abc" \grace s} \new Voice \grace c
c >>
which can be useful with stuff like tempo in
Thank you David for this lesson, I appreciate it a lot.
Thomas
> Am 16.02.2022 um 18:50 schrieb David Kastrup :
>
> Thomas Scharkowski writes:
>
>> Grace note at the beginning makes instrumentName disappear:
>> macOs 12.1
>> LilyPond 2.23.6
>>
>> --
>> \version "2.23.6"
>>
>> GraceVoice =
Thomas Scharkowski writes:
> Grace note at the beginning makes instrumentName disappear:
> macOs 12.1
> LilyPond 2.23.6
>
> --
> \version "2.23.6"
>
> GraceVoice = \new Voice
> {
> \grace
> c'8 b4
> }
>
> GraceStaff = \new Staff
> <<
> \set Staff.instrumentName = "Grace"
>
Greetings Thomas,
In the case of grace notes, the instrumentName must be placed in a \with block.
GraceStaff = \new Staff \with {
instrumentName = #"Grace"
}
<<
\GraceVoice
>>
Not sure if the curly and angled braces work exactly the same way,
because I haven't done this with variables,
Grace note at the beginning makes instrumentName disappear:
macOs 12.1
LilyPond 2.23.6
--
\version "2.23.6"
GraceVoice = \new Voice
{
\grace
c'8 b4
}
GraceStaff = \new Staff
<<
\set Staff.instrumentName = "Grace"
\GraceVoice
>>
\score {
\GraceStaff
}
NoGraceVoice = \new Voice
{
Hello Erik,
As I said, this is not a solution but just a demonstration, and it abuses the
Accidental grob to place the embellishment. This means you’ll need to force an
Accidental on the embellished note by doing a!.
@Lukas: As I said, this is just a demonstration, and it is doing very shady
oorn"
Verzonden: 26-12-2021 20:35:28
Onderwerp: Re: possible bug?
Hello Erik,
I think the behaviour you want is for some sort of embellishment which
basically is handled similar to some sort of articulation.
The appended file is in an extremely hacky demonstration of how one could
imple
Am 26.12.21 um 20:35 schrieb Valentin Petzel:
Hello Erik,
I think the behaviour you want is for some sort of embellishment which
basically is handled similar to some sort of articulation.
The appended file is in an extremely hacky demonstration of how one could
implement something like,
1 - 100 of 1639 matches
Mail list logo
