Re: 64-bit Mac build of 2.20 is now available!

[Arle Lommel]

Glad my feedback seems to be useful.

[cutting a bit here]

> Thanks, this makes sense.  I should be able to set the variables correctly 
> (and actually, the lilypond "binary" in the app bundle is already a script 
> that sets a few variables and calls the real executable, so putting a few 
> more in there should not be a problem).   
> 
> I've created https://gitlab.com/marnen/lilypond-mac-builder/-/issues/23 
>  for this bug.  
> Feel free to subscribe there for updates, or to create new issues there if 
> they're problems with the 64-bit Mac packaging rather than LilyPond itself.

Great. Glad it seems solvable.

> #2: Update.ly  doesn’t work for me when invoked from 
> Frescobaldi.
> 
> You mean convert-ly?

Yes. My mistake.

>  I get this message about a bad CPU type when I run it from Frescobaldi.
> 
> Weird, I haven't seen that.  I'll try to reproduce.  What version of Mac OS 
> are you running?

I’m running 10.15.3 on a 2016 13” Touch Bar MacBook Pro. I’m using Frescobaldi 
2.20.0. I seem to recall there are problems with the more recent versions on 
the Mac.

Best,

Arle

Re: LilyPond 2.19.84 installer on MacOS 10.15 (Hans Åberg)

[Arle Lommel]

Hans,

Thank you for providing this. It works great, except for one bug I found. It 
seems that when it’s installed it expects the file system to be using ISO Latin 
1 rather than UTF-8.  When I ran it on file names with non-ASCII characters in 
UTF-8, it returned fatal errors like this:

Warnung: »(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-dAutoRotatePages=/None -dPrinted=false 
-sOutputFile=Bartók-Béla-Székely-friss.pdf -c.setpdfwrite 
-f/var/folders/64/hl6gpmy17994gn1w87__6yvcgn/T//lilypond-JSXs35)« 
gescheitert (256)

schwerer Fehler: gescheiterte Dateien: "/Users/fenevad/Dropbox/music 
scores/bartok/Barto�\x81k-Be�\x81la-Sze�\x81kely-friss.ly"
Exited with return code 1.

If I change the name of the file to use ASCII only, it works properly.

Hope that it helps you to know about this bug.

-Arle


> On Feb 20, 2020, at 15:27, lilypond-user-requ...@gnu.org wrote:
> 
> Message: 3
> Date: Thu, 20 Feb 2020 20:47:42 +0100
> From: Hans Åberg mailto:haber...@telia.com>>
> To: LilyPond User mailto:lilypond-user@gnu.org>>
> Subject: LilyPond 2.19.84 installer on MacOS 10.15
> Message-ID:  >
> Content-Type: text/plain; charset=us-ascii
> 
> I made a LilyPond 2.19.84 installer for use on MacOS 10.15 from MacPorts 
> lilypond-devel, available on the link below. It installs in /opt/lilypond/, 
> with the program in /opt/lilypond/bin/lilypond.
> 
> If you have already something installed in this directory, it may be prudent 
> to remove it first. This can be done by the command
>  sudo rm -r /opt/lilypond
> 
> https://web2.storegate.com/share/JPhrvtH 
> 
> 

Re: Grace notes in the first measure mess up the layout

[Arle Lommel]

Thanks much. I *hunted* all over for something like this, but clearly didn’t 
have the right search string as I thought this was a problem with the *first* 
measure in a piece.

This helps.

> On Feb 3, 2020, at 22:14, Daniel Rosen  wrote:
> 
>> From: Arle Lommel [mailto:fene...@gmail.com] 
>> Sent: Monday, February 03, 2020 10:04 PM
>> To: Lilypond-User Mailing List 
>> Subject: Grace notes in the first measure mess up the layout
>> 
>> How can I get this to display as expected?
> 
> Just add an equivalent grace note spacer in the other voices, as shown in the 
> NR 
> (http://lilypond.org/doc/v2.19/Documentation/notation/special-rhythmic-concerns#grace-notes,
>  under "Known Issues and Warnings"):
> 
> \version "2.19.83"
> 
> vocal = \relative c'' {
>   \clef treble
>   \key aes \major
>   \grace s16  % <-- Here
>   R2.
> }
> 
> upper = \relative c'' {
>   \clef treble
>   \key aes \major
>   \grace s16  % <-- and here
>   c4 ees4 g4
> }
> 
> lower = \relative c' {
>   \clef bass
>   \key aes \major
>   \time 3/4
>   \grace b,16( 2.) |
> }
> 
> \score {
>  <<
>\new Voice = "mel" { \vocal }
>\new PianoStaff <<
>  \new Staff = "upper" \upper
>  \new Staff = "lower" \lower
>>> 
>>> 
>  \layout {}
> }
> 
> DR

Grace notes in the first measure mess up the layout

[Arle Lommel]

I’m running into a major layout fault when I have a grace note in the first 
measure of a piece. Measures with a grace note look as expected, but all other 
staves are *really* ugly.

I’m assuming this is *not* the intended behavior and conjecture it is happening 
because Lilypond sees the grace note as inhabiting a time before the measure 
starts and so kicks the key signature and clef to appear to the right of the 
grace note . Removing the grace note gets everything looking right.

How can I get this to display as expected?


MWE:

\version "2.19.83"

vocal = \relative c'' {
\clef treble
\key aes \major
R2.
}

upper = \relative c'' {
\clef treble
\key aes \major
c4 ees4 g4
}

lower = \relative c' {
\clef bass
\key aes \major
\time 3/4
\grace b,16( 2.) |
}

\score {
  <<
\new Voice = "mel" { \vocal }
\new PianoStaff <<
  \new Staff = "upper" \upper
  \new Staff = "lower" \lower
>>
  >>
  \layout {}
}



Best,

Arle

Re: license question

[Arle Lommel]

> From: David Nalesnik  >
> Subject: license question
> 
> Hi all,
> 
> I have a question concerning the GPL.  Is it permissible for an app
> under a GPL-incompatible license to provide output in LilyPond code?
> For example, could Finale provide a Finale->LilyPond converter even
> though the mechanics are shrouded in mystery?
> 
> Thanks,
> David



I am not a lawyer, but this question closely aligns with issues related to 
those currently before the US Supreme Court in Google v. Oracle.

With that preamble, here is my understanding:

A converter is not reproducing code. No license from the GLP project applies to 
it because you are not reproducing licensed code. The converter produces a 
textual representation of music, and this representation itself is not subject 
to the GPL terms. *Anything* can generate that code because no copyright 
applies to a method, which is what an abstract process for going from something 
like g4^. to a graphic representation of a staccato G quarter note is.

Also note that if someone wanted to write a clean-room interpreter or converter 
for Lilypond code that did not use any GPL code, that should be legal as well, 
because methods are not subject to copyright (although code is) and a Lilypond 
input file is a call to methods, not to code (although those methods are 
instantiated in code).

So there is really no reason you couldn’t create a Finale>Lilypond converter. 
The license of Lilypond itself wouldn’t matter to you in this regard because 
you wouldn’t be reproducing GPL code. You could in turn choose any license for 
the code of your converter.

-Arle

Re: SVG in \markup Block?

[Arle Lommel]

> Took some time to refactor things and add functionality. I believe I have 
> managed to support all SVG path commands, except for elliptic arcs (A/a).

Holy Hannah, that is going *far* above and beyond any reasonable (or even 
unreasonable) expectations I might have had for assistance. I honestly would 
have expected to pay someone a few hundred bucks to do what you just did. 
Although I doubt we will meet in person, should we do so the very least I could 
do would be to buy you your choice of beverage.

I’ll play around with this, but I think you’ve saved me hours of work.

If I might suggest, this is the sort of functionality it would be fantastic to 
move into the core of Lilypond because I’m sure it would be useful to so many 
people. Generating SVGs from software is much easier than trying to extract 
post-script commands or manually coding your own shapes in Lilypond.

-Arle

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

The short answer is that that isn’t the way Bartók chose to do them, even if I 
would personally do them that way and if a goal is to represent the composer’s 
intent, then that’s changing things. As others in the thread indicated, it’s 
more common than I realized, so it presumably serves a function. 

Arle 

--
Misit de iPhone meo. 

> On Jan 20, 2020, at 06:00, Simon Albrecht  wrote:
> 
> On 14.01.20 18:15, Arle Lommel wrote:
>> Why Bartók didn’t simply show the bottom D in the treble clef is an 
>> interesting question. I think he was trying to keep the relationship between 
>> the hands clear, but couldn’t quite include the upper D in a way that made 
>> sense without splitting it like this. Had he put the lower D in the treble 
>> clef where it more apparently belongs, it might have led to confusion about 
>> which hand was to play it.
> 
> To me the question would be why these two chords can’t be all stem-down, i.e. 
> with the beam within or below the lower staff. That would put the noteheads 
> on the same side and allow for using common constructs.
> 
> Best, Simon
> 

Re: SVG in \markup Block?

[Arle Lommel]

> 

SVG in \markup Block?

[Arle Lommel]

I’ve got some SVG images I would like to embed in \markup blocks. I’ve been 
searching the documentation and the archives for information on how to do this, 
but without success. If it’s been discussed before, the results are getting 
lost in all of the discussion about SVG output, so I’m not finding them (and 
the search interface doesn’t easily allow complex searches).

In a nutshell, I’d like to do one of the following:

1. Use an SVG description of a shape directly in a \markup block. (I want 
something entirely portable within a single Lilypond file, rather than 
referencing external files, hence the desire to have it directly in the \markup 
block.)

2. Convert the SVG description to appropriate native Lilypond drawing commands. 
(I’m guessing this is entirely trivial for someone who knows what to do, but I 
don’t.)

I have no preference for which one I use, as long as I don’t have to set and 
mess with numbers by trial and error to get the right shape.

Does anyone know of anything online about how to do this?

-Arle

P.S., for a concrete example of the kind of thing I want to do, I’d like to 
convert an SVG string such as this:

Re: Scheme question

[Arle Lommel]

