date:20170411

Re: Volta endings and using \set Score.repeatCommands

2017-04-11 Thread Stan Mulder

That worked Thomas. I used your next to last example because I'm not too 
worried about the midi. Thank you.


Stan


On 04/11/2017 05:22 AM, Thomas Morley wrote:

2017-04-10 3:45 GMT+02:00 Stan Mulder :

Hi group.

I'm trying to construct a certain volta ending where there is a first and
second ending, but the first ending does a D.S. to the sign, while the the
second ending is a multiple repeat for solos. I seem to have made it render
correctly, but I keep getting this error. Hopefully this is enough code:


warning: already have a volta spanner, ending that one prematurely

[64]


DSalCoda = {
   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
   \mark \markup "D.S. al Coda"
}

voltaSolos = \markup { "2, 3, 4 . . ." }

   \alternative {
 {
   s1
   \DSalCoda
   \bar "||"
 }
 {
   \set Score.repeatCommands = #(list (list 'volta voltaSolos)
'start-repeat)
   s1
   \bar ":|."
 }
   }


Stan



Hi Stan,

(1) %%%

In general, the settings accepted in the argument-list for
repeatCommands may manually create repeats with or without alternative
endings.
Drawback: \unfoldRepeats doesn't work on those manual settings. See
the following example where simple repeats are done (manually and via
\repeat volta ...):

\unfoldRepeats
\relative {
   c''1
   \set Score.repeatCommands = #'(start-repeat)
   d4 e f g
   \set Score.repeatCommands = #'(end-repeat)
   c1
   \repeat volta 2 { d,4 e f g }
}

(2) %%%

If you don't care about midi you could do the following.
Note that 'start-repeat would be used to begin a (new) repeated
section, but _not_ to start an alternative ending. Don't use it here.

\repeat volta 2 { c'1 }
\alternative {
   {
 d'1
   }
   {
 \set Score.repeatCommands =
   #(list
 'end-repeat ;; print the ending repeat-bar
 '(volta #f) ;; finish first volta
 (list 'volta voltaSolos) ;; set text for second volta
 )
 e'
   }
}

Though, in your example you don't want the closing repeat-bar, but \bar "||".
Hence 'end-repeat should be deleted and to ensure a closing first
VoltaBracket use \allowVoltaHook "||" at top-level.

Full example:

\allowVoltaHook "||"

DSalCoda = {
   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
   \mark \markup "D.S. al Coda"
}

voltaSolos = \markup { "2, 3, 4 . . ." }

\repeat volta 2 {c4 c c c }
\alternative {
   {
 c4 c c c
 \DSalCoda
 \bar "||"
   }
   {
 \set Score.repeatCommands = #(list '(volta #f) (list 'volta voltaSolos) )
 c4 c c c
 \bar ":|."
   }
}

(3) %%%

If you need unfoldRepeats, an override may fit better:

\allowVoltaHook "||"

DSalCoda = {
   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
   \mark \markup "D.S. al Coda"
}

voltaSolos = \markup { "2, 3, 4 . . ." }


voltaTxt =
 \once \override Score.VoltaBracket.before-line-breaking =
 #(lambda (grob) (ly:grob-set-property! grob 'text voltaSolos))

%\unfoldRepeats
\repeat volta 2 {c4 c c c }
\alternative {
   {
 c4 c c c
 \DSalCoda
 \bar "||"
   }
   {
   \voltaTxt
 c4 c c c
 \bar ":|."
   }
}



HTH,
   Harm




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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 18:18 schrieb Federico Bruni:
> Il giorno mar 11 apr 2017 alle 18:09, Urs Liska 
> ha scritto:
>> OTOH I may well fix this issue for Linux only, thinking that probably
>> these error reports have only come from Linux users (?).
>
> I've never experienced this issue.
> I've used Debian for several years and now Fedora since a couple of
> years almost.
>
> I used to run packages downloaded from lilypond.org, especially when I
> used Debian.
> In Fedora I'm now using the system package, because it's updated
> frequently and quickly after any dev release.

But do you also keep "old" versions around and use it through
Fresocbaldi? E.g. right now a version 2.19.41? Or do you (as I suspect)
regularly update and just use the latest available versions?

The problem will only occur when the library versions of your (current)
distro don't match those of the (older) LilyPond version.

Best
Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: "natural width" of a measure

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 21:04 schrieb tisimst:
>
>
> On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <[hidden
> email] > wrote:
>
>
>
> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
> >
> > Am 11.04.2017 um 20:36 schrieb Urs Liska:
> >> So, is there any moment in the compilation process where the
> natural,
> >> unstretched length of a measure can be calculated? It doesn't
> have to be
> >> an easily-read property and can involve calculation, but
> actually the x
> >> position of the barlines would be an easy target - *if* there's
> this
> >> magic moment in the compilation pipeline ;-)
> > Maybe you could experiment with the ly:one-line-breaking?
>
> I don't think so (only, of course, to investigate how much can be
> done
> on the internal level).
> Basically what I'm after is a ly:cheap-line-breaking mode that
> doesn't
> care at all about overall appearance or good page turns but instead
> simply places as many measures in a line as fit naturally. If then a
> line break changes and I know the natural width of the measures I can
> determine before compilation how many measures will fit on the *next*
> system.
>
>
> Does ragged-right = ##t not do what you want (at least in terms of
> displaying the natural measure widths)?

Well, it *would*. But it would require *two* compilations, one iwth
ragged-right to determine the widths and one without ragged-right to do
the actual engraving.

So, no, thanks, but it doesn't really help.

Best
Urs

>
> Best,
> Abraham 
>
> 
> View this message in context: Re: "natural width" of a measure
> 
> 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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: "natural width" of a measure

2017-04-11 Thread Urs Liska

Hi David,


Am 11.04.2017 um 22:42 schrieb David Nalesnik:
> On Tue, Apr 11, 2017 at 3:34 PM, David Nalesnik
>  wrote:
>> On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska  wrote:
>>>
>>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
 Am 11.04.2017 um 20:36 schrieb Urs Liska:
> So, is there any moment in the compilation process where the natural,
> unstretched length of a measure can be calculated? It doesn't have to be
> an easily-read property and can involve calculation, but actually the x
> position of the barlines would be an easy target - *if* there's this
> magic moment in the compilation pipeline ;-)
 Maybe you could experiment with the ly:one-line-breaking?
>>> I don't think so (only, of course, to investigate how much can be done
>>> on the internal level).
>>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>>> care at all about overall appearance or good page turns but instead
>>> simply places as many measures in a line as fit naturally. If then a
>>> line break changes and I know the natural width of the measures I can
>>> determine before compilation how many measures will fit on the *next*
>>> system.
>>>
>> But spacing depends on the sorts of durations present -- the most
>> common duration, the shortest duration.

I think I have expressed myself poorly.
I mean that after a first full engraving I would know the natural width
of a measure (as if it were typeset ragged-right). When now something
(e.g. additional notes) forces the line breaking to be changed I can
take the - known - natural widths of the following measures and
calculate which measures would fit into the next system.

