Re: PDF Links in Windows
Robin Bannister dataway.ch> writes:
> Thomas WillNot wrote:
> > I looked for settings in Acrobat Reader and found none.
> >
> > Please let me know if this functionality is possible in
> > Microsoft Windows.
>
> It is possible (without resorting to Frescobaldi).
> But there doesn't seem to be a standard way to set it up.
Frescobaldi is quite good, so it would be my first recommendation
unless a new user already has a favorite test editor.
Connecting point-and-click to your favorite text editor is not fun.
> The most direct point-and-click connection involves:
>
> A: the pdf program sending the textedit URL
> B: having a custom Windows 'URL Protocol' tell your editor
> C: your editor going to the right place
A is done automatically by Acrobat Reader; SumatraPDF does if you add
'textedit' to the LinkProtocols in a .ini file described in the docs
B is stored in the Windows registry. The LilyPond installer installs
a Scheme script, but I could never get it to work so I wrote my own
(and have to re-install it after every upgrade of LilyPond)
C is done by converting the textedit fields to the command for your
editor. Instead of LilyPond's Scheme, I use a DOS script:
@echo off
rem This is file D:\bin\textedit.cmd
rem Registry entry HLKM\Software\classes\textedit\shell\open\command
rem contains "D:\bin\textedit.cmd" "%1"
FOR /F "tokens=1,2* delims=:/" %%a IN (%1) DO set address=%%c& \
set drive=%%b
FOR /F "tokens=1,2,3,4 delims=:" %%a IN ("%address%") DO \
"%ProgramFiles(x86)%\Vim\vim74\gvim" --remote-silent +%%b %drive%:/%%a \
& "%ProgramFiles(x86)%\Vim\vim74\gvim" --remote-send "%%d|"
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: midi channel
Rob gmx.de> writes:
> for the midi playback
> the channel assignment of the staffs
> does not always do what I expect it to do.
> \new Staff \with { midiChannel = 1}
>
That control does not yet exist, but there are requests in the bug-tracker
http://sourceforge.net/p/testlilyissues/issues/2278/
http://sourceforge.net/p/testlilyissues/issues/4203/
LilyPond tries to assign channels for us, but it would be nice if we
could override her decisions. If an explicit midiChannel setting simply
over-writes LilyPond's choice, that might work. Anybody who can compile
LilyPond and knows some C++ and a bit of MIDI might enjoy testing if this
works as expected, and maybe send a patch.
For now, I think the LilyPonds assignment of staves to channels is at
least consistent, so maybe you can inspect the output to see what staves
are what channels, and then edit the midi as you need.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Voice split across staves?
Joel C. Salomon gmail.com> writes: > my specific > question is how best to show what seems to be a voice split across > staves. The following example should show what I mean: I’ve set the > piece’s first bar twice, the first time as seems logical to me, the > second time as it appears in the printed score: > Your second setting, using two Voices in the upper staff, with output that matches the printed score, is the way to go. What you think of as one logical voice, the one with the chords, is split across the pianists two hands. Piano music always prints this in a way that looks like separate voices, so it is best to use separate LilyPond Voice contexts. If you join the chord across the staves, the reader will think it is a recommendation to play the chord with a single hand, which is not the best way to perform this piece. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Style question for bar checks
Noeck gmx.de> writes:
> Would you recommend putting the bar check always after the note or in
> some circumstances also after an including brace?
> \alternative {
> { a2 b } | % wrong
> { a2 a } | % wrong
> }
If there is more than one measure in each alternative sequence,
then the | go inside each the {} for each sequence.
If each alternative sequence is shorter than one measure,
the | has to go outside the entire \alternative {{} {}} |
Alternatives that fit exactly one measure could be written either way.
I prefer a single | outside the \alternative
> This makes me think one should perhaps always write `a | }`
> instead of `a } |` – but how about this case?
> a2 \tuplet 3/2 { a4 a a } |
The tuplet is less than a measure long, so the | makes more sense outside.
I make fewer mistakes when I use Michael Hendry's style
http://lists.gnu.org/archive/html/lilypond-user/2015-04/msg00892.html
| \alternative {{a2 b} {a b}}
| \tuplet 3/2 {a4 a a} a2
| a2 \tuplet 3/2 {a4 a a}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: interesting implementation detail of \partcombine
Mike Solomon mike at mikesolomon.org writes:
I just realized that when one uses spacer rests instead of full-measure
rests in a voice that is being part combined, if there are full-measure rests
in the other voice, those rests will be shifted up.Not a biggie, but perhaps
it should be documented if it is intended behavior or fixed to work like full-
measure rests if intended behavior. What do people think?
foo = {
R1 |
R1 |
a''1 |
}
bar = {
s1 |
s1 |
f''1 |
}
\new Staff \new \Voice \partcombine \foo \bar
Formerly, they were merged, but into a spacer or rest depending on
which came first in the input file
http://sourceforge.net/p/testlilyissues/issues/261/
I argued that printing the rest to indicate its voice was the best
default choice because preserved the most information.
The 'bar' part above probably has some reason for using invisible rests,
so we keep it separate by default; we can \partCombineUnisono to merge.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Extend piano sustain pedal indication to end of bar
Andrew Bernard andrew.bernard at gmail.com writes:
How would one extend the bracket style sustain pedal indication to the end
of a bar or section? I understand from the documentation how to achieve this
for the end of a piece, but can this be done mid-piece?
I might be missing the point, but
\transpose c c' {
\set Staff.pedalSustainStyle = #'bracket
\override Staff.PianoPedalBracket.to-barline = ##t
c4\sustainOn e g b
g1\sustainOff }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Using force-hshift to create a cross-staff chord
Keith OHara k-ohara5a5a at oco.net writes: Knute Snortum ksnortum at gmail.com writes: I thought the answer would be to force-hshift the lower note but it doesn't seem to move. We should file a bug-report, to at least left-align before applying explicit force-hshifts I submitted a patch to omit the hand-aligned notes from the left-aligning. Another awkward problem is that NoteColumn.force-hshift is ignored when there is only one voice on the staff, because it is only referenced in the code that resolves the meshing or merging of chords. Making force-hshift apply to all NoteColumns is more likely to cause unforeseen problems, so I'm putting that off until a second step. We will get by a little easier after the first step is in the code, using the right force-hshifts on the staff with multiple voices ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Using force-hshift to create a cross-staff chord
Knute Snortum ksnortum at gmail.com writes:
I thought the answer would be to force-hshift the lower note but it
doesn't seem to move.
Annoyingly, LilyPond left-aligns the groups of clashing chords between
different staves. The code history says the reason was to left-align
\transpose c c''
\new Staff { f4 g } \\ { g f }
\new Staff { c4 c }
This makes force-hshift often useless for making cross-staff chords.
We should file a bug-report, to at least left-align before applying
explicit force-hshifts
For now, you could use a hidden voice
...
a2 \new Voice{\voiceOne \once \hideNotes a4 } a4
...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Control which voice if shifted left
Kieren MacMillan kieren_macmillan at sympatico.ca writes:
Curiously, switching voices as
[...]
results in a “left-shifted” voicing that closely resembles what the Satie-
engraving did. =)
In any case, it would be great to have a setting like
Context.voice-shifting = #’(3 1 2 4)
where one simply gives a list of the left-to-right order of voice
placement
to be observed if any shifting is required.
In this case, I think we should first fix one thing about what LilyPond
does
on her own.
I think LilyPond should align the innermost voices, rather than voiceOne
and voiceTwo, and consider the merging note-heads between inner voices.
That is, align the B-flat and E in the example two posts back, and merge
the Es in
\time 3/2
\key d \minor
{ \voiceOne g''2 e'' d''8 cis'' d''4 }
\\ { \voiceFour d''2 e'' b' }
\\ { \voiceTwo g'2 g' f' }
( LilyPond works best if the outer voices are one and two, and then the
inner voices are three and four, and the documentation instructs to order
voices this way. This makes practical sense, because the inner voices are
more often temporary, so we might start with voiceOne and voiceTwo and then
add voiceThree for a short time. But, the order from high pitch to low
pitch is the counter-intuitive 2, 4, 3, 1. )
I don't have a reference explaining what is standard practice for four
voices, so I'm not sure if aligning and merging inner voices is recommended
in general, but I do see it done a lot.
A minor problem is the names of the \shiftOff and \shiftOn commands, which
would look wrong if the higher-numbered inner voices are aligned. But
these would be more descriptively named \shiftTowardHead and
\shiftTowardStem anyway.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Control which voice if shifted left
Simon Albrecht simon.albrecht at mail.de writes:
Am 15.06.2015 um 16:50 schrieb Knute Snortum:
I haven't had any replies to this. How can I ask the question better?
Probably that’s because there is no way to automate this. At least I’d
be very surprised if there were one. It’s so much of a standard to shift
columns in the directions they are actually shifted, and everything more
flexible would require a much more intelligent algorithm, I think.
The code that does the shifting has a comment
TODO: these numbers are magic; should devise a set of grob
propertiess to tune this behavior.
where these numbers are the amounts to shift chords in the various cases:
\transpose c c' \new Staff
\new Voice {\voiceOne g4 g g g g c' g b g b g }
\new Voice {\voiceTwo e f a8. r16 g4 b b c' c' }
It would take some work to define and briefly document properties alongside
merge-differently-dotted to let the shift be changed for each of these
cases, but then we could change the sign of the shift for the case where
the stems currently line up.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Assertion failed!
Colin Campbell cpkc at shaw.ca writes: Under the assumption that the changed assertion handling is exposing previously non-fatal bugs, I propose to create separate issues for the 3 items now known: Daniel's two and another reported by Andrew Barnard. Colin would you let met add the three issues. I can minimize the examples fairly effectively, knowing what to expect from reviewing Daivd's patch. We'll likely be working together to figure out which operating system shows each problem; as I'm windows only at the moment. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problem with shaping chord ties held over several measures
Knute Snortum ksnortum at gmail.com writes:
I'm having a problem shaping ties of chords after more than one measure. I
have an internal voice that comes in on the third measure and the ties go
right through it. \shape doesn't seem powerful enough to handle this (at
least I don't know the syntax). Here's what the measures should look like:
\shape would be great for this, but there is a bug
https://code.google.com/p/lilypond/issues/detail?id=1789
preventing it from working on any note but the first in a chord.
g-\shape #'((0.5 . 0)(8 . -1)(-8 . -1)(0 . 0)) ~ c'~ f'^~2 q
You can flip on tie up, if you indicate the ties for each note in the chord:
\new Staff { \time 2/4 \clef bass
\new Voice { \voiceThree
s2 * 2
| d'8[( e' c' e']
| d'[ e' c' e'])
} \new Voice { \voiceFour
g c' f'2~ q~
g~ c'~ f'^~2 q
} }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Getting merge-differently-headed to work
Knute Snortum ksnortum at gmail.com writes:
I have a piece that I'm working on that has a measure with four very
crowded voices. I expected to have to resolve note collisions, but I'm
having some problems with \shiftOn and \mergeDifferentlyHeadedOn.
You don't need mergeDifferentlyHeadedOn because the heads are both filed.
Two things make merging the inner voices awkward in LilyPond
LilyPond considers merging only the voices the with the smallest \shift.
LilyPond moves voices with larger shifts always toward the stem side.
The simplest, I think, is to remove the two instances of
\mergeDifferentlyHeadedOn \shiftOn
and set the voices as usual with outer voices One and Two outer,
inner voices Three and Four inner, but 3 overrides
\new Voice { \voiceOne
\shiftOnn % with 2 'n's to indicate that this voice
% this voice shifts a lot, more than voiceFour, ...
\override NoteColumn.force-hshift = -0.2 % but force the direction
\highVoice }
\new Voice { \voiceThree \upperMiddle
\new Voice { \voiceFour
\stemUp % unusual for voiceFour
\lowerMiddle }
\new Voice { \voiceTwo \lowVoice
Maybe the things noted with comments are temporary deviations from the
usual arrangement of voices, so you might insert them in sequence in
the definitions of the variables that contain the notes.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: resetOctaveCheck cannot be removed with a tag
Reinhold Kainhofer lists at kainhofer.com writes:
I'm trying to store that part into a separate variable and use
resetRelativeOctave for the octave jumps. I'm tagging those
resetRelative and try to filter them out for the first occurrance or for
the repetition. Unfortunately, tagging resetRelatativeOctave and
filtering out with removeWithTag does NOT work.
You had a \relative applied before the \remove-with-tag
\transpose f c {
\removeWithTag #'A {
\relative c' {
f2 f
\tag #'A \resetRelativeOctave c''
c2 c }}}
so the octaves of the pitches were determined while your \resetRelativeOctave
was still in place. You need to apply the \relative after removing the tags
but before the transpose.
\transpose f c {
\relative c' {
\removeWithTag #'A {
f2 f
\tag #'A \resetRelativeOctave c''
c2 c }}}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can't compile after upgrade to 2.19.19
Stan Mulder st45882wz at earthlink.net writes: convert-ly will change something like gsharp to g-sharp, but it won't change gsharp4 to g-sharp4. Anything with a number after it doesn't convert properly. So I've had to do all those manually (or with search and replace). Oops. The rule in convert-ly was not written carefully enough. I put this on the bug list so it doesn't cause too many further problems. Since you converted your music, I take it that you do not find too much other difficulty in using 'g-sharp' for what used to be 'gsharp' ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Federico Bruni fedelogy at gmail.com writes:
2015-04-23 9:21 GMT+02:00 Martin Tarenskeen m.tarenskeen at zonnet.nl:
I often use LilyPond to quickly enter a very simple tune or small
pianosheet needing just a simple texteditor (Vim). I use \relative all the
time. c g c e g is soo much faster and easier than c''' g'' c''' e''' g'''
g'''.
And personally I find lilypond code in \relative mode easier to read.
I agree that for complex scores with much music in variables \relative mode
can have annoying side-effects.
I agree: relative mode is much easier to enter.
What if we compare relative mode to absolute mode with repeated 's removed?
Is
\relative c''' { c g c e g }
easier than
\transpose c c''' { c g, c e g}
?
I find it easier to remember that a note is below the middle octave in
the range of an instrument, than to remember whether the previous note was
more than three scale-steps away.
We can easily define a shorter way to express the transposition by octaves
\absolute c''' { c g, c e g }
and it is not too hard to change the 460 examples in the manual that have
an implicit \relative c' {} or relative c'' {} to copy/paste-able music.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Can't compile after upgrade to 2.19.19
Stan Mulder st45882wz at earthlink.net writes: I'm getting errors that I cannot fix after upgrading to 2.19.19. These errors seem to show that lily is not recognizing my english pitch names like eflat even though I've included english.ly near the top of the file. At version 2.19.16, the name changed from 'eflat' to 'e-flat' The convert-ly program will change existing files for you. I first saw it suggested here https://code.google.com/p/lilypond/issues/detail?id=4076#c20 If it was a bad idea to change, say why at bug-lilyp...@gnu.org. I'm not sure myself: the '-' is awkard to type, but easier to read, and we have short forms like 'ef' for faster typing. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Overlapping chords
D'Arcy J.M. Cain darcy at druid.net writes:
GNU LilyPond 2.16.2
Linux imp 3.13.0-51-generic #84-Ubuntu SMP
Ubuntu 14.04.2 LTS
ef2.:maj13 c4:9.5-
Not sure how to make it any tinier. Did you mean that you needed more
context?
'tiny example' is jargon for a complete example that demonstrates the
difficulty, and can be put into LilyPond to get output.
\version 2.16.2
\language english
\new ChordNames \chordmode {ef2.:maj13 c4:9.5-}
\new Staff {ef'2 g'4 g'}
People who read the email list are likely to think I use chordnames like
this all the time and get nice output but if they try themselves to use
LilyPond to do what you are trying, it will likely work for them.
In this case, I think it is a bug fixed soon after version 2.16
https://code.google.com/p/lilypond/issues/detail?id=1700
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Do we really offer the future?
Michael Hendry hendry.michael at gmail.com writes: I routinely put the bar checks at the _beginnings_ of the bars, thus... | a4 b c d | a8 b c d e f g a | a16 b c d e f g a b c d e f g a b That works very nicely. When I had a measure that took more than one line of input, I used to try to make that clear by indenting the continuation line a bit further, but that was lost on any auto-indenting. Now I can just | \acciaccatura d,8 b, g4.(\ff )b8 a4.( )g8 | a4.( )c8 b4.( )a8 | \acciaccatura ais8 b8[-.\fz ]b-. b[-.\fz ]b-. b[-.\fz ]b-. \acciaccatura ais8 b[-.\fz ]b-. | c, d b8 r c, c a8\downbow r \acciaccatura d, b, g2 and I can easily find my measures. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What is the problem with \relative? (Was: Do we really offer the future?)
Martin Tarenskeen m.tarenskeen at zonnet.nl writes:
I often use LilyPond to quickly enter a very simple tune or
small pianosheet needing just a simple texteditor (Vim). I use \relative
all the time. c g c e g is soo much faster and easier than c''' g''
c''' e''' g''' g'''.
If there were a version of \transpose c c'' that was a short as \relative,
\relative c'' { c g c e g }
\octave 2 { c g, c e g }
then the \relative method is not any shorter.
The second line lets me see that the Gs are in different octaves.
And personally I find lilypond code in \relative mode easier to read.
I agree that for complex scores with much music in variables \relative
mode can have annoying side-effects.
I wish the manual did not use the implicit \relative c'' {}
(sometimes \relative c' {} ) enclosing the examples. As soon as
the input gets complicated, \relative becomes difficult to figure out.
Learning Manual 2.2.3 has
\relative c'' {
\new PianoStaff
\new Staff { \time 2/4 c4 e | g g, | }
\new Staff { \clef bass c,,4 c' | e c | } }
where it could have
\new PianoStaff
\new Staff \octave 2 { \time 2/4 c4 e | g g, | }
\new Staff \octave 1 { \clef bass c,4 c | e c | }
if there was a function
octave =
#(define-music-function
(parser location octaves music)
(integer? ly:music?)
(_i Raise or lower @var{music} by a nubmer of @var{octaves}.)
(make-music 'TransposedMusic
'element (ly:music-transpose music (ly:make-pitch octaves 0 0
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Windows performance
Trevor Daniels t.daniels at treda.co.uk writes: Martin Tarenskeen wrote Saturday, April 18, 2015 6:29 PM Just a wild guess: did anyone on Windows try the same speed comparison using the --ps option instead of pdf output? Just done that. The conversion from ps to pdf takes only a couple of seconds with either version, so it looks like GhostScript is *not* involved. On the Pango website I see an entry against the changes for Pango 1.28.2 - Improve performance on Windows especially for non-Latin scripts and in 1.25.4 - Improved win32 performance Is this the version of Pango installed in 2.19.18? Until 2.19.17 LilyPond used Pango version 1.26.0 Just now with 2.19.18 LilyPond switched to Pango verison 1.28.3 ( https://github.com/gperciva/gub ) The Pango patch [basic-win32] Increase performance of Uniscribe code made it into Pango 1.25.4, but it broke ligatures and was reverted for Pango 1.26.0 It looks like some other regression _also_ broke ligatures on Windows. The patch that probably solved our ligature/kerning bugs 2656 and 2657 Bug 609326 - Complex script shaping failed in the FT2 backend on Windows made it into Pango 1.28.0 A second attempt at making use of Uniscribe faster Improve performance on Windows especially for non-Latin scripts made it into Pango 1.28.2 and could be the cause of our speedup ( https://git.gnome.org/browse/pango/log/?h=1.28 ) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Windows performance
Trevor Daniels t.daniels at treda.co.uk writes: Phil Holmes wrote Thursday, April 16, 2015 2:00 PM The performance of LilyPond 2.19.18 on Windows is _much_ better than previous versions. Some examples: A 26 page multi-score piece I've been working on: 2.19.16: 114s to compile 2.19.18: 52s ... [etc] Further to this, I first established that the speed-up on Windows happened between 2.19.17 and 2.19.18. One possibly relevant change between those two releases was the move from gs 8.70 to gs 9.15. This increased the size of usr/bin from 49.2Mb to 58.1Mb, virtually all of the increase being in the three gs files, so this looks like a pretty significant upgrade. Checking the GhostScript website for release 9 suggests it includes performance improvements and major changes to font handling. This looks a possible candidate, installed courtesy of Masamichi HOSODA-san. If so, yet more thanks and kudos to you, Masamichi! But wouldn't this show a speed-up on systems other than Windows? I downloaded 2.19.18 (seeing this thread title and assuming there was another slowdown) and find it completes a score in 2/3 the time that 2.19.17 takes. None of our changes to LilyPond itself could explain this. Ghostscript changed from 8.7 to 9.15, and Pango from 1.24 to 1.28, between releases 2.19.17 and .18 The change in seconds is the same when I skip Ghostscript by using the --ps option on Lilypond. On Linux, I see no measurable change (on music without lyrics). Windows font lookups were very slow, causing a significant slowdown once when we accidentally double the number of lookups. The change to the version of Pango is probably the cause of the speedup -- or maybe an underlying version change in fontforge; I'm not sure how fontforge is incorporated into LilyPond. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Windows performance
Keith OHara k-ohara5a5a at oco.net writes: Trevor Daniels t.daniels at treda.co.uk writes: Phil Holmes wrote Thursday, April 16, 2015 2:00 PM The performance of LilyPond 2.19.18 on Windows is _much_ better than previous versions. Some examples: On Linux, I see no measurable change (on music without lyrics). Well, the change I was testing was between versions of LilyPond itself, since I'm set up to compile Lilypond on Linux, and I didn't upgrade the Pango or Ghostscript packages. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to recognize Voice-continuation?
Thomas Morley thomasmorley65 at gmail.com writes:
Any chance to have LilyPond identify the second voice-b as a
continuation of the first?
This seems to be analogous to the way we need to keep the staff alive
when we temporarily leave a staff empty in piano music.
\new Staff
\new Voice = a \with { \override NoteHead #'color = #green }
s1*4
\new Voice =b \with { \override NoteHead #'color = #red }
s1*4
\relative c' {
\context Voice = a
{ \set tieWaitForNote = ##t c1~ }
\context Voice = b
{ \set tieWaitForNote = ##t cis4 d dis e^~ }
\context Voice = a
{ d2 c2 }
\context Voice = b
{ f4 e fis g }
\context Voice = a
{ e1 }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to enter explicit voices for use in Staff and TabStaff?
Thomas Morley thomasmorley65 at gmail.com writes:
Or any chance to get a neutral 'Bottom-context for use with LilyPond-syntax?
We have close, with
mus = \relative c'' {
\context Bottom = 1 { \voiceOne c4 r c r }
\context Bottom = 2 { \voiceTwo r a r a}
}
\new Staff \clef G_8 \mus
\new TabStaff \mus
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to remove tags from music returned by \keepWithTag ?
Jim Long lilypond at umpquanet.com writes:
On Tue, Mar 10, 2015 at 10:49:05AM +0100, Thomas Morley wrote:
Something in
http://lsr.di.unimi.it/LSR/Item?id=871
which matches your needs?
(didn't test myself)
\taggedRep looks especially interesting. I often use the
'extractMusic' family of snippet functions, for cases when a
phrase repeats, but with slight variation (most conveniently, at
the beginning or ending of the phrase):
But \taggedRep doesn't quite fit that use case.
The development version has a \tagGroup concept, that is intended
as a general solution to some of the problems LSR snippet 871
is intended to solve. There is basic documentation in the
version 2.19.16 manuals, and some background here
http://code.google.com/p/lilypond/issues/detail?can=2q=4083
For some uses of \taggedRep, a simple alternative is parallel music
\repeat unfold 16 {c'4 d' e' f'}
{s1\p s1\ s1*13 s4 s s s\f }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staffSize music function unreliable at LP v2.19.16
Simon Albrecht simon.albrecht at mail.de writes: Well, there’s reason enough to redirect this to bug-lilypond, isn’t it? Thanks for finding the bug, and confirming that it is a bug and not just a misunderstanding, and narrowing down the cause, and posting to bug-lilypond. The relevant code did not change, but the version of GCC used as a cross- operating-system compiler did change. Some very useful programming languages, including C,have details where behavior is allowed to vary between systems, and here it seems LilyPond inadvertently depended on one of those details. There will probably be a couple more of these strange bugs in 2.19.16 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Customizing staff to display Bohlen-Pierce scale?
txikitofandango nickgeorgopoulos at gmail.com writes: #(ly:set-default-scale (ly:make-scale '#(0 1 3/2 2 3 7/2 9/2 5 6)) ) Everything looks great, and the MIDI comes out correct within the octave, with each semitone up the scale going up a MIDI number. EXCEPT, because this is a 13-note scale, but MIDI octaves repeat every 12 numbers, I'm back at square one. Lilypond is impressively flexible, but does assume that the repeat-period of the scale spans 12 semitones in midi. (We might be able to change the hard-coded 12s -- actually 6s -- so that future users can more easily use scales spanning more than an octave.) I can see two options. 1) Currently it seems your midi pitches meant to span a tritave span only an octave, so it seems you intend to post-process the midi before listening. You can fit more pitches into 12 semitones of MIDI if your post-processing can interpret the midi pitch-bend. If you multiply your scale by 12/13 #(0 12/13 18/13 24/13 36/13 42/13 54/13 60/13 72/13) and use 6/13 instead of SHARP, LilyPond generate MIDI with pitch-bends. You would have to arrange to have one MIDI channel per voice, so each voice gets its own pitch-bend. 2) You might skip using the ' and , operators, and define pitches to span the range of your instruments. CC for low C, then C c cc for the other tritaves. The scale in ly:make-scale would be quite long, but I don't think that will caus any problem. You could work out the actual pitches in terms of 12-divisions-of-an-octave semitones, and the corresponding alteration in terms of 12ET semitones for sharp and flat, and have LilyPond produce a correct-sounding midi directly. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Naming of staff-staff-spacing
Noeck noeck.marburg at gmx.de writes: Wouldn’t it be more straight-forward to have identical objects (alists) behind these consistently named properties? I.e. a different name for this function and reserve the consistent name for what is currently the default-staff-staff- spacing? Yes. There is a request along these lines at https://code.google.com/p/lilypond/issues/detail?id=3482 It takes (understandably, I think) a lot of encouragement and/or volunteering to change the names, change the documentation, and make a conversion rule so old scores are updated properly. I have wanted to be the volunteer in this case, but haven't had the time. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Partcombine and large intervals
Phil Holmes mail at philholmes.net writes: Partcombine splits chords where the interval is greater than a ninth: [...] it's expected behaviour. I can't find this documented anywhere: is it? Only recently. Dan made the behavior adjustable and then I added a user-interface for version 2.19.16. https://code.google.com/p/lilypond/issues/detail?id=4198 I only documented the behavior in the brief function docstring : partcombine - chord-range [number-pair] part1 (music) part2 (music) Take the music in /part1/ and /part2/ and return a music expression containing simultaneous voices, where /part1/ and /part2/ are combined into one voice where appropriate. Optional /chord-range/ sets the distance in steps between notes that may be combined into a chord or unison. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Key signature and key cancellation need to be aligned
Thomas Morley thomasmorley65 at gmail.com writes: 2015-01-28 0:16 GMT+01:00 David Sumbler david at aeolia.co.uk: On Tue, 2015-01-27 at 20:26 +0100, Thomas Morley wrote: 2015-01-27 12:56 GMT+01:00 David Sumbler david at aeolia.co.uk: The problem is that the actual key signatures on the 2 staves that have them are not vertically aligned with the key cancellations on the other 2 staves. Instead, they are printed after the key cancellations. In other words, each of the 2 key signatures is printed as if there were an invisible key cancellation preceding it on the stave. This looks wrong, and I should like them to appear above and below the actual key cancellations on the other 2 staves. This is listed as a bug http://code.google.com/p/lilypond/issues/detail?id=448 maybe with a workaround that you like. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Order of contexts over staves
On Sun, 25 Jan 2015 08:37:16 -0800, Phil Holmes m...@philholmes.net wrote:
is
there a way of displaying where the various contexts are placed so I can try
to see what's going on?
I don't know of any built-in option that will help with this,
but you could temporarily ask LilyPond to draw Dynamics with one staff-line
\layout { \context { \Dynamics
\consists Staff_symbol_engraver
\override StaffSymbol.line-count = 1 } }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: instrumentSwitch and addInstrumentDefinition use
On Tue, 20 Jan 2015 08:51:13 -0800, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
2. What would be required so that the \bar ||” \key \default stuff could be
avoided
It is awkward to make this happen with an add-on to current LilyPond.
Jan-Peter took the approach of watching for transposition changes in his
autoTranspose engraver, to try generate key-change events in time for the
Key_engraver to see, but I don't think this works yet.
If we can find the time to teach LilyPond to optionally print written pitches,
given concert-pitch input without needing the explicit \transpose{} that we use
now, we /could/ teach the Key_engraver to optionally generate the key-changes.
(Then we will want a modifying option to omit the key-change, for traditional
horn parts.)
3. In a perfect world, either \instrumentSwitch would take two music expressions
(i.e., one for the “prep” period, one for the “playing” period), or there would
be
an \instrumentPrep macro — primarily to deal with the markup activities (e.g.,
“take clarinet”), but possibly for other things.
I would rather break free of the \instrumentSwitch structure, and define
variables to do exactly what I want
prepClarinet {
\set Staff.shortInstrumentName = \markup\concat {B\flat Cl}
^\markup\italic { muta in B\flat } }
takeClarinet {
\set Staff.printTransposition = bes
\tag#'part {
\once\set Staff.whichBar=||
\key\default
^\markup\small\bold\concat { Cl. in B\flat } }}
and variables that can go in their own sequence separate from the notes, if you
like
MarysArragement = {\key c\major s1*32 \prepClarinet s1*4 \takeClarinet s1*32}
...
\MarysArrangement \reedIINotes
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pianostaff 4-part writing and rests
Kieren MacMillan kieren_macmillan at sympatico.ca writes: The linked issue (https://code.google.com/p/lilypond/issues/detail? id=1228) currently has a status of “abandoned” — well, at least the associated patch does, if not the whole issue. Is there a technical reason why the most up-to-date engraver (e.g., https://github.com/openlilylib/openlilylib/blob/ c53380f5ca460d244a017389dc4bcb79a3f04d14/editorial-tools/merge-rests- engraver/definition.ily) has not been (or cannot be) rolled into the main Lilypond codebase? Or is it technically sound, and now it's only a matter of somebody making an appropriate/official patch and submitting it? The latest code looks reasonable. It needs testing and somebody willing to potentially modify it to cooperate with the rest of the code. It sets merged rests to staff-position 0, so it might interfere in mysterious ways people setting their rests by hand... the automated testing reveals things like this. It is a layer over the existing rest_collision_engraver, so either we check that each layer has a distinct-enough job that they won't confuse each other, or integrate the two rest-collision engravers into one. I never looked at this patch because from the issue title \override RestCollision #'positioning-done = #merge-rests-on-positioning I didn't recognize what problem it was trying to solve, even though I am often annoyed by that problem. I'll try to change the title and add an example of what we want it to do. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: instrumentSwitch and addInstrumentDefinition use
On Sun, 18 Jan 2015 19:34:24 -0800, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
This does have the variable reedPlayer storing written pitches, where we
recommend storing concert pitches
I would much rather code in concert pitches.
What I was suggesting, and what I put into the example, had all the typed input
in concert pitch.
By saying reedPlayer stores written pitches, I meant only that the
\transpose{...} operations, to tell LilyPond which notes should be printed at which
transposition, were included in the variable reedPlayer.
Still, I think I must be missing something fundamental… It really seems to me
that \addInstrumentDefinition already has [almost?] everything we need: the
shortInstrumentName is there, the clef is there (in case a change is needed),
the cue name is there, the transposition is there, etc.
So what is stopping us from making something very similar to the OP’s original
code Do The Right Thing™?
LilyPond has the information, but it takes some work to teach her to
consistently use it differently than she does now, and differently than the
original poster still wants her to.
You could try the attached modification (to avoid transposition of cues) of
Jan-Peter's method.
LilyPond transposes your input by 'instrumentTransposition when generating cue
notes, so leave instrumentTransposition at its default.
Instead, the attached engraver uses a new property 'printTransposition to shift
your concert-pitch input to printed pitches. Key-signature changes are not
always appropriate, but you can type \key\default to reprint the current
key-signature and have it transposed for the instrument.
(This second *-Transposition setting would be confusing to new users of
LilyPond, so any real patch would require re-writing some internals of LilyPond
so we can select the desired behavior using just the old
'instrumentTransposition to describe the instrument pitch.)
part = { g'4 b' d'' fis'' R1
\instrumentSwitch cl Bflat \bar||\key\default
g'4 b' d'' fis'' R1
\instrumentSwitch flute \bar||\key\default
g'4 b' d'' fis'' R1 }
global = { \key g\major s1*4 }
\new Staff \with { \printTransposition }
\new Voice \global \part \version 2.18.2
% vim: filetype=lilypond:
% Substitute for \key\default that works with midi{}
reprintKey = \applyContext #(lambda (c)
(define (same-scale-step? a b) (= (car a) (car b)))
(let* ((pitch-alist (delete-duplicates!
(append (ly:context-property c 'keyAlterations)
major)
same-scale-step?))
(tonic (ly:context-property c 'tonic (ly:make-pitch 0 0 0)))
(sev (ly:make-stream-event `(key-change-event)
`((pitch-alist . ,pitch-alist)
(tonic . ,tonic)
(ly:broadcast (ly:context-event-source c) sev)))
% from scm/define-context-properties.scm
#(define (translator-property-description symbol type? description)
(if (not (and
(symbol? symbol)
(procedure? type?)
(string? description)))
(throw 'init-format-error))
(if (not (equal? #f (object-property symbol 'translation-doc)))
(ly:error (_ symbol ~S redefined symbol)))
(set-object-property! symbol 'translation-type? type?)
(set-object-property! symbol 'translation-doc description)
(set! all-translation-properties (cons symbol all-translation-properties))
symbol)
#(translator-property-description 'printTransposition ly:pitch? transposition for printing with autoTransposeEngraver)
% adapted from Jan-Peter Voigt's autoTransposeEngraver at openlilylib
printTranspositionEngraver = #(lambda (context)
(let ((old-pitch-alist major)
(old-transp (ly:make-pitch 1 0 0)))
(make-engraver
(listeners
((melodic-event engraver ev)
(let ((transp (ly:context-property context 'printTransposition))
(pitch (ly:event-property ev 'pitch)))
(if (and (ly:pitch? pitch) (ly:pitch? transp))
(ly:event-set-property! ev 'pitch
(ly:pitch-diff pitch transp)
((key-change-event engraver ev)
(let ((transp (ly:context-property context 'printTransposition))
(tonic (ly:event-property ev 'tonic
(ly:context-property context 'tonic ;for \key\default
(ly:make-pitch 1 0 0
(pitch-alist (ly:event-property ev 'pitch-alist
old-pitch-alist)))
(if (ly:pitch? transp)
(begin
(ly:event-set-property! ev 'tonic
(ly:pitch-diff tonic transp))
(set! pitch-alist
(ly:transpose-key-alist pitch-alist
(ly:pitch-diff old-transp transp)))
Re: instrumentSwitch and addInstrumentDefinition use
On Sun, 18 Jan 2015 21:09:07 -0800, Paul Scott waterho...@ultrasw.com wrote: So I am saying that I would like any new features for instrument switching to suit my need to not always enter the notes in concert pitch. I don't really think that be a problem. Absolutely. There is a set of tests to make sure the old abilities of LilyPond remain working. The method of entering written-pitches is protected in this way, and also the generation of correctly-transposed cues for other instruments when you tell LilyPond the \transposition . ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Order of contexts over staves
Phil Holmes writes:
I'm setting some music with temporary staves, and ensuring the the
temporary staff is above the main staff using
\new Staff \with { alignAboveContext = #label}
I'm also using a dynamics context, which is created with
\new Dynamics \with { alignAboveContext = label }
The problem is that the dynamics appear above the ossia stave, rather
than
the main one. Is there any way to change the order they appear on, on
the
page?
I see what you are thinking, and I see what LilyPond is thinking.
The Dynamics context starts before the ossia, but has only spacers in it
until the ossia Staff starts.
LilyPond put the Dynamics above the main Staff, then later put the
ossia Staff just above the main Staff, squeezing under the Dynamics.
You could
\new Staff \with {alignAboveContext = dn } ...
\new Dynamics = dn ...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: instrumentSwitch and addInstrumentDefinition use
On Tue, 13 Jan 2015 05:54:48 -0800, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
I understand that in realistic cases you probably have the notes in one
variable and options for arrangements in another parallel sequence
flute_notes = {c'2 c'' }
arrangementB = {s1*4 \prep_alto_flute s1*4 \switch_alto_flute s1*8 }
and it is not so convenient to break flute_notes into segments for the
individual \transpose{}s.
Correct on both counts.
(n.b. I *do* break flute_notes up when absolutely necessary… but I definitely
wouldn’t call it “convenient”.)
You have to admit that this does (accidentally) make it sound a bit like you
are looking for a convenient way to write music with no regard for the
instrument.
I do see, though, that the convenience also makes it easier to make drafts and
see how the fingerings work out on alto flute or C flute, whether it is easier
to switch instruments a few measures earlier, etc.
I tried to make a concrete enhancement request
http://code.google.com/p/lilypond/issues/detail?id=4264
Well, if the notes are right there, and you can put them in {},
\instrument_alto_flute { ... } \instrument_tenor_sax { ... }
then we (including the braver non-programmers among us) can write music
functions to set up for the new instrument and transposes the stuff in {} using
the usual LilyPond commands.
Is that the best way?
I think the best way needs no music functions, just variables to set up the
instrument-switches. If you type in concert pitch you can apply a \transpose
to written-pitch directly to the input notes.
prepClarinet = { \set Staff.shortInstrumentName=Clar
^\markup\italic\center-align pick up clarinet }
switchClarinet = { ^\markup\boldClarinet
\once\set Staff.whichBar = ||
\transpositionUpdateKey bes }
reedPlayer = \transpose c c' {
c4 d e f
\prepClarinet
R1
\switchClarinet
\transpose bes c' {
c4 d e f
} }
This does have the variable reedPlayer storing written pitches, where we recommend
storing concert pitches in the manual, but that causes no problem once we learn to use
\tranposition bes . For example \addQuote reed \reedPlayer supplies
cue-notes that will be printed in concert pitch for, say, the violin player to time his
entry.
I happen to like to include \key changes with the notes, so I would have a \key
after the \switchClarinet, but you might prefer to have \transpositionUpdateKey
generate that.
You can think primarily in concert pitch, run \new Staff \reedPlayer through
Lilypond to see how the fingerings work out, and move \switchClarinet and the
\transpose {...} around as needed to make the arrangement work out.
The instrumentSwitch mechanism we had before seemed less convenient than the
way you wrote your \play_alto above, and it did not handle the transpositions
which is the tricky bit.
Yes… After Han-Wen had completed the sponsored programming (back in 2006, I
believe), I came to that sad realization.
We can't blame your sponsorship for this one.
You reported that LilyPond stopped noticing \set Staff.instrumentName during
the music
http://lists.gnu.org/archive/html/lilypond-devel/2006-06/msg00277.html
and, while fixing that, the programmers added the unnecessary instrumentSwitch
package.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: snippet throws programming errors
Cynthia Karl pckarl at mac.com writes:
\score{
\new Staff \key c \major \music
\layout {
\context { \Voice \consists Ambitus_engraver }
}
}
throws the following two programming errors:
Programming errors are intended to report conditions that a programmer
thinks cannot happen in correct operation of the program. But with a large
program with large numbers of people working on it, what one programmer thinks
is an obviously-wrong situation might be considered a harmless null-case by
another programmer.
In this case, \key c\major is alone in its own voice with no notes, so the
Ambitus_engraver for that voice creates an ambitus with no note-heads,
but the note-column engraver thinks that an ambitus with nothing in it
must be an error.
Where can I find out what's happening here?
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=lily/note-column.cc
and is there a way to suppress these errors similar to the way that
warnings can be suppressed.
I don't think so.
I would write
\new Staff \new Voice \key c \major \music
so that LilyPond's right hand doesn't fret about the empty voice for which
her left hand created an empty ambitus
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: instrumentSwitch and addInstrumentDefinition use
On Mon, 12 Jan 2015 06:36:15 -0800, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
how I *want* to use it:
flute_part = {
c'2 c'' |
b'4 g'8 a' b'4 c'' |
c'2 a' |
g'2. r4 |
\prep_alto R1*4 | % [input below in concert pitch] \play_alto a2 f' | %[
desired typeset d'2 bes' ...]
e'4 c'8 d' e'4 f'4 |
d'4 b8 c' d'4 e' |
c'2. r4 }
\new Staff \with { instrumentName = Flute } \flute_part
To date, LilyPond has taken the music expression that reaches the engravers and
1) set notes on the staff according to the pitches in the music expression
2) consulted the \transposition to modify the pitches for MIDI
I simply use \transpose.
Yep. So to data we have all done something like
flute_part = { c'2 c'' % ...
\transposition g \key f\major
\transpose g c' {
a2 f' % printing as d'2 bes' ...
} }
I understand that in realistic cases you probably have the notes in one
variable and options for arrangements in another parallel sequence
flute_notes = {c'2 c'' }
arrangementB = {s1*4 \prep_alto_flute s1*4 \switch_alto_flute s1*8 }
and it is not so convenient to break flute_notes into segments for the
individual \transpose{}s.
LilyPond has the quote/cue mechanism, where \addQuote fluteNotes \flute_notes
creates a sequence that is treated as concert pitches, as you wanted and as I used in my
last email. There are some bugs with addQuote, of which only 1823 makes me hesitate to
recommend it
http://code.google.com/p/lilypond/issues/list?q=%5CquoteDuring
For your desired input method, you want the converse of LilyPond's usual
actions :
1) apply the \transposition to the music to determine what notes to print
2) send the notes in the music expression directly to MIDI
(Maybe that would have been a better design from the beginning, for use by
composers, but it would probably have confused new users and been less
convenient for transcribing existing music.)
As I understood Jan Peter, his auto_transpose_engraver does exactly (1).
This made me think that LilyPond's note_heads_engraver could adopt that
behavior upon when instructed
\set concertPitchInput = ##t
then note_heads_performer would take the converse behavior for MIDI, then we
figure out appropriate behavior for note_name_engraver and fretboards_engraver
and chord_names_engraver and ...
This is why I think we should brainstorm and implement a really well-designed
instrumentSwitch/instrumentDefinition mechanism — we wouldn’t need any of this.
We’d simply put something like
reedI = {
\instrument “flute
[flute music here, no need for transposition]
\instrument “alto flute”
[alto music here; transposed properly in part, but optionally not in score]
Well, if the notes are right there, and you can put them in {},
\instrument_alto_flute { ... } \instrument_tenor_sax { ... }
then we (including the braver non-programmers among us) can write music
functions to set up for the new instrument and transposes the stuff in {} using
the usual LilyPond commands.
The instrumentSwitch mechanism we had before seemed less convenient than the
way you wrote your \play_alto above, and it did not handle the transpositions
which is the tricky bit.
I assume again that in realistic cases you have the notes in one variable, and then you
make different instrumental arrangements with parallel music or something fancier like
\push-to-tag, so that LilyPond can't be sure exactly what music will be played by alto
flute until the input expressions are combined in a or \push-to-tag or
whatever.
If my assumption is true, then to handle the transpositions the way you would
like, we could
A) take JanPeter's approach of waiting until engraving to figure out what music
is in what transposition,
B) teach the existing engravers to behave differently depending on 'concertPitchInput,
which we could set in our \instrumentalto flute or \instrument_alto_flute, or
C) write a function \transposeConcertToWritten, that iterates through the music (keeping
track of timing in constructs) to figure which transposition holds for
each note and converts \tranposition to \transpositionUpdateKey, which we would apply to
the assembled music just before the it goes into \new Staff (where we often use
\keepWithTag)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: snippet throws programming errors (Jim Long) 53
Cynthia Karl pckarl at mac.com writes: IMO, the problem is that my simple snippet causes LilyPond to declare that programing errors have occurred. Programming errors are a serious problem. Programming errors are only solved by correcting the program, not by avoiding them by modifying the input to the program. This is, of course, the cue for the rest of us to say : You've been using LilyPond longer than me; why haven't you yet corrected this serious problem !? You are suggesting that LilyPond is incapable of diagnosing a simple syntax error in its input. LilyPond is very accepting of varied syntax, makes up the missing parts, and in this case creates situations that other of its various spare-time programmers thought could only indicate an error. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: instrumentSwitch and addInstrumentDefinition use
Paul Scott waterhorse at ultrasw.com writes:
Is anyone using instrumentSwitch that can explain what the various
variables in addInstrumentDefinition mean?
Don't use instrumentSwitch. It is a pointless frustrating waste of time.
(The same could be said for LilyPond, except that there is sometimes a
point to wasting time with LilyPond.)
You can define a variable with the things that change each time you
switch instruments, without learning the instrument switch data structure
piccolo = { \transposition c'' \clef treble^8 }
AFAIK I really only
want the key signature to change automatically when I do an
instrument switch.
I am guessing that you input pitches as written for the instrument.
(If you write in concert pitch and then transpose for the instruments
then what I say next will not apply.)
This is a missing function of LilyPond.
One awkwardness is that LilyPond considers the key signature to be
individual to each Staff. It was created by horn players, and horn parts
traditionally omit the key signature. So LilyPond does not store a global
key signature.
We could, I think, keep this organization, and write a variant of
\tranposition bes that looks up the old key-signature and old
transposition on the Staff, figures the concert key, applies the new
transposition, figures the new key-signature for the new transposition
and sets that new key signature.
I just write an explicit \key d\major at the instrument switch when needed
(which is not very often)
Almost everything is copied from NM 1.6.3
Let's change that section
https://codereview.appspot.com/133390043/diff/80001/Documentation/notation/
staff.itely
#'(
This has to be a back-quote ` instead of a forward quote '
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: bug with compound glyphs and/or diacritical markings?
Werner LEMBERG wl at gnu.org writes: For me it works just fine on my GNU/Linux; see attached PDF. Almost certainly the problem with kerning and combining characters when using Pango on Windows, then http://code.google.com/p/lilypond/issues/detail?id=2657 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Overriding preset tablature for ukulele
Ryan Clarin ryanclarin at gmail.com writes: When I tab the note G4 (treble clef 2nd line G), \tabstaff marks it as 3rd string 3rd fret. I want it to make G as 4th string open, but cannot find in the manual how exactly to do that. It should be under string number in the fretted strings section g\4 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: instrumentSwitch and addInstrumentDefinition use
On Sun, 11 Jan 2015 12:36:43 -0800, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
So LilyPond does not store a global key signature.
No, but as you well know, many (most?) Lilypounders abstract the key signature
(etc.)
into their own global [variable](s).
Right, but LilyPond doesn't know if that is the concert-pitch key (nor does she
require all instruments to be playing in the same concert-pitch key). I
thought that would make automatic generation of key signature hard, but...
We could, I think, keep this organization, and write a
\tranpositionUpdateKey bes that looks up the old key-signature and old
transposition on the Staff, figures the concert key, applies the new
transposition, figures the new key-signature for the new transposition
and sets that new key signature.
Why can that not be rolled into an improved instrumentSwitch?
It could. The old instrumentDefinition, however, had no advantage over just
collecting the instrument-switch settings in a variable, and was harder to use.
I just write an explicit \key d\major at the instrument switch when needed
This is one of the great banes of my current Lilypond existence — as a writer
of musical theatre and band/orchestral music, I need to change instruments and
keys all the time, very often in the middle of a section (w.r.t. key
signature). Trying to remember to explicitly add key signatures etc. — and tag
them as necessary — is quite frustrating, time-consuming, and error-prone.
I guess you enter the notes in concert pitch, then ?
Do you use the \quoteDuring mechanism (as below) or Jan-Peter's
auto-transposing engraver to generate the engraved pitches for each instrument?
\version 2.19.15
transpositionUpdateKey =
#(define-music-function (parser location new-transposition) (ly:pitch?)
(_i Set instrument transposition and, based on the previous
transposition and key, generate the key-change to keep the sounding key.)
(define (generate-key-change c)
(define (same-scale-step? a b) (= (car a) (car b)))
(let* ((old-alt (delete-duplicates!
(append (ly:context-property c 'keyAlterations)
major)
same-scale-step?))
(old-tonic (ly:context-property c 'tonic (ly:make-pitch 0 0 0)))
(old-transp (ly:context-property c 'instrumentTransposition
(ly:make-pitch 0 0 0)))
(delta (ly:pitch-diff old-transp new-transposition))
(new-alt (ly:transpose-key-alist old-alt delta))
(new-tonic (ly:pitch-transpose old-tonic delta))
(sev (ly:make-stream-event `(key-change-event)
`((pitch-alist . ,new-alt)
(tonic . ,new-tonic)
(ly:broadcast (ly:context-event-source c) sev)))
#{
\applyContext #generate-key-change
\transposition $new-transposition
#} )
prepClarinet = { \set Staff.shortInstrumentName=Clar
^\markup\italic\center-align pick up clarinet }
clarinet = { ^\markup\boldClarinet
\once\set Staff.whichBar = ||
\transpositionUpdateKey bes }
concertBandEdition = {
s1*3 \tag#'Sue \prepClarinet
s1 \markAll Reeds \tag#'Sue \clarinet}
tune = { \key c\major \repeat unfold 4 {c'4 e' g' b' R1} }
backup = { \key c\major \repeat unfold 8 {c'4 e' g' b' } }
\addQuote tune \tune
\new Staff \with { instrumentName=horn in F }
\keepWithTag#'Sue
\concertBandEdition \transposition f
\quoteDuring tune #(skip-of-length tune)
\new Staff \with { instrumentName=alto clarinet }
\keepWithTag#'Joe
\concertBandEdition \transposition es
\transpose es c' \backup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: REQUEST: #'omit and #'include options for \repeat unfold?
Kieren MacMillan kieren_macmillan at sympatico.ca writes:
I’m just wondering whether it might be easy — and ultimately desireable —
to have a built-in method of
choosing which grobs get repeated and/or omitted during an unfold \repeat
expression.
Another oft-encountered use case would be
\repeat unfold N { a4\pp a a a }
Until somebody implements the requested options, we have to use parallel
music threads, one with repeated stuff, the other with the non-repeated
\new Staff \transpose c c'
\repeat unfold 16 { a4 b f g }
{ s4\pp\ s2 s4 s2\mp }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: making a Tie more parabolic
tisimst tisimst.lilypond at gmail.com writes: Kieren MacMillan wrote Any hints, for example, on what ‘ratio' actually does, or [..] effect of ratio. Seems like a bug to me that increasing ratio doesn't change the shape of the tie curve very much if the tie is at its height-limit, but maybe it's my ignorance at play here. I traced through the function calls to 'ly/bezier-bow.cc' where the curve of the tie is formed. This is old code and not the best among LilyPonds code, with spaghetti-like paths of function calls. I decided not to trust the comments. From reading the code it looks like: 'ratio' is the aspect ratio, height to width, for short ties and slurs but as ties get longer the aspect ratio is reduced so the height (of the control points, a bit less than that of the curve) remains below 'height-limit'. These are bezier curves with four control points. Short ties and slurs have the four control points equally-spaced along their length. As ties get longer the middle control points stay relatively closer to the endpoints, never getting further than twice the 'height-limit' from the end points. The transitions from short-tie to long-tie shape are smooth. I'll try to test a bit to see if LilPond behaves as reading the code makes me expect. The other details seem to deal with placing ties relative to the other music. 1) To make a tie more parabolic, I would want to move the control points toward the center. I don't see a parameter for that, but maybe someone can see how to make a scheme hook for calc-control-points that adjusts the horizontal spacing of these points. I think that could integrate well with the other placement code. Slurs have a parameter 'eccentricity' that moves control points horizontally and might be a good model. 2) The text in the docstrings could maybe be interpreted in a way consistent with behavior, but it seems they could be written much more directly (if I got it right above). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: would 'gn' for G-natural be useful in \language english ?
Paul Morris paul at paulwmorris.com writes: Keith OHara wrote I'm proposing \languageabbreviated +1 for adding an opt-in way to use 'cn' (etc.) via another version of the 'english' input language. This allows for use of this helpful form of input without confusing new users who still haven't learned LilyPond's input syntax (which I believe was the main objection to modifying 'english' itself). The proposed \language abbreviated met resistance, arguing that it is a worse choice than adding 'bn' to \language english, and that any use of 'bn' in LilyPond implies some distinction to 'b' that LilyPond does not preserve. Nevertheless, written English uses -natural in a systematic way https://archive.org/stream/wellknownpianoso00wilkrich/ wellknownpianoso00wilkrich_djvu.txt and I find that helpful in typing LilyPond, so I am taking Michael Ellis' suggestion to use an include file containing the note names I use pitchnames = #`( (cff . ,(ly:make-pitch -1 0 DOUBLE-FLAT)) (cf . ,(ly:make-pitch -1 0 FLAT)) (c . ,(ly:make-pitch -1 0 NATURAL)) (cn . ,(ly:make-pitch -1 0 NATURAL)) %% et cetera #(ly:parser-set-note-names parser pitchnames) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Beaming and grace notes
On Mon, 01 Dec 2014 12:28:54 -0800, Knute Snortum ksnor...@gmail.com wrote:
* Is there a way to keep this structure and get rid of the warning?
The warning is about being unable to fit the beam between the notes, because
you forced the stem directions in such a way to force the beam between the
staves
LilyPond usually sets the staff spacing based on everything that doesn't cross
staves, and then decides whether to 'knee' the cross-staff beam depending on
how far apart the staves are.
In this case it does look nicer with the knee, and once the rest of the music
is in place the staves will be spaced apart, anyway. You'll want the dynamics
to clear the beam, for example, and adding this spreads the staves.
upperStaffTop = \relative c'' {
\clef bass
s8. \once\override DynamicLineSpanner.staff-padding = #4
s16\ s8\ff s }
http://lilypond.org/doc/v2.18/Documentation/notation/common-notation-for-keyboards#changing-staff-manually
* The initial e flat in the lower staff is an eighth note, and the stem
needs to extend up beyond the 32nd note beams of the grace notes.
Why? The beam slope changes there, so the notation is clear in any case.
When you open up the staves it might look like you want. Otherwise, it
involves looking up 'beam-positions' in the manual, and tweaking.
If you tweak the layout before all the notes are in, you and LilyPond are going
to be second-guessing each other for a long time.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Beaming and grace notes
On Sat, 29 Nov 2014 07:44:39 -0800, Knute Snortum ksnor...@gmail.com wrote: I've attached a picture of the measure. [Debussy Prelude #2, Voiles] This piece uses a whole-tone scale (not in the part with the cross-staff grace notes of Knute's example, but most of the rest of the piece) so I would be tempted to print a version of this with wholeTone = #`( (0 . ,NATURAL) (1 . ,NATURAL) (2 . ,NATURAL) (3 . ,SHARP) (4 . ,SHARP) (5 . ,FLAT) (6 . ,FLAT)) \key c\wholeTone and see if it is easier to read with all the accidentals moved into a key signature. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Beaming and grace notes
On Sat, 29 Nov 2014 07:44:39 -0800, Knute Snortum ksnor...@gmail.com wrote:
Thank you both for your relies. Keith, your second suggestion is what I
need, if I could designate a zero length note.
Requirements:
* An actual eighth note
* Grace notes need to attached with a beam to the eighth note
* Grace notes add no duration to the measure
I've attached a picture of the measure. It has a lot of challenges in it
for me.
These small notes are not what LilyPond's \grace was designed for, but more
like the small-note tuplet that Harm pointed out. We want these note to be
spaced across the beat, but more quickly than their visible duration.
LilyPond will do most of the beaming you want if you tell her how the music
splits into two voices at the E-flat. Ignoring the fact that there are two
staves for the moment, try something like this:
\version 2.18.2
{
\key des\major \clef bass \time 2/4
aes32 bes aes ges
{\voiceTwo ees8 ~ ees4 |}
\new Voice {
\voiceOne
\scaleDurations 4/14 {
ees32[
\teeny
\override Stem #'no-stem-extend = ##t
\override Stem #'length-fraction = #0.7
ges aes bes des' ges, bes, c des f] ges[ bes c' des']
\normalsize
\revert Stem #'no-stem-extend
\revert Stem #'length-fraction
}
f'16- des'
c32 des c bes,| } }
We should probably put a Debussy example in the user manual (if he's in public
domain in europe by now) and also make a shorthand for \graceStyleOn
\graceStyleOff because often we want the style but do not want LilyPond's
\grace timing.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with Completion_heads_engraver
Jay Vara jay at diljun.com writes:
\layout {
\context {
\Staff
\remove Note_heads_engraver
\consists Completion_heads_engraver
}
}
We need to remove the Note_heads_engraver from the *Voice* and replace it
with Completion_heads_engraver.
\new Staff { \new Voice \with{
\remove Note_heads_engraver
\consists Completion_heads_engraver }
\relative c' { d4 c e fis1 g4 } }
In your example, you asked the Staff to create split notes, but the Staff
doesn't have engravers to make the Stems or Dots. The Voice still had
its Note_heads_engraver, so was creating notes that overlaid those created
by the Staff.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible Bug with \partcombine?
Joshua Nichols josh.d.nichols at gmail.com writes:
I was recently typesetting a song, using part combine, from a hymnal. I ran
into a problem: everytime I ran \partcombine, I found that unterminated
slur and cannot end slur, were common warnings. I was confused, and so I
created this small snippet that should reproduce the same issues.\version
2.18.2
I would call it a limitation of the design \partcombine.
\partcombine takes its two inputs and combines them when possible
into one LilyPond Voice. The resulting music goes through the
rest of LilyPond as usual, and in this case a pair of slurs starts
when \partcombine has produced two Voices, and ends when it only
has one (differnt) Voice holding the chords, so the slurs are left
dangling.
\partcombine on its own is smart enough to avoid switching from
separate stems to chords in the middle of a slur, but when we need
to override its choices, we need to take over completely.
The simplest solution here is to keep the voices separate through
the slurs
two = {
b a b \partcombineApart c'( b) \partcombineAutomaticOnce a b( c')
\partCombineAutomatic }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: would 'gn' for G-natural be useful in \language english ?
Ralph Palmer palmer.r.violin at gmail.com writes:
On Sun, Nov 16, 2014 at 11:31 PM, Keith OHara k-ohara5a5a at oco.net
wrote:Dear list,
In English, pronouncing the 'natural' in 'C-natural' is required if the
note is out-of-key. LilyPond does not consider the key when reading note-
input, but could easily accept 'cn' as a name for the pitch C-natural. There
was a feature request on the bug-list, that LilyPond do so.
Among those responding to the proposal, the Americans were in favor, while
the British Germans Dutch and Flemish opposed.
I have started using English note-entry with 'cn', etc., for naturals when
I would say natural and I find it helpful. If anyone else will use it,
I'll push for it and put it in LilyPond.
Hmm. . . . I am an American and I am opposed, for the reasons given in the
previous discussion(s). My 2 cents.
Then I'll propose that LilyPond accept 'cn' only when the user requests
that input style, and I won't call that style 'American'.
Another inconvenience with \languageenglish is that its default names
are the long forms, so
\displayLilyMusic \transpose c e {fs as cs}
is not as helpful for rearranging music as it could be.
I'm proposing \languageabbreviated for people who want to use
\displayLilyMusic to generate brief english, and/or want to type
'cn' for the same reasons that we sometimes pronounce 'natural'
in English. https://code.google.com/p/lilypond/issues/detail?id=4076#c26
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Beaming and grace notes
Knute Snortum ksnortum at gmail.com writes:
I want to start a run of grace notes with a note with a normal head.
...but with the c' beamed to the d'.
If these notes all happen before the beat, then
\relative c' {
\grace { \tweak #'font-size #0 c32 d e f g a b } c8 }
This looks like it might be a situation where the first note is on the beat.
In these cases, even though we call them 'grace-notes' LilyPonds \grace
is not what I want to use. I just make the notes small and grace-style
and tell LilyPond their actual (as opposed to printed) duration so she
understands how I want them to fit in the music.
\relative c' {
c16[
\teeny
\override Stem #'no-stem-extend = ##t
\override Stem #'length-fraction = #0.7
d32*1/3 e f g a b]
\normalsize
\revert Stem #'no-stem-extend
\revert Stem #'length-fraction
c8
r4 r2 }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible Bug with \partcombine?
Joshua Nichols josh.d.nichols at gmail.com writes: Is there talk about improving this feature? Yes. Someone recently gave \partcombine an option to double-stem unisons http://code.google.com/p/lilypond/issues/detail?id=4112 The example at the top of this follow-up might make more sense http://code.google.com/p/lilypond/issues/detail?id=4198 In the next experimental version (available on Windows and macOS after the one person currently practiced at cross-compiling is back from a trip) you can tell LilyPond just once to double-stem unisons, and then any notes slurred to those unisons are also kept in separate Voices so the slurs have a place to go. The basic mechanism of \partcombine, distributing your music into Voices and letting the rest of LilyPond work on those, will almost certainly stay. That is awkward sometimes, because we are thinking of two voices in the input whether set as chords or double-stemmed. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: would 'gn' for G-natural be useful in \language english ?
Dear list,
In English, pronouncing the 'natural' in 'C-natural' is required if the note is
out-of-key. LilyPond does not consider the key when reading note-input, but
could easily accept 'cn' as a name for the pitch C-natural. There was a
feature request on the bug-list, that LilyPond do so.
Among those responding to the proposal, the Americans were in favor, while the
British Germans Dutch and Flemish opposed.
The worry is that if LilyPond accepts 'cn' without an error, this might imply
that 'c' means something different than C-natural, causing someone accustomed
to ABC or Amadeus input to type 'c' for the leading-tone in the key of D.
The current situation, however, is more difficult for a user accustomed to other
English-centric note-entry systems. LilyPond flags each 'cn' with unrecognized
string and produces (usually) no engraved output.
This might remind him that 'c' always means C-natural, and thus by implication
that he should check his uses of 'c' to see if he ever meant 'cs'. But he must
first change (most of) the 'cn's to 'c' to get any output, and then has no
method better than %{comments%} to note which 'c's really meant C-natural. I
tried using 'c!' in these cases, but not all C-naturals need a printed natural.
If instead LilyPond accepts 'cn' as C-natural, and the documentation mentions that in English
'cn' is accepted as a synonym for 'c' (just after in Dutch 'aes' is accepted as a
synonym for 'as') then LilyPond will give that hypothetical user engraved output. If he has
used 'c' when he meant C-sharp, he can see that LilyPond typeset a C-natural, and hear it in the
MIDI. This behavior form LilyPond would be at least kinder to the user.
That user would want to remember give LilyPond pitches, not scale-steps.
Being able to type the explicit pitch 'cn' (when it is distinct from the scale-step C)
seems to help in that goal.
I have started using English note-entry with 'cn', etc., for naturals when I would say
natural and I find it helpful. If anyone else will use it, I'll push for it
and put it in LilyPond.
__
\language english
\new Staff \transpose c c'' {
\key c\minor \partial 2
r16 g f g ef g d g |
c g bn, g c g d g ef g g, g an, g bn, g |
c g bn, g c g d g ef g d g c g bf, g |
af, g bf, g c f af, f d f c f bf, f af, f |
g, f af, f bf, ef g, ef c ef bf, ef af, ef g, ef |
f, ef g, ef af, d f, d bn, d af, d g, d f, d |
ef, d f, d g, c ef, c r2 }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MultiMeasureRest.minimum-length only for compressed MMRs
Kieren MacMillan kieren_macmillan at sympatico.ca writes: Is there a global/automagic way to make the minimum-length value apply only to compressed MMRs? Instead of minimum-length of the rest itself, you can set the minimum-length of the number (which is, maybe non-obviously, also a 'spanner' of the measure, so that it centers correctly). Then the minimum-length affects measures with a number printed, which might be exactly what you want. \override MultiMeasureRestNumber.minimum-length = #16 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
new LSR snippets
It turns out we can use \partcombine for four voices pretty easily http://lsr.di.unimi.it/LSR/Item?id=492 and a minor documentation clarification showing how to print '8' in place of 8va http://lsr.di.unimi.it/LSR/Item?id=950 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
new LSR snippets
It turns out we can use \partcombine for four voices pretty easily http://lsr.di.unimi.it/LSR/Item?id=958 and a minor documentation clarification showing how to print '8' in place of 8va http://lsr.di.unimi.it/LSR/Item?id=950 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with \autochange and \ottava
Gilberto Agostinho gilbertohasnofb at gmail.com writes:
[in the context of music generated by an algorithm]
I am having trouble dealing with ottava changes while using autochange.
The example showed \ottava changing the ottavation of staves by hand,
but the music moving between staves automatically with \autochange.
You or your algorithm must have some idea on which staff to place the
notes, before determining whether the staff needs an ottava change.
The general solution seems to be to apply whatever algorithm you use
to choose ottavation after applying the \autochange routine
\autoOctave \autoChange {...}
or maybe easier to merge them into one.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: possible bug: \change Staff and beam collision
Gilberto Agostinho gilbertohasnofb at gmail.com writes:
but when changing staff the ottava position
gets lower (!) and collides with the beam.
LilyPond allows you to beam to any other staff, so in general that
beam might have to go up and cross the ottava bracket, while the
bracket must stay with the staff. This is not likely with ottava
brackets but cross-staff beams and their stems sometimes need to cross
similar spanning structures.
The code is so far not sophisticated enough to look ahead to staff layout
when placing the ottava on its home staff, so assumes the cross-staff
beam might have to cross it.
Logically we should have a setting
\override Staff.OttavaBracket.cross-staff =
#ly:side-position-interface::calc-cross-staf
to tell Lilypond she may move the OttavaBracket along with the beam
but when I give LilyPond permission this way, she does not move the beam.
My case is always complicated though, my main work is with algorithmically
generated music and so I always need to either automatize a solution or
completely forget about it and approach the problem of notation from a
different point of view (manual tweaking isn't an option for what I do).
I have no better suggestion. The manual tweak is simple, though,
\once\override Staff.OttavaBracket.staff-padding = #6
and Lilypond makes it easy to put overrides in a separate expression
{ s1*54 \overrideThis}
{ s1*32 s2 \overrideThat}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: To many colliding ...
From: Dr. Bernhard Kleine bernhard.kleine at gmx.net I have added a file which shows the warning. It compiles but I would like to know about the warning. LilyPond complains when two voices have the same stem direction and no indication of which note-head to shift horizontally (in the style of Bach-era polyphony) to avoid the appearance of a chord. If you want the appearance of a chord, then ignore the warning. Be aware, though, that LilyPond is still interpreting your input as two voices, which just happen to overlap in print. If the two voices have eighth notes, there will be two flags, which look ugly in the same direction. (Maybe the warning could help to remind people to check for this?) If you want LilyPond to make a true chord, you can say h g'2 in one of the two voices. Trevor Daniels t.daniels at treda.co.uk writes: It's due to the use of \stemUp and \stemDown commands. Try to code your score without using them by assigning the notes to correct voices. Well, in the example the \\ assigned default voices, but then there was some reason for wanting the \stemUp or \stemDown overrides. Using instead \voiceOne, bzw. \voiceTwo, is usually a good idea, but in the example given an explicit \voiceTwo would ask for two voices both in \voiceTwo and LilyPond gives a warning. It became clear that this warning did more harm than good. Just one month ago, we restricted it. Now when we explicitly ask for \stemDown or \voiceTwo on both voices, LilyPond sets the notes in the same column without complaint. Phil Holmes mail at philholmes.net writes: GNU LilyPond 2.19.14 Success: compilation successfully completed Version 2.19.14 is the first 'development' (for testing) version where this warning has been removed. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \parallelMusic w/ melody, chordmode, tabs worked in 2.14.0 but not in 2.18.2
Stuart A. Harvey stuart.a.harvey at gmail.com writes:
The snippet of code below used to work in 2.14.0. Now that I have
installed 2.18.2 I get “Bars in parallel music don’t have the same length”.
Is there any way to accomplish this in 2.18.2 where the lead line, chords,
and tabs are written in parallel?
The only solution I see is to remove the bar-check symbols '|'
within each segment intended for one voice.
\relative g' { g4 g8 g8 g4 b4 d4 b4 g2 a4 fis4 d2 d'4 b4 g4 d4 } |
\chordmode { g1 g1 d1 g1 } |
LilyPond started interpreting some of your '|' signs as indications
to change from on parallel input to the next, when we accepted the change
http://code.google.com/p/lilypond/issues/detail?id=451
which was clearly a mistake, but then further changes
http://code.google.com/p/lilypond/issues/detail?id=3118
made LilyPond's \parallelMusic dig deep looking for bar-check symbols.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Anacrusis in multiple tunes on page
Patrick or Cynthia Karl pckarl at mac.com writes:
Recently you posted:
What I am trying to do is is to put multiple tunes on a single page
as for a set of tunes for a dance. The problem that I'm having is
that many of these tunes start both the A part and the B part
with an anacrusis and end the part with a shorter measure to
make the number of beats work out.
and Keith OHara responded:
From what you wrote I see no problem,
I think what he means is that your more or less minimal example.
doesn't throw any warning or error messages in LilyPond 2.18.0.
I also meant that I saw no problem for LilyPond 2.18 to handle what
he described in text. In traditional music, all the measures are the
same length, but sometimes the logical A and B parts begin a
fraction of a measure early, or repeats happen in the middle of a
measure.
music = \relative b' {
\partial 4 c4
c1
\break
\partial 4 d4
d1 }
This looks like it has five beats in a measure. We don't want to dance
to that. We want to finish the first tune in time to start the pickup
for the next tune in rhythm, so the tunes fit into a set.
\relative b' {
\partial 4 c4
c2. \bar! \break
d4 d1 }
Maybe new LilyPond will allow you to put \partial in the middle of a
piece, but we do not want to use \partial in the middle of a piece.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Anacrusis in multiple tunes on page
Don Gingrich gingrich at internode.on.net writes:
Partial works fine for the initial anacrusis, but if the piece has multiple
parts, each with an anacrusis, the processor complains about the
subsequent \partial directives. It also doesn't much like a \partial
at the end of the section.
I've tried just leaving them out, but the programmer in me does not
like the warning messages that result.
From what you wrote I see no problem, and in traditional music,
I would expect you need only the \partial at the beginning of each tune,
because the meter continues unbroken within the peice.
So I am guessing that you might think that you need to use partial
whenever a visible measure is incomplete. You can end repeats
and place barlines mid-measure whenever you like.
\new ChordNames { s4 g2.*3 d2. s2 }
\new Voice \transpose c c' {
\time 3/4 \partial 4
\repeat volta 2 { c'4 g2. g2.
g2 }
b4 d2. d2 \bar |. }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to write Non sequential repeat alternatives
MarcM marc at mouries.net writes:
When i run your code i get this message: warning: already have a volta
spanner, ending that one prematurely
Oh, so that's why you had the explicit (volta #f) in your version.
If I see a warning, but the output is good, I consider myself warned
and happy, but I should have kept your good idea to avoid the warning
\score { \relative c'' {
\time 6/8
\partial 8 a16 b
\repeat volta 5 {
c 4 c8 c d e
d 8 b g g a b
} \alternative {
{
\set Score.repeatCommands = #'((volta 1,3) )
c 8 a a a b c
b 8 e, e e4 a16 b
} {
\set Score.repeatCommands = #'((volta #f)(volta 2) end-repeat)
c 8 b a b4 g8
a4 a8a4 a16 b
} {
c8b a b4 g8
a4 a8a8 e' f
} { a,4 a8 }} a4.\fermata \bar |. } }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Key signatures in hidden staves take up space
Peter Crighton petecrighton at gmail.com writes: As you can see in the following code and the attached image, there is a possible bug when using \RemoveEmptyStaves with voices in different keys (such as in a score with transposing instruments): key signatures appearing only in hidden empty staves are still causing space in the shown staves. entered at https://code.google.com/p/lilypond/issues/detail?id=4157 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to write Non sequential repeat alternatives
MarcM marc at mouries.net writes:
I found the \set Score.repeatCommands and I am getting close but the
repeat
bars are not added at the right place.
If I understand your comment,
It is played as: A , A1, A , A2, A , A3, A , A4, A , A5/End
where endings 1 and 3 are the same and you don't want to retype the notes,
then the repeats go all the way back to the start of the 'A' part,
and you can use the usual \repeat \alternative input, and change
just the labels on the voltas
\score { \relative c'' {
\time 6/8
\partial 8 a16 b
\repeat volta 5 {
c 4 c8 c d e
d 8 b g g a b
} \alternative {
{
\set Score.repeatCommands = #'((volta 1,3) )
c 8 a a a b c
b 8 e, e e4 a16 b
} {
\set Score.repeatCommands = #'((volta 2) end-repeat)
c 8 b a b4 g8
a4 a8a4 a16 b
} {
c8b a b4 g8
a4 a8a8 e' f
} { a,4 a8 }} a4.\fermata \bar |.
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partcombine/divisi framework - let the fun begin!
The development version 2.19.13 with the expanded remove-staves capability is
now available.
On Sat, 30 Aug 2014 04:41:15 -0700, Janek Warchoł janek.lilyp...@gmail.com
wrote:
2014-08-29 8:53 GMT+02:00 Keith OHara k-ohara5...@oco.net:
But if someone uses these definitions with music that uses tags for
some other purpose, the tagged music will be left out.
Hmm. That's a problem, but i don't see a good solution yet.
Simon's suggestion to use the more-selective \removeWithTag is a good solution.
Just in case anyone uses the \divisibleStaff with his own tags, and might not
think to include 'together in \keepWithTag score \divisibleStaff ... , I added
a function to clean up the divI/divII/together tags when we are done with them.
These two changes are attached.
I see now that the clean-up function I had to add was already available among several
useful tag filters from http://lsr.di.unimi.it/LSR/Item?id=871
Users of these definitions, with music that uses \tag#'part for example, need
to adapt their \keepWithTag if they want to separate out the 'divI part, and
also keep whatever they have tagged with 'part: \keepWithTag divI.part
\music\version 2.19.13
\include definitions.ily
\layout {
short-indent = 2\cm
indent = 2\cm
line-width = 10\cm
}
music = {
\together
c'4 d' e' f'
\tag#'score { s_\markup\italic balance with winds }
\sharedStems
{ a'4 f' a' g' }
{ f' d' f' e' }
\voiceDivisi {
g' b' d' b'
d'' b' g' b'-\tag#'part \upbow
}
{
g'4 e' g' e'
b' g' b' g'-\tag#'part \upbow
}
\tag#'editorial {s4\ s s s\f }
\tag#'score { s_\markup\italic balance }
\staffDivisi
{ a' f'' g' q b' }
{ a' e' b' e'' a' q }
\together
c' d' e' f'
\soloI { g' b' d' b' }
\together
f' a' d' f' f' a' e' g'
f' e' d' c'
}
\markup \bold { Violin I part: }
\new Staff \with {
instrumentName = Violin I
shortInstrumentName = V I
} \keepWithTag divI.editorial.part \music
\markup \bold { Violin II part: }
\new Staff \with {
instrumentName = Violin II
shortInstrumentName = V II
} \keepWithTag divII.editorial.part \music
\markup \bold { Combined: }
\keepWithTag editorial.score \divisibleStaff Violin \music
definitions.ily
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partcombine/divisi framework - let the fun begin!
Simon Albrecht simon.albrecht at mail.de writes: Am 29.08.2014 um 08:53 schrieb Keith OHara: You should do something similar for the \together segments. As you have it now, the together segments are un-tagged, so are included in all three staves (two of which are not printed). Oops. We need the 'together' segments to be included in all three staves, so it is printed (twice) if the music is set on a wide page where 'together' segments are on the same line as separate-staff divisi. But if someone uses these definitions with music that uses tags for some other purpose, the tagged music will be left out. A problem which always comes up when trying to use tags in more than one layer. A workaround is the use of \removeWithTag in place of \keepWithTag, e.g. replace \keepWithTag together by \removeWithTag divI.divII Yes. That method will at least preserve music that the user has tagged for some other purpose, and it co-exists with \removeWithTag for other purposes. The way \keepWithTag keeps completely untagged music is convenient, but quickly causes trouble if we use tags for other purposes. I see there is an enhancement request already https://code.google.com/p/lilypond/issues/detail?id=4083 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
would 'gn' for G-natural be useful in \language english ?
Dear user list, The suggestion quoted below from the bug-lilypond list http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html makes sense to me, as an addition to the \language english note-names. It would not fit in German-style pitch-names, where 'cis' and 'ces' get completely distinct names from 'c'. I am not sure if something similar makes sense in fixed-do naming as used in French and Spanish. Would anyone else like to see 'fn' as a second way to express F-natural in English (in addition to the existing 'f') ? David Winfrey writes: A new accidental for entering natural notes would be useful. In English, this would be 'n', as in 'bn4' or 'gn2'. These would have exactly the same effect as 'b4' or 'g2', but would be easier to debug. If the user is entering or editing music in the key of F, or some other key where B is normally flat, it is often not clear if 'b4' was intended to be B-natural, or if someone just forgot to flat it. If the note is written as 'bn4', the note was clearly meant to be B-natural. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partcombine/divisi framework - let the fun begin!
Janek Warchoł janek.lilypond at gmail.com writes: I'm working on putting together a set of functions for handling parts that split into multiple voices and/or staves Attachment (definitions.ily): text/x-lilypond, 2359 bytes Attachment (example.ly): text/x-lilypond, 825 bytes Attachment (example.pdf): application/pdf, 33 KiB I like the way 'definitions.ily' uses parallel music constructions to ensure that the parts re-synchronize even if there is a note missing in the input. You should do something similar for the \together segments. As you have it now, the together segments are un-tagged, so are included in all three staves (two of which are not printed). But if someone uses these definitions with music that uses tags for some other purpose, the tagged music will be left out. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: would 'gn' for G-natural be useful in \language english ?
On Fri, 29 Aug 2014 03:06:31 -0700, Brian Barker b.m.bar...@btinternet.com wrote: At 23:41 28/08/2014 -0700, Keith OHara wrote: The suggestion quoted below from the bug-lilypond list http://lists.gnu.org/archive/html/bug-lilypond/2014-08/msg00037.html makes sense to me, as an addition to the \language english note-names. It would not fit in German-style pitch-names, where 'cis' and 'ces' get completely distinct names from 'c'. Sorry, but I don't see the distinction you are trying to make between German and English. Surely C, C-sharp, and C-flat (and for that matter -double sharp and -double flat) have separate names in any language, including German, English, German Lilypond, and English Lilypond? In English the names use two parts, noun-adjective, which allows the construction C-natural. German has single words (ces c cis) for the pitches, and these are distinct from the names for the alterations (Be, AuflösungZeichen, Kreuz). English speakers use C-natural to name the pitch in contexts where the key has sharped the scale-step C. After entering cn in, say, D major, one would readily fall into the trap of using c in the next bar where cis (or cs) was actually meant and required. The feature-request implicitly assumed, based on experience, that such errors already happen. Anyone using, for example, ABC notation had developed the habit of typing 'C' for the pitch at scale-step C in the key. The distinct naming was suggested as a way to help us more efficiently correct those errors. Would the ability to enter 'cn', or a note in the Languages table saying In English 'cn' is an alternative to 'c' to denote the pitch C-natural, actually increase the rate of forgetting the 's' in 'cs' ? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: partcombine problems
Orm Finnendahl wrote:
Can someone shed a light on this or is it a bug?
I just reported it as a bug. It is surprising we have noticed it before.
The only workaround I can see is to use a spacer rest with grace-note-timing.
\new Staff {
\partcombine
{b4 b b b R1}
{R1 \partcombineSoloII b4 b b b}
}
% workaround: \grace s8 \partcombineSoloII
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Rest invisible after part combine
Pierre Perol-Schneider pierre.schneider.paris at gmail.com writes: As far as I remember it was a well known issue. I thougt it was over but I have to admit that I barely use partcombine. For more details, see : https://code.google.com/p/lilypond/issues/detail? id=261 When using partcombine to build an instrumental score, during the time when one instrument is playing solo, we usually want to leave out the rests for the other instrument. The usual Solo or a2 mark makes it clear whether the notes are unison or solo. For this case with all the short rests, it seems you would like an option to \partcombine that sets only in chords or as separate voices, never using the solo settings. LilyPond doesn't have exactly that yet. Also the \aikenHeads shortcut only affects one voice, so you probably want instead \set Staff.shapeNoteStyles = ##(do re miMirror fa sol la ti) just once in each Staff where you want that style. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Column line spacing changed with 2.18
Javier Ruiz-Alma javier at ruiz-alma.com writes:
Need troubleshooting help with a two-line markup block.
If you can make a *single* block that has the same height as a
two-line column, then there is no trouble with the gap.
Somebody better at LilyPond' s markup language might be able to do this
more simply, using predefined functions. I could only find this
\version 2.18.2
#(define-markup-command (barstrut layout props w arg)
(number? markup?)
#:properties ((font-size 0))
Draw a filled box of width @var{w} scaled by font size,
height matching @var{arg}.
(let* ((t (* (magstep font-size) w))
(m (interpret-markup layout props arg))
(x (cons (- t) t))
(y (ly:stencil-extent m Y) ))
(ly:round-filled-box x y 0)))
#(set-global-staff-size 30)
\markup \abs-fontsize #9 \line {
\center-column { left 1 mouses }
\barstrut #0.2 \center-column { É j }
\abs-fontsize #9 \column { line 1 line 2 }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: baseline-skip affects font size???
Richard Shann richard at rshann.plus.com writes: I see that baseline-skip is affecting the size of the white triangle, which doesn't seem to be what's in the documentation. The \triangle has behaved that way since its original introduction, at 2005-05-04 * ly/chord-modifiers-init.ly (blackTriangleMarkup): use it. * scm/define-markup-commands.scm (triangle): new command, as robust replacement for unicode Delta/Triangle. That seems to be a mistake, because characters should scale with fontsize only, not with the baseline-spacing. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: cross-staff bug?
On Sat, 26 Jul 2014 08:41:41 -0700, David Nalesnik david.nales...@gmail.com wrote: Thank you very much, Keith, for the explanations and the two snippets. They cover the situations I've encountered so far. (The first when there are no scripts present.) I suggest using the simpler first method for all cases. The second example was just an experiment to see how entangled the decisions about placement can become. I'm mystified by the need for tweaking avoid-slur, though. Without the tweaks, collision detection between scripts and DynamicLineSpanner appears to be lost. I would have thought that making Script non-cross-staff would have been sufficient. If the accent and fermata are placed depending on where the cross-staff slur goes, they don't get a permanent space reservation until the slur is placed, which is after staves are spread on the page. When I set Scripts as non-cross-staff in your example, it looks like the dynamics avoid a tentative placement of the fermata and accent, both scripts being placed on top of each other just clear of the note-head . ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: cross-staff bug?
David Nalesnik david.nalesnik at gmail.com writes:
Attempting to put dynamics above cross-staff notes using the code below
leads to some awful collisions.
LilyPond postpones deciding the placement of things that cross staves,
until the staff-spacing is known. A minor variation of your example,
with the notes a little closer together, might need to be set with
the stems all up, if the music is on a page with tight spacing between
staves, and then the accent would go below the note, but the slur
would need to clear the beam.
Some of the postponed placements collide with other objects, because
so far we haven't worked out all the interdependencies between
placements of objects. The manual suggests telling LilyPond how
far to put the dynamics from the nearest staff.
http://lilypond.org/doc/v2.18/Documentation/notation/common-notation-for-
keyboards#changing-staff-manually
The My pure_y_common.. might contain several staves indicates
an unsolved problem that LilyPond can't figure out which Staff needs
to get space around it to place the dynamics. When that error appears,
the dynamics might hit another staff, so I would use :
up = \change Staff = up
dn = \change Staff = down
\new PianoStaff
\new Staff = up {
\once\override DynamicLineSpanner #'padding = #5
s8*7^\p^\ s8^\f }
\new Staff = down {
e'8[
( \up b' \dn g' \up d'' \dn b' \up f'' \dn d'' \up
a''\marcato\fermata]) }
%% Just as an experiment, this is my best attempt
%% to help LilyPond make the placement decisions on her own
\new PianoStaff
\new Staff = up {
s8*7^\p^\ s8^\f }
\new Staff = down {
e'8[
( \up b' \dn g' \up d'' \dn b' \up f'' \dn d'' \up
\once \stemDown
\once \override Script #'cross-staff = ##f
a''-\tweak #'avoid-slur #'ignore \marcato
-\tweak #'avoid-slur #'ignore \fermata]) }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Weird spacing related to barlines
Phil Holmes mail at philholmes.net writes:
Can anyone explain what's going on here?
\score {
\new MensuralStaff {
\layout {
\context {
\Score
\override SpacingSpanner #'spacing-increment = #0
\remove Default_bar_line_engraver
}}}
The Default_bar_line_engraver works oddly, in that it turns bar lines
on and off. Without it, when you say \bar| in the music, you start
getting barlines after every note, and a double barline after every
measure. We don't see them because the MensuralStaff sets barlines
to be invisible.
\override SpacingSpanner #'spacing-increment = #0.0
asks for zero space between notes, but there is no ragged-right,
so LilyPond tries to stretch out the lines, and the space between
barlines is the only space that can stretch.
The barlines use a different setting for spacing
\override BarLine #'space-alist #'first-note = #'( fixed-space . 0.0)
for historical reasons, and unfortunately.
If you don't have measures, maybe leave Default_bar_line_engraver
in place, and just stop the measure-counting with
\context {\Score timing = ##f }
and put \bar wherever a break would be allowable.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: temporarily disable Dot_column_engraver?
On Wed, 25 Jun 2014 10:14:13 -0700, Mark Polesky markpole...@gmail.com wrote: Keith OHara wrote: Put the small notes in a temporary Voice and give that Voice a Dot_column_engraver. Having this engraver in both a Voice and Staff is not problem here. You get two DotColumns, but that is what you want, and the Dots that are caught by the DotColumn in the Voice are not caught again by that in the Staff. Doing as you suggested puts the first dot directly *below* the note head. Am I doing something wrong with my code here? Oops. That is not a problem that I suspected and I didn't check carefully enough before making my suggestion. Sorry. Probably you will want to simply move Dot_column_engraver from Staff to Voice in general, so every Voice aligns its own dots. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Double key signature
Pierre Perol-Schneider pierre.schneider.paris at gmail.com writes:
On the french list we are working on a Merulo score with an 8 lines
staff, 2 clefs and 2 key signature
As you can notice, I still have to manually set the distance between the
key signatures.
LilyPond supports custom key signatures, and will print this for d\minor
if you ask for an extended range of printed flats:
\new Staff
\with {
\override StaffSymbol.line-count = #8
\override KeySignature.flat-positions = #'((-7 . 6))
\override KeyCancellation.flat-positions = #'((-7 . 6))
% presumably sharps are also printed in both octaves
\override KeySignature.sharp-positions = #'((-6 . 7))
\override KeyCancellation.sharp-positions = #'((-6 . 7))
\override Clef.stencil = #
(lambda (grob)(grob-interpret-markup grob
#{ \markup\combine
\musicglyph #clefs.C
\translate #'(0.9 . -2) \musicglyph #clefs.F
#}))
clefPosition = #1
middleCPosition = #1
middleCClefPosition = #1
} {
\key d\minor
\time 4/4 R1
}
You might like \translate, in units of staff spaces, in place of \vspace.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: temporarily disable Dot_column_engraver?
Mark Polesky markpolesky at gmail.com writes: Normally, the dots on dotted notes in different voicesshould be aligned The textbooks say we should set dots set independently for each voice https://code.google.com/p/lilypond/issues/detail?id=2200 But slightly-misaligned dots in some cases drew some complaints, so LilyPond sets all voices' dots in one column by default. Is theresome override to tell LilyPond: In this voice, stop using the staff's Dot_column_engraver, and start using the Voice's*own* Dot_column_engraver, which I could then revert when I'm done with the small notes? Put the small notes in a temporary Voice and give that Voice a Dot_column_engraver. Having this engraver in both a Voice and Staff is not problem here. You get two DotColumns, but that is what you want, and the Dots that are caught by the DotColumn in the Voice are not caught again by that in the Staff. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Typesetting b bes! chord
Vaughan McAlley vaughan at mcalley.net.au writes:
I prefer what Lilypond does. In some modern contexts there might be a
diagonal stem from the B natural to the stem of the B flat, but
leaving it out is definitely easier.
There is an example of how to draw that diagonal stem at
http://lsr.di.unimi.it/LSR/Item?id=505
but I also prefer the single-stem chord notation.
By default, LilyPond applies the usual rules for chords to this case,
and it works well. The flat is printed left of the natural, so the
natural cannot be mistaken as canceling a double flat.
I leave these clusters printed as chords, and shift the flat a little
lower, so that the accidentals are staggered, and then I recognize it
as a chord of a second without hesitation.
{ \tweak Accidental.Y-offset #0.2 b'!
\tweak Accidental.Y-offset #-0.1 bes' 4 r4
a'! \tweak Accidental.Y-offset #-0.4 aes' 4 r4 }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible Bug with \numericTimeSignature
Joshua Nichols josh.d.nichols at gmail.com writes:
global = {
\key c \major
\numericTimeSignature
It is a bug, but you can fix this one yourself if you like.
In 'property-init.ly' the definition is
numericTimeSignature = \override Staff.TimeSignature.style = #'numbered
but we want it to apply to the entire Score, not just one Staff.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Possible Bug with \numericTimeSignature
Joshua Nichols josh.d.nichols at gmail.com writes:
I've never experienced this before now...
Oops, I just realized you mean the grace-note bug.
Whenever you write a grace note in LilyPond, you need grace
notes or skips of the same duration in every other staff.
So here in the upper staff you need \grace {s8}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Extra naturals in accidental-style teaching?
Paul Morris paul at paulwmorris.com writes: Ariel Barton wrote I am trying to use the accidental style teaching to make my music a little easier to use. The problem is, teaching produces a whole lot of superfluous natural signs that aren't really helpful; they just clutter up the page. (They don't seem to follow any particular rules, either; they seem to be distributed at random.) This may be a bug. Yes. Version 2.14 of LilyPond printed reminders for only sharps and flats. I put https://code.google.com/p/lilypond/issues/detail?id=3894 on the bug list. This is something that can be fixed without recompiling LilyPond, so any one of a number of people here might follow that link to the change in code that changed behavior, figure out what was intended, and a way to do it with the desired output. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 'Accidental' collision in newer versions of lilypond
Joey Di Nardo username652719 at gmail.com writes: Hi all, I am attempting to use Sagittal notation accidentals in my lilypond files (see folder link), and as you can see when you run ratios.ly the accidentals collide with the actual note glyphs. There was an enhancement to spacing accidentals from their notes http://code.google.com/p/lilypond/issues/detail?id=2811 and the new spacing method seems to ignore the extents defined for these custom accidentals. I can't figure out how to make the new way work, but you can go back to the old way of spacing accidentals by including \override Staff.Accidental #'horizontal-skylines = #'() with each occurrence of \override Staff.Accidental #'Y-extent = ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Overriding staff-padding for MeasureCounter fails
David Nalesnik david.nalesnik at gmail.com writes: On Fri, Feb 14, 2014 at 3:33 AM, Ed Gordijn ed.klarinet at gmail.com wrote:Hi, % \override MeasureCounter.staff-padding = #4 % doesn't work either Huh--that's strange. This will involve some investigation to get at the cause, determine if there's a bug. The code that implements staff-padding is used only when requested with \override MeasureCounter #'Y-offset = #side-position-interface::y-aligned-side ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to revert an override in partcombine
Ed Gordijn ed.klarinet at gmail.com writes:
I use an override in partcombine to ignore collisions. But how do I
revert this again?
Revert the next time that \partcombine output has the same
configuration of Voices.
As the two parts change in relation to each other, the part-combiner
sometimes routes them in to one Voice, sometimes into separate Voices.
Most overrides change a setting of the current Voice, so if you override
while voices are separate, you change the way separate voices are set,
but the next music in unison is unaffected.
Overrides apply to at the moment of the next note, so an override
immediately before \partcombineAutomatic applies to the first note
that goes into the automatically-chosen configuration of Voices.
So you have to change your overrides that apply to Voices
the next time those Voices are in use.
musicII = \relative g' {
\partcombineApart
\override Voice.NoteColumn.ignore-collision =##t
g1~
g1
\partcombineAutomatic
g2 g
\partcombineApart
\override Voice.NoteColumn.ignore-collision =##f
g2 e
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behaviour of TextSpanner dashes
Urs Liska ul at openlilylib.org writes:
[That's something I often struggle with: I think the function or
parameter definition that is generated from the sources is often quite
sparse]
You are changing behavior rather deep in the details.
You can search for stencil-offset in the setup files to see an example
of its use. In define-grobs it is used for a dyanmics spanner. It is
a pair of numbers, probably X and Y:
\relative c'{
\override TextSpanner.bound-details.left.stencil-offset = #'(0 . -0.5)
\override TextSpanner.bound-details.right.stencil-offset = #'(0 . -0.5)
\override TextSpanner.bound-details.left.text = #ggg
\override TextSpanner.bound-details.right.text = #hhh
c4^\startTextSpan c c c \stopTextSpan }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behaviour of TextSpanner dashes
At 15:24 on 05 Feb 2014, Urs Liska wrote: - the vertical position of the dashes (i.e. raise it a little bit relatively to the text) TextSpanner.bound-details.left.stencil-align-dir-y = #CENTER unfortunately doesn't help. I'd need something like raise the dashes by 0.2 ... Kieren MacMillan kieren_macmillan at sympatico.ca writes: Surprisingly it looks different with different texts. Another side-effect of the [irritating] fact that Lilypond doesn’t use the text baseline as the reference point!?!? Lilypond does use the text baseline as reference point for text. It seems that override of stencil-align-dir-y = #CENTER makes LilyPond *replace* the usual reference point with the vertical center of the text, including descenders if there are any. Other values in place of CENTER move the reference to different fractions of the vertical extent. Looking at the code, leaving stencil-align-dir-y unset leaves the reference point at the baseline. The documentation talks next about stencil-offset Try that. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Behaviour of TextSpanner dashes
On Wed, 05 Feb 2014 20:05:28 -0800, Kieren MacMillan
kieren_macmil...@sympatico.ca wrote:
Lilypond does use the text baseline as reference point for text.
Really? Then why do these texts not align along their baselines:
The default settings have the same minimum gap between staff and text,
including descenders, as the minimum space from staff to the baselines. So the
padding against collisions is all we see.
We can change the settings, increasing the space to the baseline:
http://lilypond.org/doc/v2.18/Documentation/learning/fixing-overlapping-notation#the-staff_002dpadding-property
{\textLengthOn
\override TextScript #'staff-padding = #1
c''^\markup { NO DESCENDERS!! }
c''^\markup { jjjyyyjjjggg } }
(There are some other things -- tempo marks, I think -- where the code makes so
many adjustments to placement that I could not figure out how to uncover the
simple behavior of spacing to the baseline.)
I think it would be better to move the reference line to half the x-height of
the font above the baseline (as it is now for the p, f, etc., letters in
dynamics) for any text near music.
Then the same distance from staff to reference line would make sense for items
both above and below the staff,
and it would be simpler to center lyrics between staves (no longer needing to
adjust distances by that half an x-height).
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Looking for work arround for partcombine's known issue
On Sat, 25 Jan 2014 01:05:38 -0800, Ed Gordijn ed.klari...@gmail.com wrote:
\tag #'partcombineOnly { \once\stemUp
\once\override NoteColumn #'ignore-collision =##t }
In the particular example you show, of course, the tags are not needed,
because the overrides you want for the part-combined music (stem up and
un-shifted NoteColumn) are also the desired and default output for the
individual part with the lower E.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Looking for work arround for partcombine's known issue
Ed Gordijn ed.klarinet at gmail.com writes:
musicI = { e''2( a'2) }
musicII = { e'2( \partcombineApart a'2) }
{
\partcombine \musicI \musicII
}
You can print the slurs separately
musicI = { e''2( a'2) }
musicII = {\partcombineApart e'2( a'2) }
or together
musicI = { e''2( a'2) }
musicII = { e'2( a'2) }
Maybe this is not really an 'issue' at all.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Looking for work arround for partcombine's known issue
On Fri, 24 Jan 2014 12:16:02 -0800, Ed Gordijn ed.klari...@gmail.com wrote:
So the e' e'' as a
chord and the a' with two stems.
I don't see any way to have \partcombine do that, but you could force the lower
e to have a stem up and line up with the upper note. This almost looks like a
chord. (If the overrides are inconsistent with how you want the individual
parts to look, you can use the \removeWithTag feature.)
musicI = { e''2( a'2) }
musicII = {\partcombineApart
\once\stemUp
\once\override NoteColumn #'ignore-collision =##t
e'2( a'2) }
\partcombine \musicI \musicII
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [SPAM] Re: Non-standard notation challenges (no game this time...)
Urs Liska ul at openlilylib.org writes: The point in the edition of such snippets is to _document_ the actual state of a manuscript. This isn't _music_ but rather a remainder from the compositional process. Comparing this with later states allows an editor to draw conclusions on the genesis of the composition. You will probably need to use PostScript. http://www.lilypond.org/doc/v2.18/Documentation/notation/ formatting-text#graphic-notation-inside-markup Then those markings that have no certain interpretation are not input as musical glyphs that have an intended interpretaion, but as lines and curves. Probably the PostScript can be in text scripts, but with X-offset and Y-offset hand-tuned to particular numbers so that LilyPond does not try to place these marks herself. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: how close are we to having an addAt or insertAt feature?
Kieren MacMillan kieren_macmillan at sympatico.ca writes:
What would be involved in developing a feature to add notes or tweaks at an
arbitrary moment within a music expression?
e.g.
global = \repeat unfold 100 s1
music = \addAt (4 3/8) \global \once \override RehearsalMark.extra-
offset #’(-1 . 0)
where (4 3/8) means “in the fourth measure, at the moment of the 3rd eighth
note”
There is, of course, the simultaneous music construction with
music = \global
{ s1*4 s8 s8
\once\override Score.RehearsalMark #'X-offset = #-1
\mark A }
{ s1*11 \mark12 }
{ s1*29 \mark30 }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problem with the spacing of microtonal accidentals
Stefan Thomas kontrapunktstefan at gmail.com writes: It uses the true type font HE for special microtonal accidentals.I've found this font somewhere in the web. Unfortunately the accidentals are too close to the notes. How can I give them more space? I tried everything. When I compile the file, I get the error messages like this:Mikrotoene_kurzbeispiel.ly:69:4: warning: Could not find glyph-name for alteration 1/6ch chh Which is strange, because lilypond shows the correct accidentals. The function that the Accidental's 'stencil points to by default does the job of deciding whether to remove the accidental (if it is the second note in a tie, and not at a line-break). We (at least I) happen to be considering to change this, as issue 3749. This unusual action for a 'stencil has caused all the layout code to avoid using the 'stencil property, and to go directly to the code that looks up the accidentals in 'glyph-name-alist. Specifically, the function that 'horizontal-skylines points to by default tries to use the glyph-name-alist, so you will need to replace that. Maybe setting it to #'() will work. Probably you intend to combine accidentals in a string. If not for that, you could write their letter names 'm' 'p' etc. in the glyph-name-alist. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
