On Thu, 10 Oct 2024 10:06:03 -0700
Knute Snortum wrote:
> On Thu, Oct 10, 2024 at 9:27 AM Lucas Cavalcanti
> wrote:
>
> > Put brackets before and after the "repeat unfold 3". Don't know what
> > causes this bug, but it still happens in version 2.25.19.
> >
> > %%
> > \fixed c'' {
> > \repeat
On Fri, 11 Oct 2024, Peter Chubb wrote:
> The syntax of repeat is:
>\repeat TYPE MUSIC ALTERNATIVES
> So when you have:
>\repeat volta 2 {
> \repeat unfold {}
> \alternative {
> }
>}
> The alternatives are attached to the unfolded repeat, and get unfolded.
That's the
> "Cameron" == Cameron Hall writes:
Cameron> I've run into a strange problem that I think may be a bug. In
Cameron> this MWE, I have a repeat with alternate endings. However,
Cameron> the "\repeat unfold 3 { c1 }" is causing the volta brackets
Cameron> to disappear for some reason. If I inste
On Thu, Oct 10, 2024 at 9:27 AM Lucas Cavalcanti
wrote:
> Put brackets before and after the "repeat unfold 3". Don't know what
> causes this bug, but it still happens in version 2.25.19.
>
> %%
> \fixed c'' {
> \repeat volta 2 {
> {\repeat unfold 3 { c1 }}
> \alternative { \volta 1 { d
Put brackets before and after the "repeat unfold 3". Don't know what causes
this bug, but it still happens in version 2.25.19.
%%
\fixed c'' {
\repeat volta 2 {
{\repeat unfold 3 { c1 }}
\alternative { \volta 1 { d } \volta 2 { e } } }
c4 r r2}
%%
Em qui., 10 de out. de 2024 às 13:21,
I've run into a strange problem that I think may be a bug. In this MWE,
I have a repeat with alternate endings. However, the "\repeat unfold 3
{ c1 }" is causing the volta brackets to disappear for some reason. If
I instead write out "c1 c1 c1", it works as expected. If I add another
note right bef
Thanks for the explanation! I was not aware of the previous behavior and
that was very confusing.
And I guess I was not expecting alternatives to work with /unfold/
either but that makes sense.
On 2023-09-26 23:53, David Kastrup wrote:
Stéphane SOPPERA writes:
I observed a strange behavior
Stéphane SOPPERA writes:
> I observed a strange behavior with a /repeat unfold/ inside a /repeat
> volta/ with /alternatives/. See the attached /bug_repeat__ok.ly/ for
> full source.
>
> Using Lilypond 2.24.1:
>
> \repeat volta 2 {
> %% Here we repeat th
Hi,
I observed a strange behavior with a /repeat unfold/ inside a /repeat
volta/ with /alternatives/. See the attached /bug_repeat__ok.ly/ for
full source.
Using Lilypond 2.24.1:
\repeat volta 2 {
%% Here we repeat three times the same music.
* \relative { c'4
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 Sept
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!
John,
This is a known issue.
To compensate place a spacer grace in each of the other voices/staves.
Mark
From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org]
On Behalf Of John Burt
Sent: Friday, July 24, 2020 11:31 AM
To: lilypond-user
Subject: Strange
, July 24, 2020 at 12:31 PM
To: lilypond-user
Subject: Strange behavior with grace notes
When the first notes of a piece are grace notes, if there are other voices, or
other staves in the piece, the grace note is set in a separate bar, and then
the time signature and key are printed again. I
When the first notes of a piece are grace notes, if there are other voices,
or other staves in the piece, the grace note is set in a separate bar, and
then the time signature and key are printed again. I notice the same thing
with appoggiatura and accacciatura. I tried to make this example as minim
2015-01-28 3:30 GMT+01:00 Cynthia Karl :
>
>> Message: 6
>> Date: Wed, 28 Jan 2015 00:02:13 +0100
>> From: Thomas Morley
>> To: Chris Trahan
>> Cc: LilyPond User Group
>> Subject: Re: Repeats - Strange behavior??
>> Message-ID:
>>
>&
>>>\repeat unfold 3 {c d e f} \bar "||" \break
>>
>> use \bar ".|:-||" instead, see NR ;)
>
> Why shouldn't it be changed to work like the 99% would like?
Hi,
I think there are a few things to explain here:
Even if there is a break at this point and the bar line is printed twice (at the
en
> Message: 6
> Date: Wed, 28 Jan 2015 00:02:13 +0100
> From: Thomas Morley
> To: Chris Trahan
> Cc: LilyPond User Group
> Subject: Re: Repeats - Strange behavior??
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> 2015-01-27 23:35 GMT+0
2015-01-27 23:35 GMT+01:00 Chris Trahan :
> I have two examples in the following code.
>
> The fist one shows a repeated section starting at measure 4.
>
> The second shows the same code, except that a double bar ends measure 3. In
> this case, the repeated section is not correct.
>
> Is this a bu
I have two examples in the following code.
The fist one shows a repeated section starting at measure 4.
The second shows the same code, except that a double bar ends measure 3.
In this case, the repeated section is not correct.
Is this a bug or by design?
\version "2.18.2"
\language "english"
The question was not over convert-ly. I'm sory if it sounds like that. It
was not the intention.
Actualy I first try by re-tipeing under 2.17 and when that didn't work I
went back to the original file and convert it.
I don't think it has nothing to do with convert-ly and absolutly don't
think conv
Federico Bruni writes:
> 2013/10/20 Marcos Press
>
>> The result I need is the one that said correct.
>> I don't know whay, in 2.16 the
>>
>> \override Stem.transparent = ##t
>>
>> It just turn transparent the steams, without toching the Beams.
>> But now 2.17 It turn transparent the beams too.
Graet!
Thanks!
2013/10/20 Federico Bruni
> 2013/10/20 Marcos Press
>
>> The result I need is the one that said correct.
>> I don't know whay, in 2.16 the
>>
>> \override Stem.transparent = ##t
>>
>> It just turn transparent the steams, without toching the Beams.
>> But now 2.17 It turn transpa
2013/10/20 Marcos Press
> The result I need is the one that said correct.
> I don't know whay, in 2.16 the
>
> \override Stem.transparent = ##t
>
> It just turn transparent the steams, without toching the Beams.
> But now 2.17 It turn transparent the beams too.
seen recently on this list :-)
ht
, but really it is due to
LilyPond trying to determine what you want from imprecise code
and making assumptions that produce, in this case, the wrong result.
Trevor
- Original Message -
From: "David Stocker"
To:
Sent: Thursday, March 25, 2010 2:34 PM
Subject: Strange behavior wi
Just reposting this to the right thread. My bad.
On 03/25/2010 10:40 AM, David Stocker wrote:
Moving the \voiceOne and \voiceTwo commands out of the variables and
into the appropriate voices in the notation staff avoids the problem
altogether. So the problem seems to be related to delineating a
Has anyone encountered this? It seems like a bug. Using \override
TabNoteHead #'whiteout = ##f causes slurs to jump to a different voice
in the TabStaff when two voices are present.
For what it's worth, the very presence of the \override seems to be the
trigger. In the first example, uncomment
On Sun, Nov 29, 2009 at 11:34 AM, Reinhold Kainhofer
wrote:
> Still it would be nice to collect such snippets for a future fix of
> partcombine.Otherwise we'll have to think of all possible problesm againand
> create regtets again.
When the time comes, it should be as simple as
http://code.google
Uhm, by the way: Do we have the same version of \changePitch? I use the
one Stefan linked in his initial mail on this subject, which seems to be
the most recent one. Right?
http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00556.html
The 2 versions are know synchronized (thanks to
I disagree (see below). The reason why the rests "look strange" is
that the change Pitch gives them a different "pitch" and therefore
affects their vertical placement.
No. \changePitch simply ignores rests belonging to the pattern.
It deals only with notes.
(see line 72-73-74 of changePitch.
Valentin Villenave wrote:
2009/11/27 Alexander Kobel :
But... it's nothing to do with \changePitch. Remove this command, and the
result looks the same.
I disagree (see below).
Hey, but I disagree, too (see below)! *squeak* ;-)
The reason why the rests "look strange" is
that the change Pitch
2009/11/27 Alexander Kobel :
> But... it's nothing to do with \changePitch. Remove this command, and the
> result looks the same.
I disagree (see below). The reason why the rests "look strange" is
that the change Pitch gives them a different "pitch" and therefore
affects their vertical placement.
Stefan Thomas wrote:
Dear Alexander,
look at the attached jpg-file. In my opinion the quarter-rests look strange!
Ugh. Okay, admitted.
But... it's nothing to do with \changePitch. Remove this command, and
the result looks the same.
Worse, if you add spacer rests in the second voice, no rests w
Dear Alexander,
look at the attached jpg-file. In my opinion the quarter-rests look strange!
2009/11/27 Alexander Kobel
> Stefan Thomas wrote:
>
>> Dear community,
>> I found out, that the changePitch Macro, developed by Gilles,
>> http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00556
Stefan Thomas wrote:
Dear community,
I found out, that the changePitch Macro, developed by Gilles,
http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00556.html
behaves sometimes a little bit strange, when it is used together with
partcombine.
What's strange about it? Look at the follo
Dear community,
I found out, that the changePitch Macro, developed by Gilles,
http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00556.html
behaves sometimes a little bit strange, when it is used together with
partcombine.
Here is my snippet:
\include "changePitch.ly"
oben = { e''' 4. g'''
Hello!
Yesterday I have noticed some strange behavior with
using sustain pedal marks in midi output during the writing piano piece score.
I have removed some code and left just the minimal
snippet, where this problem appear.
I am not sure, but it seems to me in old lilypond 2.11.0 everything
Hello.
avoid-slur with TextScript objects doen't seem to work a usual :
%
\version "2.11.42"
\relative c'' {
\time 2/4
fis4( f
e ees
\override Voice.TextScript #'avoid-slur = #'inside
d2^\markup \column {\flat \musicglyph #"scripts.trill" }
c4)
}
Howev
:
> Hi,
>
> Appended is an excerpt from my current work where I'm seeing some
> strange behavior of extenders. All three voices use \melisma and
> \melismaEnd, so together with the __ extenders I expected the
> underlines in the lyrics to span measures 2-4 and 6-8 entirely i
Could you please try to update to the latest stable version and see
if things have changed there. I know that there have been some
related bug fixes recently.
/Mats
Catalin Francu wrote:
Hi,
Appended is an excerpt from my current work where I'm seeing some
strange behavior of extenders
Hi,
Appended is an excerpt from my current work where I'm seeing some
strange behavior of extenders. All three voices use \melisma and
\melismaEnd, so together with the __ extenders I expected the
underlines in the lyrics to span measures 2-4 and 6-8 entirely in all
three voices. However,
I try to typeset some piece with wany repeating chords like this:
< c4 e > < c e > < c e > < c e > | < d a > < d a > < d a > < d a > |
< e d > < e d > < e d > < e d > ...
( there is much more repeats of each chord real piece)
To save some typing I try to enter it like this:
\repeat unfold 4 <
41 matches
Mail list logo