>>
>> Do you mean to typeset each measure as if it's in isolation, without
>> stretching based on surrounding measures?
>>
>> For example,
>>
>> \version "2.19.59"
>>
>> \layout { ragged-right = ##t }
>>
>> {
>>   \repeat unfold 16 { c''16 }
>>   \repeat unfold 4 { c''4 }
>>   c''1
>>   c''2 c''2
>>   \repeat unfold 64 { c''64 }
>> }
>>
>> \layout {
>>   \context {
>> \Score
>> \override SpacingSpanner.common-shortest-duration = #'()
>>   }
>> }

No, I just want to know how much space a measure would need if it were
ragged-right but still have the actual engraving stretched to justified
lines.

>>
>> %%
>>
>> Alternately, you could create a \newSpacingSection every measure,
>> though this gives different values.  Don't know why.
>>
>> 
>>
>> Here's how you can determine the widths of measures.  Note that I've
>> put everything on one line, so that the \once \override of the
>> NoteHead gives access to every column in the score.  You can adjust
>> what alignment objects are used to gauge width by changing the symbol
>> in ly:paper-column::break-align-width (available as of 2.19.59).
>> Right now, it's BreakAlignment objects to give you an extent
>> considering all prefatory materials.  staff-bar would give extents of
>> the bar lines.
>>
>> \version "2.19.59"
>>
>> \paper {
>>   page-breaking = #ly:one-line-breaking
>> }
>>
>> #(define (display-measure-widths grob)
>>(let* ((sys (ly:grob-system grob))
>>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>>   (nmpcs
>>(filter
>> (lambda (elt)
>>   (and (grob::has-interface elt 'paper-column-interface)
>>(eq? #t (ly:grob-property elt 'non-musical
>> cols))
>>   (widths
>>(map
>> (lambda (c) (ly:paper-column::break-align-width c
>> '(break-alignment)))
>> nmpcs))
>>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>>   )
>>  (pretty-print widths)))
>> {
>>
>>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>>   \repeat unfold 4 { c''8. c''16}
>>   \repeat unfold 4 { c''4 }
>>   c''1
>>   c''2 c''2
>>   \repeat unfold 64 { c''64 }
>> }
>>
>> \layout {
>>   \context {
>> \Score
>> \override SpacingSpanner.common-shortest-duration = #'()
>>   }
>> }
>>
>> Hope this helps with something!
>>

I'll have to look into this tomorrow. RIght now it's too late to install
another LilyPond ...

> Oh, I should have mentioned that the function is showing the extents
> of objects held by the columns organizing barlines, clefs, key
> signatures, etc --  not measure lengths.  Finding the measures will
> involve an extra fun step.

Looking forward to that ;-)

Best
Urs

>
> David

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: How to select lyrics font?

2017-04-11 Thread Noeck

Am 11.04.2017 um 19:47 schrieb Noeck:
> PS: The links go to the 2.16 docs and I should update it!

The links are now updated to LilyPond 2.19 (+ some other improvements):
http://joramberger.de/files/lilypond_visualindex.pdf

The old version can still be found here:
http://joramberger.de/files/lilypond_visualindex_2.16.pdf

Cheers,
Joram

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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Thomas Morley

2017-04-11 17:47 GMT+02:00 N. Andrew Walsh :
> Hi Urs, List,
>
> On Tue, Apr 11, 2017 at 11:04 AM, Urs Liska  wrote:
>>
>> b) Linux, self-compiled
>>
>> I've never experienced this issue with self-compiled LilyPonds. I assume
>> this is *not* because self-compiled versions implicitly use the bundled libs
>> but because they implicitly compile against what is available in the system.
>> But if that assumption is correct I'd experience the same issue if I should
>> run a self-compiled Lilypond that has been compiled some time ago, e.g.
>> before a major Linux upgrade.
>
>
> This was my previous method, building from most recent source (which oddly
> also reported itself as a version more recent [ie, higher version number]
> than that listed on the website as the latest source). However, I am no
> longer able to get a working Lilypond via this method, because Gentoo Linux
> has dropped support for Guile-1.*. Does newer Lily work with Guile-2.*, or
> would this still be an issue?

Hi Andrew,

there are still problems with guilev2.

But you could try to checkout the experimental branch
dev/guile-v2-work, rebase it.
Though, be prepared needing to resolve some merge conflicts. I started
to insert some of them in revised versions into master.
Then you should be able to compile LilyPond with guile up to guile-2.1.14.
Ofcourse you'll likely experience some yet unknown bugs and be
prepared to experience a heavy slow down.

It would be great to have more feedback from more testers.

If Gentoo supports only the new stable guile-2.2, please ask back. I
have an admittedly brute-force patch to make it work (simply deleting
some very rare used functionality).

Cheers,
  Harm

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

Re: "natural width" of a measure

2017-04-11 Thread David Nalesnik

On Tue, Apr 11, 2017 at 3:34 PM, David Nalesnik
 wrote:
> On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska  wrote:
>>
>>
>> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>>
>>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
 So, is there any moment in the compilation process where the natural,
 unstretched length of a measure can be calculated? It doesn't have to be
 an easily-read property and can involve calculation, but actually the x
 position of the barlines would be an easy target - *if* there's this
 magic moment in the compilation pipeline ;-)
>>> Maybe you could experiment with the ly:one-line-breaking?
>>
>> I don't think so (only, of course, to investigate how much can be done
>> on the internal level).
>> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
>> care at all about overall appearance or good page turns but instead
>> simply places as many measures in a line as fit naturally. If then a
>> line break changes and I know the natural width of the measures I can
>> determine before compilation how many measures will fit on the *next*
>> system.
>>
>
> But spacing depends on the sorts of durations present -- the most
> common duration, the shortest duration.
>
> Do you mean to typeset each measure as if it's in isolation, without
> stretching based on surrounding measures?
>
> For example,
>
> \version "2.19.59"
>
> \layout { ragged-right = ##t }
>
> {
>   \repeat unfold 16 { c''16 }
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> %%
>
> Alternately, you could create a \newSpacingSection every measure,
> though this gives different values.  Don't know why.
>
> 
>
> Here's how you can determine the widths of measures.  Note that I've
> put everything on one line, so that the \once \override of the
> NoteHead gives access to every column in the score.  You can adjust
> what alignment objects are used to gauge width by changing the symbol
> in ly:paper-column::break-align-width (available as of 2.19.59).
> Right now, it's BreakAlignment objects to give you an extent
> considering all prefatory materials.  staff-bar would give extents of
> the bar lines.
>
> \version "2.19.59"
>
> \paper {
>   page-breaking = #ly:one-line-breaking
> }
>
> #(define (display-measure-widths grob)
>(let* ((sys (ly:grob-system grob))
>   (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
>   (nmpcs
>(filter
> (lambda (elt)
>   (and (grob::has-interface elt 'paper-column-interface)
>(eq? #t (ly:grob-property elt 'non-musical
> cols))
>   (widths
>(map
> (lambda (c) (ly:paper-column::break-align-width c
> '(break-alignment)))
> nmpcs))
>   (widths (sort widths (lambda (x y) (< (car x) (car y)
>   )
>  (pretty-print widths)))
> {
>
>   \once \override NoteHead.after-line-breaking = #display-measure-widths
>   \repeat unfold 4 { c''8. c''16}
>   \repeat unfold 4 { c''4 }
>   c''1
>   c''2 c''2
>   \repeat unfold 64 { c''64 }
> }
>
> \layout {
>   \context {
> \Score
> \override SpacingSpanner.common-shortest-duration = #'()
>   }
> }
>
> Hope this helps with something!
>

Oh, I should have mentioned that the function is showing the extents
of objects held by the columns organizing barlines, clefs, key
signatures, etc --  not measure lengths.  Finding the measures will
involve an extra fun step.

David

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

Re: "natural width" of a measure

2017-04-11 Thread David Nalesnik

On Tue, Apr 11, 2017 at 1:52 PM, Urs Liska  wrote:
>
>
> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>>
>> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>>> So, is there any moment in the compilation process where the natural,
>>> unstretched length of a measure can be calculated? It doesn't have to be
>>> an easily-read property and can involve calculation, but actually the x
>>> position of the barlines would be an easy target - *if* there's this
>>> magic moment in the compilation pipeline ;-)
>> Maybe you could experiment with the ly:one-line-breaking?
>
> I don't think so (only, of course, to investigate how much can be done
> on the internal level).
> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
> care at all about overall appearance or good page turns but instead
> simply places as many measures in a line as fit naturally. If then a
> line break changes and I know the natural width of the measures I can
> determine before compilation how many measures will fit on the *next*
> system.
>

But spacing depends on the sorts of durations present -- the most
common duration, the shortest duration.

Do you mean to typeset each measure as if it's in isolation, without
stretching based on surrounding measures?

For example,

\version "2.19.59"

\layout { ragged-right = ##t }

{
  \repeat unfold 16 { c''16 }
  \repeat unfold 4 { c''4 }
  c''1
  c''2 c''2
  \repeat unfold 64 { c''64 }
}

\layout {
  \context {
\Score
\override SpacingSpanner.common-shortest-duration = #'()
  }
}

%%

Alternately, you could create a \newSpacingSection every measure,
though this gives different values.  Don't know why.

Here's how you can determine the widths of measures.  Note that I've
put everything on one line, so that the \once \override of the
NoteHead gives access to every column in the score.  You can adjust
what alignment objects are used to gauge width by changing the symbol
in ly:paper-column::break-align-width (available as of 2.19.59).
Right now, it's BreakAlignment objects to give you an extent
considering all prefatory materials.  staff-bar would give extents of
the bar lines.

\version "2.19.59"

\paper {
  page-breaking = #ly:one-line-breaking
}

#(define (display-measure-widths grob)
   (let* ((sys (ly:grob-system grob))
  (cols (ly:grob-array->list (ly:grob-object sys 'columns)))
  (nmpcs
   (filter
(lambda (elt)
  (and (grob::has-interface elt 'paper-column-interface)
   (eq? #t (ly:grob-property elt 'non-musical
cols))
  (widths
   (map
(lambda (c) (ly:paper-column::break-align-width c
'(break-alignment)))
nmpcs))
  (widths (sort widths (lambda (x y) (< (car x) (car y)
  )
 (pretty-print widths)))
{

  \once \override NoteHead.after-line-breaking = #display-measure-widths
  \repeat unfold 4 { c''8. c''16}
  \repeat unfold 4 { c''4 }
  c''1
  c''2 c''2
  \repeat unfold 64 { c''64 }
}

\layout {
  \context {
\Score
\override SpacingSpanner.common-shortest-duration = #'()
  }
}

Hope this helps with something!

David

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

placement of tuplet number on broken tuplet

2017-04-11 Thread Juan Cristóbal Cerrillo

Hello,

Is there a way of changing the position of tuplet numbers in broken tuplets?
In the following example I would like to be able to displace the lower three in 
the first bar to the right.
Any suggestions?

all best,

jc

\version "2.19.57"

\layout {
  ragged-right = ##t
  \context {\Voice
\remove "Forbid_line_break_engraver"
\override Beam.breakable = ##t 
tupletFullLength = ##t
  }
}

<<
  {
\time 2/4
r4
\tuplet 3/2 {
  c'4
  \tuplet 3/2 { c' c' c' }
}
  }
  \\
  {
r2 \break
r2
  }
>>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: "natural width" of a measure

2017-04-11 Thread tisimst

On Tue, Apr 11, 2017 at 1:00 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n202184...@n5.nabble.com> wrote:

>
>
> Am 11.04.2017 um 20:46 schrieb Malte Meyn:
> >
> > Am 11.04.2017 um 20:36 schrieb Urs Liska:
> >> So, is there any moment in the compilation process where the natural,
> >> unstretched length of a measure can be calculated? It doesn't have to
> be
> >> an easily-read property and can involve calculation, but actually the x
> >> position of the barlines would be an easy target - *if* there's this
> >> magic moment in the compilation pipeline ;-)
> > Maybe you could experiment with the ly:one-line-breaking?
>
> I don't think so (only, of course, to investigate how much can be done
> on the internal level).
> Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
> care at all about overall appearance or good page turns but instead
> simply places as many measures in a line as fit naturally. If then a
> line break changes and I know the natural width of the measures I can
> determine before compilation how many measures will fit on the *next*
> system.
>

Does ragged-right = ##t not do what you want (at least in terms of
displaying the natural measure widths)?

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/natural-width-of-a-measure-tp202182p202185.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: "natural width" of a measure

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 20:46 schrieb Malte Meyn:
>
> Am 11.04.2017 um 20:36 schrieb Urs Liska:
>> So, is there any moment in the compilation process where the natural,
>> unstretched length of a measure can be calculated? It doesn't have to be
>> an easily-read property and can involve calculation, but actually the x
>> position of the barlines would be an easy target - *if* there's this
>> magic moment in the compilation pipeline ;-)
> Maybe you could experiment with the ly:one-line-breaking?

I don't think so (only, of course, to investigate how much can be done
on the internal level).
Basically what I'm after is a ly:cheap-line-breaking mode that doesn't
care at all about overall appearance or good page turns but instead
simply places as many measures in a line as fit naturally. If then a
line break changes and I know the natural width of the measures I can
determine before compilation how many measures will fit on the *next*
system.

Urs


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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: "natural width" of a measure

2017-04-11 Thread Malte Meyn



Am 11.04.2017 um 20:36 schrieb Urs Liska:
> So, is there any moment in the compilation process where the natural,
> unstretched length of a measure can be calculated? It doesn't have to be
> an easily-read property and can involve calculation, but actually the x
> position of the barlines would be an easy target - *if* there's this
> magic moment in the compilation pipeline ;-)

Maybe you could experiment with the ly:one-line-breaking?

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

"natural width" of a measure

2017-04-11 Thread Urs Liska

Hi,

is there any chance to retrieve the "natural width" of a measure after
typesetting but before the line is stretched to the full line width?

This is a rather long-term question, but it would be terrific if - upon
a compilation - I could retrieve a list of initial widths of each
measure. From this I hope to be able to determine how many concrete
measures fit in a line, so if for example adding some content requires
the current line to be broken earlier I could determine if the next line
would still fit or if that changed break has to continue for subsequent
systems.

So, is there any moment in the compilation process where the natural,
unstretched length of a measure can be calculated? It doesn't have to be
an easily-read property and can involve calculation, but actually the x
position of the barlines would be an easy target - *if* there's this
magic moment in the compilation pipeline ;-)

Thanks for any opinions, info or pointers
Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: How to select lyrics font?

2017-04-11 Thread Noeck

Hi Mirko,

in addition to the good hints and links by Kieren, there is this visual
index of contexts, graphical objects and engravers:

http://joramberger.de/files/lilypond_visualindex.pdf

It is by far not complete. But I consider it helpful in cases where you
don't know where to look at.

The red words are the contexts and they form headings of sections: all
the objects (dark blue) and engravers (light blue) in such a section are
usually in the context. The properties are then listed behind the links
to the official documentation. You can use them as

\override Context.GraphicalObject.property = value

or in \tweaks as the documentation explains.

Cheers,
Joram


PS: The links go to the 2.16 docs and I should update it!

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

RE: Multiple ossia problems

2017-04-11 Thread Mark Stephen Mrotek

Caagr98,

See
http://lilypond.org/doc/v2.18/Documentation/notation/modifying-single-staves
#ossia-staves
for the use of \context Staff = "ossia" for multiple ossiae.

Mark

-Original Message-
From: lilypond-user
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of
caag...@gmail.com
Sent: Tuesday, April 11, 2017 12:53 AM
To: lilypond-user 
Subject: Multiple ossia problems

The first ossia is extended too far to the left (due to system start).
The second is extended too far to the right (due to grace notes).
The third is cut of at the left (also due to grace notes).
The fourth has an end-barline, which I'd prefer if it didn't.

All of them are also unnecessarily placed below each other, despite there
being plenty of space above.

Is there some way to work around these issues?

```
\version "2.18.2"

ossia = \with {
\remove "Time_signature_engraver"
\remove "Clef_engraver"
fontSize = #-3
\override StaffSymbol.staff-space = #(magstep -3)
\override StaffSymbol.thickness = #(magstep -3) }

<<
\new Staff {
a4 a a a|
R1|
a4 a a a \grace {a a}|
r1|
\grace {a4 a} a a a a|
R1|
a4 a a a
\bar "|."
}
\new Devnull {
\new Staff \with \ossia { a4 a a a }
R1|
\new Staff \with \ossia { a4 a a a }
R1|
\new Staff \with \ossia { a4 a a a }
R1|
\new Staff \with \ossia { a4 a a a }
}
 >>
```

___
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: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Federico Bruni

Il giorno mar 11 apr 2017 alle 18:09, Urs Liska  ha 
scritto:
OTOH I may well fix this issue for Linux only, thinking that probably 
these error reports have only come from Linux users (?).


I've never experienced this issue.
I've used Debian for several years and now Fedora since a couple of 
years almost.


I used to run packages downloaded from lilypond.org, especially when I 
used Debian.
In Fedora I'm now using the system package, because it's updated 
frequently and quickly after any dev release.





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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 17:55 schrieb Trevor Daniels:
> Urs Liska wrote Tuesday, April 11, 2017 9:58 AM
>
>> e) Windows 
>> I can imagine this isn't an issue because everything has to be bundled 
>> anyway. 
>> But I don't know about that. Please help me by giving me that information.
> Well, I've never seen that problem running Frescobaldi under Windows Vista,
> and I frequently invoke several different LP releases, so you could be right.

Actually I can't imagine that LilyPond on Windows in some way relies on
"system libraries" but probably bundles everything anyway. So there's
reason to think it's self-contained and immune to this issue.

But on Mac the directory layout is different (from the Frescobaldi code
I assume the executable is in
"/Applications/LilyPond.app/Contents/Resources/bin"), so I don't have
any idea about it.

OTOH I may well fix this issue for Linux only, thinking that probably
these error reports have only come from Linux users (?).

Urs

>
> Trevor
>  
>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 17:47 schrieb N. Andrew Walsh:
> Hi Urs, List,
>
> On Tue, Apr 11, 2017 at 11:04 AM, Urs Liska  > wrote:
>
> b) Linux, self-compiled
>
> I've never experienced this issue with self-compiled LilyPonds. I
> assume this is *not* because self-compiled versions implicitly use
> the bundled libs but because they implicitly compile against what
> is available in the system. But if that assumption is correct I'd
> experience the same issue if I should run a self-compiled Lilypond
> that has been compiled some time ago, e.g. before a major Linux
> upgrade.
>
>
> This was my previous method, building from most recent source (which
> oddly also reported itself as a version more recent [ie, higher
> version number] than that listed on the website as the latest source).

This is not odd.
At a certain point Lily is released and gets the next version number.
This is what you can download as a release or as the source code.
The version is increased in the Git repository, and development happens
on release+1 until that is released and made public.

> However, I am no longer able to get a working Lilypond via this
> method, because Gentoo Linux has dropped support for Guile-1.*. Does
> newer Lily work with Guile-2.*, or would this still be an issue?

Yes, this is still an issue. People have successfully built LilyPond
against Guile 2, but that seems to still require patches and doesn't
work in a satisfactory way (e.g. *significant* performance issues).

>
> I'm also unfortunately not able to help in the more generic issue of
> ghostscript, because I was updating Lily fairly regularly and can't
> check your alternative case. However, for the brief window when 1) I
> still had Guile-1.* on my system and 2) had a version of ghostscript
> that differed from that packaged with Lily, this was the issue I would
> encounter. I wrote the list a couple times over this issue, I think
> back in November or so.

Yes, I think this basically is the issue I'm trying to solve with my
Frescobaldi patch.

Urs

>
> Hope that helps (though, let's be realistic here: I'm not very
> helpful, alas!),
>
> A

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Trevor Daniels

Urs Liska wrote Tuesday, April 11, 2017 9:58 AM

> e) Windows 

> I can imagine this isn't an issue because everything has to be bundled 
> anyway. 
> But I don't know about that. Please help me by giving me that information.

Well, I've never seen that problem running Frescobaldi under Windows Vista,
and I frequently invoke several different LP releases, so you could be right.

Trevor
 



---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread N. Andrew Walsh

Hi Urs, List,

On Tue, Apr 11, 2017 at 11:04 AM, Urs Liska  wrote:

> b) Linux, self-compiled
> I've never experienced this issue with self-compiled LilyPonds. I assume
> this is *not* because self-compiled versions implicitly use the bundled
> libs but because they implicitly compile against what is available in the
> system. But if that assumption is correct I'd experience the same issue if
> I should run a self-compiled Lilypond that has been compiled some time ago,
> e.g. before a major Linux upgrade.
>

This was my previous method, building from most recent source (which oddly
also reported itself as a version more recent [ie, higher version number]
than that listed on the website as the latest source). However, I am no
longer able to get a working Lilypond via this method, because Gentoo Linux
has dropped support for Guile-1.*. Does newer Lily work with Guile-2.*, or
would this still be an issue?

I'm also unfortunately not able to help in the more generic issue of
ghostscript, because I was updating Lily fairly regularly and can't check
your alternative case. However, for the brief window when 1) I still had
Guile-1.* on my system and 2) had a version of ghostscript that differed
from that packaged with Lily, this was the issue I would encounter. I wrote
the list a couple times over this issue, I think back in November or so.

Hope that helps (though, let's be realistic here: I'm not very helpful,
alas!),

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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Urs Liska

Hi David,

thank you for the feedback.


Am 11.04.2017 um 16:47 schrieb David Wright:
> On Tue 11 Apr 2017 at 11:04:14 (+0200), Urs Liska wrote:
>> I want to finally fix an issue in Frescobaldi that has bugged me for a
>> long time, but I need some information on how LilyPond behaves in
>> different installation types/contexts.
>>
>> For some time we had popping up reports about compilation failures
>> similar to this one
>>
>> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
>> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
>> -r1200 -sDEVICE=pdfwrite -sOutputFile=An-Silvia.pdf -c.setpdfwrite
>> -f/tmp/lilypond-tBFN9M)' failed (256)
>>
>> fatal error: failed files:
>> "/home/uliska/git/uliska/notensatz/an-silvia/An-Silvia.ly"
>>
>> The reason we determined is an incompatibility between LIlyPond's
>> built-in and system-provided versions of libraries (e.g. GhostScript).
>> The reason why this actually occurs as a problem is Frescobaldi's way to
>> support multiple installations: finding the executable and directly
>> invoking it instead of passing LilyPond's library path with it. So I
>> want to fix that now, but I don't know how this issue is actually
>> relevant to the different installations one may have.
> It might be worth making sure your tests include filenames containing
> spaces (perhaps even the odd Unicode char). I mentioned this in
> http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00589.html
> but I haven't pursued this; there does seem to be a quoting issue.
> I've never observed the font problem mentioned there myself.
>
>> Please give me some information about the following situations:
>>
>> a) Linux, downloaded binary release
>> Here the installation script creates a wrapper script "lilypond". This
>> includes the line "export LD_LIBRARY_PATH="
>> This is what makes LilyPond use the bundled library versions instead of
>> the system-provided ones.
>>
>> Note that invoking the "lilypond" executable without that wrapper
>> doesn't necessarily cause the failure but only when the system libs
>> don't match the bundled ones. (For this case I don't need feedback, this
>> is what I "know". The solution is to pass this path to the lilypond
>> invocation.)
> I did try to look at what was happening with this error earlier in the month
> http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00326.html
> but didn't get very far. I was looking at the places the interpreter
> sought its libraries, and how the major and minor version numbers
> affected this, but couldn't see the pattern. It may be necessary to
> divine its intentions from the source code.

Maybe there are different issues here, maybe not.
But what I can say is that one problem I have found and that my patch
hopefully fixes is that a regular LilyPond installation through the
LInux installation script creates a wrapper script, and this sets the
LD_LIBRARY_PATH to a directory inside the LilyPond installation. If the
LilyPond executable is invoked directly this doesn't take place and a
default system version will be called.

So if this system version doesn't match LilyPond's expectations there
may errors like the infamous Ghostscript one, and I think this is *not*
related to spaces or fonts (although these may raise other independent
issues).

This is not tied to any absolute LilyPond or Ghostscript versions, but
in a way to the natural aging process of your OS environment.

What my patch does is find the library path for the used LilyPond
executable and sets the LC_LIBRARY_PATH environment variable
accordingly. I successfully tested that it fixed the issue for me.
I have a 2.19.41 installation where /usr/lib/ghostscript points to 9.15
while the more recent versions point to 9.20.
gs -v shows that by default 9.20 is used on my system, and consequently
running LilyPond 2.19.41 without the explicit library path gives the
Ghostscript failure.
*With* the patch the library path points to the /usr/lib of 2.19.41, and
obviously it then correctly invokes Ghostscript 9.15.

>
>> b) Linux, self-compiled
>> I've never experienced this issue with self-compiled LilyPonds. I assume
>> this is *not* because self-compiled versions implicitly use the bundled
>> libs but because they implicitly compile against what is available in
>> the system. But if that assumption is correct I'd experience the same
>> issue if I should run a self-compiled Lilypond that has been compiled
>> some time ago, e.g. before a major Linux upgrade.
>>
>> c) Linux, distro package
>> I have no idea how packaged versions deal with that issue. Is there a
>> wrapper script too, and what does that do? (I can't install such a
>> version to test because on Debian testing there still is "no
>> installation candidate for package lilypond").
> Presumably you're running stretch where the lilypond is currently dry.

Yes.

> You're probably familiar with 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005
> I don't know if that is the reason that

Re: Ghostscipt failure 256

2017-04-11 Thread Urs Liska

Hi,


Am 05.04.2017 um 21:31 schrieb Pieter Terpstra:
> Dear people,
> With one file that i wanted to reedit today gives now a failure, it worked 
> fine in june, 2016.
>
> Will not post it here because it is 1274 lines long.
>
> The log says this:
> Layout output to `120-Arpeggios.ps'...
> Converting to `./120-Arpeggios.pdf'...
> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=612.00 
> -dDEVICEHEIGHTPOINTS=792.00 -
> dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
> -sOutputFile=./120-
> Arpeggios.pdf -c.setpdfwrite -f120-Arpeggios.ps)' failed (256)
>
> fatal error: failed files: "/home/neljor/LLP/Giuliani/Opus1/120-Arpeggios.ly"
> Exited with return code 1.
>
> Version ghostscript is 9.15, have also tried 9.20 with the same result.
> Lilypond version is  2.18.2
>
> Any ideas??


Joining only now, but I think this hasn't been brought up in this
thread: Are you running this from Frescobaldi? If now, how exactly do
you invoke/installed LilyPond?

Urs

> Thank you so much in advance!
>
> Peter
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread David Wright

On Tue 11 Apr 2017 at 11:04:14 (+0200), Urs Liska wrote:
> I want to finally fix an issue in Frescobaldi that has bugged me for a
> long time, but I need some information on how LilyPond behaves in
> different installation types/contexts.
> 
> For some time we had popping up reports about compilation failures
> similar to this one
> 
> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
> -r1200 -sDEVICE=pdfwrite -sOutputFile=An-Silvia.pdf -c.setpdfwrite
> -f/tmp/lilypond-tBFN9M)' failed (256)
> 
> fatal error: failed files:
> "/home/uliska/git/uliska/notensatz/an-silvia/An-Silvia.ly"
> 
> The reason we determined is an incompatibility between LIlyPond's
> built-in and system-provided versions of libraries (e.g. GhostScript).
> The reason why this actually occurs as a problem is Frescobaldi's way to
> support multiple installations: finding the executable and directly
> invoking it instead of passing LilyPond's library path with it. So I
> want to fix that now, but I don't know how this issue is actually
> relevant to the different installations one may have.

It might be worth making sure your tests include filenames containing
spaces (perhaps even the odd Unicode char). I mentioned this in
http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00589.html
but I haven't pursued this; there does seem to be a quoting issue.
I've never observed the font problem mentioned there myself.

> Please give me some information about the following situations:
> 
> a) Linux, downloaded binary release
> Here the installation script creates a wrapper script "lilypond". This
> includes the line "export LD_LIBRARY_PATH="
> This is what makes LilyPond use the bundled library versions instead of
> the system-provided ones.
> 
> Note that invoking the "lilypond" executable without that wrapper
> doesn't necessarily cause the failure but only when the system libs
> don't match the bundled ones. (For this case I don't need feedback, this
> is what I "know". The solution is to pass this path to the lilypond
> invocation.)

I did try to look at what was happening with this error earlier in the month
http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00326.html
but didn't get very far. I was looking at the places the interpreter
sought its libraries, and how the major and minor version numbers
affected this, but couldn't see the pattern. It may be necessary to
divine its intentions from the source code.

> b) Linux, self-compiled
> I've never experienced this issue with self-compiled LilyPonds. I assume
> this is *not* because self-compiled versions implicitly use the bundled
> libs but because they implicitly compile against what is available in
> the system. But if that assumption is correct I'd experience the same
> issue if I should run a self-compiled Lilypond that has been compiled
> some time ago, e.g. before a major Linux upgrade.
> 
> c) Linux, distro package
> I have no idea how packaged versions deal with that issue. Is there a
> wrapper script too, and what does that do? (I can't install such a
> version to test because on Debian testing there still is "no
> installation candidate for package lilypond").

Presumably you're running stretch where the lilypond is currently dry.
You're probably familiar with 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005
I don't know if that is the reason that sid (most up-to-date) still
has version 2.18.2, the same as jessie (the current stable Debian).

But anyway, the point of distro-packaged versions on Debian-style
distributions (ie non-rolling release) is that the libraries should be
consistent, with no need for wrappers. That's true for jessie and
wheezy (oldstable). So rolling-release people probably need to comment
on this separately.
 
> d) Mac
> No idea about that. How is LilyPond installed and invoked there? Is that
> compatibility an issue in the first place?
> 
> e) Windows
> I can imagine this isn't an issue because everything has to be bundled
> anyway. But I don't know about that.
> 
> Please help me by giving me that information. It is an embarrassing and
> annoying bug in Frescobaldi, and I'd like to get rid of it. Of course I
> can do it so it "works for me", but of course it should be done better.

