date:20160602

Re: Hiding empty staves

2016-06-02 Thread Jacques Menu Muzhic

Hello Andrew,

From a previous thread:


%%%

\version "2.19.25"

%{
\RemoveEmptyStaves does not work primarily because \PianoStaff has the
Keep_alive_together_engraver.  You should remove that one (or not use
\PianoStaff) and then invoke only the second Staff as

\new Staff \with { \RemoveEmptyStaves } { ... }

I have a harp score where there are a lot of lines that require only the upper 
staff. How can I suppress the lower staff in lines where it is empty


If you don't want to retain the upper Staff with rests only when the
lower Staff has notes, things are a bit more tricky.

Basically, you'll
arrange to have your whole PianoStaff removed on demand, give it a
remove-layer of #0 but put _another_ copy of the first Staff (better
though a rest-only variant of it) in parallel with the PianoStaff,
giving it a remove-layer of #1.  That way it will only survive into the
final score when both staves in the PianoStaff will die.
%}

%\new PianoStaff
<<
  \new Staff \relative c' {
\repeat unfold 5 { c4 e g c }
\repeat unfold 12 { c2 a }
\repeat unfold 20 { R1 }
\repeat unfold 10 { c2 a }
\repeat unfold 8 { c,4 e g c }
  }

  \new Staff \with { \RemoveEmptyStaves }
  \relative c {
\clef bass
\repeat unfold 5 { c4 e g c }
\repeat unfold 42 s1
\repeat unfold 8 { c,4 e g c }
  }
>>

\layout {
  \context {
%\Staff \RemoveEmptyStaves
  }
}

%%%

> Le 3 juin 2016 à 07:54, Malte Meyn  a écrit :
> 
> 
> 
> Am 03.06.2016 um 06:39 schrieb David Wright:
>> On Thu 02 Jun 2016 at 21:14:17 (-0400), Andrew Bernard wrote:
>>> I have a two stave piece using a PianoStaff. In some sections I need to
>>> hide the unused lower stave for a number of bars. Using \RemoveEmptyStaves
>>> or \RemoveAllmptyStaves does nothing. There are only spacer rests in the
>>> staff in question.
>>> 
>>> The NR in Section A.20 says these functions 'Remove staves which are
>>> considered to be empty according to the list of interfaces set by
>>> keepAliveInterfaces, including those in the first system.’ But what does it
>>> mean for a staff to be considered empty?
> 
> This is how keepAliveInterfaces is defined:
> 
> keepAliveInterfaces = #'(
>bass-figure-interface
>chord-name-interface
>cluster-beacon-interface
>fret-diagram-interface
>lyric-syllable-interface
>note-head-interface
>tab-note-head-interface
>lyric-interface
>percent-repeat-item-interface
>percent-repeat-interface
>;; need this, as stanza numbers are items, and appear only once.
>stanza-number-interface
>  )
> 
> A Staff which doesn’t contain items of these types is removed (f. e. a Staff 
> only containig rests, spacer rests, but also key changes and some other 
> things).
> 
>> AFAICT just change PianoStaff to GrandStaff. I think I see the logic
>> in LP's behaviour.
> 
> PianoStaff is an alias for GrandStaff except that it contains the 
> Keep_alive_together_engraver. So using a GrandStaff should be the same as 
> PianoStaff \with { \remove Keep_alive_together_engraver }
> 
> This can be found in the Internals Reference and in the file engraver-init.ly.
> 
> ___
> 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: Hiding empty staves

2016-06-02 Thread Malte Meyn




Am 03.06.2016 um 06:39 schrieb David Wright:

On Thu 02 Jun 2016 at 21:14:17 (-0400), Andrew Bernard wrote:

I have a two stave piece using a PianoStaff. In some sections I need to
hide the unused lower stave for a number of bars. Using \RemoveEmptyStaves
or \RemoveAllmptyStaves does nothing. There are only spacer rests in the
staff in question.

The NR in Section A.20 says these functions 'Remove staves which are
considered to be empty according to the list of interfaces set by
keepAliveInterfaces, including those in the first system.’ But what does it
mean for a staff to be considered empty?


This is how keepAliveInterfaces is defined:

keepAliveInterfaces = #'(
bass-figure-interface
chord-name-interface
cluster-beacon-interface
fret-diagram-interface
lyric-syllable-interface
note-head-interface
tab-note-head-interface
lyric-interface
percent-repeat-item-interface
percent-repeat-interface
;; need this, as stanza numbers are items, and appear only once.
stanza-number-interface
  )

