Re: Behaviour of systemStartDelimiter
Le 30/04/2021 à 20:45, Timothy Lanfear a écrit :
I would like a StaffGroup without any systemStartDelimiter -- staves
grouped inside simultaneous music will not do because I would like a
\with clause to modify the context plugins. Unsetting the
systemStartDelimiter does the trick
\new StaffGroup \with { \unset systemStartDelimiter } <<
\new Staff { c''1 }
\new Staff { c''1 }
>>
... but not when when nested inside another StaffGroup
\new StaffGroup <<
\new Staff { c''1 }
\new StaffGroup \with { \unset systemStartDelimiter } <<
\new Staff { c''1 }
\new Staff { c''1 }
>>
>>
Removing the System_start_delimiter_engraver solves the issue, but
maybe there is something to improve here.
\new StaffGroup <<
\new Staff { c''1 }
\new StaffGroup \with { \remove System_start_delimiter_engraver } <<
\new Staff { c''1 }
\new Staff { c''1 }
>>
>>
Hi,
\unset is not really the right tool when
you have not done a \set before.
\omit SystemStartBracket would do the job. However,
removing the engraver as you are doing is really
the nicest solution in my opinion. It causes no grob
to be created at all, instead of merely removing
a grob's stencil, with the grob still potentially
taking space or having other effects.
Best,
Jean
Behaviour of systemStartDelimiter
I would like a StaffGroup without any systemStartDelimiter -- staves
grouped inside simultaneous music will not do because I would like a
\with clause to modify the context plugins. Unsetting the
systemStartDelimiter does the trick
\new StaffGroup \with { \unset systemStartDelimiter } <<
\new Staff { c''1 }
\new Staff { c''1 }
>>
... but not when when nested inside another StaffGroup
\new StaffGroup <<
\new Staff { c''1 }
\new StaffGroup \with { \unset systemStartDelimiter } <<
\new Staff { c''1 }
\new Staff { c''1 }
>>
>>
Removing the System_start_delimiter_engraver solves the issue, but maybe
there is something to improve here.
\new StaffGroup <<
\new Staff { c''1 }
\new StaffGroup \with { \remove System_start_delimiter_engraver } <<
\new Staff { c''1 }
\new Staff { c''1 }
>>
>>
--
Timothy Lanfear, Bristol, UK.
Re: Tempo markings placement for trio music
On Fri, 30 Apr 2021 at 19:55, Rachel Green wrote:
>
> Hi,
> For trios, I would like all the tempo markings to occur both above all
parts (as seen above the flute in the example below) but also right above
the harp part. When I add a tempo marking to the harp part, it places it
above the flute part, but when I add a regular markup to the harp part, the
placement is not correct (too far right). Any ideas how to have tempo
markings in both locations without manually adjusting the placement of each
markup in the harp part?
Hello,
Put a "Metronome_mark_engraver" in your Harp GrandSfaff and
remove "Staff_collecting_engraver" from Score.
You might want to do the same with "Mark_engraver".
Actually this feature is documented for text marks in NR 1.8.1 Writing text
> Text marks > Printing marks on every staff.
http://lilypond.org/doc/v2.23/Documentation/notation/writing-text.html#text-marks
You should update your LilyPond version (there used to be a bug when
putting these engravers at "staff group" levels) and it's better to use
the latest stable or unstable release.
\layout {
\context {
\Score
\remove "Staff_collecting_engraver"
}
}
\score {
<<
\new Staff \with {
instrumentName = "Flute "
} {
<<
\Markings
\Flute
>>
}
\new Staff \with {
instrumentName = "Viola"
} {
\Viola
}
\new GrandStaff \with {
instrumentName = "Harp"
\consists "Metronome_mark_engraver"
% \consists "Mark_engraver"
} <<
\new Staff {
<<
\Treble
\Markings
>>
}
\new Staff {
\Bass
}
>>
>>
}
Cheers,
Xavier
--
Xavier Scheuer
Re: Tempo markings placement for trio music
Hi Rachel,
You can make this work by adding the engraver to the staff you want it
to print above (in this case the harp's upper staff). Based on your
example the code might look something like this:
\new Staff \with {
\consists Mark_engraver
\consists Metronome_mark_engraver
} {
\tempo "Adagio"
\Treble
}
Hope that helps,
Kevin
Re: Tempo markings placement for trio music
Le 30/04/2021 à 19:17, Rachel Green a écrit :
Hi,
For trios, I would like all the tempo markings to occur both above all parts
(as seen above the flute in the example below) but also right above the harp
part. When I add a tempo marking to the harp part, it places it above the flute
part, but when I add a regular markup to the harp part, the placement is not
correct (too far right). Any ideas how to have tempo markings in both locations
without manually adjusting the placement of each markup in the harp part?
Best,
Rachel
Hi,
You'd let the Metronome_mark_engraver operate in
the harp's Staff context in addition tothe Score
context, like this:
\version "2.22.0"
\language "english"
Markings = {
\tempo "Adagio"
s1
}
Flute = \relative c'' {
\clef treble
\key a \major
r1 |
r1 |
}
Viola = \relative c' {
\key a \major
\clef C
r1
fs4
}
Treble = \relative c' {
\clef treble
\time 4/4
\key a \major
r8
}
Bass = \relative c' {
\clef bass
\key a \major
f4
}
<<
\new Staff \with {
instrumentName = Flute
}
\Flute
\new Staff \with {
instrumentName = Viola
}
\Viola
\new GrandStaff \with {
instrumentName = Harp
}
<<
\new Staff \with {
\consists Metronome_mark_engraver
}
<< \Treble \Markings >>
\new Staff \Bass
>>
>>
Please see the documentation about adding and removing
engravers:
http://lilypond.org/doc/v2.22/Documentation/notation/modifying-context-plug_002dins
Best,
Jean
Tempo markings placement for trio music
Hi,
For trios, I would like all the tempo markings to occur both above all parts
(as seen above the flute in the example below) but also right above the harp
part. When I add a tempo marking to the harp part, it places it above the flute
part, but when I add a regular markup to the harp part, the placement is not
correct (too far right). Any ideas how to have tempo markings in both locations
without manually adjusting the placement of each markup in the harp part?
Best,
Rachel
\version "2.19.80"
\language "english"
#(set-global-staff-size 18)
Markings = {
\tempo "Adagio"
s1
}
Flute = \relative c''
{
\clef treble
\key a \major
r1 |
r1 |
}
Viola = \relative c'
{
\key a \major
\clef C
r1
fs4
}
Treble = \relative c'
{
\clef treble
\time 4/4
\key a \major
r8^\markup \bold "Adagio"
}
Bass = \relative c'
{
\clef bass
\key a \major
f4
}
\score {
<<
\new Staff
\with {
instrumentName = #"Flute "
}
{ \Flute }
\new Staff
\with {
instrumentName = #"Viola"
}
{ \Viola }
\new GrandStaff
\with {
instrumentName = #"Harp"
}
<<
\new Staff = spacings \with {
\override VerticalAxisGroup.remove-empty = ##t
\override VerticalAxisGroup.remove-first = ##t }
{
\Markings
}
\new Staff { \Treble }
\new Staff { \Bass }
>>
>>
}
Re: Pitch value of previous note
On Fri, 2021-04-30 at 16:41 +0200, David Kastrup wrote: > David Sumbler writes: > > On Fri, 2021-04-30 at 04:17 -0700, Aaron Hill wrote: > > > A duration without pitch is encoded as a NoteEvent with the > > > pitchproperty. expand-repeat-notes! is the internal procedure > > > thatcarries over the most recent pitch. So long as you insert > > > theseevents early enough, LilyPond should do the heavy lifting > > > for you. > > > > You are correct: I invented a problem where none exists. > > I confess that I had not realized that a duration without a > > precedingpitch or rest takes the pitch of the preceding note. I > > actuallythought that, following a rest, it would produce further > > rests. > > We've had a fairly recent discussion about this design choice > sometimein the last three months or so. My rationale was that it > could be usedfor writing rhythmic parts using only a single pitch or > drum type in amanner where you only had to write that pitch or drum > type once and thenkeep referencing it. That rationale also explains > a difference inbehavior with chord repeats (q) with respect to > retainedarticulations/fingerings. > > I must have seen this in action many times, otherwise I would > > havelots of pitches in my music where there should be rests. But > > somehowit doesn't seem to have lodged itself in my brain. > > Perhaps I'm getting too old for this! > > Still waiting for an actual _example_ of what you want to be able > towrite. As I indicated, I imagined a non-existent problem. With no problem to be solved, an example serves no purpose. David
Re: repeatTie question
On Fri 30 Apr 2021 at 05:31:50 (+), Werner LEMBERG wrote: > > > Okay, so here's a thing: I don't know this term (let vibrate), and > > if I did, I'm not sure how it would apply in this context (it's a > > tie, right?). > > Have you actually looked into the Notation Reference, section 'Ties'? > A few paragraphs after the start of the section you can find > documentation for `\laissezVibrer`! It's ironic that \laissezVibrer follows on directly from \repeatTie on page 57, but you might miss it if the name means nothing to you, and the next illustration doesn't catch your eye. > > There is an example in the Snippets under "Expressive Marks," but > > nothing in the main manual under "Expressive Marks" nor "Long > > Repeats," and I would have never found it. > > Hmm. In the index there is > > tie, in repeats > > which points to the right place. Again, it's ironic that tie, in repeats points to page 155, and the next entry, tie, laissez vibrer is at the top of the next column (pointing to page 57). But when you turn to page 155, the nearest mention of laissez vibrer is a hundred pages away. Of course, the underlying problem is that the name \laissezVibrer is used for two musically opposite effects, so it would obviously help if the index entry tie, in repeats pointed to both \repeatTie and \laissezVibrer. > So please tell us exactly what index entries you were trying to look > up, and which are still missing. [Please use the Notation Reference > for the current development version, 2.23.2, to do that] The page references I gave above are for 2.22.0, the last version that I downloaded as one big tarball. Now turning to 2.23.2, I see that the irony is compounded: \repeatTie has moved to the bottom of page 56, so \laissezVibrer isn't on the same page. However, the index entries do point to the same area, which may or may not help if you don't know the terminology. But I couldn't help noticing that, if you use the Contents rather than the Index, the lengthy section § 1.4 Repeats now doesn't cover ties at all, nor does it point back to Ties (which falls under § 1.2 Rhythms unconnected with repeats). It would be hard to miss the connection if the two examples at pp56–7 were combined on one staff. There's an oblique reference to \repeatTie on page 161 under Known issues and warnings. Might this be preceded by a paragraph on the use of \laissezVibrer and \repeatTie, with a pointer back to pp56–7? BTW I've been using the notation \creepIn for sixty years. Pictorially, it's the reverse of \laissezVibrer. Fortunately for users, LilyPond didn't catch onto the name before deciding on \repeatTie. I see that others are searching for this notation: https://music.stackexchange.com/questions/62495/how-would-you-notate-a-non-accent Cheers, David.
Re: Pitch value of previous note
David Sumbler writes: > On Fri, 2021-04-30 at 04:17 -0700, Aaron Hill wrote: > >> A duration without pitch is encoded as a NoteEvent with the pitch >> property. expand-repeat-notes! is the internal procedure that >> carries over the most recent pitch. So long as you insert these >> events early enough, LilyPond should do the heavy lifting for you. > > You are correct: I invented a problem where none exists. > > I confess that I had not realized that a duration without a preceding > pitch or rest takes the pitch of the preceding note. I actually > thought that, following a rest, it would produce further rests. We've had a fairly recent discussion about this design choice sometime in the last three months or so. My rationale was that it could be used for writing rhythmic parts using only a single pitch or drum type in a manner where you only had to write that pitch or drum type once and then keep referencing it. That rationale also explains a difference in behavior with chord repeats (q) with respect to retained articulations/fingerings. > I must have seen this in action many times, otherwise I would have > lots of pitches in my music where there should be rests. But somehow > it doesn't seem to have lodged itself in my brain. > > Perhaps I'm getting too old for this! Still waiting for an actual _example_ of what you want to be able to write. -- David Kastrup
Re: Pitch value of previous note
On Fri, 2021-04-30 at 04:17 -0700, Aaron Hill wrote:
> On 2021-04-30 3:39 am, David Sumbler wrote:
> > I want to be able to insert a note of the same pitch as the preceding
> > one. I don't mind what form the pitch information is in, so long as I
> > can use it to create a new note. It could, for example, be in the form
> > "b,,", or something similar to "(-2, 6)" as used by ly:make-pitch.
> > There may be other possibilities.
>
> What about the existing pitch-repeating functionality in LilyPond?
>
>
> \version "2.22.0"
>
> foo = { 4 4 }
> { b'2 \foo g' \foo }
>
>
> A duration without pitch is encoded as a NoteEvent with the pitch
> property. expand-repeat-notes! is the internal procedure that carries
> over the most recent pitch. So long as you insert these events early
> enough, LilyPond should do the heavy lifting for you.
You are correct: I invented a problem where none exists.
I confess that I had not realized that a duration without a preceding
pitch or rest takes the pitch of the preceding note. I
actually thought that, following a rest, it would produce further
rests.
I must have seen this in action many times, otherwise I would have lots
of pitches in my music where there should be rests. But somehow it
doesn't seem to have lodged itself in my brain.
Perhaps I'm getting too old for this!
David
Re: Pitch value of previous note
Mark Knoop writes:
> At 12:15 on 30 Apr 2021, David Kastrup wrote:
>> David Sumbler writes:
>>> How can I access the pitch value of this most recent note for use in a
>>> Scheme function after some rests?
>>
>> Other value-propating mechanisms exist for default durations (attached
>> by the parser upon reading expressions), pitch-less durations (added
>> during the scorifying stage when a music expression is accepted into a
>> \score block), chord repeats (also at scorification).
>>
>> "For use in a Scheme function" is too hand-waving to have an idea which
>> phase of LilyPond's interpretation you would want to be interfering
>> with, so it would probably make more sense to present the problem you
>> are trying to solve rather than guess about the tools you think LilyPond
>> must be using internally.
>
> I don't know what David (Sumbler)'s use-case is, but one could imagine
> in an analysis situation something like:
>
> { c'1 g'1-\intervalFunction }
>
> where 'intervalFunction' created the markup string "Perfect 5th above
> previous pitch".
That's the kind of thing where the context available to
\intervalFunction is just not sufficient for the task and it would have
to leave a marker in place that is later on replaced by some more
globally working score-wide function, similar to how repeat pitches and
repeat chords work.
--
David Kastrup
Re: Pitch value of previous note
At 12:15 on 30 Apr 2021, David Kastrup wrote:
David Sumbler writes:
How can I access the pitch value of this most recent note for use in a
Scheme function after some rests?
Other value-propating mechanisms exist for default durations (attached
by the parser upon reading expressions), pitch-less durations (added
during the scorifying stage when a music expression is accepted into a
\score block), chord repeats (also at scorification).
"For use in a Scheme function" is too hand-waving to have an idea which
phase of LilyPond's interpretation you would want to be interfering
with, so it would probably make more sense to present the problem you
are trying to solve rather than guess about the tools you think LilyPond
must be using internally.
I don't know what David (Sumbler)'s use-case is, but one could imagine in an
analysis situation something like:
{ c'1 g'1-\intervalFunction }
where 'intervalFunction' created the markup string "Perfect 5th above previous
pitch".
--
Mark Knoop
Re: Pitch value of previous note
On 2021-04-30 4:17 am, Aaron Hill wrote:
On 2021-04-30 3:39 am, David Sumbler wrote:
I want to be able to insert a note of the same pitch as the preceding
one. I don't mind what form the pitch information is in, so long as I
can use it to create a new note. It could, for example, be in the
form
"b,,", or something similar to "(-2, 6)" as used by ly:make-pitch.
There may be other possibilities.
What about the existing pitch-repeating functionality in LilyPond?
\version "2.22.0"
foo = { 4 4 }
{ b'2 \foo g' \foo }
A duration without pitch is encoded as a NoteEvent with the pitch
property. expand-repeat-notes! is the internal procedure that carries
over the most recent pitch. So long as you insert these events early
enough, LilyPond should do the heavy lifting for you.
Sorry, that was meant to say: "*without* the pitch property".
-- Aaron Hill
Re: Pitch value of previous note
On 2021-04-30 3:39 am, David Sumbler wrote:
I want to be able to insert a note of the same pitch as the preceding
one. I don't mind what form the pitch information is in, so long as I
can use it to create a new note. It could, for example, be in the form
"b,,", or something similar to "(-2, 6)" as used by ly:make-pitch.
There may be other possibilities.
What about the existing pitch-repeating functionality in LilyPond?
\version "2.22.0"
foo = { 4 4 }
{ b'2 \foo g' \foo }
A duration without pitch is encoded as a NoteEvent with the pitch
property. expand-repeat-notes! is the internal procedure that carries
over the most recent pitch. So long as you insert these events early
enough, LilyPond should do the heavy lifting for you.
-- Aaron Hill
Re: Pitch value of previous note
David Sumbler writes:
> On Fri, 2021-04-30 at 12:15 +0200, David Kastrup wrote:
>> David Sumbler writes:
>> > In a \relative{ } passage, in order for Lilypond to work out
>> > theabsolute pitch of a note, it must have a record of the absolute
>> > pitchof the previous note, even if there have been some intervening
>> > rests. It seems probable that it has this information in all cases,
>> > whetherrelative pitch notation is being used or not.
>>
>> No. \relative is a purely transformative function that takes music
>> asinput and produces music (with a wrapping container of
>> typeRelativeOctaveMusic that prevents further applications of
>> \relative fromhaving an effect).
>> This happens immediately as a transform when \relative is
>> beingexecuted.
>> > How can I access the pitch value of this most recent note for use
>> > in aScheme function after some rests?
>>
>> Other value-propating mechanisms exist for default durations
>> (attachedby the parser upon reading expressions), pitch-less
>> durations (addedduring the scorifying stage when a music expression
>> is accepted into a\score block), chord repeats (also at
>> scorification).
>> "For use in a Scheme function" is too hand-waving to have an idea
>> whichphase of LilyPond's interpretation you would want to be
>> interferingwith, so it would probably make more sense to present the
>> problem youare trying to solve rather than guess about the tools you
>> think LilyPondmust be using internally.
>
> I want to be able to insert a note of the same pitch as the preceding
> one.
No, you want LilyPond to do that. But you fail to say when you want it
to do that and why you want it to do that, and why the existing input
methods don't cover it.
> I don't mind what form the pitch information is in, so long as I can
> use it to create a new note. It could, for example, be in the form
> "b,,", or something similar to "(-2, 6)" as used by ly:make-pitch.
> There may be other possibilities.
How about you give an example of what you want to do? As long as you
talk generics about LilyPond internals you assume must be there
somewhere, it is completely impossible to figure out whether one can map
what LilyPond has to what you want to achieve.
--
David Kastrup
Re: Pitch value of previous note
On Fri, 2021-04-30 at 12:15 +0200, David Kastrup wrote:
> David Sumbler writes:
> > In a \relative{ } passage, in order for Lilypond to work out
> > theabsolute pitch of a note, it must have a record of the absolute
> > pitchof the previous note, even if there have been some intervening
> > rests. It seems probable that it has this information in all cases,
> > whetherrelative pitch notation is being used or not.
>
> No. \relative is a purely transformative function that takes music
> asinput and produces music (with a wrapping container of
> typeRelativeOctaveMusic that prevents further applications of
> \relative fromhaving an effect).
> This happens immediately as a transform when \relative is
> beingexecuted.
> > How can I access the pitch value of this most recent note for use
> > in aScheme function after some rests?
>
> Other value-propating mechanisms exist for default durations
> (attachedby the parser upon reading expressions), pitch-less
> durations (addedduring the scorifying stage when a music expression
> is accepted into a\score block), chord repeats (also at
> scorification).
> "For use in a Scheme function" is too hand-waving to have an idea
> whichphase of LilyPond's interpretation you would want to be
> interferingwith, so it would probably make more sense to present the
> problem youare trying to solve rather than guess about the tools you
> think LilyPondmust be using internally.
I want to be able to insert a note of the same pitch as the preceding
one. I don't mind what form the pitch information is in, so long as I
can use it to create a new note. It could, for example, be in the form
"b,,", or something similar to "(-2, 6)" as used by ly:make-pitch.
There may be other possibilities.
David
Re: Pitch value of previous note
David Sumbler writes:
> In a \relative{ } passage, in order for Lilypond to work out the
> absolute pitch of a note, it must have a record of the absolute pitch
> of the previous note, even if there have been some intervening rests.
> It seems probable that it has this information in all cases, whether
> relative pitch notation is being used or not.
No. \relative is a purely transformative function that takes music as
input and produces music (with a wrapping container of type
RelativeOctaveMusic that prevents further applications of \relative from
having an effect).
This happens immediately as a transform when \relative is being
executed.
> How can I access the pitch value of this most recent note for use in a
> Scheme function after some rests?
Other value-propating mechanisms exist for default durations (attached
by the parser upon reading expressions), pitch-less durations (added
during the scorifying stage when a music expression is accepted into a
\score block), chord repeats (also at scorification).
"For use in a Scheme function" is too hand-waving to have an idea which
phase of LilyPond's interpretation you would want to be interfering
with, so it would probably make more sense to present the problem you
are trying to solve rather than guess about the tools you think LilyPond
must be using internally.
--
David Kastrup
Pitch value of previous note
In a \relative{ } passage, in order for Lilypond to work out the
absolute pitch of a note, it must have a record of the absolute pitch
of the previous note, even if there have been some intervening rests.
It seems probable that it has this information in all cases, whether
relative pitch notation is being used or not.
How can I access the pitch value of this most recent note for use in a
Scheme function after some rests?
David
Re: \pushToTag and \appendToTag examples
Gianmaria Lari writes:
>>
>> > Nota bene: I didn't yet add any examples that take advantage of David new
>> > possibilities:
>>
>> Ah, but that was sort of the point.
>>
>
> Sure, I'm sorry :(
> I'll help with that too when I will be able to access this new feature.
>
>> P.S. I would have liked to add a screenshot of the generated output
>> > immediately after each piece of code.
>> > This would make this much more interesting, easy to follow and discuss.
>> But
>> > I remember that on this mailing list pictures have to be attached and not
>> > put inside the mail.
>>
>> I use inline MIME attachments and there are few complaints, but some
>> mail clients do some sort of HTML contraption not working in text mode
>> and those will not make it through a lot of mail clients or mailing list
>> summarisers.
>>
>
> I guessed what the problem was and I hope it will change in the following
> years so that we will be able to write clearer posts.
> For me, reading (and writing) an email with pictures attached is like
> reading a book with numbered photographs placed at the end of the
> book.
"inline attachments" appear where you place them in the text if your
mail reader is not overly weird. Like this:
> But I know that this is an old argument on which many of us are
> hypersensitive. My apologies.
>
>> %%%
>> > \markup {"Simple \appendToTag with {}"}
>> > \version "2.23.2"
>> > music = {c'1 \tag #'here {} c''1}
>> > {\music}
>> > {\appendToTag #'here g'1 \music}
>> > {\pushToTag #'here g'1 \music}
>>
>> Tagging an empty {} and pushing a single element means that there is no
>> visible difference between \appendToTag and \pushToTag .
>>
>
> David, this was the point of the example!
Doesn't really help decision-making, does it?
> You read this short code, you see the output, you think about these
> two things and because of the simplicity of the example you understand
> how it works *without* reading long explanations.
How can you understand what the respective commands do when there isn't
even a difference in the result?
>> > {\appendToTag #'here {e'4 f' g' a'} \music}
>> > {\pushToTag #'here {e'4 f' g' a'} \music}
>>
>> Same here, and the example is more complex than necessary for bringing
>> the point across.
>>
>
> I'm sorry I am of exactly the opposite opinion!
> In the previous example you see the simplest possible \pushToTag and
> \appendToTag example. It adds a single note.
> And now you see an example just a bit more complex with a compound musical
> expression.
It does nothing different from the first example and it still does not
distinguish between \appendToTag and \pushToTag . While regtests do not
suffer from redundance all too much, it does not help. But the manual
already is far too long, so one has to make as little material as
possible count.
>> This at least shows a difference between \appendToTag and \pushToTag
>>
>
> Yes, but this in my opinion makes sense only *after* you saw and you
> understood the other examples.
I don't really think so. There are two differences involved:
a) pushing/appending to a non-empty target leads to different results
b) the commands may be done several times for successive changes
b) may warrant a separate example (it doesn't have one in the current
version of the docs). I don't see a gain for a). When one also
documents pushing of articulations, it is sort of a natural example to
push to a note/chord that has no articulations yet. So then it would
make some sense to illustrate pushing to an empty list (which is less
explicit with articulations and thus more important to illustrate)
there.
> And you compare it with the previous example.
>
>> \markup {"\appendToTag with {} and multiple different tag"}
>> > \version "2.23.2"
>> > music = {c'4 d' e' f' \tag #'firstLocation {}
>> > g' a' b' c'' \tag #'secondLocation {} }
>> > {\music}
>> > {\appendToTag #'secondLocation {d''2 e''} \appendToTag #'firstLocation
>> {g'4
>> > f' g' f'} \music}
>> >
>> > \markup {"\appendToTag with {} and multiple equal tag"}
>> > \version "2.23.2"
>> > music = {c'4 d' e' f' \tag #'firstLocation {}
>> > g' a' b' c'' \tag #'firstLocation {}
>> > b' a' g' f' \tag #'firstLocation {} }
>> > {\music}
>> > {\appendToTag #'firstLocation {g'2 r} \music}
>>
>> This just makes the example more complicated without demonstrating any
>> additional functionality or use. Makes it hard to interpret either
>> manual entry or regtest.
>>
>
> This shows something different and that in my opinion you should know and
> it was not visible in the previous examples.
The "multiple different tag" part is an example more complicated without
demonstrating any additional functionality or use. The "multiple equal
tag" part indeed shows something different. I did not pick this apart
carefully enough.
> If you read it after the previous example you should very easily
> understand it and put it aside for when you will need it.
The notation
Re: skylines and custom-code
Le 05/04/2021 à 12:00, Thomas Morley a écrit :
Hi Jean,
thanks for your reply, though the situation is more complex than the
initial minimal. Consider the following:
{ b'4\glissando 4 4 4 2 b'' }
The plan is to print a glissando from b' to b'' and at intermediate
NoteColumns print a Stem starting at the glissando line, i.e. the
result will be a stemmed Glissando.
(1) Obviously I need the intersection points of the y-axis of the
Stems and the Glissando.
I've coded an engraver to set the relevant pointers (from Stem to
Glissando) and use some calculations to get them. This work is done.
(2) Then I intend to move all NoteHeads of intermediate NoteColumns to
sit on the glissando line, making them transparent (or point-stencil
or omit the stencil)
This would have the advantage that LilyPond could do the rest, i.e.
print Stem, Beam, Script etc accordingly.
Obviously the calculation of the intersection points needs to be done
after the Glissando is printed, thus a simple override for
NoteHead.Y-offset will not work, afaict.
From description in the docs about unpure-pure-containers, this is a
similar situation as for Beams and needed Stem lengths.
Alas, I never came to grips with unpure-pure-containers. Granted, the
explanations/descriptions in the docs improved over the years.
Though, we don't have working coding-examples in the docs, "working"
in the sense of "let me play with the code, testing what happens if I
do this and that":
The example in NR 5.5.6 works with and without unpure-pure-containers.
The example (sort of) in CG 10.13.3 makes no sense to me, at least I
found no situation where "bar" is called at all.
The regtest unpure-pure-container.ly is probably ok as a regtest, it
shows something is done, but why should a user do that at all. As a
user I'd say, don't move the flag if you don't want a moved flag...
That's it for the docs or did I overlook something?
Unpure-pure-containers in LSR: zero
Valentin's example works without unpure-pure-container as well.
Thus, I'm at a loss, close to abandoning the work.
Nevertheless, many thanks,
Harm
P.S. attached an image what works so far (but don't enable skylines)
One month later ...
While researching mailing list archives for unrelated purposes, I
stumbled upon this:
https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg1.html
Cheers,
Jean
Re: \pushToTag and \appendToTag examples
>
> > Nota bene: I didn't yet add any examples that take advantage of David new
> > possibilities:
>
> Ah, but that was sort of the point.
>
Sure, I'm sorry :(
I'll help with that too when I will be able to access this new feature.
> P.S. I would have liked to add a screenshot of the generated output
> > immediately after each piece of code.
> > This would make this much more interesting, easy to follow and discuss.
> But
> > I remember that on this mailing list pictures have to be attached and not
> > put inside the mail.
>
> I use inline MIME attachments and there are few complaints, but some
> mail clients do some sort of HTML contraption not working in text mode
> and those will not make it through a lot of mail clients or mailing list
> summarisers.
>
I guessed what the problem was and I hope it will change in the following
years so that we will be able to write clearer posts.
For me, reading (and writing) an email with pictures attached is like
reading a book with numbered photographs placed at the end of the book.
But I know that this is an old argument on which many of us are
hypersensitive. My apologies.
> %%%
> > \markup {"Simple \appendToTag with {}"}
> > \version "2.23.2"
> > music = {c'1 \tag #'here {} c''1}
> > {\music}
> > {\appendToTag #'here g'1 \music}
> > {\pushToTag #'here g'1 \music}
>
> Tagging an empty {} and pushing a single element means that there is no
> visible difference between \appendToTag and \pushToTag .
>
David, this was the point of the example!
You read this short code, you see the output, you think about these two
things and because of the simplicity of the example you understand how it
works *without* reading long explanations.
> > {\appendToTag #'here {e'4 f' g' a'} \music}
> > {\pushToTag #'here {e'4 f' g' a'} \music}
>
> Same here, and the example is more complex than necessary for bringing
> the point across.
>
I'm sorry I am of exactly the opposite opinion!
In the previous example you see the simplest possible \pushToTag and
\appendToTag example. It adds a single note.
And now you see an example just a bit more complex with a compound musical
expression.
As before, because of the simplicity of the input and the output you should
easily understand it and also easily compare with the previous example.
But we're probably too far in our opinions. I'm not interested in changing
your mind of course. If those examples are not useful I'm sorry and that's
ok.
> \markup {"Nested \appendToTag with {}"}
> > \version "2.23.2"
> > music = {c'1 \tag #'here {} c''1}
> > {\music}
> > {\appendToTag #'here d'4 \appendToTag #'here e'4 \appendToTag #'here f'4
> > \appendToTag #'here g' \music}
> > {\pushToTag #'here d'4 \pushToTag #'here e'4 \pushToTag #'here f'4
> > \pushToTag #'here g' \music}
>
> This at least shows a difference between \appendToTag and \pushToTag
>
Yes, but this in my opinion makes sense only *after* you saw and you
understood the other examples. And you compare it with the previous example.
> \markup {"\appendToTag with {} and multiple different tag"}
> > \version "2.23.2"
> > music = {c'4 d' e' f' \tag #'firstLocation {}
> > g' a' b' c'' \tag #'secondLocation {} }
> > {\music}
> > {\appendToTag #'secondLocation {d''2 e''} \appendToTag #'firstLocation
> {g'4
> > f' g' f'} \music}
> >
> > \markup {"\appendToTag with {} and multiple equal tag"}
> > \version "2.23.2"
> > music = {c'4 d' e' f' \tag #'firstLocation {}
> > g' a' b' c'' \tag #'firstLocation {}
> > b' a' g' f' \tag #'firstLocation {} }
> > {\music}
> > {\appendToTag #'firstLocation {g'2 r} \music}
>
> This just makes the example more complicated without demonstrating any
> additional functionality or use. Makes it hard to interpret either
> manual entry or regtest.
>
This shows something different and that in my opinion you should know and
it was not visible in the previous examples.
If you read it after the previous example you should very easily understand
it and put it aside for when you will need it.
>
> > % I don't see any good reason to use the following.
> > % It mix different things making everything a bit more complex
> > % to understand withouth any advantage (imho).
> > % That's why I'm not sure it makes sense to show it.
> > \markup {"\appendToTag with {some music}"}
> > \version "2.23.2"
> > music = {c'1 \tag #'here {d'2 e'} c''1}
> > {\music}
> > {\pushToTag #'here {f'4 g' a' b'} \music}
> > {\appendToTag #'here {f'4 g' a' b'} \music}
>
> This at least shows a difference between \pushToTag and \appendToTag .
>
The fact that it shows the difference between \pushToTag and \appendToTag
is absolutely not my point. The difference between them is shown in the
previous examples.
Playing with lilypond I personally needed a way to indicate a location
inside a musical expression where I could add some musical material. I have
absolutely no idea if others have the same need or not. But if you have
this specific need then I
Re: repeatTie question
Werner wrote: >> > Have you actually looked into the Notation Reference, section 'Ties'? > A few paragraphs after the start of the section you can find > documentation for `\laissezVibrer`! > May bad. I missed that, and this is exactly the symbol I wanted to use. What I skipped over was the "indicate that notes must not be damped at the end" bit. My use is not related to that at all: I'm in a long repeat and the tie relates to the first note of the next bar, which is back at the start-repeat sign. I am not using a "piano, harp and other string and percussion." My apologies, I mean no offence, I missed seeing the little curved line in the L.v. example and how it might be applied to repeats :-) > So please tell us exactly what index entries you were trying to look > up, and which are still missing. [Please use the Notation Reference > for the current development version, 2.23.2, to do that] > I thought I could find out how to do in the section on "Long Repeats," perhaps showing a snippet. There is an example of \repeatTie in the Ties section when used in the Volta/Alternative but not of using \laissezVibrer to do the same on the first ending. (And I missed the implications of the next paragraph.) So there is no problem, I simply didn't know, couldn't find an answer to my specific question, and asked on the forum where you're meant to ask such questions. My confusion is simply one of terminology and unfamiliarity with lilypond. Kind regards .. mark.