Cheers,
David.

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

Re: How to select lyrics font?

2017-04-11 Thread Kieren MacMillan

Hi Mirko,

> thanks a lot for the many and prompt answers I received.

It’s a great list, this one!

> Kieren's suggestion works like a charm.

I’m so pleased.

> I see now that I wasn't able to find this solution myself as I didn't know 
> the name of the corresponding property (or what is it called?) in the lyrics 
> context. 
> I. e. I didn't know what the analogue of  "Staff.TimeSignature.font-name" for 
> a lyrics context is called. Is there an overview somewhere that shows all 
> property names of the different contexts?

Let’s say you’re looking in the Notation guide for lyrics stuff, e.g. 
.

At the end of each section/subsection, there is usually a “See also” section, 
which usually includes an "Internals Reference” link — in this case, there is a 
link to .

There, you will find a whole whack of information about the settings and 
parameters for the Lyrics context. (n.b. In the left-hand navigation column, 
you can also see all the other contexts.) One important thing you learn is that 
“this context creates the following layout object(s)”, which in this case 
includes LyricText 
.

There you find all of the properties and settings, either “locally” (i.e., set 
here), or available through “interfaces”, listed at the bottom. THERE, you will 
find that LyricText inherits properties from the font-interface 
.

Here — finally — you find the user-settable property called “font-name”. Which 
is what we can set, as I demonstrated.