A Staff which doesn’t contain items of these types is removed (f. e. a 
Staff only containig rests, spacer rests, but also key changes and some 
other things).



AFAICT just change PianoStaff to GrandStaff. I think I see the logic
in LP's behaviour.


PianoStaff is an alias for GrandStaff except that it contains the 
Keep_alive_together_engraver. So using a GrandStaff should be the same 
as PianoStaff \with { \remove Keep_alive_together_engraver }


This can be found in the Internals Reference and in the file 
engraver-init.ly.


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

Re: Hiding empty staves

2016-06-02 Thread David Wright

On Thu 02 Jun 2016 at 21:14:17 (-0400), Andrew Bernard wrote:
> I have a two stave piece using a PianoStaff. In some sections I need to
> hide the unused lower stave for a number of bars. Using \RemoveEmptyStaves
> or \RemoveAllmptyStaves does nothing. There are only spacer rests in the
> staff in question.
> 
> The NR in Section A.20 says these functions 'Remove staves which are
> considered to be empty according to the list of interfaces set by
> keepAliveInterfaces, including those in the first system.’ But what does it
> mean for a staff to be considered empty?

AFAICT just change PianoStaff to GrandStaff. I think I see the logic
in LP's behaviour.

Cheers,
David.

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

Re: Is there a fairly uncomplicated way of stretching out the word crescendo...

2016-06-02 Thread tisimst

Mike,

On Thu, Jun 2, 2016 at 7:07 PM, Mike Dean [via Lilypond] <
ml-node+s1069038n191323...@n5.nabble.com> wrote:

> ... over seven measures with dashes engraved as necessary.
> I'm not sure how easily I can find that in the snippet repository...
>

Here's a post with a solution I came up with a while back. You have to
manually determine where to place the syllables you want to space out, but
it's pretty straightforward:

http://leighverlag.blogspot.com/2014/11/long-broken-de-crescendo-text.html

There has been some EXCELLENT work to make this (more) automated, but I
can't remember it off the top of my head at the moment.

HTH,
Abraham

--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Is-there-a-fairly-uncomplicated-way-of-stretching-out-the-word-crescendo-tp191323p191325.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

Hiding empty staves

2016-06-02 Thread Andrew Bernard

I have a two stave piece using a PianoStaff. In some sections I need to
hide the unused lower stave for a number of bars. Using \RemoveEmptyStaves
or \RemoveAllmptyStaves does nothing. There are only spacer rests in the
staff in question.

The NR in Section A.20 says these functions 'Remove staves which are
considered to be empty according to the list of interfaces set by
keepAliveInterfaces, including those in the first system.’ But what does it
mean for a staff to be considered empty?


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

Is there a fairly uncomplicated way of stretching out the word crescendo...

2016-06-02 Thread Mike Dean

... over seven measures with dashes engraved as necessary.
I'm not sure how easily I can find that in the snippet repository...
thanks.
Mike Dean
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Slur technique comparison

2016-06-02 Thread Flaming Hakama by Elaine

In case anyone is curious as to how modifying Slur grob properties compares
to using the \shapeII command in openlilylib, below is an exploratory
comparative document.

It is based on the document in opellilylib
snippets/notation-snippets/shaping-bezier-curves/shapeII-example.ly