> Since you have a variable, you would need the quasi-quote feature if you 
> wanted the shorthand: `(,padding . 0)  But, (cons padding 0) should 
> work.
> 
> 
> -- Aaron Hill

Thank you, Aaron. The quasi-quote version did it.

Is that feature explained anywhere in the documentation? I don’t recall seeing 
anything like that anywhere and searching for “quasi-quote scheme Lilypond” 
doesn’t return anything relevant.

If it isn’t there, this seems like rather a nice thing to have in the 
documentation.

-Arle

Re: Three short questions from Bartók around fingering, about 90% there

[Arle Lommel]

> On Jan 14, 2020, at 18:05, Mark Stephen Mrotek  wrote:
> 
> Arle,
>  
> Add these before the b!
>  
> \once \override Accidental.extra-offset = #'(3 . 0)
> \once \override NoteColumn.force-hshift = #2.5
>  
> Mark

Thanks. I’m finding I have to play around with the numbers a bit and add an 
Accidental.extra-offset elsewhere, but this is really useful.

-Arle

Scheme question

[Arle Lommel]

I am a total neophyte to Scheme, but not to coding. I’ve written a simple 
function, but it does not work (I’ve reduced it to just the problematic lines. 
Can anyone tell me how to write the line indicated below?

shifter =
#(define-music-function
  (parser location padding)
  (number?)
  #{
\once \override Accidental.extra-offset = #(cons padding . 0) %<- THIS LINE
  #}
)

The relevant errors it throws when invoked are:

error: GUILE signaled an error for the expression beginning here
warning: type check for `extra-offset' failed; value `#' must be 
of type `pair of numbers’

The closest thing I can find to explaining how this works is here: 
http://lilypond.org/doc/v2.18/Documentation/extending/scheme-function-definitions

But I’m apparently missing something very obvious.

-Arle

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

> The more things interact unnecessarily, the harder it becomes doing
> things reliably.  The more we manage to get LilyPond to behave to naive
> expectations, the more useable power the average user has at their
> convenience.
> 
> So we should not try overexercising the "music is complex, so LilyPond
> can be expected to behave in unexpected ways" excuse more than
> necessary.  I don't have enough of an overview of the problem discussed
> here to figure out whether this is the case here.
> 
> -- 
> David Kastrup



David,

Thanks for responding this thoughtfully. I may try to create a minimal example 
of this later.

In this case, the steps required weren’t obvious to naive expectations, but I 
don’t know if they could be made easier.

A construct like the following will, I think, always be an unusual one (ignore 
the bad spacing on the fingering, which I have’t yet fixed).



Why Bartók didn’t simply show the bottom D in the treble clef is an interesting 
question. I think he was trying to keep the relationship between the hands 
clear, but couldn’t quite include the upper D in a way that made sense without 
splitting it like this. Had he put the lower D in the treble clef where it more 
apparently belongs, it might have led to confusion about which hand was to play 
it.

But this is all speculation, and I’m not sure there actually is a naive way to 
expect this to work because it’s an unusual approach.

The two things in this that didn’t make sense naively are: 

1. Why I couldn’t use something like " \once \override Stem.length = #8” in a 
set of beamed notes to adjust the length of the second stem, but this did work:

\stemUp \once \override Beam.positions = #'(7 . 8) 8-.[ d!8]

I’m sure there is a good reason for this, but that one really doesn’t work the 
way a naive user would expect.

2. Why a gap appeared in a complex example that didn’t appear in Kieren’s 
example (which is what necessitated the solution above). This is what I was 
referring to with the comment about various things interacting. But I suspect 
that it would be complex to find the source of that small gap, which persisted 
when I increased the stem length of the non-beamed note to try to make them 
meet. So I’m not worried here and I think no naive answer would be possible 
here just because this is weird, and trying to account for an unusual edge case 
like this probably isn’t worth the effort.

Best,

-Arle

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

> Hope that helps more!
> Kieren.


Thanks much. One of the challenging things for folks like me who dip in and out 
is keeping track of all the different ways that things can be done and how all 
the elements interact. But that is inherent to this: Music notation is orders 
of magnitude more complex than printed text.

There is a continual learning curve, but I keep coming back to Lilypond because 
of all the things I *can’t* reliably do in other software. It’s great stuff!

-Arle

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

Írta Kieren:

> p.s. Maybe this helps?


That did indeed help. It got me 90% of the way there. When I actually applied 
it in the piece I’m setting, I found that the length of the overridden stem was 
pushing the other staff away. It didn’t do this in the example you made, so I’m 
not sure what was interfering (maybe something with multiple voices going on). 
But I found that if I tweaked the other beamed notes with something like \once 
\override Beam.positions = #'(7 . 8), that allowed me to close the small gap by 
brute-forcing the stems and beam where I wanted them.

Thanks very, very much.

-Arle

Re: Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[Arle Lommel]

So schrieb David:

> Either way is acting as it should.
> 
> The manual has an index entry "beam, with lyrics" for the chapter
> "Setting automatic beam behavior" but there is no usable reference
> whatsoever in that chapter.  I actually find rather little elsewhere
> either, there are mostly just some allusions to manual beaming and
> lyrics that don't make it into a definitive statement about LilyPond's
> behavior rather than a general typesetting practice.
> 
> It's sort of an "everyone knows this except the manual" situation
> apparently.


Thanks for the explanation, which makes sense. Where should I suggest that this 
be made more prominent in the documentation? It think it ought to be mentioned 
in the section on Lyrics where slurs are discussed so that both options are 
evident to people like me, who dip in and out of Lilypond on a semi-regular 
basis but aren’t quite up on all the details.

-Arle

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

Thank you. This seems to do it nicely. I’d not submitted a MWE because I didn’t 
have anything I was confident was even the right sort of starting point and was 
looking for a pointer where to even start. Fortunately (for me), you filled the 
gap very nicely with this. I’ll need to adapt it for the contexts where I need 
it, but I see how now.

This would be a useful snippet to add to the repository.

-Arle

> On Jan 13, 2020, at 23:33, Kieren MacMillan  
> wrote:
> 
> p.s. Maybe this helps?
> 
> \version "2.19.83"
> 
> \layout {
>  \context {
>\PianoStaff
>\consists #Span_stem_engraver
>  }
> }
> 
> {
>  \new PianoStaff <<
>\new Staff {
>  bes'8[ ]
>}
>\new Staff {
>  \clef bass
>  \voiceOne
>  \autoBeamOff
>  \crossStaff { \tweak NoteColumn.X-offset #-1.175 \tweak Stem.length 10 
> bes8 s }
>  \autoBeamOn
>}
> >>
> }

Re: lilypond-user Digest, Vol 206, Issue 45

[Arle Lommel]

Sic scripsit Aaron Hill:

> In your larger document, do you use \autoBeamOff?

This was the problem. I did’t recall turning autoBeam off so I didn’t think to 
check for it.

Sic scripsit Kieran MacMillan:

> Well, that would follow "traditional" (meaning pre-1900) engraving rules for 
> vocal writing, when melismas were indicated by beams (or lack thereof) and 
> not slurs. But I think it’s worth logging, even if it just ends up being a 
> parameter/switch with the default staying as is.


Sounds like this means it isn’t a bug, but it wasn’t obvious that this would be 
expected behavior as I was unaware of the pre-1900 convention. It certainly 
doesn’t match the Bartók sources I’m working with (although Kodály does seem to 
follow this convention).

-Arle

Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[Arle Lommel]

Thanks very much to Carl Sorenson for a response that got me to start paring 
things down even more and led me to find the problem in my score where I didn’t 
previously look. Took a while

Basically, if autoBeam is off (somehow I’d turned it off outside a variable 
where I was defining things), the Lyrics somehow follow the manual beaming to 
guide their placement rather than slurs, but if it is on, they ignore it and 
act as they should.

Here is a *very* close to minimal example that shows both behaviors:

\version "2.19.83"
\score {
  <<
\new Voice = "mel" \relative c'' {
  \time 4/4

  \autoBeamOff
  c4^"This is wrong. Autobeam off" d4 c4 a4 |
  f16[( e16) d8] d4 a'2 |
  
  \autoBeamOn
  c4^"This is right. Autobeam on" d4 c4 a4 |
  f16[( e16) d8] d4 a'2 |
}
\new Lyrics \lyricsto mel {
  Ne bu -- sul -- jon, ko -- mám -- asz 
  % Should be another syllable at the end of the line above, but I'm 
omitting it
  % so it doesn't throw the next bit off
  Ne bu -- sul -- jon, ko -- mám -- asz -- szony,
}
  >>
  \layout {}
}

Here’s the rendering:



Seems this is a bug unless there is a reason why lyrics should follow manual 
beaming rather than slurs when autoBeam is off. Can anyone tell me whether I 
should log this? 

-Arle

Lyric misalignment and beaming?

[Arle Lommel]

Got a head scratcher here. Using 2.19.83, I’ve run into a problem where I 
*cannot* create a minimal example: The minimal example works exactly as it 
should and it is only in context where things fail, but I have no idea what 
actually makes them fail, so I have no idea how to make a minimal example.

I have lines like this:

f16[( e16) d8] d4 a2 |

I’ve paired it with lyrics like this:

   ko -- mám -- asz -- szony,

If I put this in a file by itself to create a minimal example it renders just 
fine:



But in the context of a larger piece, this is what I get from the exact same 
input:



However, if I change the manual beaming, to this:

f16[( e16)] d8 d4 a2 |

I get this:



Which is what I want with the lyrics, but obviously with the wrong beaming now.

So somehow the manual beams are interfering with the Lyrics alignment, but I 
cannot figure out why or how, since they don’t do it in a minimal example, but 
do in the first measure of a complex piece before anything obvious has had a 
chance to interfere with them. This same problem repeats every time I have 
manual beaming in the piece, which is frequent given its metric structure.

Does anyone have any idea what I should check to resolve this problem? I’ve 
tried everything I can think of with no luck.

-Arle

Re: lilypond-user Digest, Vol 186, Issue 108

[Arle Lommel]

Thank you Ben.

See below:

> \version "2.19.80"
> 
> %% http://lsr.di.unimi.it/LSR/Item?id=272 
> 

Don’t know how I didn’t find this, but I thought I’d gone through all of the 
time signature-related snippets. Clearly not…

The snippet is almost right, but doesn’t function quite as Hindemith’s notation 
does:

The Hindemith editions use time signatures both above and in line, but never at 
the same time. They serve different purposes. The snipped removes the ability 
to do the in-line time signatures because the time signature engraver is 
removed from the main staffs. Easy enough to put in, but then I need to brush 
up enough to selectively control where a time signature appears
Hindemith also limits the effect of a superior time signature to a single 
measure. The following measure reverts (with nothing displayed) to the original 
meter. So replicating the Schott practice would mean also hiding the time 
signature following such a measure.

But this is very useful as a suggestion of an approach. Maybe I can find a way 
to selectively hide/show time signature changes in each context to get what I 
want.

Best,

Arle

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

Re:Single-measure time signatures with raised numbers

[Arle Lommel]

Apologies for forgetting to change the subject line on my last mail…

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

Font caching problems on the Mac

[Arle Lommel]

A while back I mentioned very long start-up times for Lilypond on the Mac and 
someone suggested that the problem is with font caching. Today I was able to 
confirm that as the case. I installed a number of new fonts (Noto from Google) 
and suddenly Lilypond was facing extremely long load times (walk away and 
prepare yourself a cup of your favorite beverage and check back to see if it’s 
done recaching the fonts).

Not sure what can be done, as the inefficiency is in the font handling 
mechanism.

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

Re: Lilypond slow to start up on the Mac

[Arle Lommel]

I'm using the latest development build, but had notes the same problem using 
the latest 2.18 build, so I don't see a way to update to anything more recent 
in this case. 

I wouldn't have thought of a font cache, but that gives me something to test 
and report back on. Perhaps it is a recurrence of that problem or some 
variation. If it is, though, it's not likely to be identical because Lilypond 
works fine on its own and hangs only when invoked, and then only on the first 
run after a reboot (although that would lend some credence to a font caching 
issue). 

I'm not where I can test now, but I'll do so later. 

Thanks for the pointer. 

Arle

--
Misit de iPhone meo. 

> On Apr 23, 2018, at 14:13, David Wright <lily...@lionunicorn.co.uk> wrote:
> 
>> On Mon 23 Apr 2018 at 11:40:46 (-0400), Arle Lommel wrote:
>> I’ve noticed on the Mac for some time that the first time I invoke Lilypond 
>> from an external application after a reboot, it can take quite a while for 
>> it to respond. Normally this is something like a 40–60 second delay, after 
>> which Lilypond behaves normally. But a few days ago, after I updated to OS X 
>> 10.13.4, it seemed that Lilypond was totally unresponsive over much longer 
>> periods. After waiting about ten minutes, I finally walked away for dinner, 
>> and when I came back, it was working normally. This happened with the latest 
>> development build, but I’ve also had delays with the stable build (although 
>> never as long as this was).
>> 
>> I was invoking Lilypond through Frescobaldi, but I’ve had the same (shorter) 
>> initial delays on JEdit, and on multiple machines in the past.
>> 
>> During this longer wait, I could launch Lilypond.app and initiate a 
>> typesetting activity from within it with no problem, so it is not Lilypond 
>> itself that seems to be the problem, but rather something specific to 
>> external applications calling it.
>> 
>> Is this a known issue? If so, any ideas on ways to fix it other than 
>> typesetting something and walking away for 20 minutes before it responds?
> 
> Maybe you've hit this one which used to be a frequent problem here.
> The cure is usually either a newer version, or you could try
> deleting the font cache and hoping it will get rebuilt correctly
> (if there was a problem before) on the next run.
> 
> http://lists.gnu.org/archive/html/lilypond-user/2017-03/msg00066.html
> 
> Cheers,
> David.

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

Lilypond slow to start up on the Mac

[Arle Lommel]

I’ve noticed on the Mac for some time that the first time I invoke Lilypond 
from an external application after a reboot, it can take quite a while for it 
to respond. Normally this is something like a 40–60 second delay, after which 
Lilypond behaves normally. But a few days ago, after I updated to OS X 10.13.4, 
it seemed that Lilypond was totally unresponsive over much longer periods. 
After waiting about ten minutes, I finally walked away for dinner, and when I 
came back, it was working normally. This happened with the latest development 
build, but I’ve also had delays with the stable build (although never as long 
as this was).

I was invoking Lilypond through Frescobaldi, but I’ve had the same (shorter) 
initial delays on JEdit, and on multiple machines in the past.

During this longer wait, I could launch Lilypond.app and initiate a typesetting 
activity from within it with no problem, so it is not Lilypond itself that 
seems to be the problem, but rather something specific to external applications 
calling it.

Is this a known issue? If so, any ideas on ways to fix it other than 
typesetting something and walking away for 20 minutes before it responds?

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

Re: Double ties: Can't tweak both ties.

[Arle Lommel]

Found a solution, in this:

\override TieColumn.tie-configuration = #'((3.5 . 1) (5.5 . 1))

It’s not as precise as I’d like to be, but it gives me this, which is clear:



I’d prefer to have the direct control, but as that appears to be buggy (and not 
just counter-intuitive), this will do well enough.

I’ve logged the really bizarre behavior I encountered earlier as a bug.

Thanks for those who offered help.

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

Re: Double ties: Can't tweak both ties.

[Arle Lommel]

Thank you for looking at what I sent earlier, Carl. Turns out that it *doesn’t* 
actually work like I thought it did.

Here is a real tiny example of the problem:

\version "2.18.2"
\relative c'' {
\tieUp
2 2 ~ |
1 |
1 |
}

That yields this:


First tie moved as expected, but the second one (E to E) doesn’t budge (it 
should be inverted with the values I gave it).

(This would actually solve my problem graphically, but when I tried it in my 
actual score, things didn’t work as expected at all, with things moving in 
seemingly random ways I cannot replicate in a tiny example.)

But if I insert a \break into the mix:

\version "2.18.2"
\relative c'' {
\tieUp
2 2 ~ |
\break
1 |
1 |
}

I get this:



Now the second \shape command works, but the first one no longer does.

I think I’ve uncovered a genuine bug. I doubt very much that this is anyone’s 
idea of how this should work. I guess I’ll have to report it.

Best

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

Re: Double ties: Can't tweak both ties.

[Arle Lommel]

Thanks very much.

That did it, with a bit of messing about. I’d tried that earlier on, but had 
gotten syntax errors and assumed they had to do with putting the ties in the 
chords, but it must have been something else.

-Arle

> On Mar 12, 2018, at 13:37, Carl Sorensen <c_soren...@byu.edu> wrote:
> 
>  
>  
> From: Arle Lommel <arle.lom...@gmail.com <mailto:arle.lom...@gmail.com>>
> Date: Monday, March 12, 2018 at 10:55 AM
> To: <lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>>
> Subject: Double ties: Can't tweak both ties.
>  
>   <>
> I figured it would be no problem to fix this by tweaking the shape of ties, 
> like so:
>  
> <cis! e>1-\shape #'((0 . 0.5) (0 . 2) (0 . 2) (0 . 0))~ |
> <cis! e>1-\shape #'((0 . 0.5) (0 . 2) (0 . 2) (0 . 0))~ \< |
>  
> I’m pretty sure that you can solve this by putting the ties on the individual 
> notes inside the chords, rather than on the chord.  I would have tested it to 
> demonstrate if you had provided a tiny example. 
> http://lilypond.org/tiny-examples.html 
> <http://lilypond.org/tiny-examples.html>
>  
> HTH,
>  
> Carl

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

Double ties: Can't tweak both ties.

[Arle Lommel]

[I hope this doesn’t turn up twice. I’h having trouble sending from another 
email address and it doesn’t seem that my previous attempt to send this worked. 
So apologies if it does come through twice from different addresses.]

Hoping someone can help me on this, as I have not found any way to fix this 
problem, despite trying all sorts of things and searching for anything similar. 
I have some polyphonic music where some double ties are crashing with notes in 
another voice. It looks like this:



The relevant code looks like this:

1~ |
1~ \< |

I figured it would be no problem to fix this by tweaking the shape of ties, 
like so:

1-\shape #'((0 . 0.5) (0 . 2) (0 . 2) (0 . 0))~ |
1-\shape #'((0 . 0.5) (0 . 2) (0 . 2) (0 . 0))~ \< |

But that results in this:


Only the upper tie is reshaped and the bottom stays the same.

I’ve tried all sorts of workarounds. The most promising one was instantiating a 
separate voice for the top and bottom of the chord, but that led to other 
problems with collisions between the moving voice and the whole notes, and 
tweaking the horizontal position of the clashing c-natural has no effect when 
I’ve got this split into different voices for some reason. I also tried 
creating a new voice with transparent note heads in it and the ties attached to 
them, but that led to truly bizarre behaviors with spacing.

So is there a way to tweak the bottom tie and get this working right?

Best,

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

Double ties: Can't tweak both ties.

[Arle Lommel]

Hoping someone can help me on this, as I have not found any way to fix this 
problem, despite trying all sorts of things and searching for anything similar. 
I have some polyphonic music where some double ties are crashing with notes in 
another voice. It looks like this:



The relevant code looks like this:

1~ |
1~ \< |

I figured it would be no problem to fix this by tweaking the shape of ties, 
like so:

1-\shape #'((0 . 0.5) (0 . 2) (0 . 2) (0 . 0))~ |
1-\shape #'((0 . 0.5) (0 . 2) (0 . 2) (0 . 0))~ \< |

But that results in this:


Only the upper tie is reshaped and the bottom stays the same.

I’ve tried all sorts of workarounds. The most promising one was instantiating a 
separate voice for the top and bottom of the chord, but that led to other 
problems with collisions between the moving voice and the whole notes, and 
tweaking the horizontal position of the clashing c-natural has no effect when 
I’ve got this split into different voices for some reason. I also tried 
creating a new voice with transparent note heads in it and the ties attached to 
them, but that led to truly bizarre behaviors with spacing.

So is there a way to tweak the bottom tie and get this working right?

Best,

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

Re: Resolving cannot resolve rest collision: rest direction not set warnings

[Arle Lommel]

Thanks Jim. Your example solved it for me. I thought I was using explicit 
voices because I declared voices using a \new Voice {} construct, but I 
hadn't named them explicitly, and that seems to be the difference. Now I am 
seeing real warnings rather than these ones about rests and that helps me out 
a lot, cognitively, in finding real issues.

-Arle


On 2012 Dec 19, at 09:45 , Jim Long lilyp...@umpquanet.com wrote:

 On Wed, Dec 19, 2012 at 08:44:29AM +0100, Arle Lommel wrote:
 Hi all, I am working on the same score that spawned discussion about stem 
 lengths and now have another, hopefully less controversial, question.
 
 I keep getting warnings like the following when I run Lilypond:
 
 warning: cannot resolve rest collision: rest direction not set
 
 I've run into this or a similar problem before.
 
 Cultivate the habit of using separate, explicit voice constructs:
 
\new Voice = upper \relative c'' {
  ...
} % upper voice
\new Voice = lower \relative c'' {
  ...
} % lower voice
 
 A layman's paraphrase of the error message might be that, while
 you are manipulating stem directions and pitched rests to
 *simulate* the appearance of separate voices, Lily cannot
 reliably determine which voice(s) the rests belong to.
 
 HTH,
 
 Jim

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

Re: Resolving cannot resolve rest collision: rest direction not set warnings

[Arle Lommel]

Actually, I spoke too soon. It looked like they were gone, but when I started 
checking, my score was severely messed up in other ways by what I had done. 
When I reverted and then tried again, the rest collision errors were back, so 
the apparent absence was likely unrelated to the change in voice constructs and 
came about because I had made some other mistake that coincidentally addressed 
the cause.

It's a bit long (sorry), but here is my score block showing the declarations. 
All the variables containing the music are declared in a parallelMusic section.

For what it is worth, all of the conflicts seem to be between the voices 
ornamentsVoice and rightVoice, both of which often have simultaneous rests. 
The rests from rightVoice are placed automatically (and correctly) in the 
proper location, center-staff. The ones from ornamentsVoice I am manually 
positioning (intentionally, not because of the conflict).

\score {
\new StaffGroup

\new PianoStaff

\new Staff = RH {
\set doubleSlurs = ##t
\clef treble
\key d \major
\time 3/4

{ \new Voice=ossiaVoice \relative c' 
{ \ossia } }
\\
{ \new Voice=ornamentsVoice \relative 
c' { \ornaments } }
\\
{ \new Voice=rightVoice \relative c' 
{ \set doubleSlurs = ##t \righthand } }


}
\new Staff = LH {
\set doubleSlurs = ##t
\clef bass
\key d \major
\time 3/4

{ \new Voice = leftVoice \relative c 
{ \set doubleSlurs = ##t \lefthand } }
\new Dynamics = dynamicsVoice { 
\pedal }

}


\layout {
\context {
\PianoStaff
\consists #Span_stem_engraver
\consists Span_arpeggio_engraver
}
}
}

This would seem to be using separate, explicit voice constructs, but the 
warnings persist. Any thoughts?

(If it matters, the explanation of the voices is as follows:

ossiaVoice = a voice used to carry some occasional ossia portions. It causes no 
problem.
ornamentsVoice = a voice used for frequent gracenote-like portions that occupy 
their notated time and run parallel to the right-hand voice.
rightVoice = the primary right-hand voice
leftVoice = the primary left-hand voice
dynamicsVoice = a voice consisting entirely of spacers and \sustainOn and 
\sustainOff commands

Only the bolded voices generate the warnings, probably because they are the 
only ones that generally share the same staff.)

-Arle


On 2012 Dec 19, at 09:45 , Jim Long lilyp...@umpquanet.com wrote:

 On Wed, Dec 19, 2012 at 08:44:29AM +0100, Arle Lommel wrote:
 Hi all, I am working on the same score that spawned discussion about stem 
 lengths and now have another, hopefully less controversial, question.
 
 I keep getting warnings like the following when I run Lilypond:
 
 warning: cannot resolve rest collision: rest direction not set
 
 I've run into this or a similar problem before.
 
 Cultivate the habit of using separate, explicit voice constructs:
 
\new Voice = upper \relative c'' {
  ...
} % upper voice
\new Voice = lower \relative c'' {
  ...
} % lower voice
 
 A layman's paraphrase of the error message might be that, while
 you are manipulating stem directions and pitched rests to
 *simulate* the appearance of separate voices, Lily cannot
 reliably determine which voice(s) the rests belong to.
 
 HTH,
 
 Jim

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

Re: Resolving cannot resolve rest collision: rest direction not setwarnings

[Arle Lommel]

Here is a minimal (real) example of one measure that generates four warnings. 
As you can see the rests in the third voice are simply invoked as r4 while 
the ones in the second voice are given explicit locations (which, again, I want 
to do in this case). (I realize the notation convention here is a bit strange, 
but the composer used these quasi-grace sorts of things to indicate his 
ornamentation, but he also gave them full musical time values and rests and so 
forth.)

\version 2.16.1

\parallelMusic #'(ossia ornaments righthand lefthand pedal) {
  s2. |
  \tiny \stemUp c''4\rest c8\rest^\pp \ottava #1 d'32[ a' d, a] \ottava #0 
c,8\rest d32[ a' d, a] |
  r4 r4 d' fis4 |
  s2. |
  s2. |
}

\score {
  \new StaffGroup
  
\new PianoStaff

  \new Staff = RH {
\clef treble
\key d \major
\time 3/4

  { \new Voice=ossiaVoice \relative c' { \ossia } }
\\
  { \new Voice=ornamentsVoice \relative c' { \ornaments } }
\\
  { \new Voice=rightVoice \relative c' { \righthand } }


  }
  \new Staff = LH {
\set doubleSlurs = ##t
\clef bass
\key d \major
\time 3/4

  { \new Voice = leftVoice \relative c { \lefthand } }
  \new Dynamics = dynamicsVoice { \pedal }

  }

  
}

I've looked at the link you shared Trevor, but the application to this issue 
isn't necessarily obvious to me, other than that it makes me wonder if I need 
to change the order I declare my voices in or something.

-Arle


On 2012 Dec 19, at 11:50 , Trevor Daniels t.dani...@treda.co.uk wrote:

 
 { \new Voice=ossiaVoice \relative c' { \ossia } }
 \\
 { \new Voice=ornamentsVoice \relative c' { \ornaments } }
 \\
 { \new Voice=rightVoice \relative c' { \set doubleSlurs = ##t \righthand } }
 
 
 This construct implicitly assigns the properties of \voiceOne, \voiceTwo etc
 in order to the several music expressions separated by \\.  These settings
 control the direction of stems, placement of rests, shifts to resolve 
 collisions,
 etc.  That is probably not what you want.  This is all explained in
 section 1.5.3 of the Notation Reference:
 http://www.lilypond.org/doc/v2.17/Documentation/notation/multiple-voices#single_002dstaff-polyphony
 
 The particular error message is probably related to the way
 you are positioning the rests in ornamentsVoice, but you don't
 say how you are doing that.
 
 Trevor

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

Re: Resolving cannot resolve rest collision: rest direction notsetwarnings

[Arle Lommel]

Thanks much. This is what I was missing. I had thought, somehow, from reading 
that portion (a number of times) that the voiceOne and voiceTwo bits were 
automatically and implicitly assigned and did not realize that they have to be 
explicitly invoked. Earliest suggestions got me part of the way there, and this 
resolves the issue (although I find that it shifts the direction some things 
like trill spans go, which means I just have to do a manual walkthrough of the 
output to see what has moved). If the original notation of this piece weren't a 
little crazy this would be much easier, but that's life.

I appreciate the guidance and home some day to be able to return some knowledge.

-Arle

On 2012 Dec 19, at 16:07 , lilypond-user-requ...@gnu.org wrote:

 Please re-read the section in the NR concerning explicit use of voices: 
 http://lilypond.org/doc/v2.16/Documentation/notation/multiple-voices.  By 
 doing it this way:
  
 \parallelMusic #'(ossia ornaments righthand lefthand pedal) {
   s2. |
   \voiceOne \tiny c''4\rest c8\rest^\pp \ottava #1 d'32[ a' d, a] \ottava #0 
 c,8\rest d32[ a' d, a] |
   \voiceTwo r4 r4 d' fis4 |
   s2. |
   s2. |
 }
 Lilypond knows where to place the rests and there are no warnings about 
 collisions.
 
 --
 Phil Holmes

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

Re: Resolving cannot resolve rest collision: rest direction notsetwarnings

[Arle Lommel]

Just realized another issue. Is there a way to tell Lilypond where in the staff 
a voice’s rests should go? While Phil’s guidance to use \voiceOne and \voiceTwo 
took care of the warnings, it also means that the rests from one of the voices 
that had previously been centered in the staff now sit low in the staff because 
Lilypond thinks that they should be since they are in a lower voice. However, 
for the purposes of this piece, it would be nice to be able to say that this 
voice should ignore other voices for positioning.

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

Re: Resolving cannot resolve rest collision: rest direction notsetwarnings

[Arle Lommel]

Thanks.

The (probably deserved) chastisement aside, finding things in the documentation 
does require knowing how to find them. Finding even obvious things in the 
documentation isn't always easy if you don't already know what to look for. As 
I had spent some time earlier looking for this and not found it, I can only 
state that it wasn't also terribly easy for me to find either.

But that aside, I do appreciate the help.

Best,

ARle


On 2012 Dec 19, at 16:46 , Phil Holmes m...@philholmes.net wrote:

 This isn't very hard to find in the documentation.  It's what I just did. 
 Either use explicit positioning as you have been doing, or something like
 
 \override Rest #'staff-position = #0

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

Re: Resolving cannot resolve rest collision: rest direction notsetwarnings

[Arle Lommel]

David,

Sorry for the long response, but maybe it will be useful for project insiders 
to see how someone mostly on the outside experiences the documentation and the 
ways for finding things.

I think part of the problem is the sheer volume and being able to recognize 
what is directly relevant. For those who are immersed in the project there is a 
logic and clarity that those coming from outside may not always see. My need is 
sporadic. I may go six months and not touch Lilypond and then need it 
extensively for three weeks and then go another six months. That means I am 
consistently relearning things (although fewer things each time).

(Incidentally, I just found this page - http://lilypond.org/web/documentation - 
that is rather sorely out of date. I'm guessing it is an old, orphaned page?)

 There is a table of contents,

OK, fair enough, but, using my case as an example, take a look at the TOC and 
ask yourself if you could find the appropriate point using it if you did not 
already know where it was. My guess is the answer would be no.

Searching for rest brings up zero hits in the TOC as it first appears. Now if 
I do click into 1.2 Rhythms, I get to 1.2.2. Writing Rests. I actually had 
looked through this a number of times while working on this piece, but never 
made the connection that I should look under the heading Positioning 
multi-measure rests to determine how to change the default position of plain 
rests. (Note that this section does not actually address how to change the 
default position of plain rests and even Phil, when chiding me for not using 
the index, himself had to extrapolate from the one section to the general 
solution.)

Now, as it happens, one can extrapolate the needed information from that 
section, if one makes the leap to say “maybe this bit applies to my similar, 
but not identical, situation” and if one knows how to make that extrapolation. 
But that is an inferential leap I did not happen to make.

There is no obvious path (at least to someone not immersed in the project) to 
get from rests in my piece are showing up in the ‘wrong’ place and I want to 
change the default” that leads to the solution via the TOC.

 there is an index,

The index might have helped. However, because of the layout of site and my 
screen size, it was hidden from view for me. I simply did not know it existed. 
If I may be so bold as to make a suggestion, perhaps the Index link could be 
put at the top of the TOC to encourage its use.

Leaving that aside, had I seen it and looked up rests, I would have found rest, 
specifying vertical position, which sounds promising indeed, but which does not 
address the question of setting defaults and indeed tells me what I already 
knew about constructs like b4\rest that I was using.

The other one I would have tried was rest, collisions of. Interestingly enough, 
that links to an anchor over the single sentence in the Known issues and 
warnings section that reads “Multi-measure rests do not take part in rest 
collisions.” I'd actually argue that that link doesn't even make much sense and 
that content higher up in the page is more relevant from a user perspective to 
the index heading than what it actually links to.

Again, the index might have helped me if I already knew what I needed to find. 
But for the outside user who doesn't know it, there isn't much helpful there.

Phil was able to find things because he already knew enough to use the index to 
find something different that happened to suggest the solution.

 there is plain text search.

This, again, was hidden from me and I actually wondered why there was not a 
plain text search. I had been using plain Google to find things because I 
didn't spot that search field hidden well below the edge of my screen. Perhaps 
I should have scrolled down and seen it, but I did not. From a usability 
standpoint, the search field is wasted at the bottom of the page and should be 
made much more prominent. If anything I write in this mail has value, that 
should be it.

However, if I use it (now that I know about it) and search for rest position, 
none of the hits are obviously relevant from the Google summaries except for 
the first one, but I'd already read that page and not made the connection that 
was needed.

 The index contains rest, specifying vertical position.

As mentioned above, that addresses the solution I already knew about, but does 
not actually address how to set the default, which is what I was looking for. 
(I just triple checked to be sure.)

 There is also the analogous positioning multi-measure rests.

And therein is the problem. It is analogous, not explicit, and stating that 
that is the solution presumes that one understands, while searching, that the 
analogy is there to be made. With more care and time, I might have made that 
leap. But I was searching the documentation for my particular issue, not a 
similar/analogous one.

 So how could this have been made easier?

I don't 

Re: Resolving cannot resolve rest collision: rest direction notsetwarnings

[Arle Lommel]

Reinhold,

The position there is a perfect example of where the search probably should be 
for the main documentation. The way you have it actively encourages use. The 
way the main site has it discourages use unless someone has a big enough screen 
to spot it.

 Does an AJAX search field (currently simply greps through the index)
 help in this regard (the input field in the upper left corner):
 
 http://kainhofer.com/~lilypond/Documentation/notation/

I like it a lot. It doesn't find everything like a natural language search 
would, but it is still very useful for finding things in the index one might 
overlook.

Best,

Arle

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

Re: Short stems [ATTENTION: INLINE IMAGES]

[Arle Lommel]

The score I am working from was printed in Boston in the 1860s. It was 
relatively clear, but the corrected version of 1874 was loaded with junk: 
pervasive fingerings, nonsensical slurs, seemingly random articulation marks. 
So much was loaded in that it looks like a rat's nest. 

Thanks for pointing out the regional and temporal variations at work here. That 
tells me the Lilypond default isn't a bug. It is just a difference of aesthetic 
ideal and intention.

I suppose by developing some new fonts and changing some defaults that Lilypond 
could handle other styles as well, which is a nice testament to its design.

Best,

Arle

--
Arle Lommel
Berlin, Germany
Skype: arle_lommel
Phone (US): +1 707 709 8650

Sent from a mobile device. Please excuse any typos.

On Dec 18, 2012, at 9:03, Werner LEMBERG w...@gnu.org wrote:

 
 LilyPond tries to mimick traditional engraving.  There are bugs,
 however, saying I find xx is too short is not helpful.
 
 I thought I was fairly clear about the specifics―“I find the stem
 here awfully short because it makes the flag on the eighth note run
 into the note heads”―but I guess not. But the inline images (yes)
 shown below should resolve any confusion on the point.
 
 Interesting.  The original scan shows a typography style which isn't
 the standard LilyPond is referring to, namely scores typeset in
 Germany in the early 20th century.  It appears much `lighter'; for
 example, the stems are hardly touching the noteheads.  It's not
 surprising that the lower flag (which has a very different shape, BTW)
 isn't touching the noteheads either.
 
 
Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Short stems [ATTENTION: INLINE IMAGES]

