Re: Lilypond 2.24.1 convert-ly writes version 2.24.0 to the converted file(s)?!
At 17:41 on 01 Mar 2023, Kenneth Wolcott wrote: > Hi; > I think that convert-ly should write the current version to the > converted file(s). > If that statement is correct, then Lilypond version 2.24.1 writes the > older version (2.24.0) to the converted file(s). Please see the -c, --current-version option to convert-ly. -- Mark Knoop
Re: Lilypond 2.24.1 convert-ly writes version 2.24.0 to the converted file(s)?!
Thanks, Jean. That makes sense. But the implication is it should based on the fact that the conversion history shows all the minor versions along the way... Thanks, Ken On Wed, Mar 1, 2023 at 6:05 PM Jean Abou Samra wrote: > > Le mercredi 01 mars 2023 à 17:41 -0800, Kenneth Wolcott a écrit : > > Hi; > > I think that convert-ly should write the current version to the > converted file(s). > > If that statement is correct, then Lilypond version 2.24.1 writes the > older version (2.24.0) to the converted file(s). > > I believe it's intentional. The syntax never changes within a stable release > by definition of a stable release, so convert-ly will never make any > modifications between 2.24.0 and 2.24.1. In other words, converting to 2.24.0 > and converting to 2.24.1 is the same thing. Perhaps it could output \version > "2.24" to avoid this kind of confusion.
Re: Lilypond 2.24.1 convert-ly writes version 2.24.0 to the converted file(s)?!
Le mercredi 01 mars 2023 à 17:41 -0800, Kenneth Wolcott a écrit : > Hi; > > I think that convert-ly should write the current version to the > converted file(s). > > If that statement is correct, then Lilypond version 2.24.1 writes the > older version (2.24.0) to the converted file(s). I believe it's intentional. The syntax never changes within a stable release by definition of a stable release, so convert-ly will never make any modifications between 2.24.0 and 2.24.1. In other words, converting to 2.24.0 and converting to 2.24.1 is the same thing. Perhaps it could output `\version "2.24"` to avoid this kind of confusion. signature.asc Description: This is a digitally signed message part
Lilypond 2.24.1 convert-ly writes version 2.24.0 to the converted file(s)?!
Hi; I think that convert-ly should write the current version to the converted file(s). If that statement is correct, then Lilypond version 2.24.1 writes the older version (2.24.0) to the converted file(s). Here's my test script invocation: ./test_conversion_version.bash | tee ./test_conversion_version.log See attached files. Perhaps I'm imagining things Thanks, Ken Wolcott test_conversion_version.bash Description: Binary data test_conversion_version.log Description: Binary data test_try1.ly Description: Binary data test_try1_converted.ly Description: Binary data test_try1_converted.log Description: Binary data
Re: Tips for code reusability
I concur on entering all music in concert pitch. You may find the
auto-transpose snippet from OpenLilyLib helpful (
https://github.com/openlilylib/oll-misc/tree/master/pitch), as you can
simply write "\transposition bf" instead of wrapping all transposed blocks
in "\transpose x y { }". This is particularly helpful if players may switch
between instruments using different transpositions.
On Wed, Mar 1, 2023 at 5:59 PM Wol wrote:
> On 28/02/2023 22:02, TJ Kolev wrote:
> > I would appreciate any suggestions for the above issues. Or comments on
> > how I am putting together the whole score.
>
> I do a load of brass (and concert) band stuff. And because I play
> trombone I'm sensitive to transposition issues. So I always store my
> parts in variables IN CONCERT PITCH.
>
> When copying from a part, let's say it's a treble-clef trombone part, I
> always wrap it in "\transpose c' bf {}". Then if I want to print a
> treble-clef part I wrap the variable in "\transpose bf c' {}". And while
> it may seem redundant, when printing a bass-clef part I always wrap it
> in "\transpose c c {}".
>
> And I always print parts using "\clef treble_8" or whatever as appropriate.
>
> It means that I have no problem wondering what pitch the original part
> was in - my variables are always concert. I can print it out for eg Sop,
> Repiano or ordinary cornet. I can print trombone parts in bass or treble
> clef. I can shift between Eb, EEb, Bb, BBb basses. Whatever.
>
> If the conductor wants the score all in the same transposition, or in
> the instrument's transposition ...
>
> It's just knowing the internal representation is *always* concert just
> makes my mental gymnastics much simpler.
>
> Cheers,
> Wol
>
>
Re: Tips for code reusability
On 28/02/2023 22:02, TJ Kolev wrote:
I would appreciate any suggestions for the above issues. Or comments on
how I am putting together the whole score.
I do a load of brass (and concert) band stuff. And because I play
trombone I'm sensitive to transposition issues. So I always store my
parts in variables IN CONCERT PITCH.
When copying from a part, let's say it's a treble-clef trombone part, I
always wrap it in "\transpose c' bf {}". Then if I want to print a
treble-clef part I wrap the variable in "\transpose bf c' {}". And while
it may seem redundant, when printing a bass-clef part I always wrap it
in "\transpose c c {}".
And I always print parts using "\clef treble_8" or whatever as appropriate.
It means that I have no problem wondering what pitch the original part
was in - my variables are always concert. I can print it out for eg Sop,
Repiano or ordinary cornet. I can print trombone parts in bass or treble
clef. I can shift between Eb, EEb, Bb, BBb basses. Whatever.
If the conductor wants the score all in the same transposition, or in
the instrument's transposition ...
It's just knowing the internal representation is *always* concert just
makes my mental gymnastics much simpler.
Cheers,
Wol
Re: Tips for code reusability
I did try to do the first note trick, but obviously I didn't get the syntax
right. Got it now.
Didn't get to tags and quoting. Those look very promising. Will
investigate. Thank you for the references!
tjk :)
On Tue, Feb 28, 2023 at 5:50 PM Saul Tobin
wrote:
>
> https://lilypond.org/doc/v2.24/Documentation/notation/writing-parts#quoting-other-voices
> may help with the second question.
>
> On Tue, Feb 28, 2023 at 5:08 PM TJ Kolev wrote:
>
>> Greetings,
>>
>> I've decided to notate a brass band piece from a paper copy into some
>> digital format that would be easier to edit and transform Picked LilyPond
>> and have been using it with Frescobaldi. So far very happy with the whole
>> setup.
>>
>> I did a couple of instruments, and I am feeling my way through it. You
>> can find what I have so far here:
>> https://github.com/tjkolev/MusicScores/tree/develop/DanubeHoro
>>
>> I've been using the documentation a lot, and there are nice examples.
>> However I have some questions I was unable to find answers for. I am hoping
>> to get some ideas from this group.
>>
>> (1) DrumVoice
>> Is there a way to define a default "note" for a drum voice? The piece has
>> the bass drum and cymbal playing the same thing (with a two bar exception).
>> I currently have the music duplicated, both rendering with the "bd" note.
>> It would be nice if each was rendered with its separate note head. I was
>> looking for something like this:
>>
>> \new DrumVoice *bd* { \voiceOne \stemUp \bassncymA ... }
>>> \new DrumVoice *cymc* { \voiceTwo \stemDown \bassncymA ... }
>>
>>
>> Re:
>> https://github.com/tjkolev/MusicScores/blob/develop/DanubeHoro/drums.ly#L211-L212
>>
>> (2) Copy music and replace bars
>> Some of the instruments, for a good part of the piece, play the same
>> notes. Or transposition of some notes. Except here and there for a couple
>> of bars they play different music. I am looking for a way to do something
>> like this:
>>
>> new frenchHornMusic = flugHornMusic.Transpose();
>> flugHornMusic.Replace(bars(10 through 14), { });
>> flugHornMusic.Replace(bars(108 through 114), { });
>>
>> I know I can combine snippets of music, but the above is easier, when
>> only a few bars differ. I am OK writing some custom function, and I looked
>> at the "Extending" documentation. Could not figure out how the music is
>> structured and how to get to the bars (if such an object exists).
>>
>> I would appreciate any suggestions for the above issues. Or comments on
>> how I am putting together the whole score.
>>
>> Cheers!
>> tjk :)
>>
>
Ugly cross-staff beam
I have run into what may be an "ugly" issue, but I thought I'd post here
first.
If you have a group of notes beamed across staves, you sometimes get an
ugly beam slope.
\version "2.25.2"
\score {
\new PianoStaff <<
\new Staff = "upper" {
\voiceOne
\change Staff = "lower"
e16 g
\change Staff = "upper"
e' e'
}
\new Staff = "lower" { \clef bass s4 }
>>
}
(Image attached.) I can fix the beam with Beam.damping or Beam.positions
but the problem is that the piece I'm engraving has this sort of figure
throughout. Adjusting every one of these will quickly become tedious. Any
thoughts on how to fix the beam slope for just the cross-staff beams?
--
Knute Snortum
Re: Change Size of \slashSeparator
very helpful, thx Xavier!
On Wed, 1 Mar 2023 at 13:07, Johannes Roeßler wrote:
>
> Hi List,
>
> how can I change the size of the \slashSeparator?
Hello,
slashSeparator is a markup.
You can scale it for example with the scale command
system-separator-markup = \markup \scale #'(1.5 . 1.5) { \slashSeparator }
% 150% in X and Y, change to your convenience
Or change the definition of slashSeparator, which is
slashSeparator = \markup {
\center-align
\vcenter \combine
\beam #2.0 #0.5 #0.48
\raise #0.7 \beam #2.0 #0.5 #0.48
}
% from ly/titling-init.ly
Cheers,
Xavier
--
Xavier Scheuer
Re: Change Size of \slashSeparator
On Wed, 1 Mar 2023 at 13:07, Johannes Roeßler wrote:
>
> Hi List,
>
> how can I change the size of the \slashSeparator?
Hello,
slashSeparator is a markup.
You can scale it for example with the scale command
system-separator-markup = \markup \scale #'(1.5 . 1.5) { \slashSeparator }
% 150% in X and Y, change to your convenience
Or change the definition of slashSeparator, which is
slashSeparator = \markup {
\center-align
\vcenter \combine
\beam #2.0 #0.5 #0.48
\raise #0.7 \beam #2.0 #0.5 #0.48
}
% from ly/titling-init.ly
Cheers,
Xavier
--
Xavier Scheuer
RE: Printing Chordnames as Roman Numbers
Johan:
Does this work for yoy?
https://lsr.di.unimi.it/LSR/Item?id=907
Mark
From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of Johan
Smolinski
Sent: Wednesday, March 1, 2023 12:54 AM
To: lilypond-user@gnu.org
Subject: Printing Chordnames as Roman Numbers
I asked this in the facebook group, but was rdirected to this mailing list,
so... Here I am. :)
How can I print chordnames as roman numbers relative to given key? For
instance, in key of C (given by \key c \major), I want the chord c:7 printed as
I7 while in key of F, I want c:7 printed as V7.
Bonus:
I asked ChatGPT, and it suggested me to use the \degree command, with an
example that looks really sane. The only problem is that there is no such
command, but I will anyway show the example here, because it is just how I want
it to work:
\version "2.22.1"
\score {
\new ChordNames {
\chordmode {
\degree
{c:maj}
{d:min}
{e:min}
{f:maj}
{g:maj}
{a:min}
{b:dim}
}
}
\layout { }
}
In this example, we use the \chordmode command to specify that we want to
display chord names in roman numeral format. Then we use the \degree command to
specify the degree of each chord relative to the key.
In this case, we're using the key of C major, so we specify the chords as
follows:
c:maj represents a C major chord, which is the I chord in the key of C major.
d:min represents a D minor chord, which is the ii chord in the key of C major.
e:min represents an E minor chord, which is the iii chord in the key of C major.
f:maj represents an F major chord, which is the IV chord in the key of C major.
g:maj represents a G major chord, which is the V chord in the key of C major.
a:min represents an A minor chord, which is the vi chord in the key of C major.
b:dim represents a B diminished chord, which is the vii° chord in the key of C
major.
When you compile this code in Lilypond, you'll get a score with the chord names
displayed as roman numerals relative to the key of C major.
Change Size of \slashSeparator
Hi List, how can I change the size of the \slashSeparator? Best regards Joei
Re: DynamicsStaff spacing itself too far from the music
On Tue, 2023-02-28 at 20:16 +, Timothy Lanfear wrote:
> On 28/02/2023 17:53, Richard Shann wrote:
> In a complex score with a DynamicsStaff placed above the music for
> markups and another below for the dynamics an unusually large space
> opened up below the music and above the dynamics.
> I pared the complex score down to this MWE:
>
> A Dynamics context by default is centred between the staves above
> and below. Adjusting this behaviour might be what you need.
> \version "2.24"
>
> marks = {
> %This line is needed.
> \repeat unfold 40 {s1 }
> }
> music = {
> \repeat unfold 80 {c''1 }
> }
> dyns = {
> \repeat unfold 80 { <> \f c''1 }
> }
> \paper {
> %this line is needed.
> system-system-spacing.minimum-distance = 15
> }
>
> \score {
> << \new Dynamics \with { \override
> VerticalAxisGroup.staff-affinity = #DOWN } <<\marks >>
> \new Staff << \music >>
> \new Dynamics \with { \override
> VerticalAxisGroup.staff-affinity = #UP } << \dyns >>
> >>
> }
>
Thank you very much - it's all clear now.
Richard Shann
Re: Printing Chordnames as Roman Numbers
Le mercredi 01 mars 2023 à 09:54 +0100, Johan Smolinski a écrit :
> I asked this in the facebook group, but was rdirected to this mailing list,
> so... Here I am. :)
>
> How can I print chordnames as roman numbers relative to given key? For
> instance, in key of C (given by \key c \major), I want the chord c:7 printed
> as I7 while in key of F, I want c:7 printed as V7.
You could use a Scheme engraver.
Try this:
```
\version "2.24.1"
\layout {
\context {
\ChordNames
\consists
#(lambda (context)
(let ((tonic #{ c #}))
(make-engraver
((initialize engraver)
(set! (ly:context-property context 'chordRootNamer)
(lambda (pitch capitalized)
(let ((degree (1+ (ly:pitch-notename (ly:pitch-diff pitch
tonic)
(number-format 'roman-upper degree)
(listeners
((key-change-event engraver event)
(set! tonic (ly:event-property event 'tonic)))
}
}
\chords {
a1 b1:m c1 d2:sus4
\key a \minor
a1 b1:m c1 d2:sus4
}
```
HTH,
Jean
signature.asc
Description: This is a digitally signed message part
Printing Chordnames as Roman Numbers
I asked this in the facebook group, but was rdirected to this mailing list,
so... Here I am. :)
How can I print chordnames as roman numbers relative to given key? For
instance, in key of C (given by \key c \major), I want the chord c:7
printed as I7 while in key of F, I want c:7 printed as V7.
Bonus:
I asked ChatGPT, and it suggested me to use the \degree command, with an
example that looks really sane. The only problem is that there is no such
command, but I will anyway show the example here, because it is just how I
want it to work:
\version "2.22.1"
\score {
\new ChordNames {
\chordmode {
\degree
{c:maj}
{d:min}
{e:min}
{f:maj}
{g:maj}
{a:min}
{b:dim}
}
}
\layout { }
}
In this example, we use the \chordmode command to specify that we want to
display chord names in roman numeral format. Then we use the \degree
command to specify the degree of each chord relative to the key.
In this case, we're using the key of C major, so we specify the chords as
follows:
c:maj represents a C major chord, which is the I chord in the key of C
major.
d:min represents a D minor chord, which is the ii chord in the key of C
major.
e:min represents an E minor chord, which is the iii chord in the key of C
major.
f:maj represents an F major chord, which is the IV chord in the key of C
major.
g:maj represents a G major chord, which is the V chord in the key of C
major.
a:min represents an A minor chord, which is the vi chord in the key of C
major.
b:dim represents a B diminished chord, which is the vii° chord in the key
of C major.
When you compile this code in Lilypond, you'll get a score with the chord
names displayed as roman numerals relative to the key of C major.
