Re: minimal-breaking page breaking algorithm fails

[Keith OHara]

Kieren MacMillan  sympatico.ca> writes:

> > Is there anything you use a lot in your score that could sometimes 
> > force staves further apart,
> > depending on how the note-spacing comes out ?
> 
> My score is frenched, so the estimates could be based on system extents 
> BEFORE the empty ones are removed…
> 

The system tries to be smart about that, and it seems to work. I could not
fool the minimal page breaker with simple music on a frenched score.
(The defualt, optimal-breaking, does not impress me with how it chooses
breaks just before or after a staff becomes empty on a frenched score.)

The weakness of the page-filling system tends to be related to how it ignores
the possibility that items from different systems might interleave a bit.

\paper {
  page-breaking = #ly:minimal-breaking 
  ragged-bottom=##t }
k = 4 n = 8 m = #(* 3 n)
<<
 \repeat unfold \k {
   \repeat unfold \m {c'4 d' e' f} }
 \new Lyrics \repeat unfold \k {
   \repeat unfold \m \lyricmode {lo-4 rem ip- sum } }
 \repeat unfold \k {
   \repeat unfold \n {c,4 d' e' f'}
   \repeat unfold \n {R1 R1} } >>


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

Re: Full bar rests in single-staff polyphony

[Keith OHara]

Daniel Rosen  gmail.com> writes:

> "So far, there's no automatic support in LilyPond to avoid collisions between 
> multi-measure rests and other objects."
> 
> Is this still the case?

Yes.

> If so, is there a reason that this feature can't be added?
 
I think that part of reason full-measure rests don't avoid other
objects is that their spacing rules are different than those for anything
else inside the staff.  They go in the middle of the measure, without 
regard to rhythm.  They would need to be placed somewhat like text markup.

{ \time 3/4 << {
   b'16 a' g' d' e'4 e''
 } \\ {
   \once\override MultiMeasureRest #'staff-position = #-7
   R2.
 } >> }





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

Re: Writing to the console (debug info)

[Mark Witmer]

You can do that with Scheme.  I don't know if there's a LilyPond command
for it.

#(display ) will display what you give it, either a plain
string or an expression. The results aren't always totally useful (give it
a \paper{} block, for example, and it will just say #) but
that's a start. #(newline) will move to the next line if you want cleaner
output.

There's also a procedure called 'format' that is more like printf.

http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Formatted-Output.html#index-format-3918

-Mark
On Dec 14, 2012 6:39 PM, "Olivier Biot"  wrote:

> On Sat, Dec 15, 2012 at 12:20 AM, Eric Pancer  wrote:
>
>> On Dec 14, 2012, at 17:05, Olivier Biot  wrote:
>>
>> > Hi all,
>> >
>> > Is there a way to write text to the console in LilyPond?
>> >
>> > I'd like to display the file currently processed to keep track of
>> problems on a 60 part etude
>>
>>
>> Use a "-v" flag when running it in Terminal.
>
>
>
> Hi Eric,
>
> I'm running LilyPond either directly or from Frescobaldi. I'm not sure I
> can set the "-v" flag in Frescobaldi.
>
> Is there really no way to display something directly to the console, e.g.
> as in the C function:
>
> fprintf(stderr, "Processing %s\n", fileName);
>
> Best regards,
>
> Olivier
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: unhiding a hidden staff at the NEXT line break (instead of previous line break)

[Keith OHara]

 gmail.com> writes:
> 
> Anyone know how I can get Lilypond to unhide a staff at the NEXT line break?

No.

It looks like you have a part for a cello section with the form
unison  |A|  simple-divisi  |B|  complex-divisi
where the complex-divisi music demands a separate staff for each part.

If you put your wished-for \showStaffNextBreak at |A| then you would
be assuming there is at least one line break between |A| and |B|.

Placing your \showStaff at |B| on the two separate-part staves makes more
sense.   But I do not see a way to stop the combined-part staff at the 
same linebreak where the seaparate-part staves need to begin.  For a dirty
way to get your job done, you could mark the combined-part staff as 
removable starting _almost_one_line_ before |B| (see below).

> hideStaff = \set Staff.keepAliveInterfaces = #'()
> This ends up working quite well for 
> * short to moderate-length pieces 
> * where only one score is to be created from music 
>   so annotated with \hideStaff and \showStaff 
> * and where explicit line breaks (\beak and \noBreak) are used.

Without the transition from chords to separate staves, you can use 
RemoveEmptyStaves to set the second staff, with automatic line-breaking

  
\version "2.16.0"
\paper { #(set-paper-size "a6") indent = 1.0\cm short-indent = 1.2\cm }

letStaffVanish = \set Staff.keepAliveInterfaces = #'()
showStaff = \unset Staff.keepAliveInterfaces

violinII = \relative c' {
  c4 d e f \letStaffVanish g f e d 
  -"divisi"   
  \stopStaff s1 \startStaff
  c4-"unison" d e f g f e d
  \showStaff c d e f c1 
  \bar "|."}

violinIIa = \relative c' {
  \letStaffVanish \quoteDuring "violinII" s1*2
  e4 f g a \showStaff b g d g
  \letStaffVanish \quoteDuring "violinII" s1*4
}

violinIIb = \relative c' {
  \letStaffVanish \quoteDuring #"violinII" s1*2
  c4 d e f \showStaff g b d b 
  \letStaffVanish \quoteDuring #"violinII" s1*4 }

\addQuote "violinII" \violinII

\new StaffGroup <<
  \new Staff \with {
instrumentName = "Vn 1"
shortInstrumentName = "Vn1"  
  } \repeat unfold 8 c''1
  \new GrandStaff \with {
instrumentName = "Vn 2"
shortInstrumentName = "Vn2"  
  } <<
\new Staff \with { shortInstrumentName="outer"} \new Voice \violinIIa
\new Staff \violinII
\new Staff \with {shortInstrumentName="inner"} \new Voice \violinIIb >> >>
\layout {
  \context {
\Staff \RemoveEmptyStaves 
\override VerticalAxisGroup #'remove-first = ##t }}


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

Re: what's the most "efficient" way of doing this?

[Frédéric Bron]

> B.
> B1. Put the RehearsalMark and MetronomeMark objects in the main global 
> variable (which also includes \time, \bar, etc.).
> B2. Create a MarksOnly custom context, which only has the engravers 
> necessary to show RehearsalMark and MetronomeMarks, and let it "filter out" 
> everything else from the \global variable.
> B3. Put the \global variable in all other contexts (for parts, etc.).

That's the best solution, at least the solution I used. You can have a
look at this score:
https://sites.google.com/a/polytechnique.org/bron/home/music/schumann---4th-symphony
first look in Schumann_Symphonie4.conducteur.pdf

I have three special text lines:
1. at top: text + bar numbers
2. in the middle: text + bar numbers
3. at the bottom: bar numbers only.

Does that correspond to what you want to do?

Frédéric

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

Re: \crossStaff and \stemDown

[Thomas Morley]

Investigating \crossStaff further, I noticed  a buggy behaviour, if
the stem-direction changes.
http://lilypond.1069038.n5.nabble.com/crossStaff-breaks-if-stem-direction-changes-td137717.html

-Harm

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

Re: Writing to the console (debug info)

[Olivier Biot]

On Sat, Dec 15, 2012 at 12:20 AM, Eric Pancer  wrote:

> On Dec 14, 2012, at 17:05, Olivier Biot  wrote:
>
> > Hi all,
> >
> > Is there a way to write text to the console in LilyPond?
> >
> > I'd like to display the file currently processed to keep track of
> problems on a 60 part etude
>
>
> Use a "-v" flag when running it in Terminal.



Hi Eric,

I'm running LilyPond either directly or from Frescobaldi. I'm not sure I
can set the "-v" flag in Frescobaldi.

Is there really no way to display something directly to the console, e.g.
as in the C function:

fprintf(stderr, "Processing %s\n", fileName);

Best regards,

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

Re: Displaying string number above fingering

[Eluze]

shutterfreak wrote
> Hi all,
> 
> How can I display the string number above fingerings in all cases?
> 
> Here's a small snippet that will semi randomly arrange fingerings and
> string numbers:
> 
> %%% BEGIN snippet
> \version "2.16.1"
> 
> theMusic = \new Staff \with {midiInstrument = #"cello"} {
>   \relative d {
> \key c \major
> \time 3/4
> \clef "bass"
> 
> d8-1-\2 ( e-\thumb-\1 d-1-\2 )
> b-2-\3 ( a-\thumb-\2 g-1-\3 )  |%
> 11
> a ( b-2 a ) e4-2-\4 d8-\thumb-\3  |%
> 12
>   }
> }
> 
> \score {
>   \theMusic
>   \layout {}
> }

\set stringNumberOrientations = #'(up)

and

\override StringNumber #'outside-staff-priority = #

will help

Eluze




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Displaying-string-number-above-fingering-tp137522p137715.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Displaying string number above fingering

[Olivier Biot]

On Wed, Dec 12, 2012 at 10:25 AM, David Kastrup  wrote:

> Keith OHara  writes:
>
> > Eluze  gmail.com> writes:
> >
> >> maybe this could be merged into
> >> https://code.google.com/p/lilypond/issues/detail?id=2830
> >
> > That issue is about fingering and string numbers inside chord brackets
> <>,
> > documenting how the order of input works together with script-priority
> >
> > 8(  )
> > (  )
> >
> > articulations coming earlier in the input are printed closer to the
> > note.
>
> New_fingering_engraver
>
> > The irregular behavior Oliver sees occurs when there is no <> chord
> > indication.
>
> Fingering_engraver
>
> > I think it is a separate bug, but I am confused right now.  There are
> > two or three separate pieces of code setting fingerings and scripts
> > according to different combinations of rules, some similar to what
> > Nick posted just now.  (Too many people write new code without looking
> > at the existing code first.)
>
> Outside of chords, articulations with an event listener are funneled off
> rhythmic events and just announced at the same time.  Inside of chords,
> they remain stuck on the individual rhythmic events which are then
> passed to the New_fingering_engraver in some manner.
>
> > Then there is the problem \thumb is different than other fingerings...
>
> We should likely try doing something about that, though.
>

Thanks!

By the way, for cello:
1. \open means "open string"
2. \0 (finger zero) sometimes is used as a synonym for open string
3. \flageolet means "touch the string at the flageolet position" - often
played with the 3rd finger; in this case, the flageolet mark resides
closest to the note head, then the finger number
4. \thumb means "played with the thumb". I suspect that it might be
combined with the flageolet sign to distinguish between stopping the string
(pressing it against the fingerboard) and touching the string with the
thumb at the desired flageolet position (typically one octave above the
open string, i.e., at the half string length a.k.a. first thumb position).
4. \harmonic is used for playing artificial harmonics by stopping the
string at a given note and touching the remainder of the string to excite
the desired harmonic (e.g. a fourth above the stopped note). The harmonic
sign can be accompanied by a finger number.

I have a strong suspicion that the same applies to other bowed string
instruments, but I can't state this with full confidence since I'm only
familiar with cello (playing) and violin/viola/double bass from reading
their sheet music.


>  > It seems if we give Fingerings and StringNumbers different
> > script-priorities by default, as David suggested, it would render a
> > lot of this (buggy) code moot.
>
> I am not sure this would cure the double-engraver scenario, but it might
> make some sense trying to at least make both engravers use the same kind
> of tie-breaking in comparable situations.
>

The main problem I see is that /maybe/ some "articulations" behave
differently for different instruments. The most remarkable example being
the classical guitar (with p/i/f/a fingering) versus cello.

How about creating a system similar to the drumset definition for assigning
the proper per instrument priorities to these scripts?

Best regards,

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

Re: Writing to the console (debug info)

[Eric Pancer]

On Dec 14, 2012, at 17:05, Olivier Biot  wrote:

> Hi all,
> 
> Is there a way to write text to the console in LilyPond?
> 
> I'd like to display the file currently processed to keep track of problems on 
> a 60 part etude


Use a "-v" flag when running it in Terminal. 
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Harmonic Analysis

[David Nalesnik]

Hi Mark,

On Fri, Dec 14, 2012 at 5:01 PM, Mark Stephen Mrotek
 wrote:
> Mr. Kastrup:
>
> Following your suggestion, the code for "/rN.ly" was included in the coding
> of the piece for which I was doing the harmonic analysis.

I think you mean me, David Nalesnik.

> It work easily.
> And its inclusion brought up two additional questions. I wanted to query the
> contributor, "MS," yet the e-mail address was withheld.

That's Mike Solomon in another thread, who was passing along a snippet
from the LSR.  (In the near future, I'll be updating the LSR with the
new code you're now using.)  But I can certainly answer your questions
here!

>
> 1. Since the symbols are connected, by Lyric mode, to the pitches in the
> bass, how can harmonies that change without a change in the bass be
> identified, e.g., another voice moves to create a "7th?"
> 2. Sometimes the bass moves yet the harmony does not, e.g., bass has a
> "passing" tone. How can a "blank" be put in under that pitch?
>
> Thank you for your kind attention.

Well, it's possible to give lyric syllables durations, so they aren't
tied to the note values in the line you're attaching the lyrics to.
This question came up in conjunction with analysis symbols in that
other thread, so I'll just point you to a relevant message.  My reply
to the earlier question also includes a link to the Notation Reference
about ways to align lyrics.

http://www.mail-archive.com/lilypond-user@gnu.org/msg75967.html

Hope this helps!

-David

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

Re: Fast generation of png files

[Eluze]

Piotr Tokarski wrote
> Hi!
> I would like to ask how to generate a png file in a minimal time. I
> tried to use " -dpreview -dno-print-pages " options, but from
> "test.ly" file, it produced "test.pdf"," test..preview.pdf" and
> "test.preview.png" files. I think if I could skip the pdf files, the
> generating time could be shorter.

have a look at
http://www.lilypond.org/doc/v2.17/Documentation/usage/command_002dline-usage#basic-command-line-options-for-lilypond

it tells how to specify which format to use and going on to
http://www.lilypond.org/doc/v2.17/Documentation/usage/command_002dline-usage#advanced-command-line-options-for-lilypond
(which you seem to have found already) how to suppress the regular output.

hth
Eluze





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Fast-generation-of-png-files-tp137693p137711.html
Sent from the User mailing list archive at Nabble.com.

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

Writing to the console (debug info)

[Olivier Biot]

Hi all,

Is there a way to write text to the console in LilyPond?

I'd like to display the file currently processed to keep track of problems
on a 60 part etude.

Best regards,

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

RE: Harmonic Analysis

[Mark Stephen Mrotek]

Mr. Kastrup:

Following your suggestion, the code for "/rN.ly" was included in the coding
of the piece for which I was doing the harmonic analysis. It work easily.
And its inclusion brought up two additional questions. I wanted to query the
contributor, "MS," yet the e-mail address was withheld.

1. Since the symbols are connected, by Lyric mode, to the pitches in the
bass, how can harmonies that change without a change in the bass be
identified, e.g., another voice moves to create a "7th?"
2. Sometimes the bass moves yet the harmony does not, e.g., bass has a
"passing" tone. How can a "blank" be put in under that pitch?

Thank you for your kind attention.

Mark Stephen Mrotek

-Original Message-
From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of
David Kastrup
Sent: Saturday, December 08, 2012 10:37 PM
To: lilypond-user@gnu.org
Subject: Re: Harmonic Analysis

David Nalesnik  writes:

> Hi Mark,
>
> On Sat, Dec 8, 2012 at 7:29 PM, Mark Stephen Mrotek 
>  wrote:
>
>> The function for creating Roman numerals for harmonic analysis is 
>> given (at
>> http://lsr.dsi.unimi.it/LSR/Item?id=710) as:
>
> Here I'd suggest that you use the (considerably) updated version of 
> this file found here:
> http://www.mail-archive.com/lilypond-user@gnu.org/msg69861/rN.ly

Might be worth copying the second over the first?

--
David Kastrup


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


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

Re: Manually aligning notes

[Thomas Morley]

2012/12/14 Hilary Snaden :
> I need to move the last d in this snippet to the *right* to avoid it
> colliding with the fis4 in the other voice. Inserting something like "\once
> \override NoteColumn #'force-hshift = #2" after the tie doesn't move it at
> all. Is there a way of moving it?
>
> << { \stemDown fis2 _~ fis4 e } \\ { d2 ~ d } >>
>
> --
> Hilary

Perhaps:

<< { \stemDown fis2 _~ \shiftOn fis4 e } \\ { d2 ~ d } >>

But there's still a warning about:
warning: ignoring too many clashing note columns


HTH,
  Harm

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

Re: Manually aligning notes

[Eluze]

Hilary Snaden wrote
> I need to move the last d in this snippet to the *right* to avoid it 
> colliding with the fis4 in the other voice. Inserting something like 
> "\once \override NoteColumn #'force-hshift = #2" after the tie doesn't 
> move it at all. Is there a way of moving it?
> 
> << { \stemDown fis2 _~ fis4 e } \\ { d2 ~ d } >>

you have to enable shifting:

<< { \stemDown \shiftOn fis2 _~ fis4 e } \\ { d2 ~ d } >>

see the NR for details on how \voicexxx are handled.

hth

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Manually-aligning-notes-tp137703p137706.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Manually aligning notes

[Trevor Daniels]

Hilary Snaden wrote Friday, December 14, 2012 10:12 PM

>I need to move the last d in this snippet to the *right* to avoid it 
> colliding with the fis4 in the other voice. Inserting something like 
> "\once \override NoteColumn #'force-hshift = #2" after the tie doesn't 
> move it at all. Is there a way of moving it?
> 
> << { \stemDown fis2 _~ fis4 e } \\ { d2 ~ d } >>

Well, adding \shiftOn will do it:

<< { \stemDown \shiftOn fis2 _~ fis4 e } \\ { d2 ~ d } >>

but is this choice of voices optimum?

Trevor

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

RE: Full bar rests in single-staff polyphony

[Daniel Rosen]

No answer... should I send this to the bug list as a feature request? Here's an 
example:

\version "2.16.1"
\new Staff <<
  \new Voice { \time 3/4 \voiceOne e' e' e' }
  \new Voice { \voiceTwo R1*3/4 }
>>

DR

-Original Message-
From: Daniel Rosen 
Sent: Thursday, December 13, 2012 10:00 AM
To: lilypond-user@gnu.org
Subject: Full bar rests in single-staff polyphony

>From a list conversation 
>(http://lilypond.1069038.n5.nabble.com/Full-bar-rests-in-multi-voiced-piano-scores-question-and-a-suggestion-td29115.html#a29121)
> from 2008:

"So far, there's no automatic support in LilyPond to avoid collisions between 
multi-measure rests and other objects."

Is this still the case? If so, is there a reason that this feature can't be 
added?

DR

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

Manually aligning notes

[Hilary Snaden]

I need to move the last d in this snippet to the *right* to avoid it 
colliding with the fis4 in the other voice. Inserting something like 
"\once \override NoteColumn #'force-hshift = #2" after the tie doesn't 
move it at all. Is there a way of moving it?


<< { \stemDown fis2 _~ fis4 e } \\ { d2 ~ d } >>

--
Hilary

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

Re: \crossStaff and \stemDown

[Eluze]

Thomas Morley wrote
> Because \voiceThree has \shiftOn enabled.

exactly - so another solution is (keeping the "natural" order of voices):

\new PianoStaff <<
  \new Staff <<
\new Voice {
  \voiceOne \shiftOn
  g''4
}
\new Voice {
  \voiceThree  \shiftOff
  < b d'>8 [ < b d'>8 ]
}
  >>
  \new Staff {
\clef bass
\new Voice {
  \voiceOne 
  \crossStaff { 8 8 }
}
  }
>>

… and playing with \shiftOn/\shiftoff you can control which notes are
cross-staffed!

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/crossStaff-and-stemDown-tp137487p137699.html
Sent from the User mailing list archive at Nabble.com.

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

Re: \crossStaff and \stemDown

[Thomas Morley]

2012/12/14 Eluze :
> ornello wrote
>> So the problem of my original fragment seems to be related to adding
>> another voice in one of the staves. Here is another example:
>>
>> {
>>   \new PianoStaff <<
>> \new Staff <<
>>   \new Voice {
>> \voiceOne
>> g''4
>>   }
>>   \new Voice {
>> \voiceTwo
>> \stemUp
>> < b d'>8 [ < b d'>8 ]
>>   }
>> >>
>> \new Staff {
>>   \clef bass
>>   \new Voice {
>> \voiceOne
>> \crossStaff {
>> 
>> 8
>> 
>> 8 }
>>   }
>> }
>>   >>
>> }
>>
>> Seems that I can not prevent the stem from going up to voice 1 of the
>> upper staff. But this is not surprising because the cross-staff
>> information is only given in the lower staff, so it is unclear whether the
>> stem should be connected to voice one or to voice two in the upper staff.
>
> here is a working example (but don't ask why!):
>

Because \voiceThree has \shiftOn enabled.


> \new PianoStaff <<
>   \new Staff <<
> \new Voice {
>   \voiceThree
>   g''4
> }
> \new Voice {
>   \voiceOne
>   < b d'>8 [ < b d'>8 ]
> }
>   >>
>   \new Staff {
> \clef bass
> \new Voice {
>   \voiceOne
>   \crossStaff { 8 8 }
> }
>   }
>>>
>
> Eluze
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/crossStaff-and-stemDown-tp137487p137696.html
> Sent from the User mailing list archive at Nabble.com.
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re: \crossStaff and \stemDown

[Eluze]

ornello wrote
> So the problem of my original fragment seems to be related to adding
> another voice in one of the staves. Here is another example:
> 
> {
>   \new PianoStaff <<
> \new Staff <<
>   \new Voice {
> \voiceOne
> g''4
>   }
>   \new Voice {
> \voiceTwo
> \stemUp
> < b d'>8 [ < b d'>8 ]
>   }
> >>
> \new Staff {
>   \clef bass
>   \new Voice {
> \voiceOne
> \crossStaff { 
> 
> 8 
> 
> 8 }
>   }
> }
>   >>
> }
> 
> Seems that I can not prevent the stem from going up to voice 1 of the
> upper staff. But this is not surprising because the cross-staff
> information is only given in the lower staff, so it is unclear whether the
> stem should be connected to voice one or to voice two in the upper staff.

here is a working example (but don't ask why!):

\new PianoStaff <<
  \new Staff <<
\new Voice {
  \voiceThree
  g''4
}
\new Voice {
  \voiceOne
  < b d'>8 [ < b d'>8 ]
}
  >>
  \new Staff {
\clef bass
\new Voice {
  \voiceOne
  \crossStaff { 8 8 }
}
  }
>>

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/crossStaff-and-stemDown-tp137487p137696.html
Sent from the User mailing list archive at Nabble.com.

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

Re: beams

[Nick Payne]

On 15/12/12 01:37, Christopher Brooks wrote:


16~ [g'32 aes64 g fis g des b c fis,32]

[g e'16 d c64 b c16] c16.


Put the second "[" after the g, not before.

  16~ [g'32 aes64 g fis g des b c fis,32]
g[ e'16 d c64 b c16] c16.

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

beams

[Christopher Brooks]

When I write this, it puts the beams in another place, places a beam for the 
first group, but not the second. This is mystifying

16~ [g'32 aes64 g fis g des b c fis,32]
  [g e'16 d c64 b c16] c16.

[cid:image001.png@01CDD9DE.97A1E8B0]
Christopher Brooks LEED(r) AP
Senior consultant

ACOUSTIC DIMENSIONS
Go Beyond

direct contact
T   1.717.291.9123
E   cbro...@ad-ny.com

NEW YORK Office
T   1.914.712.1300
W acousticdimensions.com

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

lyqi link from LP web site not valid

[Nick Payne]

The link to lyqi at 
http://lilypond.org/doc/v2.17/Documentation/web/easier-editing is not 
valid (the page http://nicolas.sceaux.free.fr/lilypond/lyqi.html doesn't 
exist. The correct link now appears to be http://github.com/nsceaux/lyqi 
.


Nick

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

Re: editing

[Nick Payne]

On 15/12/12 01:49, Christopher Brooks wrote:


I have found that if I edit in Microsoft Wordpad, I can undo much 
farther back than in the lilypond editor. This is a help for stumblers 
such as myself.




There are much better editors to assist with writing lilypond code. See 
http://lilypond.org/doc/v2.17/Documentation/web/easier-editing.


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

Fast generation of png files

[Piotr Tokarski]

Hi!
I would like to ask how to generate a png file in a minimal time. I
tried to use " -dpreview -dno-print-pages " options, but from
"test.ly" file, it produced "test.pdf"," test..preview.pdf" and
"test.preview.png" files. I think if I could skip the pdf files, the
generating time could be shorter.

--
Piotr Tokarski

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

Re: Neal Morse songbook done with LilyPond

[Peter Crighton]

Thank you, Stjepan!
I have yet to see it printed, but the book should arrive at my house
in the coming days.

--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de


2012/12/13 Stjepan Horvat :
> Hey Peter..The sample looks great!
>
> On Wed, Dec 12, 2012 at 4:56 PM, Peter Crighton
>  wrote:
>>
>> All the best,
>> Peter Crighton
>>
>> --
>
>
>
> --
> Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje.
> Izreke 12:18

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

Re: brainstorming a really smart system engraver

[Kieren MacMillan]

Hello again!

I think I have the PERFECT solution to this problem, if only \quoteDuring did 
the following two things:
   1. Quoted lyrics.
   2. Observed \RemoveEmptyStaves as if the quoted portion was empty (i.e., if 
the quoted material did NOT stop a hara-kiri action).

Then, I could simply write a single line (e.g., the soprano), and \quoteDuring 
it into the other "choral unison" parts. When another (non \quoteDuring-ed) 
portion of the score demanded the "expansion" of the score to 2 or more staves, 
the \quoteDuring portion would display the appropriate notes and lyrics.

Does this make sense?
Is it possible with some existing Lilypond features, or would it require new 
features?

Thanks,
Kieren.

On 2012-Dec-14, at 08:47, Kieren MacMillan wrote:

> Hello all,
> 
> Like many people on this list, I engrave a number of choral works using 
> Lilypond. Like a smaller subset of those people, I engrave a number of large 
> and very large works (musicals, operas, extended choral works, etc.), which 
> require multiple editions (full score, pianovocal score, vocal book, etc.) 
> each with their own font sizes, system and page breaks, and so on.
> 
> There are many times when two or more of my vocal or choral lines share 
> material — for example, in my "Wither's Carol", the entire first verse (with 
> the exception of a single two-measure chunk) is in "choral unison" (meaning 
> everyone singing the same notes and words in their own usual octave) — 
> whereas there are other very contrapuntal sections where material is totally 
> independent. Hence, there are sections where a score COULD be adequately 
> represented using only 1 choral staff, and other sections that require 2 or 3 
> or 4 (or even more) independent staves.
> 
> Ultimately, I would like to have Lilypond choose the correct number of staves 
> so that horizontal and vertical spacing is optimal, using partcombine (or 
> 'partexplode'?), cueing, etc., to accomplish its task.
> 
> I realize this is an AI nightmare and well outside Lilypond's current scope. 
> So as a half-measure, I would love to be able to tag certain sections as 
> "requires X staves", and then have Lilypond choose the least number of 
> required staves based on system/line breaking. As I [manually] change the 
> line breaks, the systems would automagically "expand" or "contract" as 
> necessary/possible to accommodate the new layout. Unfortunately, the current 
> tagging system is insufficient to do this, as far as I can tell.
> 
> Can anyone think of a reasonably easy way to implement this feature?
> If so, I'll be happy to sponsor it.
> 
> Thanks,
> Kieren.


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

what's the most "efficient" way of doing this?

[Kieren MacMillan]

Hello all,

Let's say I've got a series of RehearsalMark and MetronomeMark objects. I want 
them to appear at (e.g.) three places in my score:

1. Above the top staff of my score, at "full size";
2. Above the string StaffGroup (about 2/3 of the way down the score), at "3/4 
size"; and,
3. Below the last staff of my score, at "3/4 size".

My score is frenched, so the top staff will not always be the flute, the top of 
the string StaffGroup will not always be the Violin 1, and the last line will 
not always be the double basses.

I want to find the sweet spot of engraving efficiency, both for me (the least 
work) and for Lilypond (the least impact on performance). I've got two basic 
ideas on how to do this:

A.
A1. Put the RehearsalMark and MetronomeMark objects in a separate variable 
(using either skips or tags).
A2. Add this variable (only) to contexts at the appropriate points in the 
score.
A3. Add this variable to all other contexts (for parts, etc.).

B.
B1. Put the RehearsalMark and MetronomeMark objects in the main global 
variable (which also includes \time, \bar, etc.).
B2. Create a MarksOnly custom context, which only has the engravers 
necessary to show RehearsalMark and MetronomeMarks, and let it "filter out" 
everything else from the \global variable.
B3. Put the \global variable in all other contexts (for parts, etc.).

C.
C1. Move the relevant engravers from the Score context to the appropriate 
contexts in my score.
C2. Tweak the placement of the grobs as necessary.

Thoughts?

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

Re: \crossStaff and \stemDown

[ornello]

Eluze wrote
> I think the \crossStaff command (and the \autoBeamOn/Off) have to be set
> in the voice (or staff) where the stem originates, i.e. in the upper staff
> if you set \voiceTwo or \stemDown.

Ah, excellent suggestion! This is indeed symmetrical, and working:

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

{
  \new PianoStaff <<
\new Staff {
  \stemDown
  \autoBeamOff
  \crossStaff { b4 r d'16\> e'8. g8} r\!
  \autoBeamOn
  e'8 f' g'4 e'2
}
\new Staff {
  \clef bass
  \voiceOne
  \stemDown
  4 e, g16 a8. c8 d
  g8 f g4 c2
}
  >>
}

So the problem of my original fragment seems to be related to adding another
voice in one of the staves. Here is another example:

\layout {
  \context {
\Score
autoBeaming = ##f
  }
  \context {
\PianoStaff
\consists #Span_stem_engraver
  }
}

{
  \new PianoStaff <<
\new Staff <<
  \new Voice {
\voiceOne
g''4
  }
  \new Voice {
\voiceTwo
\stemUp
< b d'>8 [ < b d'>8 ]
  }
>>
\new Staff {
  \clef bass
  \new Voice {
\voiceOne
\crossStaff { 8 8 }
  }
}
  >>
}

Seems that I can not prevent the stem from going up to voice 1 of the upper
staff. But this is not surprising because the cross-staff information is
only given in the lower staff, so it is unclear whether the stem should be
connected to voice one or to voice two in the upper staff.

I believe it is not a bug but WAD. What do you think?

Dominik



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/crossStaff-and-stemDown-tp137487p137683.html
Sent from the User mailing list archive at Nabble.com.

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

editing

[Christopher Brooks]

I have found that if I edit in Microsoft Wordpad, I can undo much farther
back than in the lilypond editor. This is a help for stumblers such as
myself.

 

Christopher Brooks

violinist

925 Virginia Avenue

Lancaster, PA 17603

717-291-9123

cbro...@orpheus-acoustics.com

 

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

brackets

[Christopher Brooks]

I get it: the bracket comes after the first note to be bracketed:

 

a( b c[ d e)]

 

Not like in algebra.

 

Christopher Brooks

violinist

925 Virginia Avenue

Lancaster, PA 17603

717-291-9123

cbro...@orpheus-acoustics.com

 

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

Re: Lyrics (David Kastrup)

[David Kastrup]

"Maarten de Keijzer"  writes:

> Hi David, you wrote:
>
>>
>> You are aware that you don't _need_ to use \lyricsto or \addlyrics?
>> Just specify the duration you want in the text itself like
>>
>> \new Lyrics \lyricsmode { "And there were"1 "shepherds in"2. the4 field. }
>> 
>> If you go "one lyric per bar", then you should just need the first 1 and
> all the other strings will be of the same length automatically.
>>
>> --
>> David Kastrup
>
> Where do I have to put this part of code?
> I tried several places, but the score doesn''t compile, stating: syntax
> error, unexpected STRING \new Lyrics \lyricsmode {.

Try \lyricmode instead.

-- 
David Kastrup


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

RE: Re:Lyrics (David Kastrup)

[Maarten de Keijzer]

Hi David, you wrote:

>
> You are aware that you don't _need_ to use \lyricsto or \addlyrics?
> Just specify the duration you want in the text itself like
>
> \new Lyrics \lyricsmode { "And there were"1 "shepherds in"2. the4 field. }
> 
> If you go "one lyric per bar", then you should just need the first 1 and
all the other strings will be of the same length automatically.
>
> --
> David Kastrup

Where do I have to put this part of code?
I tried several places, but the score doesn''t compile, stating: syntax
error, unexpected STRING \new Lyrics \lyricsmode {.

Regards,
Maarten



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

markup baselines

[Kieren MacMillan]

Hello all,

What would be required to change all markups so that the baseline is the 
reference point, and extenders and descenders are ignored (or maybe assumed) 
for skyline calculations?

At least for markups that often should be on the same baseline (e.g., 
MetronomeMark), it is somewhat frustrating to have to manually tweak so that 
(e.g.,) "molto rall." in one measure and "Tempo primo" in the next measure end 
up on the same baseline.

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

brainstorming a really smart system engraver

[Kieren MacMillan]

Hello all,

Like many people on this list, I engrave a number of choral works using 
Lilypond. Like a smaller subset of those people, I engrave a number of large 
and very large works (musicals, operas, extended choral works, etc.), which 
require multiple editions (full score, pianovocal score, vocal book, etc.) each 
with their own font sizes, system and page breaks, and so on.

There are many times when two or more of my vocal or choral lines share 
material — for example, in my "Wither's Carol", the entire first verse (with 
the exception of a single two-measure chunk) is in "choral unison" (meaning 
everyone singing the same notes and words in their own usual octave) — whereas 
there are other very contrapuntal sections where material is totally 
independent. Hence, there are sections where a score COULD be adequately 
represented using only 1 choral staff, and other sections that require 2 or 3 
or 4 (or even more) independent staves.

Ultimately, I would like to have Lilypond choose the correct number of staves 
so that horizontal and vertical spacing is optimal, using partcombine (or 
'partexplode'?), cueing, etc., to accomplish its task.

I realize this is an AI nightmare and well outside Lilypond's current scope. So 
as a half-measure, I would love to be able to tag certain sections as "requires 
X staves", and then have Lilypond choose the least number of required staves 
based on system/line breaking. As I [manually] change the line breaks, the 
systems would automagically "expand" or "contract" as necessary/possible to 
accommodate the new layout. Unfortunately, the current tagging system is 
insufficient to do this, as far as I can tell.

Can anyone think of a reasonably easy way to implement this feature?
If so, I'll be happy to sponsor it.

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

Re: \crossStaff and \stemDown

[Eluze]

ornello wrote
> 
> Eluze wrote
>> well - I think originally the idea was to display chords over two staves
>> (and nothing more)!
> That is what I want to do, but with stems down. Stems up seem to work
> well. I have tried with the documentation sample, but same problem:

I think the \crossStaff command (and the \autoBeamOn/Off) have to be set in
the voice (or staff) where the stem originates, i.e. in the upper staff if
you set \voiceTwo or \stemDown.

hth
Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/crossStaff-and-stemDown-tp137487p137676.html
Sent from the User mailing list archive at Nabble.com.

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

Re: \crossStaff and \stemDown

[ornello]

Hi Eluze,

thanks for your reply.


Eluze wrote
> well - I think originally the idea was to display chords over two staves
> (and nothing more)!

That is what I want to do, but with stems down. Stems up seem to work well.
I have tried with the documentation sample, but same problem:

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

{
  \new PianoStaff <<
\new Staff {
  \stemDown
  \crossStaff {*4 r d'16\> e'8. g8} r\!
  e'8 f' g'4 e'2
}
\new Staff {
  \clef bass
  \voiceOne
  \stemDown
  \autoBeamOff
  4 e, g16 a8. c8 d
  \autoBeamOn
  g8 f g4 c2
}
  >>
}

I don't see a reason why it should not work with stems down, the solution
might be symmetrical. But I have to check the coding to see how it is
implemented. I'll send a bug/feature request report for this.

Thanks for your suggestion anyway...

Dominik



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/crossStaff-and-stemDown-tp137487p137674.html
Sent from the User mailing list archive at Nabble.com.

___
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…

[m...@mikesolomon.org]

On 14 déc. 2012, at 10:13, Arle Lommel  wrote:

> 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"  
> wrote:
> 
>> On 14 déc. 2012, at 09:31, Arle Lommel  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
>> 
> 

Hey Arle,

Several members of the bug squad are experienced in working with people to 
confirm that something is in fact a bug and write up a report.  If you have a 
suspicion that something is a bug, don't worry about if it actually is one or 
not.  The most important thing is to get the e-mail sent to the bug list - the 
worst that can happen is that we create a tracker issue and then delete it once 
we realize it's not a bug.

If, on the other hand, your question is of the nature "how do I do thing X" 
then the user list is the most appropriate.

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]

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: 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"  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

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 at http://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…

[Trevor Daniels]

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]

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

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"  wrote:

> On 14 déc. 2012, at 09:31, Arle Lommel  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…

[m...@mikesolomon.org]

On 14 déc. 2012, at 09:31, Arle Lommel  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: Forced double accidental

[David Kastrup]

David Nalesnik  writes:

> On Thu, Dec 13, 2012 at 9:30 PM, David Nalesnik
>  wrote:
>>
>> I notice that you haven't added the $ sign before offsets in the LSR
>> snippet as Harm and I advised.  Try that and I see no reason the
>> snippet shouldn't work..
>>
>
> Ah, no, I see. You did add it, but not in the right place.

Good thing it is no longer needed in current versions.

-- 
David Kastrup


___
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: 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