Essentially the same chain of links can be followed from any Notation guide 
page dealing with time signatures (e.g., 
),
 leading to the analogue Staff.TimeSignature.font-name.

Eventually, when you use Lilypond for a while, you know how to get to where you 
need to go directly (without all the linking), or apply an analogous property 
immediately (because you know how property inheritance works).

Hope this helps!
Kieren.


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


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

Re: Separate Emmentaler/Fonts

2017-04-11 Thread caagr98

If it's just the alteration symbols you need, you could try just using 
the standard Unicode ones: ♩♪♫♬♭♮♯ (U+2669 to U+266F).

On 04/11/17 14:35, tisimst wrote:

Hi, Urs/Andrew/Johan!

On Tue, Apr 11, 2017 at 6:10 AM, Urs Liska [via Lilypond] <[hidden 
email] > wrote:

Am 11.04.2017 um 13:03 schrieb Johan Vromans:
> On Tue, 11 Apr 2017 12:09:41 +0200, "N. Andrew Walsh"
> <[hidden email]
> wrote:
>
>> thanks for the link. I only needed the font for specific glyphs (sharp
>> signs and the like), which I presume are individual glyphs that would
>> still work within a body of regular text, yes?
> Would Bravura be an option then?
> It's open source, very complete, SMuFl, and can be used from all standard
> software.