(You'll need to download openlilylib if you want to compile this.)


The more I wrangle with modifying grob properties, I see that it is not
quite a satisfying interface.

The units used do not feel "linear" and the interactions among the
properties can be sensitive.

And some types of problems like collisions with accidentals can't really be
addressed without severe compromises in other parts of the shape.

Also, I noticed quite a difference in output between 2.17.29 (what
openlilylib docs reference) and 2.19.15.


Regardless, I think that it is an interesting comparison.  You can
certainly get improved output on these problem curves (but not hand-crafted
precision) without using a library.



\version "2.19.15"

\include "shapeII.ily"
\include "special-cpts-display.ily"

\paper {
  ragged-right = ##t
  indent = 0
  top-markup-spacing #'basic-distance = #5
}

\header {
  title = \markup \column {
\vspace #2
"Adjusting slurs and ties in LilyPond"
\vspace #1
  }
  subtitle = "Comparing improvements in \shape to modifying Slur grob
properties"
}


%%
\markup \vspace #2
\markup\large\bold "Introduction"
\markup \vspace #1

\markup \vspace #0.5
\markup \justify {
  Comparing the effects of the "shapeII" function to modifying Slur grob
properties.
}
\markup \vspace #0.5
\markup\small\typewriter\column {
"\override Slur.height-limit = 2   % default"
"\override Slur.ratio = 0.36   % default"
"\override Slur.details.free-head-distance = 0.3   % default"
}
\markup \vspace #0.5
\markup \justify {
  Here's a case where default LilyPond slur looks ugly:
}
\markup \vspace #0.5
\markup\small\typewriter\column {
  "\relative c'' {"
  "  d4( d' b g g,8 f' e d c2)"
  "}"
}
\relative c'' {
  d4( d' b g g,8 f' e d c2)
}
\markup \justify {
  We begin by moving the control points towards the note heads.
}
\markup \vspace #0.5
\markup \justify {
  For the "\shape" approach, this means moving first and last
control-points 2.3 staffspaces downward.
}
\markup \vspace #0.5
\markup \justify {
  For the grob properties approach, this means setting free-head-distance
to something larger, like 0.86.
}
\markup \vspace #0.5

\markup\small\typewriter\column {
  "\relative c'' {\relative c'' {"
  "  \shape #'((0 . -2.3)"
  "(0 . 0)  "
  "(0 . 0)  "
  "(0 . -2.3)) Slur \override
Slur.details.free-head-distance = 0.86"
  "  d4( d' b g g,8  f' e d c2) d4( d' b g g,8  f' e d c2)"
  "}  }"
}
\relative c'' {
  \shape #'((0 . -2.3)(0 . 0)(0 . 0)(0 . -2.3)) Slur
  d4( d' b g g,8  f' e d c2)
  \override Slur.details.free-head-distance = 0.86
  d4( d' b g g,8  f' e d c2)
}
\markup \justify {
  The ends of the slur are now correct, but the middle is wrong.
}
\markup \vspace #0.5
\markup \justify {
  For the "\shape" approach, we move 2nd control-point "1 staffspace" "to
the" left and
  "3 staffspaces up," and the 3rd point 2 staffspaces to the left.
}
\markup \vspace #0.5
\markup \justify {
  For the grob properties approach, we flatten the curve by reducing the
height-limit.
}
\markup \vspace #0.5
\markup\small\typewriter\column {
  "  \shape #'((0  . -2.3)"
  "(-1 . 3)"
  "(-2 . 0)  \override Slur.height-limit = 0.1"
  "(0  . -2.3)) Slur \override
Slur.details.free-head-distance = 0.86"
}
\markup \vspace #0.7
\relative c'' {
  \shape #'((0 . -2.3)(-1 . 3)(-2 . 0)(0 . -2.3)) Slur
  d4( d' b g g,8  f' e d c2)
  \override Slur.height-limit = 0.1
  %\override Slur.ratio = 0.01
  \override Slur.details.free-head-distance = 0.86
  d4( d' b g g,8  f' e d c2)
}

\markup \vspace #1
%%
\markup\large\bold "Epilogue"
\noPageBreak
\markup \vspace #0.5
\noPageBreak
\markup \vspace #0.5
\markup \justify {
  Take this example: first two measures are two nearly identical phrases
  (the difference is just one accidental) which get two drastically
different
  slur shapes by default. 3rd measure contains the same phrase as the 2nd,
  but with changed spacing – again we get a different default slur
  (as of LilyPond 2.17.30):
}
\markup \vspace #0.5

SUp = \change Staff = "up"
SDn = \change Staff = "down"

\new PianoStaff <<
  \new Staff = up \relative d {
\clef G
\key e \major
\time 3/16

\voiceTwo
\slurUp

\SDn \times 2/3 { b32( g' b }
\SUp \times 2/3 { d g e' }
\times 2/3 { d b g') }
|
\SDn \times 2/3 { b,,,32( g' b }
\SUp \times 2/3 { dis g e' }

Re: Embedding LilyPond in iOS app?

2016-06-02 Thread SNIPER36

Thanks to everyone in the thread for the input, I'm looking in to Verovio
and it should suit my needs just fine. But now I need to find a project to
use Lilypond with because it's just an amazing tool. I had a feeling it was
too complex to actually run on iOS but thought I'd ask. Thanks again!
John

On Mon, May 30, 2016 at 12:27 AM, Urs Liska [via Lilypond] <
ml-node+s1069038n191147...@n5.nabble.com> wrote:

>
>
> Am 30.05.2016 um 00:48 schrieb RonH:
> > But according to the LilyPond web site, this app was made with LilyPond:
> >
> > http://etudeapp.com/
> >
> > Doesn't that imply that it can be embedded in iOS?
>
> No, not at all. If that app shows music engraved with LilyPond that's
> great. But as far as their website tells the app doesn't do *any*
> engraving on its own, it just *displays* scores and allows some
> interaction with it (highlighting current beat). Other than the Henle
> app discussed recently this app doesn't even allow resizing of the
> scores (they present that as a feature: it's already sized perfectly for
> the iPad, so no resizing required ...).
>
> Urs
>
> >
> > RonH
> >
> >
> >
> > --
> > View this message in context:
> http://lilypond.1069038.n5.nabble.com/Embedding-LilyPond-in-iOS-app-tp190782p191141.html
> > Sent from the User mailing list archive at Nabble.com.
> >
> > ___
> > lilypond-user mailing list
> > [hidden email] 
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> ___
> lilypond-user mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Embedding-LilyPond-in-iOS-app-tp190782p191147.html
> To unsubscribe from Embedding LilyPond in iOS app?, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Embedding-LilyPond-in-iOS-app-tp190782p191317.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: Harmonic notehead style

2016-06-02 Thread Paul


On 06/01/2016 10:03 AM, Andrew Bernard wrote:
Thanks so much for this. That has given me the impetus and 
understanding to code my solution. 


Glad to help.
In your context you are using an engraver, so you simply omit the 
notehead styles such as harmonic. In my case, I am overriding the 
notehead stencil to draw my own custom shapes, and so what I do now is 
to check when the style is ‘harmonic and provide my own drawing 
routine for that, rather than omitting it. This is really perfect, 
because the whole point of my custom override is to generate a very 
particular look and feel for my composer’s noteheads, and other 
stylistic appearance considerations.


Sounds good!  Just to clarify (in case anyone is reading that 
closely)... this custom engraver doesn't "omit" the harmonic noteheads, 
but rather leaves them unchanged.  They are drawn with the default 
harmonic note head stencil.  (Maybe that's what you meant?)


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

Re: using variable within make-pango-font-tree

2016-06-02 Thread David Kastrup

menelikke  writes:

> Hi
>
> does anybody knows if and how is possibile to use a variable within
> "make-pango-font-tree" function, please?
>
> I'm using
>
> \version "2.18.2"  % necessary for upgrading to future LilyPond versions.
> \include "global.ly"
> \paper {
>   #(define fonts
>  (make-pango-font-tree  \docfont 
> "Arial"   
>   "Arial"
> (/ staff-height pt 25)
>  )
>)
> .
> .
>
> where docfont is a variable defined as
>
> docfont = "Papyrus"
>
> in the external "global.ly" file.
>
> Using that i get a "GUILE" error at expression starting from here
>   #
>(define fonts
>
> Please note that 
> docfont = "\"Papyrus\""
> doesn't work too. 

You are in Scheme already within the define, so you just need to write
docfont instead of \docfont here.

-- 
David Kastrup

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

using variable within make-pango-font-tree

2016-06-02 Thread menelikke

Hi

does anybody knows if and how is possibile to use a variable within
"make-pango-font-tree" function, please?

I'm using

\version "2.18.2"  % necessary for upgrading to future LilyPond versions.
\include "global.ly"
\paper {
  #(define fonts
 (make-pango-font-tree  \docfont 
"Arial"   
"Arial"
(/ staff-height pt 25)
 )
   )
.
.

where docfont is a variable defined as

docfont = "Papyrus"

in the external "global.ly" file.

Using that i get a "GUILE" error at expression starting from here
  #
   (define fonts

Please note that 
docfont = "\"Papyrus\""
doesn't work too. 

Thanks 



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

Re: Hiding empty staves

Re: Hiding empty staves

Re: Hiding empty staves

Re: Is there a fairly uncomplicated way of stretching out the word crescendo...

Hiding empty staves

Is there a fairly uncomplicated way of stretching out the word crescendo...

Slur technique comparison

Re: Embedding LilyPond in iOS app?

Re: Harmonic notehead style

Re: using variable within make-pango-font-tree

using variable within make-pango-font-tree

11 matches

Site Navigation

Mail list logo

Footer information