Re: Stencil questions (adding text and defining line style)

[Urs Liska]

Hi Nathan (and Harm and David),


Am 21.09.2016 um 23:43 schrieb Nathan Ho:
> Hi Urs,
>
> grob-interpret-markup is the way to create text. You can position it
> with ly:stencil-translate, and add it to another stencil using
> ly:stencil-add:
>
> (ly:stencil-add
>   your-current-stencil
>   (ly:stencil-translate
> (grob-interpret-markup
>   grob
>   (markup "Hey"))
> '(2 . 3)))

and here's to that: I noticed that with more than a few inflections it
becomes hard to match the definition in the file with the result in the
score. Adding index labels makes this easier, although there's no real
reference to the index number in the file.

Maybe one could allow to specify an optional label, and only if that's
present print it. That will allow the user to print *some* labels for
easier navigation, without requiring him to add labels to all inflections.

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

Re: Stencil questions (adding text and defining line style)

[Urs Liska]

Hi David,


Am 21.09.2016 um 23:47 schrieb David Nalesnik:
> Hi Urs,
>
> On Wed, Sep 21, 2016 at 1:49 PM, Urs Liska  wrote:
>> Hi all,
>>
>> it may seem unprobable but I don't find the information how I can add
>> some text to my constum-made stencils.
>>
>> Concretely I want to add a text element at a certain position to a
>>   (ly:stencil-add
>> construction
> You would probably create the text stencil using grob-interpret-markup.
> .
>> The other thing I didn't find is: how can I create a dashed (or
>> otherwise styled) line stencil with make-line-stencil?
> You should use ly:line-interface::line (which is available from
> 2.19.27, off the top of my head).
>
> Here's an example with both text and different line styles.
>
> (Even though TextScript doesn't support line-interface, you can still
> tweak line-related properties!)
>
> \version "2.19.46"
>
> #(define (my-stencil grob)
>(let* ((line (ly:line-interface::line grob 1.5 0 6 0))
>   (text (grob-interpret-markup grob "A"))
>   (stil (apply ly:stencil-add (list line text
>  stil))
>
> {
>   \override TextScript.stencil = #my-stencil
>   c''1 -\tweak style #'dashed-line ^""
>   c''1 -\tweak style #'zigzag ^""
> }

Thank you, I could integrate this into my slur editing (helper)
interface. Attached you can see how the handles to the second and third
control points are prolonged by a dashed line. This actually makes
editing easier because the length of this handle (i.e. the distance from
the end points to the neighboring control points) is defined as the
ratio to the baseline. Seeing the "1" unit as a dashed line makes it
much easier to judge what value to try next.

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

Re: What to do wanting a 4th order Bézier?

[Carl Sorensen]

On 9/21/16 11:59 AM, "Urs Liska"  wrote:

>
>  
>  
>
>
>
>Am 21.09.2016 um 19:48 schrieb tisimst:
>
>
>  
>
>  By the way, how do the curves appear
>when the thickness is more pronounced (i.e., thicker). Does
>it still come back down to a point at the end of each
>segment? My guess is it does (simply because I haven't
>tested it myself).
>
>  
>
>
>
>Yes, it does, see attached.

I haven't looked at the code, but it should not be hard to get this to
work.  Instead of a bezier, we use a bezier sandwich to make slurs.  It
would be possible to use the bezier code for one side of the slur, and
then offset the interior end control point for the sandwich.

The dashed slur code shows how this is done for dashed slurs.

If you haven't done it by the time I finish with the dots stuff, I will
try to take a look at it.

Thanks,

Carl


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

Re: Stencil questions (adding text and defining line style)

[Thomas Morley]

Hi Urs,

2016-09-21 23:47 GMT+02:00 David Nalesnik :

>> The other thing I didn't find is: how can I create a dashed (or
>> otherwise styled) line stencil with make-line-stencil?

I was going to write:
If you regard the basics you'll see something like the following example:

\markup
  \box {
  \stencil
#(ly:make-stencil
   (list
 'dashed-line
 0.2 ; width
 0.5 ;; on
 0.5 ; off
 10 ;; x-end
 10 ;; y-end
 0 ;; phase
 )
   ;; x-ext
   (cons 0 10)
   ;; y-ext
   (cons 0 10))
  \stencil
#(ly:make-stencil
   (list
 'draw-line
 0.2 ; width
 0  ; startx
 0 ; starty
 10 ; endx
 10 ;endy
 )
   '(0 . 10)
  '(0 . 10))
}

So there's no direct method to switch between both, because of the
kind and amount of arguments differ.
But you can use some "meta"-functions like:

(and now follow David' reply)


>
> You should use ly:line-interface::line (which is available from
> 2.19.27, off the top of my head).
>
> Here's an example with both text and different line styles.
>
> (Even though TextScript doesn't support line-interface, you can still
> tweak line-related properties!)
>
> \version "2.19.46"
>
> #(define (my-stencil grob)
>(let* ((line (ly:line-interface::line grob 1.5 0 6 0))
>   (text (grob-interpret-markup grob "A"))
>   (stil (apply ly:stencil-add (list line text
>  stil))
>
> {
>   \override TextScript.stencil = #my-stencil
>   c''1 -\tweak style #'dashed-line ^""
>   c''1 -\tweak style #'zigzag ^""
> }
>
>>
>> More generally: how can I learn more about these things? Searching
>> lilypond.org seems to only point to snippets and no real explanations.
>
> There's not much to go on.
>
> grob-interpret-markup is mentioned here:
> http://lilypond.org/doc/v2.19/Documentation/extending/callback-functions
>
> The function doesn't have a docstring:
>
> #(display (procedure-documentation grob-interpret-markup))
>
> returns #f ...
>
> ly:line-interface::line is listed in the IR (Scheme functions)
>
> Sorry I can't be more helpful.
>
> David

Cheers,
  Harm

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

Re: Stencil questions (adding text and defining line style)

[David Nalesnik]

Hi Urs,

On Wed, Sep 21, 2016 at 1:49 PM, Urs Liska  wrote:
> Hi all,
>
> it may seem unprobable but I don't find the information how I can add
> some text to my constum-made stencils.
>
> Concretely I want to add a text element at a certain position to a
>   (ly:stencil-add
> construction

You would probably create the text stencil using grob-interpret-markup.
.
>
> The other thing I didn't find is: how can I create a dashed (or
> otherwise styled) line stencil with make-line-stencil?

You should use ly:line-interface::line (which is available from
2.19.27, off the top of my head).

Here's an example with both text and different line styles.

(Even though TextScript doesn't support line-interface, you can still
tweak line-related properties!)

\version "2.19.46"

#(define (my-stencil grob)
   (let* ((line (ly:line-interface::line grob 1.5 0 6 0))
  (text (grob-interpret-markup grob "A"))
  (stil (apply ly:stencil-add (list line text
 stil))

{
  \override TextScript.stencil = #my-stencil
  c''1 -\tweak style #'dashed-line ^""
  c''1 -\tweak style #'zigzag ^""
}

>
> More generally: how can I learn more about these things? Searching
> lilypond.org seems to only point to snippets and no real explanations.

There's not much to go on.

grob-interpret-markup is mentioned here:
http://lilypond.org/doc/v2.19/Documentation/extending/callback-functions

The function doesn't have a docstring:

#(display (procedure-documentation grob-interpret-markup))

returns #f ...

ly:line-interface::line is listed in the IR (Scheme functions)

Sorry I can't be more helpful.

David

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

Re: Stencil questions (adding text and defining line style)

[Nathan Ho]

On 2016-09-21 11:49, Urs Liska wrote:


Concretely I want to add a text element at a certain position to a
  (ly:stencil-add
construction.


Hi Urs,

grob-interpret-markup is the way to create text. You can position it 
with ly:stencil-translate, and add it to another stencil using 
ly:stencil-add:


(ly:stencil-add
  your-current-stencil
  (ly:stencil-translate
(grob-interpret-markup
  grob
  (markup "Hey"))
'(2 . 3)))

ly:stencil-combine-at-edge is also really handy if you want to position 
a stencil relative to bounding box of another one, like "place this 
thing vertically centered so its left edge is 0.1 staff spaces away from 
the right edge of this other thing."



The other thing I didn't find is: how can I create a dashed (or
otherwise styled) line stencil with make-line-stencil?


I don't think it's possible, but you can use draw-dashed-line / 
draw-dotted-line in a grob-interpret-markup.



More generally: how can I learn more about these things? Searching
lilypond.org seems to only point to snippets and no real explanations.


I've generally relied on examining examples in the LSR to learn about 
this sort of thing. The "Scheme functions" section of the Notation and 
Internals manuals is helpful, but a lot of the functions are not clearly 
documented, and they're definitely not presented in a manner that's 
conducive to step-by-step learning.


Since it's pretty tough to use stencils, as you can see I resort a lot 
to markups. They're not the perfect solution, but they're better 
documented and easier to use.



Nathan

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

OT: What to do wanting a 4th order Bézier?

[Karlin High]

On 9/21/2016 11:01 AM, Urs Liska wrote:
>
> I wouldn't claim production readiness yet, but I've gone a long way 
> with multi-segmented slurs :-)
>
> As you can see from the attached PDF files (if they don't block the 
> message from being delivered ...) we can now print slurs with an 
> arbitrary number of connected segments! The slur in the first system 
> is along the lines of the orginal print, and I've added a "fancy" 
> example with the red slur in the lower system.
>

I can't help but think of the Windows 7 "Ribbons" screensaver every time 
I look at these PDFs. Maybe this music is the soundtrack for it...
--
Karlin High
Missouri, USA

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

using a dynamic voice splitter with partcombine

[Kieren MacMillan]

Hello all,

In the snippet attached below, you will see a function I use to allow for 
coding music and dynamics which do not necessarily have the same moments.

It works wonderfully for me — saves typing, keeps the code clean and 
manageable, etc. — and I want to keep using it [or something similar]. HOWEVER, 
when using partcombine, it fails in unexpected ways (in this case by *partly* 
working).

I’m guessing the problem is related to one or more of the “known issues” (cf. 
http://lilypond.org/doc/v2.19/Documentation/notation/multiple-voices#automatic-part-combining)
 — in particular, “All \partcombine… functions can only accept two voices” 
and/or [most likely] “\partcombine keeps all spanners (slurs, ties, hairpins, 
etc.) in the same Voice so that if any such spanners start or end in a 
different Voice, they may not be printed properly or at all”, and/or maybe even 
“If the \partcombine function cannot combine both music expressions (i.e., when 
both voices have different durations), it will give the voices, internally, its 
own custom names: one and two respectively. This means if there is any “switch” 
to a differently named Voice context, the events in that differently named 
Voice will be ignored”.

Regardless, I’m hoping someone can suggest how to recode or replace the 
\splitDyn function so that it works when using partcombine.

Many thanks,
Kieren.

%%% SNIPPET BEGINS
\version "2.19.46"

\paper { line-width = 4\in ragged-right = ##f }

splitDyn =
  #(define-music-function (notestuff dynstuff)
   (ly:music? ly:music?)
   #{
   << { $notestuff } { $dynstuff } >>
   #})

musicA = {
\splitDyn { c''1 } { s4\> s\! s\< s\! }
}
musicB = {
\splitDyn { e''1 } { s4\> s\! s\< s\! }
}

\markup "Works:"
\new Staff \musicA

\markup "Fails:"
\new Staff \partcombine \musicA \musicB
%%%  SNIPPET ENDS


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

Stencil questions (adding text and defining line style)

[Urs Liska]

Hi all,

it may seem unprobable but I don't find the information how I can add
some text to my constum-made stencils.

Concretely I want to add a text element at a certain position to a
  (ly:stencil-add
construction.

The other thing I didn't find is: how can I create a dashed (or
otherwise styled) line stencil with make-line-stencil?

More generally: how can I learn more about these things? Searching
lilypond.org seems to only point to snippets and no real explanations.

TIA
Urs

-- 
Urs Liska
www.openlilylib.org

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

Re: What to do wanting a 4th order Bézier?

[Simon Albrecht]

On 21.09.2016 19:48, tisimst wrote:

A next thing would be to show how this can be used to make flat slurs ;-)


If you try
%%
\version "2.19.47"
{
  1-\tweak control-points #'((0 . -5)(1 . -5)(5 . -5)(6 . -5)) ( 1)
}
%%
you see that the slur stencil procedure can produce a flat line (well, 
kind of, with the rounded sandwiching applied), so it’s possible to use 
this compoundSlur code with flat segments. I don’t know what you mean – 
do you mean ‘Novello-style’ moveable-type-like slurs with a rounded 
beginning, a long flat middle segment, and a rounded ending?


By the way, how do the curves appear when the thickness is more 
pronounced (i.e., thicker). Does it still come back down to a point at 
the end of each segment? My guess is it does (simply because I haven't 
tested it myself).


It sure does, and I thought that this is not a problem or in the 
contrary preferable because an engraver might have done the same, as in 
writing with a quill, so the curve naturally has these ‘bottlenecks’.


Best, Simon

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

Re: What to do wanting a 4th order Bézier?

[Urs Liska]

Am 21.09.2016 um 19:46 schrieb Carl Sorensen:
>
> On 9/21/16 11:34 AM, "Urs Liska"  wrote:
>
>> By contrast
>>
>> inflection =
>> #'((point-X-ratio . 0.4)
>>   (point-Y . 12))
>
> I like this, but I would probably change it to
>
> inflection = 
> #'((X-ratio . 0.4) (Y-offset . 12))
>
> I think that the "point" part of the name is superfluous.

Great suggestion, I'll do it that way.


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

Re: What to do wanting a 4th order Bézier?

[Urs Liska]

Am 21.09.2016 um 19:48 schrieb tisimst:
> By the way, how do the curves appear when the thickness is more
> pronounced (i.e., thicker). Does it still come back down to a point at
> the end of each segment? My guess is it does (simply because I haven't
> tested it myself).

Yes, it does, see attached.

> That would be nice to be able to be able to specify whether it should
> taper back down or not. Feature request!

Well, that would be a "general" feature request which I can't do
anything about. I'm using LilyPond's code to drawing splines, concretely
(ly:slur::print grob).

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

Re: What to do wanting a 4th order Bézier?

[tisimst]

On Wed, Sep 21, 2016 at 11:36 AM, Urs Liska [via Lilypond] <
ml-node+s1069038n194817...@n5.nabble.com> wrote:

> I'm not clear if we are all talking about the same things. Maybe write it
> down explicitly:
>
> inflection =
> #'((point . (.4 . 12)))
>
> would now mean: "40 % through the horizontal space between the end points
> and 12 staff spaces above the vertical center between the points. This is
> completely easy to write down but surely confusing to learn, even if
> documented properly.
>
> By contrast
>
> inflection =
> #'((point-X-ratio . 0.4)
>(point-Y . 12))
>
> seems clearer but more verbose to write out.
>

I'm a fan of the verbosity, especially with such complex objects as this
where you may (easily!) have 10+ different numbers adjusting the overall
shape. It also self-documents what the values represent.

--
Abraham Lee

P.S. This is absolutely awesome, Urs! Well done. A next thing would be to
show how this can be used to make flat slurs ;-) By the way, how do the
curves appear when the thickness is more pronounced (i.e., thicker). Does
it still come back down to a point at the end of each segment? My guess is
it does (simply because I haven't tested it myself). That would be nice to
be able to be able to specify whether it should taper back down or not.
Feature request!




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/What-to-do-wanting-a-4th-order-Bezier-tp194666p194820.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: What to do wanting a 4th order Bézier?

[Carl Sorensen]

On 9/21/16 11:34 AM, "Urs Liska"  wrote:

>
>By contrast
>
>inflection =
>#'((point-X-ratio . 0.4)
>   (point-Y . 12))


I like this, but I would probably change it to

inflection = 
#'((X-ratio . 0.4) (Y-offset . 12))

I think that the "point" part of the name is superfluous.



>seems clearer but more verbose to write out.

IMO, clarity should outweigh brevity in cases like this.

Thanks,

Carl


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

Re: different font size settings for instrumentName and shortInstrumentName

[Pierre Perol-Schneider]

Done:
http://lsr.di.unimi.it/LSR/Item?id=1046

Cheers,
Pierre

2016-09-21 18:50 GMT+02:00 Kieren MacMillan :

> Hi Pierre,
>
> That works perfectly!
>
> Might I suggest that would make a great snippet in the doc section on
> instrument names?
> I can’t be the only one who’s ever wanted different size names for the two
> types…
>
> Many thanks,
> 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: What to do wanting a 4th order Bézier?

[Urs Liska]

Am 21.09.2016 um 19:29 schrieb Simon Albrecht:
>> suggestion) but apply it to the vertical center between the two
>> endpoints? That way the whole slur should somewhat shift together with
>> changed Y of an end point.
>>
>> Would it be acceptable to have a pair? as an argument when the two
>> elements*do*  refer to X and Y but with completely different behaviour?
>> Or should that then be separated to two individual properties?
>
> That sounds like way over the top. The user interface should be
> reasonably easy to understand, so I’d prefer a simple staff-space
> offset for Y. It seems like a good idea to do it relative to the
> vertical center between the two endpoints, then 0 as a default is
> sensible.

I'm not clear if we are all talking about the same things. Maybe write
it down explicitly:

inflection =
#'((point . (.4 . 12)))

would now mean: "40 % through the horizontal space between the end
points and 12 staff spaces above the vertical center between the points.
This is completely easy to write down but surely confusing to learn,
even if documented properly.

By contrast

inflection =
#'((point-X-ratio . 0.4)
   (point-Y . 12))

seems clearer but more verbose to write out.

Urs

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

Re: What to do wanting a 4th order Bézier?

[Simon Albrecht]

On 21.09.2016 19:22, Urs Liska wrote:

Am 21.09.2016 um 19:18 schrieb Carl Sorensen:

On 9/21/16 10:22 AM, "Urs Liska"  wrote:

 The other thing I came across is the specification of the
inflection*point*. Basically the idea of specifying independent
X and Y ratios between the slur's endpoints seems practical, as
it is pretty predictable. But I realized that this only works
well when the endpoints are sufficiently different on the
Y-scale. If the slur is horizontal then*any*  inflection will
necessarily be on that same horizontal line! So I need a
suggestion what could be a suitable, predictable*and*
un-limited approach to specifying this.

I think that you could use the X fraction as the X coordinate of the
inflection point.  And you could use a Y offset (in staff spaces from the
starting point) as the Y coordinate of the inflection point.  It seems
that should be relatively easy to implement.

Implementing that is easy, of course. What I'm thinking about mostly is
the predictability of the results when anything changes, for example the
Y coordinate of either point.

What would you think of using a staff-space offset for Y (as per your
suggestion) but apply it to the vertical center between the two
endpoints? That way the whole slur should somewhat shift together with
changed Y of an end point.

Would it be acceptable to have a pair? as an argument when the two
elements*do*  refer to X and Y but with completely different behaviour?
Or should that then be separated to two individual properties?


That sounds like way over the top. The user interface should be 
reasonably easy to understand, so I’d prefer a simple staff-space offset 
for Y. It seems like a good idea to do it relative to the vertical 
center between the two endpoints, then 0 as a default is sensible.


Best, Simon

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

Re: different font size settings for instrumentName and shortInstrumentName

[Simon Albrecht]

Hi Kieren,

I think the most natural way to do this would be to define a scheme 
function, which generates an output def, so that the following two 
examples would have the same result:


%%%
\version "2.19.47"

\score {
  \new Staff \with {
instrumentName = \markup \fontsize #3 "Flute"
shortInstrumentName = \markup \fontsize #-2 "Fl."
  }
  { 1 \break 1 }
}

nameInstrument =
#(define-scheme-function (long short) (string? string?)
   (ly:make-output-def
;;; do whatever it takes to make an output def with the above content…
))

\score {
  \new Staff \nameInstrument "Flute" "Fl." { 1 \break 1 }
}
%%

David K. recently made it possible to use multiple \with blocks per 
context creation, so that could easily be combined with other 
modifications to the Staff.


Unfortunately, ly:make-output-def is totally opaque, even looking at the 
definition in the source doesn’t give me (ok, I don’t know any C++) the 
slightest hint how to use it. What’s more, one cannot use \displayScheme 
on a with block… so I need to ask for others to chime in here – it can’t 
be too complicated, can it?


Best, Simon

On 21.09.2016 16:08, Kieren MacMillan wrote:

Hello all,

Has anyone elegantly solved the problem of having different font settings 
(size, in particular) for instrumentName and shortInstrumentName? I know I 
could write a music function, and then use

 instrumentName = “long name”
 shortInstrumentName = \myfunction ”short name”

or even just use

 instrumentName = “long name”
 shortInstrumentName = \markup \fontsize #-2 ”short name”

etc., but I’d prefer a global solution that can be set as a context override.

Thanks!
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



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

Re: What to do wanting a 4th order Bézier?

[Urs Liska]

Am 21.09.2016 um 19:18 schrieb Carl Sorensen:
>
> On 9/21/16 10:22 AM, "Urs Liska"  wrote:
>
>>  The other thing I came across is the specification of the
>>inflection *point*. Basically the idea of specifying independent
>>X and Y ratios between the slur's endpoints seems practical, as
>>it is pretty predictable. But I realized that this only works
>>well when the endpoints are sufficiently different on the
>>Y-scale. If the slur is horizontal then *any* inflection will
>>necessarily be on that same horizontal line! So I need a
>>suggestion what could be a suitable, predictable *and*
>>un-limited approach to specifying this.
> I think that you could use the X fraction as the X coordinate of the
> inflection point.  And you could use a Y offset (in staff spaces from the
> starting point) as the Y coordinate of the inflection point.  It seems
> that should be relatively easy to implement.

Implementing that is easy, of course. What I'm thinking about mostly is
the predictability of the results when anything changes, for example the
Y coordinate of either point.

What would you think of using a staff-space offset for Y (as per your
suggestion) but apply it to the vertical center between the two
endpoints? That way the whole slur should somewhat shift together with
changed Y of an end point.

Would it be acceptable to have a pair? as an argument when the two
elements *do* refer to X and Y but with completely different behaviour?
Or should that then be separated to two individual properties?

Urs

>
> Thanks,
>
> Carl


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

Re: What to do wanting a 4th order Bézier?

[Carl Sorensen]

On 9/21/16 10:22 AM, "Urs Liska"  wrote:

>  The other thing I came across is the specification of the
>inflection *point*. Basically the idea of specifying independent
>X and Y ratios between the slur's endpoints seems practical, as
>it is pretty predictable. But I realized that this only works
>well when the endpoints are sufficiently different on the
>Y-scale. If the slur is horizontal then *any* inflection will
>necessarily be on that same horizontal line! So I need a
>suggestion what could be a suitable, predictable *and*
>un-limited approach to specifying this.

I think that you could use the X fraction as the X coordinate of the
inflection point.  And you could use a Y offset (in staff spaces from the
starting point) as the Y coordinate of the inflection point.  It seems
that should be relatively easy to implement.

Thanks,

Carl
>


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

Re: What to do wanting a 4th order Bézier?

[Simon Albrecht]

On 21.09.2016 18:22, Urs Liska wrote:


Maybe the below message will get through later, but maybe it's blocked 
because of the attachement size, so I resend it with the attachments 
uploaded to


https://cloud.ursliska.de/index.php/s/km6cHCuuMF7AcWt and
https://cloud.ursliska.de/index.php/s/6R90WOE3JPOGNKL



Urs, this is totally awesome! Many thanks :-) I’ll have to review the 
interface, but these examples are so promising…

Best, Simon


(these may not be permanent!)

Best
Urs


Am 21.09.2016 um 18:01 schrieb Urs Liska:


Hey all,

I wouldn't claim production readiness yet, but I've gone a long way 
with multi-segmented slurs :-)


As you can see from the attached PDF files (if they don't block the 
message from being delivered ...) we can now print slurs with an 
arbitrary number of connected segments! The slur in the first system 
is along the lines of the orginal print, and I've added a "fancy" 
example with the red slur in the lower system.


Of course it's somewhat tedious to finetune these slurs, but I found 
it's surprisingly convenient to do, and with little surprises. The 
critical point is that the segments are completely independent -with 
the exeption of the forced equal angle at the inflection points. So 
what one basically does is add one inflection point after another, 
and one can independently tweak the slur to the left of each 
inflection point, without serious side-effects.


I've completely disposed of any "offset" specification except for the 
positioning of the two ends. For all the control point editing you 
will give it an angle (which is relative to the baseline of the 
segment) and a ratio (in relation to the length of that baseline). 
This gives very predictable results and makes tweaking as easy as one 
can expect with such complex notation. Of course this even more begs 
for a graphical tweaking interface ... But of course this function is 
substantially more reliable than anything you can do with other tools.


I don't copy the whole code into the email anymore, the sources are 
now at 
https://github.com/openlilylib/snippets/tree/compound-slur/notation-snippets/shaping-bezier-curves, 
in the files compound-slurs.ily and common-math-and-stencils.ily. 
I'll go through another round of tidying up, but I'm happy about any 
suggestions to improve the code.


To give an idea about the interface, this is the definition of the 
(first few inflections of the) upper Sorabij slur:


^\compoundSlur \with {
  annotate = ##t
%  show-original-slur = ##t

  start-point = #'(0 . 3)
  start-angle = 65
  start-ratio = 0.6
  end-point = #'(2.5 . 4)
  end-angle = -70

  inflection =
  #'((point . (.215 . 1.55))
 (angle . -55)
 (ratio-left . 0.4)
 (ratio-right . 0.22))

  inflection =
  #'((point . (.26 . -0.2))
 (angle . 60)
 (ratio-left . .45)
 (ratio-right . .4))

  inflection =
  #'((point . (.49 . 0.35))
 (angle . 33)
 (ratio-left . .45)
 (ratio-right . .15))

% ...
}

So you give a few general properties for the start and end points and 
then each inflection as an individual unit. The "point" is the ratio 
between the end points of the slur. Angle is given relative to the 
*left* base-line (and the spline to the right will exactly mirror 
that value). ratio-left and ratio-right specify the length of the two 
handles around the inflection point.


I think it's already pretty clean with regard to type checking and 
falling back to defaults for missing or wrong-type properties (while 
issuing a warning).


If you want to try it out you will have to have scholarLY installed 
separately, in the version from 
https://github.com/oll-core/scholarly. But it may be worth the 
effort, as it also demonstrates one of the GSoC news: triggering 
footnotes from annotations.


So far I have the impression it works very well, with some minor and 
not-so-minor glitches.


The minor one is that I'd like to specify the starting point relative 
to the note head instead of to LilyPond's default decision. I think 
whenever such compound slurs are necessary LilyPond's default slur 
will be completely irrelevant to us, and we can instead specify the 
end points explicitly anyway. \shapeII already has this as an option, 
so I'll look for that.


One larger thing is that I don't support broken slurs yet (and I 
won't go after that right now - hopefully someone else chimes in now).


The other thing I came across is the specification of the inflection 
*point*. Basically the idea of specifying independent X and Y ratios 
between the slur's endpoints seems practical, as it is pretty 
predictable. But I realized that this only works well when the 
endpoints are sufficiently different on the Y-scale. If the slur is 
horizontal then *any* inflection will necessarily be on that same 
horizontal line! So I need a suggestion what could be a suitable, 
predictable *and* un-limited approach to specifying this.


Another minor wish I would like to implement is printing an optional 
grid 

Re: different font size settings for instrumentName and shortInstrumentName

[Kieren MacMillan]

Hi Pierre,

That works perfectly!

Might I suggest that would make a great snippet in the doc section on 
instrument names?
I can’t be the only one who’s ever wanted different size names for the two 
types…

Many thanks,
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: different font size settings for instrumentName and shortInstrumentName

[Pierre Perol-Schneider]

Or even:

\version "2.19.48"

longInstrumeentNameFontSize = 6
shortInstrumeentNameFontSize = -3

\layout {
\context {
\Staff
\override InstrumentName.after-line-breaking = #(lambda (grob)
   (ly:grob-set-property! grob 'long-text
  (markup #:fontsize longInstrumeentNameFontSize (ly:grob-property
grob 'long-text)))
  (ly:grob-set-property! grob 'text
  (markup #:fontsize shortInstrumeentNameFontSize (ly:grob-property
grob 'text)))

  )
}
}

\new Staff
   \with {
 instrumentName = "Flute"
 shortInstrumentName = "Fl."
   }
   { c''1 \break c'' }

Cheers,
Pierre

2016-09-21 18:28 GMT+02:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:

> Hi Kieren,
>
> How about:
>
> 
> \version "2.19.48"
>
> shortInstrumeentNameFontSize = -3
>
> \layout {
> \context {
> \Staff
> \override InstrumentName.after-line-breaking = #(lambda (grob)
>   (ly:grob-set-property! grob 'text
>   (markup #:fontsize shortInstrumeentNameFontSize
> (ly:grob-property grob 'text
> }
> }
>
> \new Staff
>\with {
>  instrumentName = "Flute"
>  shortInstrumentName = "Fl."
>}
>{ c''1 \break c'' }
> 
>
> Cheers,
> Pierre
>
> 2016-09-21 16:08 GMT+02:00 Kieren MacMillan  >:
>
>> Hello all,
>>
>> Has anyone elegantly solved the problem of having different font settings
>> (size, in particular) for instrumentName and shortInstrumentName? I know I
>> could write a music function, and then use
>>
>> instrumentName = “long name”
>> shortInstrumentName = \myfunction ”short name”
>>
>> or even just use
>>
>> instrumentName = “long name”
>> shortInstrumentName = \markup \fontsize #-2 ”short name”
>>
>> etc., but I’d prefer a global solution that can be set as a context
>> override.
>>
>> Thanks!
>> 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
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: different font size settings for instrumentName and shortInstrumentName

[Pierre Perol-Schneider]

Hi Kieren,

How about:


\version "2.19.48"

shortInstrumeentNameFontSize = -3

\layout {
\context {
\Staff
\override InstrumentName.after-line-breaking = #(lambda (grob)
  (ly:grob-set-property! grob 'text
  (markup #:fontsize shortInstrumeentNameFontSize (ly:grob-property
grob 'text
}
}

\new Staff
   \with {
 instrumentName = "Flute"
 shortInstrumentName = "Fl."
   }
   { c''1 \break c'' }


Cheers,
Pierre

2016-09-21 16:08 GMT+02:00 Kieren MacMillan :

> Hello all,
>
> Has anyone elegantly solved the problem of having different font settings
> (size, in particular) for instrumentName and shortInstrumentName? I know I
> could write a music function, and then use
>
> instrumentName = “long name”
> shortInstrumentName = \myfunction ”short name”
>
> or even just use
>
> instrumentName = “long name”
> shortInstrumentName = \markup \fontsize #-2 ”short name”
>
> etc., but I’d prefer a global solution that can be set as a context
> override.
>
> Thanks!
> 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
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: What to do wanting a 4th order Bézier?

[Urs Liska]

Maybe the below message will get through later, but maybe it's blocked
because of the attachement size, so I resend it with the attachments
uploaded to

https://cloud.ursliska.de/index.php/s/km6cHCuuMF7AcWt and
https://cloud.ursliska.de/index.php/s/6R90WOE3JPOGNKL

(these may not be permanent!)

Best
Urs


Am 21.09.2016 um 18:01 schrieb Urs Liska:
>
> Hey all,
>
> I wouldn't claim production readiness yet, but I've gone a long way
> with multi-segmented slurs :-)
>
> As you can see from the attached PDF files (if they don't block the
> message from being delivered ...) we can now print slurs with an
> arbitrary number of connected segments! The slur in the first system
> is along the lines of the orginal print, and I've added a "fancy"
> example with the red slur in the lower system.
>
> Of course it's somewhat tedious to finetune these slurs, but I found
> it's surprisingly convenient to do, and with little surprises. The
> critical point is that the segments are completely independent -with
> the exeption of the forced equal angle at the inflection points. So
> what one basically does is add one inflection point after another, and
> one can independently tweak the slur to the left of each inflection
> point, without serious side-effects.
>
> I've completely disposed of any "offset" specification except for the
> positioning of the two ends. For all the control point editing you
> will give it an angle (which is relative to the baseline of the
> segment) and a ratio (in relation to the length of that baseline).
> This gives very predictable results and makes tweaking as easy as one
> can expect with such complex notation. Of course this even more begs
> for a graphical tweaking interface ... But of course this function is
> substantially more reliable than anything you can do with other tools.
>
> I don't copy the whole code into the email anymore, the sources are
> now at
> https://github.com/openlilylib/snippets/tree/compound-slur/notation-snippets/shaping-bezier-curves,
> in the files compound-slurs.ily and common-math-and-stencils.ily. I'll
> go through another round of tidying up, but I'm happy about any
> suggestions to improve the code.
>
> To give an idea about the interface, this is the definition of the
> (first few inflections of the) upper Sorabij slur:
>
> ^\compoundSlur \with {
>   annotate = ##t
> %  show-original-slur = ##t
>
>   start-point = #'(0 . 3)
>   start-angle = 65
>   start-ratio = 0.6
>   end-point = #'(2.5 . 4)
>   end-angle = -70
>
>   inflection =
>   #'((point . (.215 . 1.55))
>  (angle . -55)
>  (ratio-left . 0.4)
>  (ratio-right . 0.22))
>
>   inflection =
>   #'((point . (.26 . -0.2))
>  (angle . 60)
>  (ratio-left . .45)
>  (ratio-right . .4))
>
>   inflection =
>   #'((point . (.49 . 0.35))
>  (angle . 33)
>  (ratio-left . .45)
>  (ratio-right . .15))
>
> % ...
> }
>
> So you give a few general properties for the start and end points and
> then each inflection as an individual unit. The "point" is the ratio
> between the end points of the slur. Angle is given relative to the
> *left* base-line (and the spline to the right will exactly mirror that
> value). ratio-left and ratio-right specify the length of the two
> handles around the inflection point.
>
> I think it's already pretty clean with regard to type checking and
> falling back to defaults for missing or wrong-type properties (while
> issuing a warning).
>
> If you want to try it out you will have to have scholarLY installed
> separately, in the version from https://github.com/oll-core/scholarly.
> But it may be worth the effort, as it also demonstrates one of the
> GSoC news: triggering footnotes from annotations.
>
> So far I have the impression it works very well, with some minor and
> not-so-minor glitches.
>
> The minor one is that I'd like to specify the starting point relative
> to the note head instead of to LilyPond's default decision. I think
> whenever such compound slurs are necessary LilyPond's default slur
> will be completely irrelevant to us, and we can instead specify the
> end points explicitly anyway. \shapeII already has this as an option,
> so I'll look for that.
>
> One larger thing is that I don't support broken slurs yet (and I won't
> go after that right now - hopefully someone else chimes in now).
>
> The other thing I came across is the specification of the inflection
> *point*. Basically the idea of specifying independent X and Y ratios
> between the slur's endpoints seems practical, as it is pretty
> predictable. But I realized that this only works well when the
> endpoints are sufficiently different on the Y-scale. If the slur is
> horizontal then *any* inflection will necessarily be on that same
> horizontal line! So I need a suggestion what could be a suitable,
> predictable *and* un-limited approach to specifying this.
>
> Another minor wish I would like to implement is printing an optional
> grid which will ease finding the right inflection 

different font size settings for instrumentName and shortInstrumentName

[Kieren MacMillan]

Hello all,

Has anyone elegantly solved the problem of having different font settings 
(size, in particular) for instrumentName and shortInstrumentName? I know I 
could write a music function, and then use

instrumentName = “long name”
shortInstrumentName = \myfunction ”short name”

or even just use

instrumentName = “long name”
shortInstrumentName = \markup \fontsize #-2 ”short name”

etc., but I’d prefer a global solution that can be set as a context override.

Thanks!
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: lilypond-book: Processing multiple lytex files with a single command

[Federico Bruni]

Il giorno mer 21 set 2016 alle 14:49, tapani  ha 
scritto:
I need to process several dozen lytex files at once for a single 
project (on
Ubuntu). Is there a way of processing every lytex file in a given 
location
with a single command, rather than having to compile each one 
separately?


[I read somewhere about using a makefile, but I failed to understand 
it

sufficiently to apply it.]

Any help would be very much appreciated!


Hey Tapani

Yes, makefile is a good way to go.
I started using it in the last weeks and I think it's very very useful 
with LilyPond. I've been wanting to try to improve the doc about 
Makefile but didn't find the time to study it a bit more and try a 
patch.


Basically you'll have to do something like this (replace "[TAB] " with 
a real TAB character):


# Rule to compile any .ly file to PDF and MIDI
# The pattern is "output: input". I'll use % (same as * in bash), to 
catch all files ending with...

# $< is the input file
#
%.pdf, %.midi: %.ly
[TAB] lilypond $<

# Rule to build a lilypond-book file
mybook.pdf: mybook.lytex
[TAB] lilypond-book OPTIONS... $<

# Targets
book: mybook.pdf

clean:
[TAB] rm *.pdf *.midi




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

Re: lilypond-book: Processing multiple lytex files with a single command

[mskala]

On Wed, 21 Sep 2016, tapani wrote:
> I need to process several dozen lytex files at once for a single project (on
> Ubuntu). Is there a way of processing every lytex file in a given location
> with a single command, rather than having to compile each one separately?

for fn in *.lytex ; do lilypond-book $fn ; done

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/

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

Re: Building Lilypond on Ubuntu 16.04

[Thomas Weber]

Thanks for bringing me on track, Werner.  I was able to solve the problem in a 
quick and dirty manner, however it would be useful to learn how to solve it 
properly.

What I did was:

$ sudo ln -s /usr/include/freetype2/freetype/config 
/usr/include/freetype2/config
$ sudo sed -i 's|/freetype2$|/freetype2/freetype|' 
/usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc
$ ./configure
$ make

Which gives me a working lilypond 2.19.49.  What I didn't try previously was 
the first step, i.e. the symbolic link to the config folder.


Am 21.09.2016 um 10:59 schrieb Werner LEMBERG:
>
> You still don't tell us what lilypond version you are compiling.  


You're right.  I tried compiling the current master branch.


> And
> the interesting data is not the make output but the data in
> `config.log' that protocols how the build system got configured.
>


O.K., so I attached the full log (that's from the unmodified .pc file).  Here 
are the lines with "freetype" in them:

$ grep freetype config.log
configure:9267: result: -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2
configure:9273: result: -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 
-lfontconfig -lfreetype
configure:9307: g++ -c   -O2 -finline-functions -g -pipe 
-I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7  
-fno-strict-aliasing -g -fstack-protector-strong  -g -fwrapv  
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/freetype2 conftest.cpp >&5
configure:9307: g++ -E -I/usr/include/python2.7 
-I/usr/include/x86_64-linux-gnu/python2.7  -fno-strict-aliasing -g 
-fstack-protector-strong  -g -fwrapv  -I/usr/include/pango-1.0 
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 
conftest.cpp
configure:9319: g++ -o conftest   -O2 -finline-functions -g -pipe 
-I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7  
-fno-strict-aliasing -g -fstack-protector-strong  -g -fwrapv  
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/freetype2  conftest.cpp -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 
-lglib-2.0 -lfontconfig -lfreetype -ldl  >&5
configure:9409: result: -I/usr/include/freetype2
configure:9415: result: -lfontconfig -lfreetype
configure:9513: checking for freetype2 >= 2.1.10
configure:9524: result: -I/usr/include/freetype2
configure:9530: result: -lfreetype
FONTCONFIG_CFLAGS='-I/usr/include/freetype2'
FONTCONFIG_LIBS='-lfontconfig -lfreetype'
FREETYPE2_CFLAGS='-I/usr/include/freetype2'
FREETYPE2_LIBS='-lfreetype'
PANGO_FT2_CFLAGS='-I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2'
PANGO_FT2_LIBS='-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 
-lfontconfig -lfreetype'


>>  I tried changing the line "Cflags: -I${includedir}/freetype2" to
>> "Cflags: -I${includedir}/freetype2/freetype", but the headers are
>> still not found.
> Pfft, don't change this file!  It was installed during a `make
> install' of the FreeType library.  If you have a different FreeType
> library installed, then you have *another* `freetype2.pc' file.
> Search that.


This is a pretty clean and fresh system, I didn't install anything outside of 
the package manager.  All I got was:

$ LANG=C sudo find / -name 'freetype2.pc'
find: './run/user/1000/gvfs': Permission denied
./usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc


> It might be possible to change the order of directories searched by
> pkg-config.  You can do that by modifying the `PKG_CONFIG_PATH'
> environment variable.  More details can be found in pkg-config's
> manpage.
>
> Have a look at the output of
>
>   pkg-config --debug 2>&1 | less
>
> and search for `freetype'; this shows you what pkg-config finds where.


$ pkg-config --debug 2>&1 | grep freetype
File 'freetype2.pc' appears to be a .pc file
Will find package 'freetype2' in file 
'/usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc'

That's the very freetype2.pc file I modified to make things work.

Could that mean the package libreetype6-dev has a broken .pc file (because 
Cflags should point to a different folder)?  These are the .pc and .h files it 
installs:

$ dpkg-query -L libfreetype6-dev | grep -E '(\.pc$)|(\.h$)'
/usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc
/usr/include/freetype2/freetype/ftcid.h
/usr/include/freetype2/freetype/ftmodapi.h
/usr/include/freetype2/freetype/fttrigon.h
/usr/include/freetype2/freetype/ftoutln.h
/usr/include/freetype2/freetype/ftglyph.h
/usr/include/freetype2/freetype/ftincrem.h
/usr/include/freetype2/freetype/fterrors.h

Re: Building Lilypond on Ubuntu 16.04

[Thomas Weber]

Thanks for your reply, Werner.  What I did is the following:


$ git pull ; LANG=C make all | tail
Already up-to-date.
make[1]: *** No rule to make target '/usr/include/freetype2/freetype.h', needed 
by 'out/vaticana-ligature.o'.  Stop.
make: *** [all] Error 2
make[2]: Entering directory '/home/tom/devel/lilypond/scripts/build'
true
make[2]: Leaving directory '/home/tom/devel/lilypond/scripts/build'
make[1]: Leaving directory '/home/tom/devel/lilypond/scripts'
make[1]: Entering directory '/home/tom/devel/lilypond/flower'
true
make[1]: Leaving directory '/home/tom/devel/lilypond/flower'
make[1]: Entering directory '/home/tom/devel/lilypond/lily'
make[1]: Leaving directory '/home/tom/devel/lilypond/lily'
/home/tom/devel/lilypond/stepmake/stepmake/generic-targets.make:6: recipe for 
target 'all' failed


Am 21.09.2016 um 08:39 schrieb Werner LEMBERG:
>
> However, if you use
> either the `freetype-config' script or the `freetype2.pc' file for
> pkg-config tool to specify the header include directory, together with
> proper header macros like FT_FREETYPE_H in the source code, nothing
> should change for compilation.


Pardon my ignorance - how would I have to use freetype-config or how would I 
have to manipulate freetype2.pc?  I tried changing the line "Cflags: 
-I${includedir}/freetype2" to "Cflags: -I${includedir}/freetype2/freetype", but 
the headers are still not found.

Thomas

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

Re: Changing horizontal position of dots on dotted notes

[Simon Albrecht]

On 21.09.2016 05:13, Paul wrote:
It looks like LilyPond does not adjust the position of the dots based 
on the width of the stem (neither from its stencil nor its X-extent). 


In fact, only yesterday I had a situation when a \voiceOne dot was 
placed _on top_ of the \voiceThree stem…


Best, Simon

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

Re: Building Lilypond on Ubuntu 16.04

[Werner LEMBERG]

> When I try to "make" Lilypond on Ubuntu 16.04, the freetype headers
> are expected to be located in /usr/include/freetype2/.  That's also
> where Ubuntu's package libfreetype6-dev used to put them, at least
> in Ubuntu versions 14.04 to 15.10, but in 16.04 (also 12.04,
> interestingly), it's in /usr/include/freetype2/freetype/.  Hence, a
> symbolic link won't work and I'm not too eager to mess with a folder
> hierarchy that should be left under control of the package manager.
> 
> Is there a command line option for make that I can supply to point
> it to the directory where the headers actually are?

Please give a precise log file.  The location of FreeType header files
has changed in version 2.5.1 and again in 2.6.  However, if you use
either the `freetype-config' script or the `freetype2.pc' file for
pkg-config tool to specify the header include directory, together with
proper header macros like FT_FREETYPE_H in the source code, nothing
should change for compilation.

Which version of lilypond are you going to compile?  You should
*always* mention this!  Have you tried the latest development version?


Werner

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

Re: Start of the first row of a staff

[Marc Hohl]

Am 21.09.2016 um 08:19 schrieb Marco Bagolin:

Hello all,
please, I need a help because I don't find a solution in the snippet
repository.
I need that the first line of the staff is aligned as subsequent lines,
NOT as the attached example.


Does

\paper {
  indent = 0
}

Do what you mean? Or am I misunderstanding your request?

Marc


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

Re: Start of the first row of a staff

[Martin Neubauer]

Hello,

Try putting

%%%
\paper {
indent = 0\mm
}
%%%

in your lilypond source.

Regards,
Martin

On 21/09/2016 08:19, Marco Bagolin wrote:
> Hello all,
> please, I need a help because I don't find a solution in the snippet
> repository.
> I need that the first line of the staff is aligned as subsequent lines,
> NOT as the attached example.
> What is the command to use?
> start_staff.jpg
> 
>  
> 
> Thank you all in advance.
> 
> Regards
> Marco B.
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
-- 
Superficial similarities spawn spurious statements.


0xF9176739.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Start of the first row of a staff

[Marco Bagolin]

Hello all,
please, I need a help because I don't find a solution in the snippet
repository.
I need that the first line of the staff is aligned as subsequent lines, NOT
as the attached example.
What is the command to use?
start_staff.jpg



Thank you all in advance.

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

Building Lilypond on Ubuntu 16.04

[Thomas Weber]

When I try to "make" Lilypond on Ubuntu 16.04, the freetype headers are 
expected to be located in /usr/include/freetype2/.  That's also where Ubuntu's 
package libfreetype6-dev used to put them, at least in Ubuntu versions 14.04 to 
15.10, but in 16.04 (also 12.04, interestingly), it's in 
/usr/include/freetype2/freetype/.  Hence, a symbolic link won't work and I'm 
not too eager to mess with a folder hierarchy that should be left under control 
of the package manager.

Is there a command line option for make that I can supply to point it to the 
directory where the headers actually are?

Thanks!
Thomas

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