Doesn't the "text" part of SMuFL look like it's what one would need for
that purpose?

That's precisely what BravuraText (or any other [SMuFL]Text font) was 
designed for, so most of the glyphs are re-positioned/sized to follow 
the normal text baseline rather than their music positioning and size. 
They usually have zero-width side bearings, though, so you'll need to 
add some manual space around each symbol.

There's still the issue with actually getting the symbol as a unicode 
char. Whether you use Bravura, Emmentaler, or virtually any other 
non-Sibelius/Finale/etc. font, you'll may need to use some character 
viewer to be able to view+select+copy+paste it into your editing app. On 
the one hand, if you did want to use BravuraText, I suggest going to the 
SMuFL gitbook  which uses real 
characters at their real code points which you can select+copy+paste 
just like normal text. You just need to have a SMuFL font installed like 
BravuraText to render the character correctly. I've done that many times.

HTH,
Abraham

View this message in context: Re: Separate Emmentaler/Fonts 

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: Separate Emmentaler/Fonts

2017-04-11 Thread tisimst

Hi, Urs/Andrew/Johan!

On Tue, Apr 11, 2017 at 6:10 AM, Urs Liska [via Lilypond] <
ml-node+s1069038n202164...@n5.nabble.com> wrote:

>
>
> Am 11.04.2017 um 13:03 schrieb Johan Vromans:
> > On Tue, 11 Apr 2017 12:09:41 +0200, "N. Andrew Walsh"
> > <[hidden email] >
> wrote:
> >
> >> thanks for the link. I only needed the font for specific glyphs (sharp
> >> signs and the like), which I presume are individual glyphs that would
> >> still work within a body of regular text, yes?
> > Would Bravura be an option then?
> > It's open source, very complete, SMuFl, and can be used from all
> standard
> > software.
>
> Doesn't the "text" part of SMuFL look like it's what one would need for
> that purpose?
>

That's precisely what BravuraText (or any other [SMuFL]Text font) was
designed for, so most of the glyphs are re-positioned/sized to follow the
normal text baseline rather than their music positioning and size. They
usually have zero-width side bearings, though, so you'll need to add some
manual space around each symbol.