[Arle Lommel]

 …how can you be so sure that the LilyPond output wrong?

I'm not at all sure it is wrong, but as Werner points out, there were 
non-German traditions that Lilypond does not address. Since this comes from one 
of those and I am trying to represent the score in a nicer format that is still 
true to the original in some fashion, I want to make the change indicated. 

 The original image does not represent
 quality engraving and cannot and should not be used as an example,
 IMNSHO.  There are too many problems with it to take it as a standard.

I agree that it is far from perfect. At the same time there have been a number 
of aspects where I have found it clearer for this piece than the Lilypond 
default. I would not hold it up as a model for other things. Ultimately much of 
this is a matter of taste. 

 
 
 Of course, your feeling that there is something wrovng with the LilyPond
 output could still hold, but we'd need more and esp. better examples.

I don't know that anything needs to change. I have my opinion and others have 
theirs. I would not presume to state that mine is the single correct one. 

 While you are free to change it in your own score, that's not even
 recommended as long as we don't know what it should look like.

Should conceals a lot of assumptions :-)

 
 The chord looks MUCH better to me
 
 ..yes...
 
 and which is closer to the old engraving
 
 ...yes..., but this engraving, though possibly old, is not nice, or
 does not look like any of the engravings we have been mimicking.

Again, I'm looking for something else then. That's ok I think. 

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

