Merging notes and shiftOn
In the documentation on collision resolution
(http://lilypond.org/doc/v2.15/Documentation/notation/multiple-voices#collision-resolution),
it states: The \shiftOn command allows (but does not force) the notes
in a voice to be shifted. When \shiftOn is applied to a voice, a note or
chord in that voice is shifted *only* if its stem would otherwise
collide with a stem from another voice, and only if the colliding stems
point in the same direction. (the emphasis on *only* is mine).
However, in the example below, where I have to use shiftOff in the
middle voice (to get the two F notes to merge) and shiftOn in the treble
voice (to prevent the merged half notes from having their heads filled
in), the two A half notes in the treble voice *are* being shifted,
though from my reading of the sentence quoted above, the shift is not
needed.
\version 2.15.38
treble = \relative c''' {
\shiftOn
a2 a
}
bass = \relative c' {
f2 f
}
middle = \relative c' {
\shiftOff f8[ c'] b c f,[ c'] b c
}
\score {
\new Staff {
\clef treble
\mergeDifferentlyHeadedOn
\context Voice = 1 { \voiceOne \treble }
\context Voice = 2 { \voiceTwo \bass }
\context Voice = 3 { \voiceThree \middle }
}
\layout { }
}
attachment: test.png___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: musicxml2ly
On Sun, 8 Apr 2012, Martin Tarenskeen wrote: The good news is that in many cases only a little editing of the .ly file is required to turn a bad conversion into a good one. For example, all lead sheets from Wikifonia that I have tried have the Chords printed below instead of above the staff. I remember this had been fixed in one of the previous lilypond 2.15.x versions, but with musicxml2ly from Lilypond 2.15.37 I am still (again?) having this problem. -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Merging notes and shiftOn
On 12/05/12 16:06, Nick Payne wrote:
In the documentation on collision resolution
(http://lilypond.org/doc/v2.15/Documentation/notation/multiple-voices#collision-resolution),
it states: The \shiftOn command allows (but does not force) the notes
in a voice to be shifted. When \shiftOn is applied to a voice, a note
or chord in that voice is shifted *only* if its stem would otherwise
collide with a stem from another voice, and only if the colliding
stems point in the same direction. (the emphasis on *only* is mine).
However, in the example below, where I have to use shiftOff in the
middle voice (to get the two F notes to merge) and shiftOn in the
treble voice (to prevent the merged half notes from having their heads
filled in), the two A half notes in the treble voice *are* being
shifted, though from my reading of the sentence quoted above, the
shift is not needed.
\version 2.15.38
treble = \relative c''' {
\shiftOn
a2 a
}
bass = \relative c' {
f2 f
}
middle = \relative c' {
\shiftOff f8[ c'] b c f,[ c'] b c
}
\score {
\new Staff {
\clef treble
\mergeDifferentlyHeadedOn
\context Voice = 1 { \voiceOne \treble }
\context Voice = 2 { \voiceTwo \bass }
\context Voice = 3 { \voiceThree \middle }
}
\layout { }
}
p.s. I have just found out that if I replace \shiftOn with \shiftOn
\override NoteColumn #'force-hshift = #0, then the notes in the treble
voice do not actually get moved, and I still get the correct merging of
the notes in the other voices. However, it still seems that the
documentation does not correctly describe how shiftOn actually behaves.
Nick
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: musicxml2ly
On Sat, 12 May 2012, Martin Tarenskeen wrote: On Sun, 8 Apr 2012, Martin Tarenskeen wrote: The good news is that in many cases only a little editing of the .ly file is required to turn a bad conversion into a good one. For example, all lead sheets from Wikifonia that I have tried have the Chords printed below instead of above the staff. I remember this had been fixed in one of the previous lilypond 2.15.x versions, but with musicxml2ly from Lilypond 2.15.37 I am still (again?) having this problem. Same with 2.15.38 -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Merging notes and shiftOn
Nick Payne wrote Saturday, May 12, 2012 7:23 AM
On 12/05/12 16:06, Nick Payne wrote:
In the documentation on collision resolution
(http://lilypond.org/doc/v2.15/Documentation/notation/multiple-voices#collision-resolution),
it states: The \shiftOn command allows (but does not force) the notes in
a voice to be shifted. When \shiftOn is applied to a voice, a note or
chord in that voice is shifted *only* if its stem would otherwise collide
with a stem from another voice, and only if the colliding stems point in
the same direction. (the emphasis on *only* is mine).
However, in the example below, where I have to use shiftOff in the middle
voice (to get the two F notes to merge) and shiftOn in the treble voice
(to prevent the merged half notes from having their heads filled in), the
two A half notes in the treble voice *are* being shifted, though from my
reading of the sentence quoted above, the shift is not needed.
\version 2.15.38
treble = \relative c''' {
\shiftOn
a2 a
}
bass = \relative c' {
f2 f
}
middle = \relative c' {
\shiftOff f8[ c'] b c f,[ c'] b c
}
\score {
\new Staff {
\clef treble
\mergeDifferentlyHeadedOn
\context Voice = 1 { \voiceOne \treble }
\context Voice = 2 { \voiceTwo \bass }
\context Voice = 3 { \voiceThree \middle }
}
\layout { }
}
p.s. I have just found out that if I replace \shiftOn with \shiftOn
\override NoteColumn #'force-hshift = #0, then the notes in the treble
voice do not actually get moved, and I still get the correct merging of
the notes in the other voices. However, it still seems that the
documentation does not correctly describe how shiftOn actually behaves.
You're right. In your example the stems don't actually collide
because of the large vertical separation, but their note columns
still clash. Perhaps we should change collide to align and
colliding to aligning in the text. Maybe we need to add a
bit about force-hshift not being overridden too, which seems
a good work-around in this situation.
Ideally the code should be amended to test for a vertical
separation sufficiently large to avoid the stems overlapping,
in which case a shift would not be needed, and then the text
as written would be correct.
Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
Hi David, Hi Thomas, thank you very much! I'm increasingly fascinated by LilyPond - and this mailing list. And I'll definitely have to learn how to write Scheme functions myself ... With your suggestions I can really solve the problem at hand, so thanks. What I especially like about the new solution is that it automatically uses the original Stem's thickness (so it's independent from overrides. Maybe it would be nice to be able to use this more generally (as a \stemDashed command). But for this it shouldn't have a fixed number of dashes but rather a consistent dash pattern (independent from the Stem's length. Although I don't really understand the function, I assume that the original Stem's length is already used. So it should be quite simple to use this and calculate the dashes from that? I don't expect to be able to apply such complex operations as curve's 'dash-definition. But if one would use two variables that are defined in the function's file one could then redefine them in the music file. But as said, for my actual task I can very well use it as it is and just decide upon the number of dashes manually. Best Urs Am 12.05.2012 04:57, schrieb David Nalesnik: Hi Harm, I suggest the code below. It's very close to your own but it seems to avoid the problems. When I tried your code out, the same problems happened for me! I concluded that this is an issue with the viewer in LilyPondTool, and sure enough, when I view PDF with external PDF-viewer, the problem disappears, and I see all 20 line segments with both your version and mine too. Certain aspects of your rewrite are clearer than mine--thank you! Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
LilyPond wins LoMuS 2012!
Hey LilyPond users, I have an exciting piece of news to share with you. LilyPond won LoMuS 2012, one of the most prestigious awards in the open source community for musical software. http://concours.afim-asso.org/ All of you should be very proud, as your work with LilyPond helps those who develop the program make it a better piece of software. Tweet the news far and wide! It would be wonderful if the community of users grew as a result of this award. Cheers, Mike Begin forwarded message: From: Thierry Coduys thierry.cod...@le-hub.org Subject: LoMus 2012 Date: 12 mai 2012 12:15:03 HAEC To: m...@mikesolomon.org Dear Mike, The jury wishes to congratulate you on your LilyPond open source software, that won the First Prize at the LoMus 2012 contest. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond wins LoMuS 2012!
2012/5/12 m...@apollinemike.com m...@apollinemike.com: Hey LilyPond users, I have an exciting piece of news to share with you. LilyPond won LoMuS 2012, one of the most prestigious awards in the open source community for musical software. http://concours.afim-asso.org/ All of you should be very proud, as your work with LilyPond helps those who develop the program make it a better piece of software. Tweet the news far and wide! It would be wonderful if the community of users grew as a result of this award. Cheers, Mike Begin forwarded message: From: Thierry Coduys thierry.cod...@le-hub.org Subject: LoMus 2012 Date: 12 mai 2012 12:15:03 HAEC To: m...@mikesolomon.org Dear Mike, The jury wishes to congratulate you on your LilyPond open source software, that won the First Prize at the LoMus 2012 contest. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user Wow! Congratulations! -Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond wins LoMuS 2012!
On Sat, May 12, 2012 at 1:41 PM, m...@apollinemike.com m...@apollinemike.com wrote: Hey LilyPond users, I have an exciting piece of news to share with you. LilyPond won LoMuS 2012, one of the most prestigious awards in the open source community for musical software. Congratulations!! Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
Hi,
On Sat, May 12, 2012 at 3:05 AM, Urs Liska li...@ursliska.de wrote:
Hi David, Hi Thomas,
thank you very much!
I'm increasingly fascinated by LilyPond - and this mailing list.
And I'll definitely have to learn how to write Scheme functions myself ...
With your suggestions I can really solve the problem at hand, so thanks.
What I especially like about the new solution is that it automatically
uses the original Stem's thickness (so it's independent from overrides.
Maybe it would be nice to be able to use this more generally (as a
\stemDashed command). But for this it shouldn't have a fixed number of
dashes but rather a consistent dash pattern (independent from the Stem's
length. Although I don't really understand the function, I assume that the
original Stem's length is already used. So it should be quite simple to use
this and calculate the dashes from that?
I don't expect to be able to apply such complex operations as curve's
'dash-definition. But if one would use two variables that are defined in
the function's file one could then redefine them in the music file.
I've come up with a simpler variant which makes use of the 'dashed-line
function. (I didn't use this initially because I couldn't figure out how
to get the roundedness of the line segments to match the ordinary stem's
and also because I wanted to ensure a full-length dash at top and bottom.)
These functions require two arguments: one for the length of the dash and
one for the length of the spaces in between. Setting values might require
some trial and error. Some combinations won't fit the length of the stem
such that a segment appears at its end.
See what you think!
\version 2.15.38
#(define (dashed-stem on off)
(lambda (grob)
(let* ((stencil (ly:stem::print grob))
(X-ext (ly:stencil-extent stencil X))
(Y-ext (ly:stencil-extent stencil Y))
(width (interval-length X-ext))
(len (interval-length Y-ext)))
(ly:output-def-set-variable! (ly:grob-layout grob) 'blot-diameter
0.08)
(ly:stencil-translate
(ly:make-stencil
`(dashed-line ,width ,on ,off 0 ,len 0))
(cons 0 (interval-start Y-ext))
dashedStem =
#(define-music-function (parser location on off) (number? number?)
#{
\once \override Stem #'stencil = #(dashed-stem on off)
#})
\relative c'' {
\dashedStem #0.5 #0.75
c
\dashedStem #0.5 #0.5
c
\dashedStem #0.25 #0.5
c
\dashedStem #0.25 #0.25
c
}
-David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
On Sat, May 12, 2012 at 7:32 AM, David Nalesnik david.nales...@gmail.comwrote: I've come up with a simpler variant which makes use of the 'dashed-line function. (I didn't use this initially because I couldn't figure out how to get the roundedness of the line segments to match the ordinary stem's and also because I wanted to ensure a full-length dash at top and bottom.) Hmmm, Setting 'blot-diameter like I did actually affects regular stems and the newly-drawn stems not at all... So I guess the earlier method is the way to go. (That is, unless there is a way to change the rounding of the 'dashed-line stencil, or if such things really don't matter!) Those functions using 'round-filled-box could be tailored to match the capabilities of 'dashed-line. Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
Hi again, Hmmm, Setting 'blot-diameter like I did actually affects regular stems and the newly-drawn stems not at all... So remove this line if you use the newer function: (ly:output-def-set-variable! (ly:grob-layout grob) 'blot-diameter 0.8) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Tab stems won't show up when using TabVoice
Hi there.
I'm working on the transcription of some of my ukulele arrangements,
which will be published both as Staff only / Staff + TabStaff / TabStaff
only.
In order to get a useable TabStaff only output, I need to set
`\tabFullNotation` in order to show rhythms, etc.
And I've just discovered that the stems won't show up when using
TabVoice -- it doesn't matter if the voices are implicit, explicit or
just one explicit voice.
% Example - Tab stems won't show up when using TabVoice
\version 2.15.38
myNotes = { g' e' c' g }
myVoiceA = { e'8 d'8 c'4 e' c' }
myVoiceB = { c g c g }
myVoices = { \myVoiceA \\ \myVoiceB }
myMusic = {
\myNotes
\myVoices
}
\new TabStaff {
\tabFullNotation
\myNotes
% stems are not shown when two implicit voices appear
\myVoices
% stems are not shown either when two explicit voices appear
\new TabVoice {
\voiceOne
\myVoiceA
}
\new TabVoice {
\voiceTwo
\myVoiceB
}
% stems are not shown when _one_ explicit voice appear
\new TabVoice {
\myVoiceA
}
% everything fine again
\myNotes
}
% End example
This problem exists in 2.14.2 too.
Should we call this a bug?
Best.
--
Choan Gálvez
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Ukulele string tunings
Hi. Current tunings for tenor and baritone ukulele are string reversed. From `ly/string-tunings-init.ly`: %% ukulele tunings \makeDefaultStringTuning #'ukulele-tuning \stringTuning g' c' e' a' \makeDefaultStringTuning #'ukulele-d-tuning \stringTuning a' d' fis' b' \makeDefaultStringTuning #'tenor-ukulele-tuning \stringTuning a' e' c' g \makeDefaultStringTuning #'baritone-ukulele-tuning \stringTuning e' b g d Those two last tuning should be g c' e' a' and d g b e' respectively. In addition, I'd say those two tunings are weirly named -- from the same file, all guitar tunings are named `guitar-something`, all banjo tunings `banjo-something`. As I haven't find any report about the wrong definitions, I think it's be safe to assume that no one is using them and it would be ok to rename them. I'd suggest rewriting them as: \makeDefaultStringTuning #'ukulele-linear-tuning \stringTuning g c' e' a' \makeDefaultStringTuning #'ukulele-baritone-tuning \stringTuning d g b e' or alternatively, remove them. What do you think? Best. -- Choan Gálvez ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ukulele string tunings
Choan Gálvez choan.gal...@gmail.com writes: Current tunings for tenor and baritone ukulele are string reversed. From `ly/string-tunings-init.ly`: %% ukulele tunings \makeDefaultStringTuning #'ukulele-tuning \stringTuning g' c' e' a' \makeDefaultStringTuning #'ukulele-d-tuning \stringTuning a' d' fis' b' \makeDefaultStringTuning #'tenor-ukulele-tuning \stringTuning a' e' c' g \makeDefaultStringTuning #'baritone-ukulele-tuning \stringTuning e' b g d Those two last tuning should be g c' e' a' and d g b e' respectively. In addition, I'd say those two tunings are weirly named -- from the same file, all guitar tunings are named `guitar-something`, all banjo tunings `banjo-something`. But those are not tenor or baritone tunings of a ukulele, but rather tunings of the tenor or baritone ukulele. Namely different instruments. So there is some consistency after all: instrument-tuningvariant-tuning Not sure whether this reason is good enough. As I haven't find any report about the wrong definitions, I think it's be safe to assume that no one is using them and it would be ok to rename them. Indeed this would seem to indicate that a convert-ly rule would not need to accompany such a change. I'd suggest rewriting them as: \makeDefaultStringTuning #'ukulele-linear-tuning \stringTuning g c' e' a' \makeDefaultStringTuning #'ukulele-baritone-tuning \stringTuning d g b e' or alternatively, remove them. What do you think? Not sure about the renaming. Of course, strings need to get reversed. It would appear that this had been wrong in any version of the file. I seem to remember, however, that LilyPond is not overly skilled dealing with non-increasing string pitches, so the standard ukulele would likely not be fabulously supported either. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond wins LoMuS 2012!
2012/5/12 m...@apollinemike.com m...@apollinemike.com: Hey LilyPond users, I have an exciting piece of news to share with you. LilyPond won LoMuS 2012, one of the most prestigious awards in the open source community for musical software. http://concours.afim-asso.org/ All of you should be very proud, as your work with LilyPond helps those who develop the program make it a better piece of software. Tweet the news far and wide! It would be wonderful if the community of users grew as a result of this award. Bravo! Is there any linkable notice in the web? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond wins LoMuS 2012!
On Sat, May 12, 2012 at 6:41 AM, m...@apollinemike.com m...@apollinemike.com wrote: Hey LilyPond users, I have an exciting piece of news to share with you. LilyPond won LoMuS 2012, one of the most prestigious awards in the open source community for musical software. Congratulations!! What an honor! -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ukulele string tunings
On 5/12/12 16:08 , David Kastrup wrote: Choan Gálvezchoan.gal...@gmail.com writes: Current tunings for tenor and baritone ukulele are string reversed. From `ly/string-tunings-init.ly`: %% ukulele tunings \makeDefaultStringTuning #'ukulele-tuning \stringTuningg' c' e' a' \makeDefaultStringTuning #'ukulele-d-tuning \stringTuninga' d' fis' b' \makeDefaultStringTuning #'tenor-ukulele-tuning \stringTuninga' e' c' g \makeDefaultStringTuning #'baritone-ukulele-tuning \stringTuninge' b g d Those two last tuning should beg c' e' a' andd g b e' respectively. In addition, I'd say those two tunings are weirly named -- from the same file, all guitar tunings are named `guitar-something`, all banjo tunings `banjo-something`. But those are not tenor or baritone tunings of a ukulele, but rather tunings of the tenor or baritone ukulele. Namely different instruments. Yes. And no. The most common tuning for ukuleles --soprano, concert and tenor-- is g' c' e' a' (C reentrant tuning). The one which is currently defined as `tenor-ukulele-tuning` is used in soprano, concert and baritone too: g c' e' a' (C linear tuning). And the most used tuning for tenor ukuleles is g' c' e' a' (currently ukulele-tuning, that's fine). The `baritone-ukulele-tuning` is used --as far as I know-- only in baritone sized instruments, as the pitches are too low to sound nice in small instruments. But... there is an A linear tuning for baritone too. I'd use the following naming strategy: * Start with ukulele- * Use pitch- when the tuning is other than the common C tuning (C6) * Use linear- when the tuning is linear instead of the more common reentrant tuning * Finish with tuning. So, we'd have: ukulele-tuning g' c' e' a' ukulele-linear-tuning g c' e' a' (currently tenor-ukulele-tuning) ukulele-d-tuning a' d' fis' b' ukulele-g-linear-tuning d g b e' (currently baritone-ukulele-tuning) Those are the most used tunings. The not-so-common tunings can be left out, just like they are now. FYI, I use too: f' bes d' g' (that would be ukulele-bes-tuning) d' g b e' (that would be ukulele-g-tuning) e a cis' fis' (that would be ukulele-a-linear-tuning) So there is some consistency after all: instrument-tuningvariant-tuning Not sure whether this reason is good enough. As I haven't find any report about the wrong definitions, I think it's be safe to assume that no one is using them and it would be ok to rename them. Indeed this would seem to indicate that a convert-ly rule would not need to accompany such a change. I'd suggest rewriting them as: \makeDefaultStringTuning #'ukulele-linear-tuning \stringTuningg c' e' a' \makeDefaultStringTuning #'ukulele-baritone-tuning \stringTuningd g b e' or alternatively, remove them. What do you think? Not sure about the renaming. Of course, strings need to get reversed. Should I open an issue about the reversing? It would appear that this had been wrong in any version of the file. I seem to remember, however, that LilyPond is not overly skilled dealing with non-increasing string pitches, so the standard ukulele would likely not be fabulously supported either. It is not. But that's something I can deal (and do deal) with... and a starting point for maybe a hundred posts more ;) Best. -- Choan Gálvez ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ukulele string tunings
- Original Message - From: Choan Gálvez choan.gal...@gmail.com To: lilypond-user@gnu.org Sent: Saturday, May 12, 2012 3:30 PM Subject: Re: Ukulele string tunings On 5/12/12 16:08 , David Kastrup wrote: Not sure about the renaming. Of course, strings need to get reversed. Should I open an issue about the reversing? No - please follow http://lilypond.org/bug-reports.html -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ukulele string tunings
Choan Gálvez choan.gal...@gmail.com writes: On 5/12/12 16:08 , David Kastrup wrote: Choan Gálvezchoan.gal...@gmail.com writes: Current tunings for tenor and baritone ukulele are string reversed. From `ly/string-tunings-init.ly`: %% ukulele tunings \makeDefaultStringTuning #'ukulele-tuning \stringTuningg' c' e' a' \makeDefaultStringTuning #'ukulele-d-tuning \stringTuninga' d' fis' b' \makeDefaultStringTuning #'tenor-ukulele-tuning \stringTuninga' e' c' g \makeDefaultStringTuning #'baritone-ukulele-tuning \stringTuninge' b g d Those two last tuning should beg c' e' a' andd g b e' respectively. In addition, I'd say those two tunings are weirly named -- from the same file, all guitar tunings are named `guitar-something`, all banjo tunings `banjo-something`. But those are not tenor or baritone tunings of a ukulele, but rather tunings of the tenor or baritone ukulele. Namely different instruments. Yes. And no. The most common tuning for ukuleles --soprano, concert and tenor-- is g' c' e' a' (C reentrant tuning). The one which is currently defined as `tenor-ukulele-tuning` is used in soprano, concert and baritone too: g c' e' a' (C linear tuning). And the most used tuning for tenor ukuleles is g' c' e' a' (currently ukulele-tuning, that's fine). The `baritone-ukulele-tuning` is used --as far as I know-- only in baritone sized instruments, as the pitches are too low to sound nice in small instruments. But... there is an A linear tuning for baritone too. I'd use the following naming strategy: * Start with ukulele- * Use pitch- when the tuning is other than the common C tuning (C6) * Use linear- when the tuning is linear instead of the more common reentrant tuning * Finish with tuning. I find linear weird. But it is not relevant what _I_ find weird if that is what Ukulele players associate with it. Programmers of LilyPond rarely know all the instruments that they are writing support for. If you have a development version of LilyPond checked out, I would suggest preparing a patch/issue using git-cl. Otherwise, submitting a careful proposal to the bug list should get your issue added to the bug database, but it will depend on someone picking it up to get a fix created. So proposing a patch yourself will speed up the process and make sure that the code corresponds best with what you consider useful for your instrument. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Regarding horizontal shifts.
Hi Hwaen,
On Fri, May 11, 2012 at 7:01 PM, Hwaen Ch'uqi hwaench...@gmail.com wrote:
Greetings All,
In this snippet, the second arpeggio overlaps with the preceding
cross-staff notation. How may I best solve this? Ideally, I should
like to shift the second half of the measure to the right. Has the
solution something to do with padding? My efforts thus far have not
yielded anything fruitful.
Overriding arpeggio's X-extent (i.e. telling LilyPond that it should
be wider) should do the trick, but unfortunately doesn't. I think
this is a bug; LilyPond doesn't recognize that the last note/chord
before the arpeggio is in the upper staff. A workaround is to insert
something into the bottom voice of the bottom staff and hide it (even
when it's hidden, Lily will consider it when calculating spacing).
I hope this explanation is clear.
Here's an example of such workaround:
\score{
\new PianoStaff
\set PianoStaff.connectArpeggios = ##t
\new Staff = up{
\key c \minor \time 2/4 \clef treble \relative{
{
c4\arpeggio d\arpeggio
}
\\
{
r16 g, es \change Staff = down \voiceOne g, c \change Staff =
up \voiceTwo g' es r c g f \change Staff = down \voiceOne g, c d
\change Staff = up \voiceTwo c' g f
}
}
}
\new Staff = down{
\key c \minor \time 2/4 \clef bass \relative{
{
s2
}
\\
{
c,, c'4\arpeggio d d'\arpeggio
}
{
s8. \hideNotes r16 \unHideNotes
}
}
}
}
hope this helps,
Janek
PS you should be using \voiceOne instead of \stemUp. The latter
doesn't result in proper placement of articulations and other things.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Overrides galore for contemporary-minded folk
Hey all, Some more new music coming your way! And, like the previous works I sent to the list, this one has many overrides. As always, you are all welcome to e-mail me about whatever hacks you find interesting and I'll pass along the code. http://www.ensemble101.fr/scores/j-sho.pdf http://www.youtube.com/watch?v=L8wcNM1KlEc http://soundcloud.com/ensemble101/j-sho All free, all the time! Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Overrides galore for contemporary-minded folk
Mike, On 12 May 2012 17:42, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, Some more new music coming your way! And, like the previous works I sent to the list, this one has many overrides. As always, you are all welcome to e-mail me about whatever hacks you find interesting and I'll pass along the code. http://www.ensemble101.fr/scores/j-sho.pdf Actually I am slightly disappointed, where's the fauna indicators? I was hoping for chickens or ducks this time - I like ducks (actually Eider ducks make a wonderful sound - especially so if you are British and of a certain age[1]). James [1] http://en.wikipedia.org/wiki/Frankie_Howerd ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Overrides galore for contemporary-minded folk
On 12 mai 2012, at 19:10, James wrote: Mike, On 12 May 2012 17:42, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, Some more new music coming your way! And, like the previous works I sent to the list, this one has many overrides. As always, you are all welcome to e-mail me about whatever hacks you find interesting and I'll pass along the code. http://www.ensemble101.fr/scores/j-sho.pdf Actually I am slightly disappointed, where's the fauna indicators? I was hoping for chickens or ducks this time - I like ducks (actually Eider ducks make a wonderful sound - especially so if you are British and of a certain age[1]). James I opted for flora this time to change things up a bit :) Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
OK! This should do it.
Those functions using 'round-filled-box could be tailored to match the
capabilities of 'dashed-line.
The rewrite combines both of the approaches above: it uses
'round-filled-box for the stencil, and allows you to specify the length of
the dashes and the spaces in between the dashes. The trade-off is that you
may need to play around with the values to get the stem to end with a dash,
or to end with a dash which isn't cut off too much.
I incorporated the alterations that Harm made because I think they make the
code clearer.
I imagine the function build-pos-list could be done more elegantly, but at
least it works. Any suggestions for doing this more artfully are welcome!
Thanks,
David
\version 2.15.38
%#(set-global-staff-size 30)
#(define (make-round-filled-box x1 x2 y1 y2 blot-diameter)
(ly:make-stencil (list 'round-filled-box (- x1) x2 (- y1) y2
blot-diameter)
(cons x1 x2)
(cons y1 y2)))
#(define (build-pos-list len on off)
(let ((lst '(0)))
(define (helper)
(let ((bottom (+ (car lst) on)))
(if ( bottom len)
(begin
(set! lst (cons bottom lst))
(let ((top (+ (car lst) off)))
(if ( top len)
(begin
(set! lst (cons top lst))
(helper))
(set! lst (cons len lst)
(set! lst (cons len lst)
(helper)
(reverse lst)))
#(define (dashed-stem on off)
(lambda (grob)
(let* ((blot (ly:output-def-lookup (ly:grob-layout grob)
'blot-diameter))
(stencil (ly:stem::print grob))
(X-ext (ly:stencil-extent stencil X))
(thickness (interval-length X-ext))
(Y-ext (ly:stencil-extent stencil Y))
(len (interval-length Y-ext))
(new-stencil empty-stencil)
(factors (build-pos-list len on off)))
(define (helper args)
(if (= 2 (length args))
(begin
(set! new-stencil
(ly:stencil-add
new-stencil
(ly:stencil-translate-axis
(make-round-filled-box (/ thickness -2) (/ thickness 2)
(car args) (cadr args)
blot)
(interval-start Y-ext)
Y)))
(helper (cddr args)))
new-stencil))
(if (or (zero? on) (zero? off))
stencil
(helper factors)
dashedStems =
#(define-music-function (parser location on off) (number? number?)
#{
\override Stem #'stencil = #(dashed-stem on off)
#})
\relative c'' {
\dashedStems #0.5 #0.4
c d e f,,
a'8 g' f' g,
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
David Nalesnik david.nales...@gmail.com writes: OK! This should do it. Those functions using 'round-filled-box could be tailored to match the capabilities of 'dashed-line. The rewrite combines both of the approaches above: it uses 'round-filled-box for the stencil, and allows you to specify the length of the dashes and the spaces in between the dashes. The trade-off is that you may need to play around with the values to get the stem to end with a dash, or to end with a dash which isn't cut off too much. I incorporated the alterations that Harm made because I think they make the code clearer. I imagine the function build-pos-list could be done more elegantly, but at least it works. Any suggestions for doing this more artfully are welcome! I don't really understand the function, but maybe something like (define (build-pos-list len on off) (let helper ((lst '()) (next 0) (on on) (off off)) (if ( next len) (helper (cons next lst) (+ next on) off on) (reverse! lst (list len) will do. No idea whether this should have an even number of elements always or not. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Regarding horizontal shifts.
On 5/12/12, Janek Warchoł janek.lilyp...@gmail.com wrote:
Hi Hwaen,
On Fri, May 11, 2012 at 7:01 PM, Hwaen Ch'uqi hwaench...@gmail.com wrote:
Greetings All,
In this snippet, the second arpeggio overlaps with the preceding
cross-staff notation. How may I best solve this? Ideally, I should
like to shift the second half of the measure to the right. Has the
solution something to do with padding? My efforts thus far have not
yielded anything fruitful.
Overriding arpeggio's X-extent (i.e. telling LilyPond that it should
be wider) should do the trick, but unfortunately doesn't. I think
this is a bug; LilyPond doesn't recognize that the last note/chord
before the arpeggio is in the upper staff. A workaround is to insert
something into the bottom voice of the bottom staff and hide it (even
when it's hidden, Lily will consider it when calculating spacing).
I hope this explanation is clear.
Here's an example of such workaround:
\score{
\new PianoStaff
\set PianoStaff.connectArpeggios = ##t
\new Staff = up{
\key c \minor \time 2/4 \clef treble \relative{
{
c4\arpeggio d\arpeggio
}
\\
{
r16 g, es \change Staff = down \voiceOne g, c \change Staff =
up \voiceTwo g' es r c g f \change Staff = down \voiceOne g, c d
\change Staff = up \voiceTwo c' g f
}
}
}
\new Staff = down{
\key c \minor \time 2/4 \clef bass \relative{
{
s2
}
\\
{
c,, c'4\arpeggio d d'\arpeggio
}
{
s8. \hideNotes r16 \unHideNotes
}
}
}
}
hope this helps,
Janek
PS you should be using \voiceOne instead of \stemUp. The latter
doesn't result in proper placement of articulations and other things.
Yes, this works beautifully! And thank you for the general tip.
Hwaen Ch'uqi
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Dashed Stem
On Sat, May 12, 2012 at 1:39 PM, David Kastrup d...@gnu.org wrote: I don't really understand the function, but maybe something like (define (build-pos-list len on off) (let helper ((lst '()) (next 0) (on on) (off off)) (if ( next len) (helper (cons next lst) (+ next on) off on) (reverse! lst (list len) will do. No idea whether this should have an even number of elements always or not. Thank you, David. This works like a charm! -David N. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ukulele string tunings
Hi. On 5/12/12 16:51 , David Kastrup wrote: Choan Gálvezchoan.gal...@gmail.com writes: On 5/12/12 16:08 , David Kastrup wrote: Choan Gálvezchoan.gal...@gmail.com writes: In addition, I'd say those two tunings are weirly named -- from the same file, all guitar tunings are named `guitar-something`, all banjo tunings `banjo-something`. But those are not tenor or baritone tunings of a ukulele, but rather tunings of the tenor or baritone ukulele. Namely different instruments. Yes. And no. The most common tuning for ukuleles --soprano, concert and tenor-- isg' c' e' a' (C reentrant tuning). The one which is currently defined as `tenor-ukulele-tuning` is used in soprano, concert and baritone too:g c' e' a' (C linear tuning). And the most used tuning for tenor ukuleles isg' c' e' a' (currently ukulele-tuning, that's fine). The `baritone-ukulele-tuning` is used --as far as I know-- only in baritone sized instruments, as the pitches are too low to sound nice in small instruments. But... there is an A linear tuning for baritone too. I'd use the following naming strategy: * Start with ukulele- * Use pitch- when the tuning is other than the common C tuning (C6) * Use linear- when the tuning is linear instead of the more common reentrant tuning * Finish with tuning. I find linear weird. But it is not relevant what _I_ find weird if that is what Ukulele players associate with it. Low G tuning is more common among players than C linear tuning. For other pitches, I'd say the common term is D with low fourth. And Baritone tuning is more common than G linear tuning. But, there's no consensus --nor it is needed. Unfortunately, it's impossible to extract a naming estrategy from the most common names, and that's why I made my proposal. But, I'd rather left the renaming out than abusing other users with my (not so) highly opinionated terms -- I'll keep them for my include files. Programmers of LilyPond rarely know all the instruments that they are writing support for. If you have a development version of LilyPond checked out, I would suggest preparing a patch/issue using git-cl. Done. Just the reversing of the chords. Otherwise, submitting a careful proposal to the bug list should get your issue added to the bug database, but it will depend on someone picking it up to get a fix created. So proposing a patch yourself will speed up the process and make sure that the code corresponds best with what you consider useful for your instrument. :) Best. -- Choan Gálvez http://choangalvez.nom.es/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ukulele string tunings
Choan Gálvez choan.gal...@gmail.com writes: On 5/12/12 16:51 , David Kastrup wrote: Choan Gálvezchoan.gal...@gmail.com writes: On 5/12/12 16:08 , David Kastrup wrote: Choan Gálvezchoan.gal...@gmail.com writes: In addition, I'd say those two tunings are weirly named -- from the same file, all guitar tunings are named `guitar-something`, all banjo tunings `banjo-something`. But those are not tenor or baritone tunings of a ukulele, but rather tunings of the tenor or baritone ukulele. Namely different instruments. Yes. And no. The most common tuning for ukuleles --soprano, concert and tenor-- isg' c' e' a' (C reentrant tuning). The one which is currently defined as `tenor-ukulele-tuning` is used in soprano, concert and baritone too:g c' e' a' (C linear tuning). And the most used tuning for tenor ukuleles isg' c' e' a' (currently ukulele-tuning, that's fine). The `baritone-ukulele-tuning` is used --as far as I know-- only in baritone sized instruments, as the pitches are too low to sound nice in small instruments. But... there is an A linear tuning for baritone too. I'd use the following naming strategy: * Start with ukulele- * Use pitch- when the tuning is other than the common C tuning (C6) * Use linear- when the tuning is linear instead of the more common reentrant tuning * Finish with tuning. I find linear weird. But it is not relevant what _I_ find weird if that is what Ukulele players associate with it. Low G tuning is more common among players than C linear tuning. For other pitches, I'd say the common term is D with low fourth. And Baritone tuning is more common than G linear tuning. But, there's no consensus --nor it is needed. Unfortunately, it's impossible to extract a naming estrategy from the most common names, and that's why I made my proposal. But, I'd rather left the renaming out than abusing other users with my (not so) highly opinionated terms -- I'll keep them for my include files. When in doubt rather pick names that you are likely to find written on score parts than in music theoretical papers. While one usually would want a somewhat good reason to _change_ some names, you quite aptly observed that it is unlikely that the current names have been in use, as they don't work. So you can pick the best names from scratch without needing to consider what is there already, but the best names should be what musicians and composers for that instrument are used to, not what appeals to your personal aesthetics best. I did not want to suggest that the existing names are good in that regard: I don't know the naming practices for the instrument family. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