There's still the issue with actually getting the symbol as a unicode char.
Whether you use Bravura, Emmentaler, or virtually any other
non-Sibelius/Finale/etc. font, you'll may need to use some character viewer
to be able to view+select+copy+paste it into your editing app. On the one
hand, if you did want to use BravuraText, I suggest going to the SMuFL
gitbook  which uses real characters
at their real code points which you can select+copy+paste just like normal
text. You just need to have a SMuFL font installed like BravuraText to
render the character correctly. I've done that many times.

HTH,
Abraham

--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Separate-Emmentaler-Fonts-tp202158p202165.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: Separate Emmentaler/Fonts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 13:03 schrieb Johan Vromans:
> On Tue, 11 Apr 2017 12:09:41 +0200, "N. Andrew Walsh"
>  wrote:
>
>> thanks for the link. I only needed the font for specific glyphs (sharp
>> signs and the like), which I presume are individual glyphs that would
>> still work within a body of regular text, yes?
> Would Bravura be an option then?
> It's open source, very complete, SMuFl, and can be used from all standard
> software.

Doesn't the "text" part of SMuFL look like it's what one would need for
that purpose?

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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: Separate Emmentaler/Fonts

2017-04-11 Thread Johan Vromans

On Tue, 11 Apr 2017 12:09:41 +0200, "N. Andrew Walsh"
 wrote:

> thanks for the link. I only needed the font for specific glyphs (sharp
> signs and the like), which I presume are individual glyphs that would
> still work within a body of regular text, yes?

Would Bravura be an option then?
It's open source, very complete, SMuFl, and can be used from all standard
software.

-- Johan

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

Re: Separate Emmentaler/Fonts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 12:13 schrieb Urs Liska:
>> thanks for the link. I only needed the font for specific glyphs
>> (sharp signs and the like), which I presume are individual glyphs
>> that would still work within a body of regular text, yes?
>
> Yes, but you have to know how to find/access them in the font.

Ah, and of course probably you have to adjust the spacing

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: Separate Emmentaler/Fonts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 12:09 schrieb N. Andrew Walsh:
> Hi Urs,
>
> thanks for the link. I only needed the font for specific glyphs (sharp
> signs and the like), which I presume are individual glyphs that would
> still work within a body of regular text, yes?

Yes, but you have to know how to find/access them in the font.

>
> On Tue, Apr 11, 2017 at 12:03 PM, Urs Liska  > wrote:
>
> Of course you have to note that the fonts will not work anywhere
> outside LilyPond.
>
> Well, if you're using LaTeX (haha) you can easily make use of it
> using that package (which is also part of TeXLive (which also
> means the fonts are present in that too)).
>
>
> Well, *I* certainly use LaTeX, like a civilized person, but my
> partners in this project are philistines. I tried explaining how you
> and I proofed your paper over git, and all I got was a blank stare. I
> think the vast majority of the (text) publishing world still basically
> operates as if they're using hard copies. I throw up just thinking
> about it.

I just got a review of a paper I had to submit as a Word document. I
used styles for special content (like "composer", "work title" etc.) and
- as I usually do - colored them so I can immediately see that I have
applied the right style.

The first comment from the reviewer was to apologize for the significant
number of edits that are all marked by Word because he first "had to
remove all the colors and italics I had introduced to the text".
OMG.

Urs

>
> Cheers,
>
> A

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: Separate Emmentaler/Fonts

2017-04-11 Thread N. Andrew Walsh

Hi Urs,

thanks for the link. I only needed the font for specific glyphs (sharp
signs and the like), which I presume are individual glyphs that would still
work within a body of regular text, yes?

On Tue, Apr 11, 2017 at 12:03 PM, Urs Liska  wrote:

> Of course you have to note that the fonts will not work anywhere outside
> LilyPond.
> Well, if you're using LaTeX (haha) you can easily make use of it using
> that package (which is also part of TeXLive (which also means the fonts are
> present in that too)).
>

Well, *I* certainly use LaTeX, like a civilized person, but my partners in
this project are philistines. I tried explaining how you and I proofed your
paper over git, and all I got was a blank stare. I think the vast majority
of the (text) publishing world still basically operates as if they're using
hard copies. I throw up just thinking about it.

Cheers,

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

Re: Separate Emmentaler/Fonts

2017-04-11 Thread Urs Liska



Am 11.04.2017 um 11:58 schrieb N. Andrew Walsh:
> Hi List,
>
> quick question: is there a place online where I can download the
> Emmentaler font separately?

I don't know about Lilypond itself, but they are included here:
https://github.com/uliska/lilyglyphs/tree/master/fonts

> I'm trying to recommend it for a translation project I'm doing, and I
> don't want to start my advice with "step 1, install Lilypond" because
> these people aren't actually music typesetters.

Of course you have to note that the fonts will not work anywhere outside
LilyPond.
Well, if you're using LaTeX (haha) you can easily make use of it using
that package (which is also part of TeXLive (which also means the fonts
are present in that too)).

>
> On a side note, is fonts.openlilylib.org
>  still down? The main page still says
> "we're moving!"

this site will stay down forever, since Abraham actually has moved finally.
Abraham, you should eventually provide me with a proper redirection
page. Or should I simply do an HTTP redirect to your site?

Urs

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

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Separate Emmentaler/Fonts

2017-04-11 Thread N. Andrew Walsh

Hi List,

quick question: is there a place online where I can download the Emmentaler
font separately? I'm trying to recommend it for a translation project I'm
doing, and I don't want to start my advice with "step 1, install Lilypond"
because these people aren't actually music typesetters.

On a side note, is fonts.openlilylib.org still down? The main page still
says "we're moving!"

Cheers,

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

Re: Volta endings and using \set Score.repeatCommands

2017-04-11 Thread Thomas Morley

2017-04-10 3:45 GMT+02:00 Stan Mulder :
> Hi group.
>
> I'm trying to construct a certain volta ending where there is a first and
> second ending, but the first ending does a D.S. to the sign, while the the
> second ending is a multiple repeat for solos. I seem to have made it render
> correctly, but I keep getting this error. Hopefully this is enough code:
>
>
> warning: already have a volta spanner, ending that one prematurely
>
> [64]
>
>
> DSalCoda = {
>   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
>   \mark \markup "D.S. al Coda"
> }
>
> voltaSolos = \markup { "2, 3, 4 . . ." }
>
>   \alternative {
> {
>   s1
>   \DSalCoda
>   \bar "||"
> }
> {
>   \set Score.repeatCommands = #(list (list 'volta voltaSolos)
> 'start-repeat)
>   s1
>   \bar ":|."
> }
>   }
>
>
> Stan



Hi Stan,

(1) %%%

In general, the settings accepted in the argument-list for
repeatCommands may manually create repeats with or without alternative
endings.
Drawback: \unfoldRepeats doesn't work on those manual settings. See
the following example where simple repeats are done (manually and via
\repeat volta ...):

\unfoldRepeats
\relative {
  c''1
  \set Score.repeatCommands = #'(start-repeat)
  d4 e f g
  \set Score.repeatCommands = #'(end-repeat)
  c1
  \repeat volta 2 { d,4 e f g }
}

(2) %%%

If you don't care about midi you could do the following.
Note that 'start-repeat would be used to begin a (new) repeated
section, but _not_ to start an alternative ending. Don't use it here.

\repeat volta 2 { c'1 }
\alternative {
  {
d'1
  }
  {
\set Score.repeatCommands =
  #(list
'end-repeat ;; print the ending repeat-bar
'(volta #f) ;; finish first volta
(list 'volta voltaSolos) ;; set text for second volta
)
e'
  }
}

Though, in your example you don't want the closing repeat-bar, but \bar "||".
Hence 'end-repeat should be deleted and to ensure a closing first
VoltaBracket use \allowVoltaHook "||" at top-level.

Full example:

\allowVoltaHook "||"

DSalCoda = {
  \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
  \mark \markup "D.S. al Coda"
}

voltaSolos = \markup { "2, 3, 4 . . ." }

\repeat volta 2 {c4 c c c }
\alternative {
  {
c4 c c c
\DSalCoda
\bar "||"
  }
  {
\set Score.repeatCommands = #(list '(volta #f) (list 'volta voltaSolos) )
c4 c c c
\bar ":|."
  }
}

(3) %%%

If you need unfoldRepeats, an override may fit better:

\allowVoltaHook "||"

DSalCoda = {
  \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
  \mark \markup "D.S. al Coda"
}

voltaSolos = \markup { "2, 3, 4 . . ." }


voltaTxt =
\once \override Score.VoltaBracket.before-line-breaking =
#(lambda (grob) (ly:grob-set-property! grob 'text voltaSolos))

%\unfoldRepeats
\repeat volta 2 {c4 c c c }
\alternative {
  {
c4 c c c
\DSalCoda
\bar "||"
  }
  {
  \voltaTxt
c4 c c c
\bar ":|."
  }
}



HTH,
  Harm

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

Re: LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Urs Liska

I don't know why the previous email was formatted so badly, I'll try it
again


Hi all,

I want to finally fix an issue in Frescobaldi that has bugged me for a
long time, but I need some information on how LilyPond behaves in
different installation types/contexts.

For some time we had popping up reports about compilation failures
similar to this one

warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
-r1200 -sDEVICE=pdfwrite -sOutputFile=An-Silvia.pdf -c.setpdfwrite
-f/tmp/lilypond-tBFN9M)' failed (256)