Re: Short stems

[Arle Lommel]

No worries at all. If most people were “impolite” in the same way (offering 
solutions and helping) the world would be better off. Since you've helped me 
before, I didn't take it personally in any way. 

Arle 

 I apologize having been impolite.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Best practices in lyric typesetting

[Arle Lommel]

MS,

 Putting aside the impossibility of the attached exercise, you'll see that the 
 lyrics stay shifted way down for the part of the attached example that moves 
 to D major.

I ran into the reverse problem with pedal markings the other day: they were 
*not* aligned (and in fact seemed to behave like you want lyrics to. I can 
testify that the misalignments that resulted until I put the pedal markings 
into their own context was *seriously* disruptive visually. And that was for 
something relatively minor. If lyrics jumped around, I would personally find it 
rather disruptive as a singer, especially since vertical alignment sometimes is 
not just a matter of aesthetics but also of semantics, as when an alternative 
bass lyric is written below a primary lyric. So if the signers see lines 
jumping about, how will they know what the correct interpretation is?

Of course, as others have pointed out, you can probably resolve your situation 
by using ottava marks to keep things more neatly in the staff. I agree that the 
gap below the staff is very difficult to deal with and understand your 
motivation, but I think the solution would be to find a way to eliminate the 
cause of the gap, if possible.

(That said, although I don't have the solution, I am 100% in favor of leaving 
the system flexible enough to allow people to do what they want. You never know 
in advance when something you consider out of the question will not only be 
possible but may even be the best solution in a context you never thought of.)

Best,

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

Resolving cannot resolve rest collision: rest direction not set warnings

[Arle Lommel]

Hi all, I am working on the same score that spawned discussion about stem 
lengths and now have another, hopefully less controversial, question.

I keep getting warnings like the following when I run Lilypond:

warning: cannot resolve rest collision: rest direction not set

They appear from snippets like this (reduced to a single example measure with 
two voices that are displayed single staff, although the original had five 
voices in three staves):

\parallelMusic #'(ornaments righthand) {
%006
\stemUp c''4\rest c8\rest \ottava #1 d'32[ a' d, a32] \ottava #0 
c,8\rest d32[ a' d, a] |
r4 r4 d fis4 |
}

I understand that the issue is that the rests in the second voice (the two r4 
bits) and the ones in the first (c''4\rest and c8\rest  would occupy the 
same physical space (if I weren't already manually setting the location of the 
ones in the first voice), so the cause is clear. (If I were setting my own 
music this would be written so as to avoid the problem in the first place, but 
here I need to preserve the composer’s mode of expression.)

Since I am manually resolving the locations (and in fact want to do so in this 
case for other reasons), this is more of a question of curiosity than a 
problem, but how would one, in general, resolve this issue automatically? Is 
there a way to set the rest direction for each voice such that they would no 
longer clash? I've tried searching for answers to this issue and not found 
anything yet, although I'm sure someone will point me at something that (in 
hindsight) was obvious.

Best,

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

Short stems

[Arle Lommel]

I have run into an odd little aesthetic issue. I'm finding that some eighth (or shorter) notes get stems that are too short when they stick out from the staff.For instance, I find the stem here awfully short because it makes the flag on the eighth note run into the note heads:But the measure before I get this:Which looks fine.While I am can tweak note stem lengths on an individual basis, it seems a less than ideal to address the issue.Is there some setting that can be used to keep the stems from getting so short? For the most part it only bothers me on the eight notes and shorter duration where the flags make it more apparent.Best,Arle___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

A question of list etiquette and images. (Was Re: Short stems)

[Arle Lommel]

First off, thanks very much, Harm, for taking the time to review my issue and 
provide a detailed response, despite the complaint about images. I will work 
with it and see how it works out.

Now please forgive me for diverting from Lilypond-related matters to issues of 
the list etiquette. My issue is raised by this statement:

 please:
 DON'T POST INLINE-IMAGES!
 Attach them!
 I'm surely not alone with filtering them out.


It provides an interesting conundrum. I use a Macintosh with the default client 
(Apple Mail) or a mobile device (iPhone) with the built-in mail client. With 
neither of those is there any distinction between in-line and attached images 
at all. In other words, short of changing my entire mail set up, I don't have 
any choice* but to post inline images.

The best I could do is put images at the end of the message, but that doesn't 
address the issue you raise at all since they are still, even then, treated as 
inline images and it only changes the location within the message.

(*OK, technically there is a kludge from the Terminal to change default 
behavior to not allow in-line viewing—on the Mac, but not, as far as I can 
tell, on the iPhone—, but it ends up disrupting normal function of the mail 
programs and would require quitting the program, changing the default in the 
terminal, and restarting the mail program just to deal with the list. Nor, as 
far as I can tell, would it fix the problem for someone else. I believe it only 
changes the display preference for me.)

Given that, does anyone have any suggestions to how behave nicely for list 
members like Harm when images are involved? Sometimes graphics are needed, and 
from a user perspective being able to say like this is very useful. Surely if 
Harm is not alone in filtering them out, I am also not alone in using current 
mail clients that don't make the distinction Harm wants me to make. I'm surely 
not the only one for whom DON'T POST INLINE-IMAGES! Attach them!” is a dictum 
that cannot be complied with because it is not a meaningful one in our software.

Best regards,

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

Re: Short stems

[Arle Lommel]

 then you might comment on the recommendation for improvement here
 http://code.google.com/p/lilypond/issues/detail?id=2724 
 which will probably prompt some action.

I will look at that. See my note below: I think the default values are a 
problem.

 LilyPond's default is the list I typed above : shorten stems with zero flags 
 by 1.0 staffspace, stems with one-or-more flags by 0.5 staff space.   
 I guess you will like something closer to  #'(1.0 0.3 0.2)
 where the extra entry is for stem with two-or-more flags


After some experiment I ended up completely turning off shortening for eighth 
and shorter. Even the minimal values you supplied were leaving the flags 
colliding with note heads.

\override Stem #'details #'stem-shorten =  #'(1.0 0 0)

And that seems to resolve the issue. I'll have to play around with Harm's more 
involved solution as well and see what it offers me.

Thanks,

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

Re: Improving alignment of pedal marks

[Arle Lommel]

Thanks. This works beautifully, once I figured out how to get the right pedal 
style (because I'd changed it for a staff context earlier I had to update that 
bit, and then it worked and the alignment looks great!

-Arle

On 2012 Dec 15, at 23:55 , Nathan when.possi...@gmail.com wrote:

 You can move the \sustain commands to a Dynamics context:
 
 \new Staff { \clef bass c,1\sustainOn c,1\sustainOff c,1 c,,1\sustainOn 
 c,,1\sustainOff }
 
 
   \new Staff { \clef bass c,1 c,1 c,1 c,,1 c,,1 }
   \new Dynamics { s1\sustainOn s1\sustainOff s1 s1\sustainOn s1\sustainOff }
 
 
 Regards,
 Nathan 

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

Moving a staff closer to another one

[Arle Lommel]

Hi all,

I have a piece with the following overall structure:

\score {
\new StaffGroup

\new PianoStaff

\new Staff = RH { \relative c' { \righthand } }
\new Staff = LH { \relative c { \lefthand } }


\new Staff = pedalMarks \with {
\remove Key_engraver
\remove Clef_engraver
\remove Staff_symbol_engraver
\remove Time_signature_engraver
}
{
\relative c { \pedal }
}

}

I would like to move the staff pedalMarks so that it sits substantially 
closer to the piano staff than the default spacing.

I have spent an few hours with the documentation at:

http://lilypond.org/doc/v2.16/Documentation/notation/flexible-vertical-spacing-within-systems

and I have had absolutely zero luck in getting anything there to work as I 
hoped it would.

I see the example with negative spacing (which is what I actually want, but I 
cannot seem to apply it to my case here).

Can anyone help me figure out how to get negative spacing here?

Best,

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

Re: Moving a staff closer to another one

[Arle Lommel]

I've moved sustain pedal articulations to a separate voice using spacers 
because they did not fit cleanly on the other voices. If I put the pedal voice 
in the left-hand it forces all the rests in the left-hand voice to sit a fifth 
higher. In addition the marks end up aligned all over the place, often by small 
offsets from each other to avoid other objects, and it looks *very* sloppy. By 
moving them to a separate staff I was able to keep the left-hand clean and also 
keep the pedal markings strictly and cleanly aligned. All I'd need to do to 
make it look right is move the staff with them closer to the other piano staff.

I'm open to other ways to achieve the effect.

Here's an example of the structure I'm using in parallelMusic:

%012
\tiny \stemUp c''4\rest c8\rest \ottava #1 cis'32 gis' cis, gis \ottava 
#0 c8\rest cis,32 gis' cis, gis | %righthand
\top r4 r4 cis'' eis4 _\mg | %lefthand
s2.\sustainOff | %pedal

I realize that there are other notes I could hang the pedal marks off, but 
often in this piece I have to use temporary polyphony and the \sustainOn point 
falls in a different voice than the \sustainOff, in which case the \sustainOff 
disappears in the output. Based on that a separate voice that I had better 
control over seemed the best approach.

The question is how to put it in the pedal markings in such a way that they 
look neat and that I can control them. A separate staff, except for the 
spacing, gives exactly what I'm looking for in terms of output.

Best,

-Arle

On 2012 Dec 15, at 18:54 , Phil Holmes m...@philholmes.net wrote:

 What are you trying to achieve with the pedal Staff?
 
 --
 Phil Holmes
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a staff closer to another one

[Arle Lommel]

Great. That takes care of the issue with the rests, but not with the vertical 
alignment of the pedal brackets, which move all over the place to accommodate 
other objects. But knowing this about voices helps me a ton. I've learned 
Lilypond on an ad hoc, as needed basis, so there is still a lot to learn.

-Arle

On 2012 Dec 15, at 21:31 , Phil Holmes m...@philholmes.net wrote:

 I think that when you say If I put the pedal voice in the left-hand it 
 forces all the rests in the left-hand voice to sit a fifth higher you must 
 be using implicit voices, which sets each voice as voiceOne, voiceTwo, etc, 
 and therefore moves the rests to avoid collisions.  I've not got time now to 
 give an example of how to do this with voices, but try simply using \new 
 Voice with both your music and your pedals (placed using spacers) and if you 
 can't get that working, post a minimal working example that doesn't look 
 right.
 
 --
 Phil Holmes

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

Improving alignment of pedal marks

[Arle Lommel]

Thanks to Phil Holmes’ suggestion to learn move about using explicit voices I resolved one of my major problems with the piece I'm working on. Thanks much.The second problem remains. How can I improve the vertical alignment of pedal marks? The piece I am working on has a lot of situations like the following:I know that this is acceptable at some level, but it would look MUCH nicer (neater and more intentional) if all of the pedal marks were vertically aligned rather than arrayed here and there to avoid other objects. I realize that not everyone would want this and that for many pieces it would be needed, but for the one I'm working on if all the pedal brackets lined up (at least within a row), it would be a marked improvement, especially as this piece is already quite visually noisy.Best,Arle___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond-user Digest, Vol 121, Issue 70

[Arle Lommel]

Thanks Joram and others

On 2012 Dec 14, at 04:18 , Joram wrote:

 A few remarks to your notes:
 - The last [ should probably be opened after the fisis32.

Harm caught that. Something happened in my editing in my mail program where I 
messed that up.

 - The 32 is necessary only once

I know, but in my code I try to be explicit about the note durations everywhere 
so that if I copy and paste bits around I don't ever have to worry about 
whether I have picked up a duration from somewhere else. Having the numbers 
doesn't hurt anything (other than making for more verbose code), so I tend to 
do that.

 - The marked dis actually is in the same octave as the disis.

Again, I think I messed something up in putting it in my mail and didn't catch 
it. The snippet was actually a reduction from a much more complex original and 
I made the rookie mistake of not testing it rigorously after simplifying it. In 
the original it was an octave higher… I'll slap my wrist with a ruler now!

 - You are right, the extra natural is shown by default (same octave).
 
 I think what you want is extraNatural = ##t as shown here. I moved the
 first disis to check if it is shown even in a different octave.
 
 \version 2.16.0
 {
  #(set-accidental-style 'modern)  % accidentals in different octaves
  \set Staff.extraNatural = ##t% extra natural (which is not modern)
  \stemUp
  dis32[ disis' eis fis] fisis[ gis gisis ais]
  e'![ dis cis ais] fisis[ dis cis ais]
 }
 
 I do not know how to make the sharp bold (I would consider that to be a
 bit exaggerated, though).

No interest in that, although I rather suspect that was written with a smile at 
my expense ;-)

Thanks for looking at this. I now have a couple of solutions, the ad-hoc one 
Harm suggested and the generalized one you suggested. Both are useful. In the 
case of this piece, I am trying to recreate some inconsistent 19th-century 
engraving (which was particularly inconsistent with accidentals, to the point 
that in a few cases I am fundamentally uncertain what notes were actually meant 
and I now need to listen to recordings and try it out myself -- I don't have 
access to a piano right now, unfortunately -- to figure out what in the world 
may have been intended), so the ad-hoc solution was ideal, but I'll certainly 
keep your solution in mind for other pieces by the same composer where the 
engraving is more consistent.

Thanks,

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

Likely bug in 2.16.1: Changing document fonts messes lots of things up…

[Arle Lommel]

[Trying again: for some reason this message was ignored by the list, so I'm 
trying without any attachments.]

OK, one more issue (possible bug?) has arisen that I cannot diagnose. (Lilypond 
2.16.1, Mac OS X 10.8.2)

I have followed instructions on how to change document fonts, as outlined at 
http://lilypond.org/doc/v2.16/Documentation/notation/fonts

But I find when I change the fonts that there are some undesirable side effects 
in *other* areas: Basically everything but the staff, note stems, and beams 
gets bigger, meaning more is crammed in the same space. Chords start to look 
like smears, note heads stick slightly past the stems, and time signatures and 
clefs stick outside the staff.

Here are side-by-side screen shots comparing the default output with the output 
when the font is changed:

SEE https://dl.dropbox.com/u/223919/lilypond/fontProblem.gif

And here is what happens to clefs and time signatures:

SEE https://dl.dropbox.com/u/223919/lilypond/badclef.gif

As can be seen, the difference is quite significant and it renders the use of 
other fonts effectively impossible. For the record, here is how I changed the 
fonts (per the link above):

\paper {
myStaffSize = #20
#(define fonts
(make-pango-font-tree Minion Pro
Minion Pro
Minion Pro
(/ myStaffSize 20)
))
}

(In this case I used Minion Pro for all sorts because my document only used the 
first type, not the sans-serif or typewriter styles, so I just set everything 
to one font.)

I have tried a number of different fonts of various types (OpenType PS, 
OpenTypeTTF, PS type 1, etc.) and this happens consistently for me regardless 
of the font chosen.

Anyone have any idea why changing the font does this and how I might be able to 
use a different text font without having this problem?

If this is not a bug (even though it sure looks like one), perhaps the 
documentation could be updated with an explanation on how to adjust for these 
sorts of problems.

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

Re: Likely bug in 2.16.1: Changing document fonts messes lots of things up…

[Arle Lommel]

MS,

Thanks. I wanted to confirm that it is a bug before submitting. I've tracked 
down the cause (but not the solution) and will submit there.

-Arle

On 2012 Dec 14, at 10:07 , m...@mikesolomon.org m...@mikesolomon.org wrote:

 On 14 déc. 2012, at 09:31, Arle Lommel fene...@gmail.com wrote:
 
 [Trying again: for some reason this message was ignored by the list, so I'm 
 trying without any attachments.]
 
 OK, one more issue (possible bug?) has arisen that I cannot diagnose. 
 (Lilypond 2.16.1, Mac OS X 10.8.2)
 
 
 Dear Arle,
 
 Please submit all bug reports to bug-lilyp...@gnu.org.
 Alternatively, you can use the gmane bug reporter at 
 http://dir.gmane.org/gmane.comp.gnu.lilypond.bugs.
 
 Cheers,
 MS
 

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

Re: Likely bug in 2.16.1: Changing document fonts messes lots of things up…

[Arle Lommel]

I found the cause. I had changed the global staff size to 16. As long as the 
global staff size stays at the default value of 20, things are fine. If it goes 
smaller or larger, the scaling goes off. Unfortunately the commands for 
changing fonts are not size independent, which seems like a very odd choice, 
nor is it obvious from the documentation what the numbers in myStaffSize = 
#20 and (/ myStaffSize 20) actually do. Even playing with the numbers I am 
unable to figure it out.

Although there may be a logic to the structure, there are two things that 
should be considered

1. If there is a rationale why font choice should be tied to staff size in this 
way, the documentation at 
http://lilypond.org/doc/v2.16/Documentation/notation/fonts should be updated to 
explain those values so that users nor versed in the arcana of the font system 
can make an intelligent choice of values to allow for different staff sizes. 
(I'd volunteer text, but I can't figure out what in the world the values do.) 
Maybe somebody with more knowledge can explain the numbers?

2. Even if it is intentional, I'd argue it is so nonintuitive that the design 
choice should be reconsidered and the mechanism for font choice made 
independent of the staff size.

I will submit this as a bug in a moment.

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

Likely bug in 2.16.1: Changing document fonts messes lots of things up…

[Arle Lommel]

OK, one more issue (possible bug?) has arisen that I cannot diagnose. (Lilypond 2.16.1, Mac OS X 10.8.2)I have followed instructions on how to change document fonts, as outlined athttp://lilypond.org/doc/v2.16/Documentation/notation/fontsBut I find when I change the fonts that there are some undesirable side effects in *other* areas: Basically everything but the staff, note stems, and beams gets bigger, meaning more is crammed in the same space. Chords start to look like smears, note heads stick slightly past the stems, and time signatures and clefs stick outside the staff.Here are side-by-side screen shots comparing the default output with the output when the font is changed:And here is what happens to clefs and time signatures:As can be seen, the difference is quite significant and it renders the use of other fonts effectively impossible. For the record, here is how I changed the fonts (per the link above):\paper {	myStaffSize = #20	#(define fonts	(make-pango-font-tree "Minion Pro"		"Minion Pro"		"Minion Pro"		(/ myStaffSize 20)	))}(In this case I used Minion Pro for all sorts because my document only used the first type, not the sans-serif or typewriter styles, so I just set everything to one font.)I have tried a number of different fonts of various types (OpenType PS, OpenTypeTTF, PS type 1, etc.) and this happens consistently for me regardless of the font chosen.Anyone have any idea why changing the font does this and how I might be able to use a different text font without having this problem?If this is not a bug (even though it sure looks like one), perhaps the documentation could be updated with an explanation on how to adjust for these sorts of problems.-Arle___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Likely bug in 2.16.1: Changing document fonts messes lots of things up…

[Arle Lommel]

Hi Trevor,

I see you answered before I posted that I'd found the cause, and I think the 
discovery of the cause shows that your answer is really to a different problem. 
There is a real problem with font handling here and taking the approach in the 
documentation sections you point to to fix it would be fundamentally a kludge, 
one that would have to be changed every time there is a change in global staff 
size and one that would require manual correction to any local overrides.

Thank you for trying to point me to the proper location in the manuals, but I 
think I've discovered a genuine bug…

Best,

Arle


On 2012 Dec 14, at 10:18 , Trevor Daniels t.dani...@treda.co.uk wrote:

 
 Arle Lommel Friday, December 14, 2012 8:31 AM
 
 I have followed instructions on how to change document fonts, as outlined at 
 http://lilypond.org/doc/v2.16/Documentation/notation/fonts
 
 But I find when I change the fonts that there are some undesirable side 
 effects in *other* areas: Basically everything but the staff, note stems,  
 and beams gets bigger, meaning more is crammed in the same space. Chords 
 start to look like smears, note heads stick slightly past the stems,  and 
 time signatures and clefs stick outside the staff.
 
 If this is not a bug (even though it sure looks like one), perhaps the 
 documentation could be updated with an explanation on how to adjust for  
 these sorts of problems.
 
 You must have missed this section in the docs:
 
 http://www.lilypond.org/doc/v2.17/Documentation/learning/appearance-of-objects
 
 Have a look in particular at
 
 http://www.lilypond.org/doc/v2.17/Documentation/learning/size-of-objects
 
 and 
 
 http://www.lilypond.org/doc/v2.17/Documentation/learning/length-and-thickness-of-objects
 
 Trevor


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

Re: Likely bug in 2.16.1: Changing document fonts messes lots of things up…

[Arle Lommel]

Hi all,

I've finally figured the workaround for this issue. I think this should be 
contributed to the documentation until a better (i.e., scale-independent) 
solution is implemented. The example can stay the same:

\paper  {
  myStaffSize = #20
  #(define fonts
(make-pango-font-tree Times New Roman
  Nimbus Sans
  Luxi Mono
   (/ myStaffSize 20)))
}

\relative c'{
  c1-\markup {
roman,
\sans sans,
\typewriter typewriter. }
}

But the following text should be added at the end of the section:

Note that if the global staff size is set to a value other than 20 (the default 
value), e.g., using #(set-global-staff-size 30), the value of myStaffSize must 
also be set to match the global staff size or problems with scaling of note 
heads and other objects will appear. The 20 that appears (/ myStaffSize 20), 
however, should remain unchanged.

(And I did test what happens if I do not set the global staff size at all and 
just set myStaffSize. Both MUST be set to the same value or problems arise.)

I am not sure how to contribute to the documentation, or I would do this myself.

Best,

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

Re: Forced double accidental

[Arle Lommel]

Hi Harm,

Thanks. It looks like I screwed things up in my editing in the mail program.

Here is the appropriate example without the errors:

\stemUp dis32[ disis32 eis32 fis32] fisis32[ gis32 gisis32 ais32] e'!32[ dis!32 
cis32 ais32] fisis32[ dis32 cis32 ais32]

