Re: The Power of Lilypond

[Kieren MacMillan]

Hi Urs,

> If you do this I'll probably fire up Facebook again. I would specifically 
> stress how the information in the critical report (measure, beat information, 
> instrument, automatic detection of multiple entries in the same measure) is 
> generated directly from the score.

It's done (with permission)!

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Bug? getting the stencil of the stem removes the beam

[Lucas Werkmeister]

Hi,

thanks a lot for looking into this and finding a better implementation!

On 15.03.2018 23:33, Thomas Morley wrote:
> Hi Lucas,
>
> all below under the condition 'if I understand correctly' ;)
>
> 2018-03-15 18:38 GMT+01:00 Lucas Werkmeister :
>> Hi everyone,
>>
>> I was trying to use the \displaceHeads function from snippet 861 [1] [2] on
>> an eight-note chord, but found that it completely removes the beam for some
>> reason.
> Not exactly true.
> The beam _is_ there: this very small line at the very right of the
> resulting pdf (you've cut it off in your image)
Well spotted, and sorry for the incorrect crop :)
>
>> I reduced it down to the following code:
>>
>> \version "2.18.2"
>>
>> {
>>   \tweak before-line-breaking #(lambda (grob)
>>  (ly:grob-property (ly:grob-object grob
>> 'stem) 'stencil))
>>   c'8[ c']
>> }
> That I call a tiny example. I'd love to see more people doing so ;)
>
>> You can find a screenshot of the result at [3]. The function here doesn’t
>> mutate anything,
> Not exactly. The stem-stencil _is_ evaluated!
>
>> but apparently just accessing the stem is enough to render
>> the associated beam invisible
> Not just assessing but evaluating the stencil before-line-breaking and
> the beam is there (see above)
I was thinking in terms of “none of the functions have an exclamation
mark”, but I didn’t think of those pesky side effects!
>
>> (at a guess, I’d say the beam’s stencil is
>> being unset somehow – it still influences the layout otherwise). Is that a
>> bug in LilyPond?
> Not really.
> The Beam needs to set it's related stem-stencils, if a user does it
> 'before-line-breaking as the lsr-snippet does, the procedure setting
> the beam is disturbed.
>
> So far the lsr-snippet is bad.
> Though, in my humble opinion LilyPond should print a meaningful message...
>
>> The \displaceHeads problem was previously reported at [4] (and I’ve added
>> the author to CC for this email), but as far as I can see the thread didn’t
>> go anywhere. (To answer the question in the reply [5] – changing
>> before-line-breaking to after-line-breaking fixes the beam, but also removes
>> the displacement effect, so as far as I can tell you might as well just get
>> rid of the \displaceHeads completely.) I hope the reduced example above will
>> help to get this bug (if it is one) fixed :)
>
> Probably below will help.
> I avoided any stencil-call (not sure whether calling 'direction will
> turn out to be a problem, though)
> The functions `setOtherScriptParent' and `adjustStem' from the
> lsr-snippet would work, but are not used in the example.
>
>
> \version "2.19.65"
>
>
> #(define ((positioning-done move-values) grob)
> ;; TODO whole and longer notes are not special cased
> ;; probably exclude them form the procedure by uncommenting the condition
> ;;
> ;  (if (< (ly:grob-property grob 'duration-log) 1)
> ;  #f
>   (let* ((nc (ly:grob-parent grob X))
>  (grob-ext
>(ly:grob-extent grob nc X))
>  (dir (ly:grob-property grob 'direction))
>  (thick (ly:grob-property grob 'thickness))
>  (stem-ext
>(if (interval-sane? grob-ext)
>grob-ext
>'(0 . 0)))
>  (stem-thick
>(if (zero? (interval-length stem-ext))
>thick
>(* -1 dir (interval-length stem-ext
>  (note-heads-array
>(ly:grob-object grob 'note-heads))
>  (note-heads-list
>(if (ly:grob-array? note-heads-array)
>(ly:grob-array->list note-heads-array)
>'(
>
> (for-each
>   (lambda (note-head v)
> (let* ((nh-ext (ly:grob-extent note-head nc X))
>(nh-x-length (- (cdr nh-ext) (car nh-ext
>
> (ly:grob-translate-axis!
>   note-head
>   (* v (+ nh-x-length (* dir (/ stem-thick 2
>   X)))
>   note-heads-list
>   move-values))
>   ;)
>   #t)
>
>
> chrd =
> <
>   \tweak color #green
>   cis'
>   \tweak color #red
>   dis'
>   \tweak color #blue
>   eis'
>> 8
> {
>   \cadenzaOn
>   \override NoteHead.layer = 500
>   \accidentalStyle forget
>
>   <>^"DEFAULTS"
>   \chrd^[]
>   \chrd_[]
>   <
> \tweak color #green
> cis'
> \tweak color #red
> dis'
> \tweak color #blue
> eis'
>   >1
>
>   \bar "||"
>
>   <>^"TWEAKED"
>   \once \override Stem.positioning-done =
> #(positioning-done
>   '(1 0 1)
>   ;'(0 1 0)
>   )
>   \chrd^[]
>
>   \once \override Stem.positioning-done =
> #(positioning-done
>   ;'(-1 0 -1)
>   ;'(0 -1 0)
>   '(-1 0 -1)
>   )
>   \chrd_[]
>
>   \once \override Stem.positioning-done =
> #(positioning-done
>   ;'(-1 0 -1)
>   ;'(0 -1 0)
>   '(0 -0.668 0)
>   )
>   <
> \tweak color #green
> 

Re: Bug? getting the stencil of the stem removes the beam

[Thomas Morley]

Hi Lucas,

all below under the condition 'if I understand correctly' ;)

2018-03-15 18:38 GMT+01:00 Lucas Werkmeister :
> Hi everyone,
>
> I was trying to use the \displaceHeads function from snippet 861 [1] [2] on
> an eight-note chord, but found that it completely removes the beam for some
> reason.

Not exactly true.
The beam _is_ there: this very small line at the very right of the
resulting pdf (you've cut it off in your image)

> I reduced it down to the following code:
>
> \version "2.18.2"
>
> {
>   \tweak before-line-breaking #(lambda (grob)
>  (ly:grob-property (ly:grob-object grob
> 'stem) 'stencil))
>   c'8[ c']
> }

That I call a tiny example. I'd love to see more people doing so ;)

>
> You can find a screenshot of the result at [3]. The function here doesn’t
> mutate anything,

Not exactly. The stem-stencil _is_ evaluated!

> but apparently just accessing the stem is enough to render
> the associated beam invisible

Not just assessing but evaluating the stencil before-line-breaking and
the beam is there (see above)

> (at a guess, I’d say the beam’s stencil is
> being unset somehow – it still influences the layout otherwise). Is that a
> bug in LilyPond?

Not really.
The Beam needs to set it's related stem-stencils, if a user does it
'before-line-breaking as the lsr-snippet does, the procedure setting
the beam is disturbed.

So far the lsr-snippet is bad.
Though, in my humble opinion LilyPond should print a meaningful message...

>
> The \displaceHeads problem was previously reported at [4] (and I’ve added
> the author to CC for this email), but as far as I can see the thread didn’t
> go anywhere. (To answer the question in the reply [5] – changing
> before-line-breaking to after-line-breaking fixes the beam, but also removes
> the displacement effect, so as far as I can tell you might as well just get
> rid of the \displaceHeads completely.) I hope the reduced example above will
> help to get this bug (if it is one) fixed :)


Probably below will help.
I avoided any stencil-call (not sure whether calling 'direction will
turn out to be a problem, though)
The functions `setOtherScriptParent' and `adjustStem' from the
lsr-snippet would work, but are not used in the example.


\version "2.19.65"


#(define ((positioning-done move-values) grob)
;; TODO whole and longer notes are not special cased
;; probably exclude them form the procedure by uncommenting the condition
;;
;  (if (< (ly:grob-property grob 'duration-log) 1)
;  #f
  (let* ((nc (ly:grob-parent grob X))
 (grob-ext
   (ly:grob-extent grob nc X))
 (dir (ly:grob-property grob 'direction))
 (thick (ly:grob-property grob 'thickness))
 (stem-ext
   (if (interval-sane? grob-ext)
   grob-ext
   '(0 . 0)))
 (stem-thick
   (if (zero? (interval-length stem-ext))
   thick
   (* -1 dir (interval-length stem-ext
 (note-heads-array
   (ly:grob-object grob 'note-heads))
 (note-heads-list
   (if (ly:grob-array? note-heads-array)
   (ly:grob-array->list note-heads-array)
   '(

(for-each
  (lambda (note-head v)
(let* ((nh-ext (ly:grob-extent note-head nc X))
   (nh-x-length (- (cdr nh-ext) (car nh-ext

(ly:grob-translate-axis!
  note-head
  (* v (+ nh-x-length (* dir (/ stem-thick 2
  X)))
  note-heads-list
  move-values))
  ;)
  #t)


chrd =
<
  \tweak color #green
  cis'
  \tweak color #red
  dis'
  \tweak color #blue
  eis'
>8

{
  \cadenzaOn
  \override NoteHead.layer = 500
  \accidentalStyle forget

  <>^"DEFAULTS"
  \chrd^[]
  \chrd_[]
  <
\tweak color #green
cis'
\tweak color #red
dis'
\tweak color #blue
eis'
  >1

  \bar "||"

  <>^"TWEAKED"
  \once \override Stem.positioning-done =
#(positioning-done
  '(1 0 1)
  ;'(0 1 0)
  )
  \chrd^[]

  \once \override Stem.positioning-done =
#(positioning-done
  ;'(-1 0 -1)
  ;'(0 -1 0)
  '(-1 0 -1)
  )
  \chrd_[]

  \once \override Stem.positioning-done =
#(positioning-done
  ;'(-1 0 -1)
  ;'(0 -1 0)
  '(0 -0.668 0)
  )
  <
\tweak color #green
cis'
\tweak color #red
dis'
\tweak color #blue
eis'
  >1
}

Not tested beyond the given examples, though.


Best,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: The Power of Lilypond

[Craig Dabelstein]

Hi Urs,

I'll definitely write you a post for the Scores of Beauty page. I'll start
this weekend.

Thanks again for all your help. I appreciate it.

Craig


On 15 March 2018 at 08:10, Urs Liska  wrote:

> Hi Craig,
>
> Am 14.03.2018 um 21:13 schrieb Craig Dabelstein:
>
> Hi all,
>
> I thought some of you might like to see this document. It uses Scholarly,
> Lilyglyphs and lyluatex all in the ONE document. It's a huge leap forward!
> It has saved heaps of time and avoided the mess of multiple files and
> having to concatenate them together as a PDF.
>
> A huge thank you to all the developers who make this kind of thing
> possible.
>
> The document is the opening pages of a new Critical Edition of a score by
> Catel from the French Revoution.
>
> https://www.dropbox.com/s/meloxafms99i174/catel%20comp.pdf?dl=0
>
>
> It makes me really happy to look at this document, thanks so much for
> sharing! Even on this list we rarely get the opportunity to see finished
> products with the whole context.  But of course it makes me particularly
> happy to see some of my work bearing fruits and helping others to produce
> beautiful volumes.
>
> Maybe it would be a great thing if you could write a blog post about this
> work describing in not-too-much depth the different technologies that play
> together here. I think this would be a strong complement to the more
> theoretical posts about the advantages of our set of tools and would make a
> good item one could easily refer to.
>
> Best
> Urs
>
>
> All the best,
>
> Craig
>
>
> --
> *Craig Dabelstein*
> Maxime's Music
> craig.dabelst...@gmail.com
> *http://maximesmusic.com *
>
>
> ___
> lilypond-user mailing 
> listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>


-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Bug? getting the stencil of the stem removes the beam

[Lucas Werkmeister]

Hi everyone,

I was trying to use the \displaceHeads function from snippet 861 [1] [2]
on an eight-note chord, but found that it completely removes the beam
for some reason. I reduced it down to the following code:

\version "2.18.2"

{
  \tweak before-line-breaking #(lambda (grob)
 (ly:grob-property (ly:grob-object grob
'stem) 'stencil))
  c'8[ c']
}

You can find a screenshot of the result at [3]. The function here
doesn’t mutate anything, but apparently just accessing the stem is
enough to render the associated beam invisible (at a guess, I’d say the
beam’s stencil is being unset somehow – it still influences the layout
otherwise). Is that a bug in LilyPond?

The \displaceHeads problem was previously reported at [4] (and I’ve
added the author to CC for this email), but as far as I can see the
thread didn’t go anywhere. (To answer the question in the reply [5] –
changing before-line-breaking to after-line-breaking fixes the beam, but
also removes the displacement effect, so as far as I can tell you might
as well just get rid of the \displaceHeads completely.) I hope the
reduced example above will help to get this bug (if it is one) fixed :)

An ugly workaround (back at the \displaceHeads level) is to remove all
the stem-related code and instead hard-code a value for the stem width –
the default seems to be 0.065. For convenience, you can find the result
at [6]. (If your stem width is different, take the original function,
replace the ly:grob-translate-axis! call with (display x-corr) in order
to print the correct value, and then substitute that.)

Cheers,
Lucas

[1]: http://lsr.di.unimi.it/LSR/Item?id=861
[2]: http://lsr.di.unimi.it/LSR/Snippet?id=861
[3]: https://i.imgur.com/hslsBDG.png
[4]: https://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00214.html
[5]: https://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00220.html
[6]:
https://gist.github.com/lucaswerkmeister/5ae87eaa3695b8a39f5d1e05bc9b077c

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Edition Engraver bug?

[Stefano Troncaro]

It's strange, I tested with a project that had some "rebel ties", commented
out the previous fix and used \tieDown, and the ties went in the direction
I wanted them to... I'll have to look at it in more detail, but it must
surely be my fault, I must have missed something.
However in the example above it does work exactly as you mention it does. I
think the warnings are ok, they are kind of verbose, but it is telling you
"find another way to do this!" so I think the verbosity is useful.

2018-03-15 11:57 GMT-03:00 Jan-Peter Voigt :

> Hi Stéfano,
>
> I tested with the force-rebel-tie.ly file you sent earlier in this
> thread. What I meant was that \tieDown still does have no effect, when
> there is a \voiceOne statement - maybe hidden via << \\ >>. So the first
> tie is not changed with the EE-mod in the demo.
> Do you think the warnings are too verbose?
>
>
> Am 14.03.2018 um 21:47 schrieb Stefano Troncaro:
>
> I wanted to let you know that I have tried the refactor-override branch
> and the overrides seem to be working fine! I do get a lot of warnings as
> you explained, but it does not appear the the EE overrides are getting
> overwritten, or maybe I'm misunderstanding your explanation?
>
> 2018-03-13 13:50 GMT-03:00 Stefano Troncaro :
>
>> Hi Jan-Peter,
>>
>> Thank you for your work! I will test the changes later today and let you
>> know how it results.
>>
>> 2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt :
>>
>>> Am 13.03.2018 um 11:37 schrieb David Kastrup:
>>>
 Jan-Peter Voigt  writes:

 Hi Stefano,
>
> I have been looking into the issue and created a branch
> 'refactor-override' for the edition-engraver.
> The following is changed in there:
> * Overrides are not applied "by hand" but send as a StreamEvent so
> that once is handled by lily and not the EE
> * Override (and Revert, Set, Unset) sent by the EE are marked so that
> they can be distinguished from other overrides
>
> That means once-overrides are note reverted wrong anymore and the EE
> gives a warning if an overrides supersedes/overwrites an EE mod. This
> is still not completely satisfactory when the EE shall override all
> other settings. But at least it doesn't revert wrong.
>
> If this branch is tested more thoroughly I will merge it into master.
> Now I am looking for a way to let the EE be the last broadcaster so
> that it will not be overridden by overrides sent from the actual music
> stream.
>

 How do you trigger the EE?  Overrides from the music stream are sent by
 the iterators.  That's after start-translation-timestep and before
 process-music.

>>>
>>> The EE broadcasts overrides (events) inside start-translation-timestep.
>>> I tried to do it in process-music, but then they were applied too late.
>>> The EE is looking in its internal mod-store if there is something to do
>>> for this timestep (for this context). Is there a way to act between those
>>> slots - the latest action before process-music?
>>>
>>>
>>> ___
>>> lilypond-user mailing list
>>> lilypond-user@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Edition Engraver bug?

[Jan-Peter Voigt]

Hi Stéfano,

I tested with the force-rebel-tie.ly file you sent earlier in this 
thread. What I meant was that \tieDown still does have no effect, when 
there is a \voiceOne statement - maybe hidden via << \\ >>. So the first 
tie is not changed with the EE-mod in the demo.

Do you think the warnings are too verbose?

Am 14.03.2018 um 21:47 schrieb Stefano Troncaro:
I wanted to let you know that I have tried the refactor-override 
branch and the overrides seem to be working fine! I do get a lot of 
warnings as you explained, but it does not appear the the EE overrides 
are getting overwritten, or maybe I'm misunderstanding your explanation?


2018-03-13 13:50 GMT-03:00 Stefano Troncaro >:


Hi Jan-Peter,

Thank you for your work! I will test the changes later today and
let you know how it results.

2018-03-13 7:47 GMT-03:00 Jan-Peter Voigt >:

Am 13.03.2018 um 11:37 schrieb David Kastrup:

Jan-Peter Voigt >
writes:

Hi Stefano,

I have been looking into the issue and created a branch
'refactor-override' for the edition-engraver.
The following is changed in there:
* Overrides are not applied "by hand" but send as a
StreamEvent so
that once is handled by lily and not the EE
* Override (and Revert, Set, Unset) sent by the EE are
marked so that
they can be distinguished from other overrides

That means once-overrides are note reverted wrong
anymore and the EE
gives a warning if an overrides supersedes/overwrites
an EE mod. This
is still not completely satisfactory when the EE shall
override all
other settings. But at least it doesn't revert wrong.

If this branch is tested more thoroughly I will merge
it into master.
Now I am looking for a way to let the EE be the last
broadcaster so
that it will not be overridden by overrides sent from
the actual music
stream.


How do you trigger the EE?  Overrides from the music
stream are sent by
the iterators.  That's after start-translation-timestep
and before
process-music.


The EE broadcasts overrides (events) inside
start-translation-timestep. I tried to do it in process-music,
but then they were applied too late.
The EE is looking in its internal mod-store if there is
something to do for this timestep (for this context). Is there
a way to act between those slots - the latest action before
process-music?


___
lilypond-user mailing list
lilypond-user@gnu.org 
https://lists.gnu.org/mailman/listinfo/lilypond-user






___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing email address

[David Wright]

On Thu 15 Mar 2018 at 07:12:35 (+), Mark Austin wrote:
> How is this done?

Subscribe with the new address (making sure you send to the
foo-request address and not foo itself), submit and
confirmations, wait for postings to arrive ok, then
unsubscribe the old address *from the old address* using
-request again.

If the old address is inaccessible, it can sometimes be
a little awkward, so it's best done before you lose it.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing email address

[Ben]

On 3/15/2018 3:12 AM, Mark Austin wrote:

How is this done?



Hi Mark,

I assume you mean changing your address / how it relates to this mailing 
list?


https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Transposing Keyless Brass Parts

[Shevek]

For my brass parts, I use the OpenLilyLib auto-transpose snippet, and \remove
Key_engraver.



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Thriple flat/sharp glyphs...

[David Kastrup]

Torsten Hämmerle  writes:

> Werner LEMBERG wrote
>>> I just used \score inside a custom markup-command and set the size
>>> by \layout { #(layout-set-staff-size design_size) }
>>> 
>>> It looks as if #(layout-set-staff-size) doesn't scale down all the
>>> distances.
>> 
>> I think this behaviour is correct – the idea is to have staves with
>> different sizes aligned vertically.
>
> The behaviour is correct for a score with mixed-size staves, I agree.
> But the documentation uses #(layout-set-staff-size ...) directly in the
> \layout block at the very end of the score. This suggests that the command
> is meant for the whole score in this case.
> But I'll take a closer look at this on occasion bevor filing a bug report.

Please note that there is also score markup.  I don't want to imply that
score markup is currently being scaled correctly (this turned out a
surprisingly icky thing) but there are uses for them (like trill
executions which should likely not reserve space in the original score)
that might warrant this kind of command.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Thriple flat/sharp glyphs...

[Torsten Hämmerle]

Werner LEMBERG wrote
>> I just used \score inside a custom markup-command and set the size
>> by \layout { #(layout-set-staff-size design_size) }
>> 
>> It looks as if #(layout-set-staff-size) doesn't scale down all the
>> distances.
> 
> I think this behaviour is correct – the idea is to have staves with
> different sizes aligned vertically.

The behaviour is correct for a score with mixed-size staves, I agree.
But the documentation uses #(layout-set-staff-size ...) directly in the
\layout block at the very end of the score. This suggests that the command
is meant for the whole score in this case.
But I'll take a closer look at this on occasion bevor filing a bug report.



Werner LEMBERG wrote
> There is still one thing that surprises me: The
> distances between accidentals and noteheads increase for smaller
> sizes.  Comparing, say, `feta13' with `feta26', you can see that the
> whitespace before accidentals increases at smaller sizes also.  I'm
> not sure that I really like this for all circumstances.
> [...]

In any case, this is actually standard LilyPond and has nothing to do with
our new accidental glyphs.
To demonstrate this (and the differences between design sizes Abraham and
myself have been referring to), I've set up a tiny example in a totally out
of the box LilyPond 2.19.81 in my Windows 10 installation:

It's driving me nuts that I don't seem to capable of showing different stave
sizes in one PDF without having strange spacing issues:

 BEGIN SNIPPET
\version "2.19.81"

\layout { indent = 0 }

music = \relative c' { c8. ees16( fis8. a16 b8.) gis16 f8. d16 }

\markup \column {
  \score {
\new Staff \with { \magnifyStaff #11/20 } \music
  }
  \scale #'(11/20 . 11/20) \score {
\new Staff \music
  }
}
 END SNIPPET


 

Next, I compared the output of \magnifyStaff to an "ordinary" file using
#(set-global-staff-size 11) using layout control features (all in the
2.19.81 Windows installation).
So the spacing issues you still have are really non-intentional and I'm
currently unsure how to obtain a realistic and natural spacing for the
design size comparisons. Bugger!

 

All the values shown may be scaled, ok, but you'd expect a factor of 0.55
(11/20), but no.
Probably some magstep rounding issues involved, but this cannot be the only
cause.

All the best,
Torsten

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Transposing Keyless Brass Parts

[Torsten Hämmerle]

Glassmenagerie wrote
> The Bb trumpet player would need to transpose
> up 7 intervals on the fly.  There is no key signature.  Quite a challenge
> for amateur players.  
> I'd like the best way to arrive at the correct notes and key signature for
> the Bb trumpet. 

Hi,

Traditionally, there are certain instruments in an orchestral score that
don't have a key signature, e.g. Timpani, Glockenspiel, Horns and sometimes
Trumpets.

The reason why Horns and Trumpets don't have a general key signature goes
back to the times when there were no valves, i.e. you only could play tones
of the harmonic series and you had to use a different instrument for each
key (hence trumpets in D, trumpets in A, trumpets in F, etc.)

Now that trumpets and French horns have valves, there is no reason not to
use key signatures and exclusively score "trumpet in Bb" and "horn in F".

Professional players are being used to on-the-fly transposition because they
just need to be able to play from traditional/old sheet music.
But, in my opinion, you can't expect that from amateur players, and when
setting a new score, there is no reason why you shouldn't use key signatures
for these instruments.


Slavonic Dance III trumpet part

I like coding sounding pitch. But, if it's easier for you, you might prefer
just copying the original.
As has been proposed by Jay, you might use Frescobaldi to convert it to
concert pitch.
It's just a matter of personal preference.

>From there, it's easy to have it transposed to wherever you want.
As an example, I stuck with your transposed coding (in F) and applied a
\transpose c' f' to get sounding pitch. From there, it's much less confusing
if you can start from sounding pitch, imho.

After that, I've set up several versions, including the original trumpet in
F (w/o key signature), trumpet in F (with key sig.), trumpet in Bb (with key
sig.) and Concert Pitch (with key sig.).

% START SNIPPET

\version "2.18.2"

trumpetI_III_F = \transpose c' f' \relative g' {
  \time 2/4
%  \key es \major
  g8[-.\p g ( aes ) aes] (
  g ) g4  g8 (
  f ) f4 f8 (
  g\<[ ) g ( f\> ees]\! )
  d4 ( c
  bes2 )
  \bar "|."
}

\score {
  <<
\new Staff \with { instrumentName = #"in F" } \transpose f' c'
\trumpetI_III_F
\new Staff \with { instrumentName = #"in F" } \transpose f' c' { \key as
\major \trumpetI_III_F }
\new Staff \with { instrumentName = #"in Bb" } \transpose bes c' { \key
as \major \trumpetI_III_F }
\new Staff \with { instrumentName = #"sounding" } { \key as \major
\trumpetI_III_F }
  >>
}

% END SNIPPET

 

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing email address

[David Kastrup]

Mark Austin  writes:

> How is this done?

Like with basically any mailing list, letting the full headers of any
mail from it displayed will give you the links you need.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Changing email address

[Mark Austin]

How is this done?

-- 
Mark Austin

--
For Whigs admit no force but argument
--

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Thriple flat/sharp glyphs...

[Werner LEMBERG]

> I just used \score inside a custom markup-command and set the size
> by \layout { #(layout-set-staff-size design_size) }
> 
> It looks as if #(layout-set-staff-size) doesn't scale down all the
> distances.

I think this behaviour is correct – the idea is to have staves with
different sizes aligned vertically.

> The funny thing is that the "Notation" document claims Known issues
> and warnings: "layout-set-staff-size does not change the distance
> between the staff lines."
> 
> As far as I can see it at the moment, the distance between staff
> lines seems to be one of the few distances it does change.

If you can provide a small MWE I suggest you file a documentation bug
report.

>   
> Now, the spacing looks much (!) better.

Indeed, thanks.  There is still one thing that surprises me: The
distances between accidentals and noteheads increase for smaller
sizes.  Comparing, say, `feta13' with `feta26', you can see that the
whitespace before accidentals increases at smaller sizes also.  I'm
not sure that I really like this for all circumstances.

Pro: It improves appearance if you combine larger and smaller staves.

Con: Pocket scores would have more horizontal whitespace available for
 formatting if accidentals have less whitespace at the left and
 right side.  I will have a look in some manually engraved pocket
 scores to check this.


   Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Transposing Keyless Brass Parts

[Jay Anderson]

On Wed, Mar 14, 2018 at 2:48 PM, Glassmenagerie 
wrote:

> Here are a few measures of the 1st trumpet part in F of the 3rd dance of
> the
> Dvorak Slavonic Dances, Op46.  The Bb trumpet player would need to
> transpose
> up 7 intervals on the fly.  There is no key signature.  Quite a challenge
> for amateur players.  The concert key starts out in Ab, changes to C at mm.
> 66, then back to Ab at mm. 110.  I'd like the best way to arrive at the
> correct notes and key signature for the Bb trumpet.
>

The docs are always a good starting point:
http://lilypond.org/doc/v2.18/Documentation/notation/displaying-pitches#instrument-transpositions


Without looking at your example there are a few ways:

1) Write out the notes you want (Frescobaldi can transpose the notes in the
source).
2) Use /transpose to move the notes to what you want the players to read.
3) Use /transposition f in conjunction with some auto-transposition
libraries:
https://github.com/openlilylib/openlilylib/tree/master/editorial-tools/auto-transpose
.

I would suggest not using a key signature in either the original or the
transposed version for a trumpet part, but if you really want that you
could use tags (or the fancy edition engraver that's all the rage these
days: https://github.com/openlilylib/edition-engraver).

-Jay
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user