fatal error: failed files:
"/home/uliska/git/uliska/notensatz/an-silvia/An-Silvia.ly"



The reason we determined is an incompatibility between LIlyPond's
built-in and system-provided versions of libraries (e.g. GhostScript).
The reason why this actually occurs as a problem is Frescobaldi's way to
support multiple installations: finding the executable and directly
invoking it instead of passing LilyPond's library path with it. So I
want to fix that now, but I don't know how this issue is actually
relevant to the different installations one may have.

Please give me some information about the following situations:

a) Linux, downloaded binary release
Here the installation script creates a wrapper script "lilypond". This
includes the line "export LD_LIBRARY_PATH="
This is what makes LilyPond use the bundled library versions instead of
the system-provided ones.

Note that invoking the "lilypond" executable without that wrapper
doesn't necessarily cause the failure but only when the system libs
don't match the bundled ones. (For this case I don't need feedback, this
is what I "know". The solution is to pass this path to the lilypond
invocation.)

b) Linux, self-compiled
I've never experienced this issue with self-compiled LilyPonds. I assume
this is *not* because self-compiled versions implicitly use the bundled
libs but because they implicitly compile against what is available in
the system. But if that assumption is correct I'd experience the same
issue if I should run a self-compiled Lilypond that has been compiled
some time ago, e.g. before a major Linux upgrade.

c) Linux, distro package
I have no idea how packaged versions deal with that issue. Is there a
wrapper script too, and what does that do? (I can't install such a
version to test because on Debian testing there still is "no
installation candidate for package lilypond").

d) Mac
No idea about that. How is LilyPond installed and invoked there? Is that
compatibility an issue in the first place?

e) Windows
I can imagine this isn't an issue because everything has to be bundled
anyway. But I don't know about that.

Please help me by giving me that information. It is an embarrassing and
annoying bug in Frescobaldi, and I'd like to get rid of it. Of course I
can do it so it "works for me", but of course it should be done better.

Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org

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

Re: How to select lyrics font?

2017-04-11 Thread Manuela

Ok, now I read "_lyrics_ (not markup)?" Sry for the noise



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-select-lyrics-font-tp202142p202154.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

LD_LIBRARY_PATH in different installation contexts

2017-04-11 Thread Urs Liska

Hi all,

I want to finally fix an issue in Frescobaldi that has bugged me for a
long time, but I need some information on how LilyPond behaves in
different installation types/contexts.

For some time we had popping up reports about compilation failures
similar to this one


warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
-r1200 -sDEVICE=pdfwrite -sOutputFile=An-Silvia.pdf -c.setpdfwrite
-f/tmp/lilypond-tBFN9M)' failed (256)

fatal error: failed files:
"/home/uliska/git/uliska/notensatz/an-silvia/An-Silvia.ly"

The reason we determined is an incompatibility between LIlyPond's
built-in and system-provided versions of libraries (e.g. GhostScript).
The reason why this actually occurs as a problem is Frescobaldi's way to
support multiple installations: finding the executable and directly
invoking it instead of passing LilyPond's library path with it. So I
want to fix that now, but I don't know how this issue is actually
relevant to the different installations one may have. Please give me
some information about the following situations: a) Linux, downloaded
binary release Here the installation script creates a wrapper script
"lilypond". This includes the line "export
LD_LIBRARY_PATH=" This is what makes LilyPond
use the bundled library versions instead of the system-provided ones.
Note that invoking the "lilypond" executable without that wrapper
doesn't necessarily cause the failure but only when the system libs
don't match the bundled ones. (For this case I don't need feedback, this
is what I "know". The solution is to pass this path to the lilypond
invocation.) b) Linux, self-compiled I've never experienced this issue
with self-compiled LilyPonds. I assume this is *not* because
self-compiled versions implicitly use the bundled libs but because they
implicitly compile against what is available in the system. But if that
assumption is correct I'd experience the same issue if I should run a
self-compiled Lilypond that has been compiled some time ago, e.g. before
a major Linux upgrade. c) Linux, distro package I have no idea how
packaged versions deal with that issue. Is there a wrapper script too,
and what does that do? (I can't install such a version to test because
on Debian testing there still is "no installation candidate for package
lilypond"). d) Mac No idea about that. How is LilyPond installed and
invoked there? Is that compatibility an issue in the first place? e)
Windows I can imagine this isn't an issue because everything has to be
bundled anyway. But I don't know about that. Please help me by giving me
that information. It is an embarrassing and annoying bug in Frescobaldi,
and I'd like to get rid of it. Of course I can do it so it "works for
me", but of course it should be done better. Urs

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

Re: How to select lyrics font?

2017-04-11 Thread Manuela

You may use this

\paper {
  #(define fonts
(set-global-fonts
  #:music "emmentaler"
  #:brace "emmentaler"
  #:roman "Century Schoolbook L"
  #:sans "sans-serif"
  #:typewriter "monospace"
  #:factor (/ staff-height pt 20)
  ))
}

from the Lilypond Blog
http://lilypondblog.org/2015/03/managing-alternative-fonts-with-lilypond/



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/How-to-select-lyrics-font-tp202142p202153.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

Multiple ossia problems

2017-04-11 Thread caagr98


The first ossia is extended too far to the left (due to system start).
The second is extended too far to the right (due to grace notes).
The third is cut of at the left (also due to grace notes).
The fourth has an end-barline, which I'd prefer if it didn't.

All of them are also unnecessarily placed below each other, despite 
there being plenty of space above.


Is there some way to work around these issues?

```
\version "2.18.2"

ossia = \with {
\remove "Time_signature_engraver"
\remove "Clef_engraver"
fontSize = #-3
\override StaffSymbol.staff-space = #(magstep -3)
\override StaffSymbol.thickness = #(magstep -3)
}

<<
\new Staff {
a4 a a a|
R1|
a4 a a a \grace {a a}|
r1|
\grace {a4 a} a a a a|
R1|
a4 a a a
\bar "|."
}
\new Devnull {
\new Staff \with \ossia { a4 a a a }
R1|
\new Staff \with \ossia { a4 a a a }
R1|
\new Staff \with \ossia { a4 a a a }
R1|
\new Staff \with \ossia { a4 a a a }
}
>>
```

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

Re: Volta endings and using \set Score.repeatCommands

2017-04-11 Thread Jacques Menu Muzhic

Ooops, forget the ‘Something new’…