And you suggestion, which makes it 

stemUp dis32[ disis32 eis32 fis32] fisis32[ gis32 gisis32 ais32] e'!32[ 
\once\override Accidental #'restore-first = ##t dis!32 cis32 ais32] fisis32[ 
dis32 cis32 ais32]

Does take care of the issue, so that does it.

Thanks so much. I hope that is the last question I have for this piece!

Best,

Arle

On 2012 Dec 13, at 12:50 , Thomas Morley thomasmorle...@googlemail.com wrote:

 2012/12/13 Arle Lommel fene...@gmail.com:
 One more question:
 
 I need a way to force a note to show a cancellation natural (from a double
 sharp) followed by a sharp sign. Lilypond doesn't want to do this in my case
 with any of the accidental styles I've tried because the note is in a
 different octave from the original double sharp. So far I can, of course,
 get it to display the sharp sign, but I can't seem to figure out how to get
 the cancellation natural to show up as well.
 
 Here is the snippet in question with the note where I need the cancellation
 natural plus the sharp bolded:
 
 \stemUp dis32[ disis32 eis32 fis32] fisis32[ gis32 gisis32 ais32] e'!32[
 dis#32 cis32 ais32] [fisis32 dis32 cis32 ais32]
 
 Well, your example doesn't compile, if I make it complie the described
 behaviour isn't shown and a warning about the misplaced [ is
 printed.
 
 Anyway, perhaps you could try:
 
 \version 2.16.1
 {
disis''
\once\override Accidental #'restore-first = ##t
dis'
 }
 
 Essentially, I want the behavior of modern, except for this part:
 
 It omits some extra natural signs, which were traditionally prefixed to a
 sharp following a double sharp, or a flat following a double flat.
 
 
 I want the extra natural signs that default would provide, except I need
 them in other octaves, not just the same octave where they cancel. It
 doesn't seem there is a style for this.
 
 Best,
 
 -Arle
 
 -Harm


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

Missing 8s

[Arle Lommel]