> Le 11 avr. 2017 à 08:55, Jacques Menu Muzhic  a écrit :
> 
> 2.19.55 does not issue thie message, though:
> 
> Starting lilypond 2.19.55 [Untitled (2)]...
> Processing 
> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp9vqxhrdx/document.ly
>  '
> Parsing...
> Interpreting music...
> warning: already have a volta spanner, ending that one prematurely
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to 
> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-6CJE49'...
> Converting to `document.pdf'...
> Deleting 
> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-6CJE49'...
> Success: compilation successfully completed
> Completed successfully in 0.8 ».
> 
> Something new in 2.19.58?
> 
> JM
> 
>> Le 11 avr. 2017 à 05:41, Stan Mulder > > a écrit :
>> 
>> Mark,
>> 
>> The output looks the way I want it as I showed in a previous image 
>> attachment. It's just that  I am getting that warning, so I thought 
>> something is wrong somewhere.
>> 
>> Stan
>> 
>> 
>> On 04/10/2017 11:19 PM, Mark Stephen Mrotek wrote:
>>> Stan,
>>>  
>>> I get the same warning.
>>> What in the output do you want changed?
>>>  
>>> Mark
>>>  
>>> From: Stan Mulder [mailto:st4588...@earthlink.net 
>>> ] 
>>> Sent: Monday, April 10, 2017 8:02 PM
>>> To: Mark Stephen Mrotek  
>>> Subject: Re: Volta endings and using \set Score.repeatCommands
>>>  
>>> Mark & Jacques,
>>> 
>>> My example was not complete. But if you try this, you still get this 
>>> warning:
>>> 
>>> Interpreting music...
>>> warning: already have a volta spanner, ending that one prematurely
>>> 
>>> 
>>> 
>>> \version "2.19.58"
>>> 
>>> DSalCoda = {
>>>   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
>>>   \mark \markup "D.S. al Coda"
>>> }
>>> 
>>> voltaSolos = \markup { "2, 3, 4 . . ." }
>>> \repeat volta 2 {c4 c c c }
>>> \alternative {
>>>   {
>>> c4 c c c
>>> \DSalCoda
>>> \bar "||"
>>>   }
>>>   {
>>> \set Score.repeatCommands = #(list (list 'volta voltaSolos) 
>>> 'start-repeat)
>>> c4 c c c
>>> \bar ":|."
>>>   }
>>> }
>>> 
>>> 
>>> So I think I am doing something wrong with the Score.repeateCommands.
>>> 
>>> Stan
>>>  
>>> On 04/10/2017 12:24 PM, Mark Stephen Mrotek wrote:
>>> Jacques,
>>>  
>>> When I insert
>>> \repeat volta 2 {c1}
>>> Before the \alternative, no error messages appear.
>>>  
>>> Mark
>>>  
>>> From: lilypond-user 
>>> [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org 
>>> ] On Behalf Of 
>>> Jacques Menu Muzhic Sent: Monday, April 10, 2017 12:47 AM To: Stan Mulder 
>>>   Cc: 
>>> lilypond-user   
>>> Subject:Re: Volta endings and using \set Score.repeatCommands
>>>  
>>> Hello Stan,
>>>  
>>> Here is what I get with 2.19.55:
>>>  
>>> Starting lilypond 2.19.55 [Untitled]...
>>> Processing 
>>> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp3a9rlkcp/document.ly
>>>  '
>>> Parsing...
>>> /var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp3a9rlkcp/document.ly:9:3
>>>  : error: syntax error, unexpected \alternative
>>> \alternative {
>>> Interpreting music...
>>> Preprocessing graphical objects...
>>> Finding the ideal number of pages...
>>> Fitting music on 1 page...
>>> Drawing systems...
>>> programming error: Spanner `VoltaBracket' is not fully contained in parent 
>>> spanner. Ignoring orphaned part
>>> continuing, cross fingers
>>> Layout output to 
>>> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-gglOd2'...
>>> Converting to `document.pdf'...
>>> Deleting 
>>> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-gglOd2'...
>>> fatal error: failed files: 
>>> "/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp3a9rlkcp/document.ly
>>>  "
>>> Exited with return code 1.
>>>  
>>> Your code lacks something like:
>>>  
>>> \repeat volta 5 { … }
>>>  
>>> ahead of \alternative.
>>>  
>>> Le 10 avr. 2017 à 03:45, Stan Mulder >> > a écrit :
>>>  
>>> Hi group.
>>> I'm trying to construct a certain volta ending where there is a first and 
>>> second ending, but the first ending does a D.S. to the sign, while the the 
>>> second ending is a multiple repeat for solos. I seem to have made it render 
>>> correctly, but I keep getting this error. Hopefully this is enough code:
>>>  
>>>  
>>> warning: already have a volta spanner, ending that one prematurely
>>> [64]
>>>  
>>>  
>>> DSalCoda = {

Re: Volta endings and using \set Score.repeatCommands

2017-04-11 Thread Jacques Menu Muzhic

2.19.55 does not issue thie message, though:

Starting lilypond 2.19.55 [Untitled (2)]...
Processing 
`/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp9vqxhrdx/document.ly'
Parsing...
Interpreting music...
warning: already have a volta spanner, ending that one prematurely
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to 
`/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-6CJE49'...
Converting to `document.pdf'...
Deleting `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-6CJE49'...
Success: compilation successfully completed
Completed successfully in 0.8 ».

Something new in 2.19.58?

JM

> Le 11 avr. 2017 à 05:41, Stan Mulder  a écrit :
> 
> Mark,
> 
> The output looks the way I want it as I showed in a previous image 
> attachment. It's just that  I am getting that warning, so I thought something 
> is wrong somewhere.
> 
> Stan
> 
> 
> On 04/10/2017 11:19 PM, Mark Stephen Mrotek wrote:
>> Stan,
>>  
>> I get the same warning.
>> What in the output do you want changed?
>>  
>> Mark
>>  
>> From: Stan Mulder [mailto:st4588...@earthlink.net 
>> ] 
>> Sent: Monday, April 10, 2017 8:02 PM
>> To: Mark Stephen Mrotek  
>> Subject: Re: Volta endings and using \set Score.repeatCommands
>>  
>> Mark & Jacques,
>> 
>> My example was not complete. But if you try this, you still get this warning:
>> 
>> Interpreting music...
>> warning: already have a volta spanner, ending that one prematurely
>> 
>> 
>> 
>> \version "2.19.58"
>> 
>> DSalCoda = {
>>   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT
>>   \mark \markup "D.S. al Coda"
>> }
>> 
>> voltaSolos = \markup { "2, 3, 4 . . ." }
>> \repeat volta 2 {c4 c c c }
>> \alternative {
>>   {
>> c4 c c c
>> \DSalCoda
>> \bar "||"
>>   }
>>   {
>> \set Score.repeatCommands = #(list (list 'volta voltaSolos) 
>> 'start-repeat)
>> c4 c c c
>> \bar ":|."
>>   }
>> }
>> 
>> 
>> So I think I am doing something wrong with the Score.repeateCommands.
>> 
>> Stan
>>  
>> On 04/10/2017 12:24 PM, Mark Stephen Mrotek wrote:
>> Jacques,
>>  
>> When I insert
>> \repeat volta 2 {c1}
>> Before the \alternative, no error messages appear.
>>  
>> Mark
>>  
>> From: lilypond-user 
>> [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org 
>> ] On Behalf Of 
>> Jacques Menu Muzhic Sent: Monday, April 10, 2017 12:47 AM To: Stan Mulder 
>>   Cc: lilypond-user 
>>   Subject:Re: Volta 
>> endings and using \set Score.repeatCommands
>>  
>> Hello Stan,
>>  
>> Here is what I get with 2.19.55:
>>  
>> Starting lilypond 2.19.55 [Untitled]...
>> Processing 
>> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp3a9rlkcp/document.ly
>>  '
>> Parsing...
>> /var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp3a9rlkcp/document.ly:9:3
>>  : error: syntax error, unexpected \alternative
>> \alternative {
>> Interpreting music...
>> Preprocessing graphical objects...
>> Finding the ideal number of pages...
>> Fitting music on 1 page...
>> Drawing systems...
>> programming error: Spanner `VoltaBracket' is not fully contained in parent 
>> spanner. Ignoring orphaned part
>> continuing, cross fingers
>> Layout output to 
>> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-gglOd2'...
>> Converting to `document.pdf'...
>> Deleting 
>> `/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T//lilypond-gglOd2'...
>> fatal error: failed files: 
>> "/var/folders/jc/xrpy67_x6_vcjfzpzds_9_6mgn/T/frescobaldi-9sn6c32v/tmp3a9rlkcp/document.ly
>>  "
>> Exited with return code 1.
>>  
>> Your code lacks something like:
>>  
>> \repeat volta 5 { … }
>>  
>> ahead of \alternative.
>>  
>> Le 10 avr. 2017 à 03:45, Stan Mulder > > a écrit :
>>  
>> Hi group.
>> I'm trying to construct a certain volta ending where there is a first and 
>> second ending, but the first ending does a D.S. to the sign, while the the 
>> second ending is a multiple repeat for solos. I seem to have made it render 
>> correctly, but I keep getting this error. Hopefully this is enough code:
>>  
>>  
>> warning: already have a volta spanner, ending that one prematurely
>> [64]
>>  
>>  
>> DSalCoda = {   \once \override Score.RehearsalMark.self-alignment-X = #RIGHT 
>>   \mark \markup "D.S. al Coda" }
>> voltaSolos = \markup { "2, 3, 4 . . ." }
>>   \alternative { {   s1   \DSalCoda   \bar "||" } {  
>>  \set Score.repeatCommands = #(list (list 'volta voltaSolos) 
>> 'start-repeat)   s1   \bar ":|." }   }
>> Stan
>>

41 matches

Mail list logo