Just thought I would share a strange little bug that I can't explain (Lilypond 
2.16.1 on Mac OS X 10.8.2). I've switched the document font for a document to 
use Adobe Brioso Pro. It works well for the piece and everything is beautiful 
except one thing: in the bar numbers any “8” disappears. So if the bar number 
is “98” it appears as “9”. If the number is “82” it shows up as “2”. I'm going 
to have to switch fonts because of this (which isn't that big a deal), but I 
thought I'd ask if there is any known issue that would cause this problem or if 
it indicates a corrupted font cache somewhere.

Best,

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

Removing bar lines between piano staff and ossia and making space between consecutive ossias

[Arle Lommel]

Thanks to everyone for recent help. I've been truly impressed by how helpful people have been for my requests.Now I have one more problem with the piano piece I am working on. I am using a pianoStaff, which works fine, except that I now have a portion with a bunch of ossia parts (almost one a measure) that occupy only about the span of an eighth note each. I have run into two issues that I cannot find addressed online anywhere, and I am hoping someone can help:1. When adding an ossia to a piano staff the bar lines are automatically connected down from the ossia to the main piano staff. Normally not a problem, but for the piece I am working on I don't want them connecting. I find plenty of snippets about how to remove bar lines in the staff while leaving them on between staves, but nothing about the reverse. It isn't for lack of searching for a solution and trying out various things. So can anyone make a suggestion on how to achieve this?2. In the first two instances where I call the ossia parts, there is one on the last half beat of a measure and a *separate* one on the first half beat of the next measure. Lilypond, quite logically, assumes that these should be stuck together (since there is no time between them) and under any other circumstance I would be happy for it to do so. But here it would be ideal if I could somehow put a little white space between them because I need to show that they are not a single continuous ossia but rather two separate optional performance variants.So here is what I have versus what I want (showing both changes):And here is a two measure example of the code (simplified from what is shown above to try to get closer to a tiny example:\version "2.16.1"staffPiano = \new PianoStaff {	\set PianoStaff.midiInstrument = #"acoustic grand"	\set PianoStaff.instrumentName = #"Piano"		\time 3/4		\context Staff = "top" {			\clef treble			\key b \major			\relative c' {	{		\once \stemDown e ais cis \tweak #'duration-log #1 fis \arpeggio	}\\	{		\tiny c''8\rest dis,8 dis4 dis4	}\\	{ \skip 2 \skip 8	\new Staff = Ossia \with {alignAboveContext = #"top"fontSize = #-2\override StaffSymbol #'staff-space = #(magstep -2)\remove "Time_signature_engraver"\override Clef #'transparent = ##t			} {\override Staff.KeySignature #'stencil = ##f\key b \majorfis16 fis16 \ottava #0			}	}|	{		fis8[ fis8] fis8[ fis8] fis8 fis8]	}	\context Staff = Ossia {		\startStaff r8 dis8 \stopStaff			}			}		}		\context Staff = "bottom" { 		\clef bass			\key b \major			\relative c {fis,4 fis4 fis4 |fis4 fis4 fis4 |			}		}	}\score {			\staffPiano		 \layout { 	 \context { 	 	 \PianoStaff 	 	 \consists #Span_stem_engraver 	 	 \consists "Span_arpeggio_engraver" 	 } }}Any suggestions would be welcome.-Arle Lommel___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Removing bar lines between piano staff and ossia and making space between consecutive ossias

[Arle Lommel]

Thomas,

Thanks so much. That got me about 90% of the way there, but playing around with 
what you did got me the other 10% of the way there, so that does it. What was 
missing for me was the  \once \override Staff.BarLine #'allow-span-bar = ##f, 
which was obvious in its intent, but which my previous searches had not 
discovered.

The *1/2 bit I also wasn't familiar with, but it solves things and it looks 
like I can use it many other places in the score where I find that Lilypond is 
being too literal in its mapping of note duration to physical length. So I get 
an added benefit from your explanation :-)

Best,

Arle


On 2012 Dec 13, at 00:19 , Thomas Morley thomasmorle...@googlemail.com wrote:

 Hi Arle,
 
 2012/12/12 Arle Lommel fene...@gmail.com
 Thanks to everyone for recent help. I've been truly impressed by how helpful 
 people have been for my requests.
 
 Now I have one more problem with the piano piece I am working on. I am using 
 a pianoStaff, which works fine, except that I now have a portion with a bunch 
 of ossia parts (almost one a measure) that occupy only about the span of an 
 eighth note each. I have run into two issues that I cannot find addressed 
 online anywhere, and I am hoping someone can help:
 
 1. When adding an ossia to a piano staff the bar lines are automatically 
 connected down from the ossia to the main piano staff. Normally not a 
 problem, but for the piece I am working on I don't want them connecting. I 
 find plenty of snippets about how to remove bar lines in the staff while 
 leaving them on between staves, but nothing about the reverse. It isn't for 
 lack of searching for a solution and trying out various things. So can anyone 
 make a suggestion on how to achieve this?
 
 Try 
 \once \override Staff.BarLine #'allow-span-bar = ##f
 as shown below.
  
 
 2. In the first two instances where I call the ossia parts, there is one on 
 the last half beat of a measure and a *separate* one on the first half beat 
 of the next measure. Lilypond, quite logically, assumes that these should be 
 stuck together (since there is no time between them) and under any other 
 circumstance I would be happy for it to do so. But here it would be ideal if 
 I could somehow put a little white space between them because I need to show 
 that they are not a single continuous ossia but rather two separate optional 
 performance variants.
 
 One way would be to scale the last note of the first ossia add \stopStaff ans 
 the remaining note-value as a spacer-rest.
  
 \version 2.16.1
 
 staffPiano = 
 \new PianoStaff {
 \set PianoStaff.midiInstrument = #acoustic grand
 \set PianoStaff.instrumentName = #Piano
 \time 3/4
 
 
 \context Staff = top { 
 \clef treble
 \key b \major
 \relative c' {
 
   {
 \once \stemDown 
 e ais cis \tweak #'duration-log #1 fis \arpeggio
   }
   \\
   {
 \tiny c''8\rest dis,8 dis4 dis4
   }
   \\
   { 
 s2 s8 % why /skip?
 % 
 \new Staff = Ossia \with {
 alignAboveContext = #top
 fontSize = #-2
 \override StaffSymbol #'staff-space = 
 #(magstep -2)
 \remove Time_signature_engraver
 \override Clef #'transparent = ##t
 \override KeySignature #'stencil = ##f
 } % end \with for ossia-staff 
 {
 \key b \major
 %% scaling the latter 16th to insert a 
 s32 later.
 fis16 fis16*1/2 \ottava #0
 \stopStaff 
 s32
 %% setting BarLine 'transparent for 
 ossia-staff.
 \once \override Staff.BarLine 
 #'transparent = ##t
 %% disallow span-bar for ossia-staff.
 \once \override Staff.BarLine 
 #'allow-span-bar = ##f
 }
 % 
   }
   
   |
 % bar 2
 
   {
 fis8[ fis8] fis8[ fis8] fis8 fis8]
   }
  \context Staff = Ossia {
  \startStaff 
  r8 dis8 
  \stopStaff

Tweaking notehead direction in chords

[Arle Lommel]

I've been looking for how to tweak the direction of noteheads within chords. 
I've got a few instances where Lilypond’s default isn't as clear as when I flip 
the direction of some of the noteheads. I've searched the repository and tried 
various tweaks using direction, but nothing seems to matter. I'm sure it's 
easy, but I can't find it.

As a minimal example, consider this chord:

e fis ais cis4

The default is to have the e face left and the other heads face right, but in 
the piece I am reproducing the e faces right and the fis faces left. Doing it 
this way, as per the old engraver, increases the white space between the 
noteheads and increases legibility.

Any guidance on how to achieve this? If there is an easy way, I would suggest 
adding it to the LSR as well, since this is a basic sort of tweak that others 
must surely need, but which doesn't seem to be easy to find.

Best,

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

Re: Tweaking notehead direction in chords

[Arle Lommel]

Brilliant, Paul. It isn't as easy as I'd hoped, but this works and is really 
minimally difficult for me to use. I used 1.25 and -1.25 as values and it is 
certainly close enough that I can't complain. This helps a *lot*.

Best regards,

Arle

On 2012 Dec 11, at 21:05 , Paul Morris wrote:

 Hi Arle,
 
 On Dec 11, 2012, at 2:37 PM, Arle Lommel fene...@gmail.com wrote:
 
 I've been looking for how to tweak the direction of noteheads within chords. 
 I've got a few instances where Lilypond’s default isn't as clear as when I 
 flip the direction of some of the noteheads. I've searched the repository 
 and tried various tweaks using direction, but nothing seems to matter. I'm 
 sure it's easy, but I can't find it.
 
 As a minimal example, consider this chord:
 
 e fis ais cis4
 
 The default is to have the e face left and the other heads face right, but 
 in the piece I am reproducing the e faces right and the fis faces left. 
 Doing it this way, as per the old engraver, increases the white space 
 between the noteheads and increases legibility.
 
 Any guidance on how to achieve this? If there is an easy way, I would 
 suggest adding it to the LSR as well, since this is a basic sort of tweak 
 that others must surely need, but which doesn't seem to be easy to find.
 
 I had trouble figuring this out earlier this year and David Nalesnik helped 
 me out with the code below.[1]  I have had it on my list to add it to the LSR 
 (while giving proper credit to David N.), as it is something that is not easy 
 to figure out on your own.  
 
 (I think the fully accurate horizontal offsets should be 1.251178 and 
 -1.251178 rather than 1.3 or -1.3 for regular sized noteheads.  They would be 
 a little larger for whole note note heads, but I don't know those values at 
 the moment.)
 
 Let me know if you have questions about how it works.
 
 HTH,
 -Paul
 
 
 #(define ((shift offsets) grob)
  (let ((note-heads (ly:grob-array-list (ly:grob-object grob 'note-heads
(for-each
  (lambda (p q) (set! (ly:grob-property p 'X-offset) q))
  note-heads offsets)))
 
 displaceHeads =
 #(define-music-function (parser location offsets) (list?)
  #{
\once \override NoteColumn #'before-line-breaking = #(shift offsets)
  #}
 )
 
 theMusic = {
  \displaceHeads #'(0 0 1.3)
  c' e' g' 4
 
  \displaceHeads #'(0 1.3 1.3)
  d' f' a'
 
  \displaceHeads #'(0 1.3 1.3)
  d' f' a'
 
  \displaceHeads #'(0 0 1.3)
   c' e' g'
 
  \displaceHeads #'(-1.3 -1.3 0)
   c'' e'' g''
 
  \displaceHeads #'(-1.3 -1.3 0)
   c''' e''' g'''
 
  \displaceHeads #'(0 0 1.3)
   c e g
 
  \displaceHeads #'(0 -1.3 0)
   c'' e'' g''
 
  \displaceHeads #'(0 0 -1.3)
   c'' e'' g''
 }
 
 \new Staff {
  \theMusic
 }
 
 [1] http://lists.gnu.org/archive/html/lilypond-user/2012-12/msg00186.html


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

Re: How to cross-staff beam different length notes in a chord.

[Arle Lommel]

As a follow-up, I managed to mostly solve the problem with this example (relevant additions in bold):top = { \change Staff = "top" }bottom = { \change Staff = "bottom" }staffPiano = \new PianoStaff {	\set PianoStaff.instrumentName = #"Piano"		\time 3/4		\context Staff = "top" {			\clef treble			\key b \major			\relative c' { { \stemUp fis2 } \\ { \bottom \stemUp \once \override Stem #'cross-staff = ##t \once \override Stem #'length = #25 \once \override NoteColumn #'ignore-collision = ##t fis, b dis4^"  Ben marcato e sostenuto il canto" \top \stemNeutral fis'' b dis8_"m.g." b,8\rest cisis, gis'4 } \\ { \tiny d'''8\rest \ottava #1 \stemUp dis32 fis32 dis32 fis,32 \ottava #0 b4\rest fis4\rest | }  |			}		}		\context Staff = "bottom" { 		\clef bass			\key b \major			\relative c, {\stemDown b b'2^\p eis' b'4 |			}		}	}However, the result still has some problems:Note that the stems are slightly misaligned. Not a huge deal, but it looks a bit sloppy.Any better way to handle this?-Arle___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Apologies

[Arle Lommel]

Not sure what my mail program did, so sorry for all the base64 crap dumped in 
the list just now, and please ignore the earlier messages, which was sent from 
the wrong address and shouldn't have even gone through.

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

Trying once more…

[Arle Lommel]

Hopefully this won't puke on the list. What is the best way to handle something like this:Where the notes in a "chord" are of unequal length.I've tried using polyphony and forcing the stem direction, but I've gotten problems with very small misalignments in the stems, and in this case it would be nice if the direction of the note heads could be handled automatically.I've tried searching the documentation and not found anything obviously relevant.-Arle___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Trying once more.

[Arle Lommel]

Between Phil's suggestion, which prompted me to add a missing:

\context {
 \PianoStaff
\consists #Span_stem_engraver
}

in the layout {} block (which made cross-staff beaming possible), and Thomas’ 
suggestion to use \tweak #'duration-log #, I've got this working nicely.

The hardest thing was that I had never used #'duration-log and did not know 
that the numeric values don't match the note-lengths used elsewhere. Took a bit 
of trial and error, but it worked in the end.

Thank you all very much. Now I'm back in business :-)

Best,

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

Simple hymn question

[Arle Lommel]

Hello all,

I've got what should be a simple question, but one which is giving me no end of 
trouble. I'm attempting to set a carol for homophonic choir, so I do *not* need 
independent voices, but I do need the lyrics between the staves. All of the 
examples I have found online are considerably more complex than what I need and 
I can easily add the lyrics below the bass part. Getting them between the 
staves should be simple, but I don't know how to do it and have not found clear 
instructions for my simple case.

(Just to be clear, I am looking for display something like this: 
http://www.christmas-carol-music.org/SATB/InTheBleak.html)

Can anyone help me? It's frustrating that something seemingly so simple is 
proving so elusive and difficult. I'm hoping someone will look at this and say 
well, the answer obviously, is to do this…” and point me to an actual example 
that does it.

Best,

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

Re: Changing quarter tone notation

[Arle Lommel]

Thanks Keith,

I appreciate the answer. It was what I was afraid of. Since I really don't know 
Scheme well enough to hack things like that, I guess I'll stick with the 
default glyphs. I wanted to avoid articulations since that means the underlying 
tones in the Lilypond would be incorrect (e.g., c instead of cih), which would 
cause problems for conversion later on if I find a way to do what I want 
without a workaround. Since this was a (very) nice to have rather than a 
can't live without it request, I'll hold on it, but thank you very much for 
looking at it and trying to help.

Best regards,

Arle


On Sep 5, 2012, at 11:44 PM, Keith OHara k-ohara5...@oco.net wrote:

 On Wed, 05 Sep 2012 06:37:38 -0700, Arle Lommel fene...@gmail.com wrote:
 
 If the arrows were independent of the sharp and flat signs (which would 
 derive as normal from the key signature plus accidentals, as if the 
 quarter-tone shifts did not exist) and placed above/below the note heads, 
 that would be it. For example, if I want a C-natural ↑ in the LSR example 
 and the key signature doesn't specify C♯, I get a glyph with a♮+ ↑ in it. In 
 the system I would like to use there would be no natural sign at all in this 
 case, just the arrow over (or below) the note head.
 
 
 No, there is not any mechanism in LilyPond to print two independent glyphs 
 (such as sharp or arrow or both) in two different places, based on pitch 
 names.
 
  cih'4 \( b4 | a4 b4 | cih4 a4 | a8 e4. | fih4 d4 | e2 \) |
 
 If there are no arrow alterations in your key signatures, and you do not need 
 to transpose by the pitch-change represented by an arrow,
 
 then you might want to represent the arrows as articulations.
   up = ^↑
   dn = _↓
   \transpose c c''{ c-\up cis-\dn }
 
 The text-scripts above are not very nice, but I think with a minor amount of 
 writing a Scheme data structure you can define your own Scripts that get the 
 right placement in the staff and inside slurs.  I have never done this 
 myself, so look in the manuals and .scm definition files so far as you are 
 interested, or maybe someone else here has done similar and will suggest how.
 


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

Re: lilypond-user Digest, Vol 118, Issue 20

[Arle Lommel]

Hi Keith,Thanks for this answer and my apologies for taking a while to acknowledge it. For some reason I missed it at the time and only today found it.The bit there is a different system then what I need in that it puts arrows on the accidentals. The system I'm looking for puts the arrows above or below the note heads. Admittedly that system wouldn't work for polyphonic music with chords, but for the Hungarian music I work with the lines are monophonic and putting the arrows above or below the note heads is quite clear. Incidentally, that also effectively distinguishes between C♯ up and D♭ down, since you can apply either arrow to a note head.So I'm not sure that the LSR item is what I'm looking for, although it *is* a step in the right direction. If the arrows were independent of the sharp and flat signs (which would derive as normal from the key signature plus accidentals, as if the quarter-tone shifts did not exist) and placed above/below the note heads, that would be it. For example, if I want a C-natural ↑ in the LSR example and the key signature doesn't specify C♯, I get a glyph with a♮+↑ in it. In the system I would like to use there would be no natural sign at all in this case, just the arrow over (or below) the note head.Here is a visual comparison of the two using an actual sample of one of the tunes I am working with:And here is the code that generates the top:notes = \relative a' { \key a\minor \set Staff.extraNatural = ##f \time 2/4 cih'4 \( b4 | a4 b4 | cih4 a4 | a8 e4. | fih4 d4 | e2 \) |}I'd like to be able to take something like this and generate the bottom output, if possible.If it's not currently possible (or at least not possible without a significant amount of Scheme hacking), then I will stick to the half sharp signs I'm currently using.Thanks,-ArleThis methodhttp://lsr.dsi.unimi.it/LSR/Item?id=784is maybe more complicated than you need, because it takes trouble todistinguish C-sharp-up from D-natural-down.You might need only the part with \override KeySignature #'glyph-name-alist = \arrowGlyphsand a simplified version of arrowGlyphs arrowGlyphs = #`((1 . "accidentals.doublesharp")(3/4 . "accidentals.sharp.arrowup")(1/2 . "accidentals.sharp")etc.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing quarter tone notation

[Arle Lommel]

[apologies for reposting, but I had the wrong subject heading, which means nobody would have read this before.]Hi Keith,Thanks for this answer and my apologies for taking a while to acknowledge it. For some reason I missed it at the time and only today found it.The bit there is a different system then what I need in that it puts arrows on the accidentals. The system I'm looking for puts the arrows above or below the note heads. Admittedly that system wouldn't work for polyphonic music with chords, but for the Hungarian music I work with the lines are monophonic and putting the arrows above or below the note heads is quite clear. Incidentally, that also effectively distinguishes between C♯ up and D♭ down, since you can apply either arrow to a note head.So I'm not sure that the LSR item is what I'm looking for, although it *is* a step in the right direction. If the arrows were independent of the sharp and flat signs (which would derive as normal from the key signature plus accidentals, as if the quarter-tone shifts did not exist) and placed above/below the note heads, that would be it. For example, if I want a C-natural ↑ in the LSR example and the key signature doesn't specify C♯, I get a glyph with a♮+↑ in it. In the system I would like to use there would be no natural sign at all in this case, just the arrow over (or below) the note head.Here is a visual comparison of the two using an actual sample of one of the tunes I am working with:And here is the code that generates the top:notes = \relative a' { \key a\minor \set Staff.extraNatural = ##f \time 2/4 cih'4 \( b4 | a4 b4 | cih4 a4 | a8 e4. | fih4 d4 | e2 \) |}I'd like to be able to take something like this and generate the bottom output, if possible.If it's not currently possible (or at least not possible without a significant amount of Scheme hacking), then I will stick to the half sharp signs I'm currently using.Thanks,-ArleThis methodhttp://lsr.dsi.unimi.it/LSR/Item?id=784is maybe more complicated than you need, because it takes trouble todistinguish C-sharp-up from D-natural-down.You might need only the part with \override KeySignature #'glyph-name-alist = \arrowGlyphsand a simplified version of arrowGlyphs arrowGlyphs = #`((1 . "accidentals.doublesharp")(3/4 . "accidentals.sharp.arrowup")(1/2 . "accidentals.sharp")etc.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Lyrics help

[Arle Lommel]

Hello all,

I've got a pretty basic question, but looking through the manuals and trying 
things out hasn't seemed to help me get closer to a solution.

I'm transcribing some songs I collected in the field and I need to have a volta 
repeat in the music where the lyrics for two verses are listed under the 
repeated section and then for the rest of the song has a single line. I've 
figured out ways to attach two lines to the entire song (and obviously ways to 
attach one line to the entire song), but not a way to have two lines for just 
part of the song.

To be clearer, here is a little ASCII diagram of what I am after:

|: SOME MUSIC GOES HERE :|  SOME MORE MUSIC IN THE SAME VOICE |
1. Lyrics to verse one3. Lyrics to voice three
2. Lyrics to verse two

| SOME MORE MUSIC GOES HERE IN THE SAME VOICE |
4. Lyrics to verse four 4. Lyrics to verse five…   etc.

I imagine the answer is simple, but none of the example or snippets I have 
found seem to address how to do this and all my attempts to figure out a 
solution have led to strange side effects. (Also, I want automatic alignment of 
the lyrics to the voice since I'm constantly tweaking the transcription and 
don't want to adjust values in two places, but the closest solution I've found 
so far—I don't remember now exactly what I did—lost the automatic alignment.)

So sorry if I've missed something obvious, but this item that should be as 
simple as anything is eluding me.

Best regards,

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

Changing quarter tone notation

[Arle Lommel]

As a separate question from the last, does anyone know of a simple way to override the quarter-tone notation in Lilypond? In particular, I want to replace half sharps with an upward arrow over the note, which is the de facto standard in the particular ethnomusicological area I work in. While the half sharp is clear enough, expectations in my field are for the arrow, which I know in other contexts may not be as clear (since it may indicate microtonal variation of less than a quarter tone).For example, I have this output now from Lilypond:But this is what I would like to see:I don't want to do this as a hack with text markup, but rather have cih simply equal the c note head with the arrow above so that the underlying music code actually represents the pitches rather than entering c with some markup to make it look like cih.Any suggestions?Best,Arle Lommel___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lyrics help

[Arle Lommel]

Thanks Trevor,

Thanks for pointing me in the right direction. My mistake was to look in 
lyrics, not repeats, I guess. I just tried it and it worked well, so I'm set. 
As you say, not trivially obvious, but I can see the logic behind the syntax 
(even if I would never have guessed it in a hundred years). Seems like 
something where some rationalization might help, but I won't look a gift horse 
in the mouth (especially not one that does so much that I need that would be 
well-nigh impossible with any of the non-free packages).

But this does it, so much appreciated.

Best,

Arle

On Aug 30, 2012, at 9:48 AM, Trevor Daniels t.dani...@treda.co.uk wrote:

 The way to do this is not trivially obvious.  You'll find some
 clues in
 
 http://www.lilypond.org/doc/v2.17/Documentation/notation/techniques-specific-to-lyrics#lyrics-and-repeats
 
 Read the whole section.
 
 (If this doesn't help, please post again.)
 
 Trevor

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

Re: Lyrics help

[Arle Lommel]

Actually, as I look, I'm not sure how I missed this. But I did search for quite 
a while, so thank you again Trevor for the help.

Best,

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

PDF preview in jEdit

[Arle Lommel]

Hi all,

Just started using jEdit and lilypondtool today on Mac OS X because I liked the 
idea of the PDF Preview and the integration between it and the editor. However, 
in trying it out, I find that once I first invoke the preview function it won't 
update for me, so I can't see any changes: it stubbornly displays whatever it 
displayed when first invoked. Even saving the document does nothing.

I've looked in vain for some sort of obvious refresh button or something like 
that and even closing the viewer and reopening it still shows the same PDF. I'm 
probably missing something really obvious, but the lilypondtool documentation 
online doesn't seem to mention how to get the preview to update.

Can anyone help me out?

Best,

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

Re: PDF preview in jEdit

[Arle Lommel]

Thank you Patrick, but I should have made it clear, *that* was the item that 
kept serving me up the old version of the file as a preview, even after saving 
and making changes. Running the “Run Lilypond” botton, per Bert’s suggestion, 
however, seems to take care of the issue.

-Arle


On Jan 17, 2011, at 14:29 , Patrick Schmidt wrote:
 There is a button called Preview Output (PDF) right after the Convert to 
 newer version button.
 
 HTH
 patrick


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

Re: Complex time signature

[Arle Lommel]

Ralph, look here:

http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.ly

I've used this, with some adjustment in the 2.13 development versions, and I 
think it works unaltered in 2.12. It should do exactly what you want. In some 
of the later 2.13 versions you have to manually control beaming as that gets 
broken, but since you are using 2.12, I think that Reinhold’s materials should 
work as is.

In my case, I store the polymetric bits in a separate file and include them, so 
I get code like the following:


 \include ../_includes/polymetric.ly
 
 upper = \relative c'' { 
   \clef treble 
   \key e \minor
   \override Score.TimeSignature #'break-visibility = #'#(#f #t #t)
   \compoundMeter #'((3 3 2 8)) 
   \time 8/8 
   \tempo 8 = 560
   \overrideBeamSettings #'Staff #'(8 . 8) #'end #'((* . (3 3 2)))
   
 %m1
   \once \override Rest #'extra-offset = #'(8 . 0) r1\mp |
   r4. r4. g8(^\( fis8) |
   \repeat volta 2 {
   e4. e4. e4 |
   d4. g4.~g4 |
 


It's been a while since I worked with this, and I think I had to manually force 
the beaming in some instances for later versions of 2.13.

If you'd like a sample PDF and the full (2.13.24) file so you can see how these 
things work, let me know

-Arle


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

Re:Complex time signature

[Arle Lommel]

Even if that is perfect for your needs, you might want to take a look at 
Reinhold’s code anyway. It provides the proper Bartókian output (3+3+2/8), 
while the LSR code can only produce 3/8 + 3/8 + 2/8 type output. I prefer the 
former as cleaner and easier to read.

-Arle


 
 Thank you, James -
 
 That's perfect.
 
 Ralph
 
 -- 
 Ralph Palmer
 Montague City, MA
 USA
 palmer.r.vio...@gmail.com
 
 
 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 http://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: Complex time signature

[Arle Lommel]

))


%
% The music function to set the complex time signature
%

compoundMeter =
#(define-music-function (parser location args) (pair?)
  (let* ((mlen (calculate-compound-measure-length args))
 (beat (calculate-compound-base-beat args))
;  (beatGrouping (calculate-compound-beat-grouping args beat))
 )
;   (display Time signature: )(display args)(newline)
;   (display beat grouping: )(display beatGrouping)(newline)
  #{
\once \override Staff.TimeSignature #'stencil = #ly:text-interface::print
\once \override Staff.TimeSignature #'text = #(format-compound-time $args)
% \set Staff.beatGrouping = #(reverse (cdr (reverse $args)))
\set Timing.measureLength = $mlen
\set Timing.timeSignatureFraction = #(cons (ly:moment-main-numerator $mlen)
   (ly:moment-main-denominator $mlen))
\set Timing.beatLength = $beat

% TODO: Implement beatGrouping and auto-beam-settings!!!
#} ))

\relative c'' {

\new Staff {
\clef treble
\key a \mixolydian
\compoundMeter #'((3 3 4 16)) 
\time 10/16 
\set beatStructure = #'(3 3 4)

a16^A b16 a16 cis8 a16 cis8 a16 b16 |
fis'8. \acciaccatura a,8 fis'8. \acciaccatura a8 e4 |
e16. fis16. e16. d16. cis8 a8 |
b8. \acciaccatura a8 b8 a16 cis4 |
}

}


On Jan 14, 2011, at 12:51 , Hans Aberg wrote:

 On 14 Jan 2011, at 18:28, Arle Lommel wrote:
 
 Even if that is perfect for your needs, you might want to take a look at 
 Reinhold’s code anyway. It provides the proper Bartókian output (3+3+2/8), 
 while the LSR code can only produce 3/8 + 3/8 + 2/8 type output. I prefer 
 the former as cleaner and easier to read.
 
 I have another Bartok example
  4+2+3
8
 However, the LSR Sedi Donka meter http://lsr.dsi.unimi.it/LSR/Item?id=192 
 is in a Bulgarian book written as
  7+7+11
  8 8 8
 with the '+' centered of course.
 
 

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

Re: Complex time signature

[Arle Lommel]

 Somebody in this list used the notation of writing just the number in the 
 staff, and the '+' decomposition above it and the staff within parenthesis in 
 smaller size. That seems me to be a good idea. The '+' is not needed if the 
 decomposition can be seen from the beaming.

Seems like a good way to approach it. I prefer the format I use in some work 
I've, but primarily because I was writing pieces with shifting polymetrics and 
preferred to make everything rather obvious. But the idea you mention does seem 
appropriate where the emphasis in the score is not on the rhythm and something 
more discreet is desired.

-Arle


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

Re: Complex time signature

[Arle Lommel]

Reinhold,

Thanks for the changes. I wasn't aware of the new version and I'm glad to see 
it in LSR.

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

OT: Discussion with developer on documentation

[Arle Lommel]

Apologies for a question not directly related to Lilypond, but is there anyone 
who works with the documentation for Lilypond on this list with whom I could 
interact privately? I am working on a totally unrelated open-source project and 
we we are faced with about 500 pages of legacy documentation in Word that we 
need to port to the web in a more friendly format than Word. Lilypond’s 
documentation seems like an ideal model for me, and I’d like to get a better 
picture of what might be involved in order to arrive at that end.

Best,

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

Re: Possible bug in lyrics mode

[Arle Lommel]

I’ve gone ahead and submitted the lyric mode spacing issue to the gmane lilypond bugs list. This is the first time I've submitted a bug and as I look at the other postings, so I'll askhere if I need to do anything beyond posting it there to get the bug actually listed?For what it's worth, I've created a more compact example (still fairly large since I need to show multiple lines) and compared it with ideal output:This graphic shows just how bad the problem can be. At the font size output by Lilypond, the ideal minimum distance between baselines of the text should be somewhere around 14.7 pt (as shown at right, which is what the output should look like, more or less). In some cases, however, the actual line spacing is less than half what the minimum should be and even at itsgreatest value it achieves effectivelynegativeleading (if the distance between baselines is less than the font size the leading is essentially negative). From a typographical standpoint this is absolutely terrible and from a performance standpoint it renders the lyrics text unreadable.Does anyone have any thoughts on how to get an acceptable output without resorting to kludges like the following where minimum-distance needs to be set by trial and error to get something even close to right?\override VerticalAxisGroup #'inter-loose-line-spacing = #'((space .1) (padding . 1) (minimum-distance . 4) (stretchability . 1))(Also, in my trials I never found that any of the values besides minimum-distance seemed to actually do anything at all. Maybe I just don't understand them.)(For me, obviously getting a bug fix is the way to go, but I'm going to guess that this will not get high priority since it doesn't deal with notation. I hope I'm wrong though.)Best,ArleI include the minimal example used to generate the examples above:\version "2.13.28"\header {	title = "Some really bad spacing"}\paper{ ragged-right=##t }melody = \relative a' {	\key c \dorian	\time 4/4	\clef treble		c4 bes8 g8 c8 bes8 g4 |}verseA = { \lyricmode { This texty has de -- scend -- ers } }verseB = { \lyricmode { This text has none at all } }verseC = { \lyricmode { aces are cans. axes are caves } }verseD = { \lyricmode { so are cons, ox -- en zero } }verseE = { \lyricmode { AND NOW I AM SHOUT -- ING } }\score {			\new Voice = "melody" { \melody }		\new Lyrics \lyricsto "melody" \verseA		\new Lyrics \lyricsto "melody" \verseB		\new Lyrics \lyricsto "melody" \verseC		\new Lyrics \lyricsto "melody" \verseD		\new Lyrics \lyricsto "melody" \verseE	}\layout {\context { \Lyrics}}___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re:Possible bug in lyrics mode

[Arle Lommel]

Just after I posted the additional example, Urs confirmed that it was posted to 
the bug list and given medium priority. So please disregard the question about 
if I needed to do anything else. The example I included may be useful though.

Best,

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

Possible bug in lyrics mode

[Arle Lommel]

Hi all,

Just thought I'd mention something I believe to be a bug in lyrics mode, but 
thought I'd ask if there is a rationale for it before I submit.

I found this a few weeks ago and got a workaround thanks to the list, but it 
was a bit of a pain and I can't help but think this is a bug.

Line height for lyrics (at least in 2.13.24) is determined by the postscript 
bounding box for the characters in the line (or at least that's what it seems), 
*not* the em-square, which is the basic unit for almost all typographic 
measurements. This means that if a line has no descenders (j, p, or y), it 
loses height at the bottom and the next line will sit closer to it that it 
would if that line contained descenders. Similarly, if the line contains no 
ascenders (which is, admittedly, unlikely, but certainly not impossible), the 
spacing between lines is figured from the x-height of the text rather than the 
cap height. As a result the visual spacing between lines can be very uneven, 
with some lines closer to each other than to other ones and very irregular 
appearance.

The following image shows the problem. The dotted red lines show even spacing, 
but you can see that Lilypond’s output is nowhere near even. The problem is the 
third line, which lacks descenders, thus forcing the fourth line to sit too 
close to it:

inline: badSpacing.png
I would argue that the layout engine should work based on the em-square of the 
font, which would result in consistent and predictable spacing. The way it is 
in 2.13.24 though is essentially unpredictable since you can’t know what the 
output is unless you know in advance what the lyrics text will be.

Before I file it as a bug, though, I would like to know if there is a reason to 
base the line height on the postscript bounding boxes of the text.

-Arle___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: invisible rest that takes no horizontal space

[Arle Lommel]

 On 6/18/10 12:32 PM, Dmytro O. Redchuk wrote:
 Why not:
  % [...]
  d4. e8 fis4 e |
  \partial 2
  d2 \bar :|:
  fis2 g |
  % [...]
 
 
 Yes. That would be the solution if I could start from scratch. The
 problem is that I have more than 1000 melodies in which the
 invisible rest is used instead of \partial. We do not have the
 resources to change them all.

Dmytro, how well defined are the contexts where these occur? If the patterns 
are well enough defined, you could probably automate all the replacements with 
\partial by using a regular expression across all the files that is centered on 
looking for the s2 sorts of things. Whether it would work would really depend 
on how predictable these things would be. It would be much simpler if you were 
using bar checks as then there would be something in the pattern to anchor the 
search on, but your example

d2 s2 \bar :|:

could be accounted for with something like

Search string:
([a-g](?:is|es)?2) s2 \\bar :\|:

Replacement string:
\\partial 2\r\1 \\bar :|:

Depending on your environment, you might have to modify the strings to match 
your flavor of regex. I've tested this pattern and it accounts for your test 
case. Where it would break down is if these partial measures are variable in 
length or if you have variable numbers of notes before the spacer, in which 
case it might not work. If there is anything that indicates the measure bar 
line location that starts the partial measure, it should be possible (even if 
that something is just a new line).

If you aren't comfortable with regex and would like me to look at some examples 
to see if you could automate the replacements, let me know off list and I may 
be able to help if you want to see if it's possible to fix these that way.

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

Alternative polymetric representation

[Arle Lommel]

(Sorry for the lengthy post, but a couple of issues came up when I tried to 
work with an older file I did some time ago.)

About 18 months ago Reinhold helped me figure out how to display time 
signatures like (3+3+4)/16 in which there is a complex upper portion of the 
time signature over a simple lower portion. Reinhold provided a fairly complex 
fix at that time, but with updating from 2.12.2 to 2.13.18, it runs into some 
problems with beat grouping. In particular running the convert does a 
reasonable job except for this error:

 Not smart enough to convert beatGrouping. 
beatGrouping with a specified context must now be accomplished with
\overrideBeamSettings.
 Please refer to the manual for details, and update manually.

OK. Fair enough, I need to look at the current manual, but there are some 
problems with the documentation online that make this problematic.

If I go to here:

http://lilypond.org/doc/v2.13//Documentation/web/manuals.html

and search, it does not search the 2.13 documentation, but the 2.12 
documentation (where \overrideBeamSettings is, for obvious reasons, not found).

So I modify the search string to change the version number to 2.13. Not a big 
deal, just a minor annoyance, but it only brings up one hit:

http://lilypond.org/doc/v2.13/Documentation/ce/lily-547b3574.ly

Which returns a 404. (And the Google hit doesn't have a cache to look at!)

So the question is where can I find the documentation for 
\overrideBeamSettings? I'd like to consult that *before* I come here and get a 
RTFM response, but in this case it seems that TFM doesn't exist.

For what it's worth, what I'm trying to get right is the equivalent in function 
to 
http://lilypond.org/doc/v2.13//Documentation/snippets/rhythms#changing-time-signatures-inside-a-polymetric-section-using-_005cscaledurations
 , but the display is quite a bit different in appearance and cleaner, e.,g.,

inline: timeSample.gif
That was the output from 2.12.2. If I convert it and convert to PDF, I get the 
following, which is (obviously) not what I want:

inline: timeSample2.gif

(I'm not sure why the first line only is doubled.)

At the time I first got Reinhold's solution, I believe he said that this time 
signature notation would make it into the trunk for 2.13, but I'm not entirely 
certain I recall that right.

So my question is if there is now a preferred way to accomplish this sort of 
time signature in 2.13.x with autobeaming (and hopefully no unexplained 
duplication of the first line of the *monophonic* score)

If anyone wants to see the entire scores in question, here is the link to the 
original Lilypond file for 2.12.2, which worked under that version:

http://dl.dropbox.com/u/223919/lilypond/compound.ly

And here is the PDF:

http://dl.dropbox.com/u/223919/lilypond/compound.pdf

Here is the link to the output from the convert function (2.13.18):

http://dl.dropbox.com/u/223919/lilypond/compound2.ly

And the PDF it makes:

http://dl.dropbox.com/u/223919/lilypond/compound2.pdf

Any guidance on this would be welcome since this is digging into some pretty 
obscure code.

Thanks in advance for any insights,

Arle Lommel___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Alternative polymetric representation

[Arle Lommel]

Thanks to Alexander for the quick fix. I hadn't found that bit (obviously), in 
part because I wasn't thinking about it in the context of beams, but rather in 
the context of polymetric time signatures and that problem. Had I thought to 
look in the semi-obvious place, I suppose I would have found it.

Carl, it's not time critical, especially now that I have a workaround that 
restores the former behavior. But I'll be curious to see how the new autobeam 
syntax works (especially in conjunction with my unusual metrical requirements). 
Is there some way to sign up to be notified of changes in particular areas of 
Lilypond? I'm particularly interested in anything to do with simplifying 
polymetric time signatures. If I were a real programmer (rather than a PHP 
kludger), I would gladly volunteer to work on this area of the program.

Finally, I found the cause for the duplication of my first line: it was simply 
duplicated in the source file. I have no idea why that happened, but it was NOT 
Lilypond's fault.

Best,

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

Problem with complete lack of spacing between stanzas

[Arle Lommel]

I am working with Lilypond 2.13.8 and have run into the problem that the 
default spacing between stanzas of lyrics is unacceptably small (it has 
ascenders and descenders of different lines crashing into each other). I've 
searched the documentation and the web to find solutions and have found a 
number of instances where people have described this problem and offered 
solutions, either globally in the Lyrics context or for specific stanzas 
(preferable in this case), but none of them seems to have any impact on my 
file. They don't return errors, they just fail to do *anything* at all and the 
stanzas stay stubbornly stuck together and ugly.

I include an abbreviated version of my file below (four stanzas are deleted for 
the sake of brevity).

I would appreciate any working suggestions for how to control these spacing 
issues on a per stanza basis.

Best,

Arle Lommel

\version 2.13.8
\header {
%   title = Alma a fa alatt, nyári piros alma
}

#(set-default-paper-size letter)
#(set-global-staff-size 16)
\paper{
indent = 0\cm
top-margin = 4.76\cm
bottom-margin = 4.76\cm
right-margin = 4\cm
left-margin = 4\cm
}

melody = \relative a' {
\key c \dorian
\time 4/4
\clef treble

c4\( bes8 g8 c8 bes8 g4 | ees4 f4 g8 f4. | c2 c4\) r4 | \break
ees'8\( ees4. d4 c4 | bes4 c4 d8 c8 d8 c8 | g2 g4\) r4 | \break

ees'4\( ees4 d8 c4. | bes4 c4 d8 c8 d8 c8 | g2 bes4\) r4 | \break
c4\( bes8 g8 c8 bes8 g4 | ees4 f4 g8 f4. | c2 c4\) r4 \bar |.
}

verseOne = {
\set stanza = #1. 
\lyricmode {
Al -- ma a fa a -- latt, nyá -- ri pi -- ros al -- ma,
Ha -- rag -- szik rám a sze -- re -- tőm é -- de -- sany -- ja,
En -- gem gya -- láz, en -- gem tesz a vesz a szó -- ra,
Sze -- re -- tem a lá -- nyát, nem te -- he -- tek ró -- la.
}
}

verseOneE = {
\lyricmode {
\override LyricText #'font-shape = #'italic
Ap -- ple be -- neath the tree, scar -- let fruit of sum -- mer,
Steam -- ing, fum -- ing, mad at me, my lov -- er’s moth -- er,
Treats me like dirt, nev -- er, nev -- er good words from her,
But I can -- not help that, for I love her daugh -- ter.
}
}

\score {

\new Voice = melody {
\melody
}
\new Lyrics \lyricsto melody \verseOne
\new Lyrics \lyricsto melody \verseOneE

\layout { }
}

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

Specialist staff for Hungarian bagipe

[Arle Lommel]

I have made a specialist notation for notating the Hungarian bagpipe  
and am hoping to figure out a way to emulate this notation in  
Lilypond. Since I'm relatively new to Lilypond, I may have missed  
something obvious, but I have searched the documentation to try to  
figure it out and not found anything obvious. Some of the percussion  
type staffs come close to my needs, but aren't quite there (and aren't  
notated appropriately).


I've made an example of the staff I need here:

http://dl.getdropbox.com/u/223919/specialStaves.png

The lower part (labeled kontra) is a staff for a chanter pipe (one of  
two in this case) that has only two pitches. While I've made a special  
cleff (the AE bit), I could live without it (I would prefer it though  
since it makes the notation simpler to follow).


The upper part is a standard staff with treble clef and needs no  
special attention. So my goal is to place this two-line staff (with  
extra spacing between the two lines) below the main staff and assign a  
voice to it. Since there are only two possible pitches, I need to  
assign the pitches of A and E (both the ones above middle C) to those  
lines. Their behavior would be like a regular staff aside from the  
strange spacing and clef.


Again, I've tried to figure out how to assign custom staff types and  
clefs, etc., but I think my request is unusual enough that I've just  
not found anything directly relevant.


(And yes, I could use a two-staff system or two voices in one staff,  
but this notation has the advantage of being clearer for the purposes  
of illustrating what I need to.)


Any help, pointers in the right direction, etc. would be much  
appreciated (even of the you missed the obvious in section x.x.xx of  
the documentation sort of thing).


Best regards,

Arle Lommel


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

Re: Specialist staff for Hungarian bagipe

[Arle Lommel]

Thanks for the most helpful response. Somehow I missed that portion of  
the documentation, even though I do recall looking at it earlier. My  
guess is that if I can define the right line positions and limit the  
number to two, I'll be there. Now I have a starting point.


Best,

Arle

On Jun 9, 2009, at 3:06 PM, David Bobroff wrote:


I'm sure you can get LilyPond to do what you need.  Start here:

http://lilypond.org/doc/v2.13/Documentation/user/lilypond/Modifying-single-staves#Modifying-single-staves

-David



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