Re: Delete new LSR-snippet?

2016-12-23 Thread Thomas Morley
2016-12-24 0:53 GMT+01:00 Knut Petersen :
> Hi Trevor!
>>
>> I seem to remember a post or maybe an LSR entry for placing
>> divisi arrows at the end of a staff.  Maybe this could be
>> adapted to achieve the same effect more reliably?
>>
>> Found it  - LSR 650.  It modifies the barline stencil.
>
>
> Something like the following code  could be a base:
>
> \version "2.19.53"
>
> mpBarLine = {
>   \once \override Staff.BarLine #'stencil =
> #(lambda (grob) (ly:stencil-combine-at-edge (ly:bar-line::print grob) X
> RIGHT
> (grob-interpret-markup grob mpBarLineMarkup) 0))
>   \break
> }
>
> mpBarLineMarkup = \markup \with-dimensions #'(0 . 0) #'(0 . 0) {
>   \line {\hspace #3 \override #'(line-width . 20)
>  \justify{This is a marginal note}
>   }
> }
>
> \paper {
>   left-margin = 2\cm
>   line-width = 14\cm
>   indent = 0\cm
>   ragged-right = ##f
> }
>
> {
>   \repeat unfold 16 { c'' 4 } \break
>   \repeat unfold 16 { c'' 4 } \mpBarLine
>   \repeat unfold 16 { c'' 4 } \bar "|."
> }
>
> \layout {}
>
>

I once made a work-around to display InstrumentName on the right,
maybe it's usable here as well.

Cheers,
  Harm

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


Re: Delete new LSR-snippet?

2016-12-23 Thread Thomas Morley
2016-12-23 18:55 GMT+01:00 Simon Albrecht :
> On 23.12.2016 12:42, Thomas Morley wrote:
>>
>> with
>> http://lsr.di.unimi.it/LSR/Item?u=1=1049
>> a new snippet arrived.
>> Though, it only demonstrates how to use 'extra-offset, imho.
>
>
> And very poorly – how the staff lines resurface after the text script…

As far as I can tell, those are strange artefacts. I've seen it only
in LSR, but not, when compiling it on my computer.

> This is definitely not showcase-able and I agree about deleting it.
> Maybe you can write a kind of encouraging message to the contributor?

I'll write something on -user, before deleting (or modifying).
But it's not possible for me to get the authors name or e-mail (unless
stated in the snippet), so I have to write public to "The author of
snippet ..."

Thanks,
  Harm

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


Re: Delete new LSR-snippet?

2016-12-23 Thread Alexander Kobel

On 2016-12-23 20:48, Trevor Daniels wrote:

I seem to remember a post or maybe an LSR entry for placing
divisi arrows at the end of a staff.  Maybe this could be
adapted to achieve the same effect more reliably?

Found it  - LSR 650.  It modifies the barline stencil.


IIRC: How come that a bunch of people digs out my ancient snippets these 
days? ;-)



Hope it helps!
Alexander

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


Re: \arrow markup command

2016-12-23 Thread Thomas Morley
2016-12-23 23:06 GMT+01:00 Simon Albrecht :
> Hello again,
>
> I created a better preview image and on the way noticed that a small
> adjustment is necessary, so that the line doesn’t obstruct the finer tip of
> the filled arrow head.
>
> Best, Simon

Hi Simon,

For now some remarks, too late dive in deeper.

Why not keep the simple arrow-head-markup-command? In the past I
already combined it with curves. Maybe sometimes with dotted or dashed
lines as well.

I'd prefer different args for arrow-markup, not angle/length but a
destination, i.e. a target-point given by a pair of x,y-coordinates.
Would be more in line with other line-drawing markup-commands.

Cheers,
  Harm

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


Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

2016-12-23 Thread Knut Petersen

Dear all,


I just uploaded Knut's patch (with minor reformatting, to obey the 
80-char-per-line limit) to Rietveld; see
  https://codereview.appspot.com/313240043
The corresponding issue can be found at
  https://sourceforge.net/p/testlilyissues/issues/5018/ 


I missed the warnings hidden by the attached patch (they were masked by some 
other code
in my private git tree).

cu,
 Knut

>From 50d9ab59c3c332578f338ea5ff01427a4ae553e8 Mon Sep 17 00:00:00 2001
From: Knut Petersen 
Date: Fri, 23 Dec 2016 23:44:30 +0100
Subject: [PATCH] Lyric autoextenders: Silence some warnings

The warnings are caused by "" and more unusual constructs.

Signed-off-by: Knut Petersen 
---
 lily/self-alignment-interface.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lily/self-alignment-interface.cc b/lily/self-alignment-interface.cc
index 512f970e0e..f204f2a810 100644
--- a/lily/self-alignment-interface.cc
+++ b/lily/self-alignment-interface.cc
@@ -59,7 +59,7 @@ Self_alignment_interface::aligned_on_self (Grob *me, Axis a, bool pure, int star
   // However, empty extent and non-empty stencil would be suspicious.
   if (!ext.is_empty ())
 return scm_from_double (- ext.linear_combination (scm_to_double (align)));
-  else if (me->get_stencil ())
+  else if (me->get_stencil () && me->name() != "LyricText")
 warning (me->name () + " has empty extent and non-empty stencil.");
 }
   return scm_from_double (0.0);
@@ -141,7 +141,7 @@ Self_alignment_interface::aligned_on_parent (Grob *me, Axis a)
   // However, empty extent and non-empty stencil would be suspicious.
   if (!ext.is_empty ())
 x -= ext.linear_combination (scm_to_double (self_align));
-  else if (me->get_stencil ())
+  else if (me->get_stencil () && me->name() != "LyricText")
 warning (me->name () + " has empty extent and non-empty stencil.");
 }
 
@@ -150,7 +150,7 @@ Self_alignment_interface::aligned_on_parent (Grob *me, Axis a)
   // See comment above.
   if (!he.is_empty ())
 x += he.linear_combination (scm_to_double (par_align));
-  else if (him->get_stencil ())
+  else if (him->get_stencil () && him->name() != "LyricText")
 warning (him->name () + " has empty extent and non-empty stencil.");
 }
 
-- 
2.11.0

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


Re: Delete new LSR-snippet?

2016-12-23 Thread Knut Petersen

Hi Trevor!

I seem to remember a post or maybe an LSR entry for placing
divisi arrows at the end of a staff.  Maybe this could be
adapted to achieve the same effect more reliably?

Found it  - LSR 650.  It modifies the barline stencil.


Something like the following code  could be a base:

\version "2.19.53"

mpBarLine = {
  \once \override Staff.BarLine #'stencil =
#(lambda (grob) (ly:stencil-combine-at-edge (ly:bar-line::print grob) X 
RIGHT
(grob-interpret-markup grob mpBarLineMarkup) 0))
  \break
}

mpBarLineMarkup = \markup \with-dimensions #'(0 . 0) #'(0 . 0) {
  \line {\hspace #3 \override #'(line-width . 20)
 \justify{This is a marginal note}
  }
}

\paper {
  left-margin = 2\cm
  line-width = 14\cm
  indent = 0\cm
  ragged-right = ##f
}

{
  \repeat unfold 16 { c'' 4 } \break
  \repeat unfold 16 { c'' 4 } \mpBarLine
  \repeat unfold 16 { c'' 4 } \bar "|."
}

\layout {}



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


Re: \arrow markup command

2016-12-23 Thread Simon Albrecht

Hello again,

I created a better preview image and on the way noticed that a small 
adjustment is necessary, so that the line doesn’t obstruct the finer tip 
of the filled arrow head.


Best, Simon


arrow.pdf
Description: Adobe PDF document
\version "2.19.53"

\header {
  tagline = ##f
}
\paper {
  #(set-paper-size "a10")
}

#(define (number-or-boolean? arg)
   (or (number? arg)
   (boolean? arg)))

#(define-markup-command (arrow layout props ang length filled)
   (number? number-or-boolean? boolean?)
   #:category graphic
   "Draw an arrow of length @var{length}.
Use filled head if @var{filled} is true.
Rotate by @var{ang} degrees; default points to the right.
In order to draw an arrowhead only, use @code{##f} for @var{length}.

@lilypond[verbatim,quote]
\\markup {
  \\arrow #0 #3 ##f
  \\arrow #-60 #5 ##t
  \\arrow #90 ##f ##t
}
@end lilypond
"
   (let* ((head (markup #:with-color green #:arrow-head X 1 filled))
  (adjust -.5)
  (arro (if length
(markup
 #:combine
 head
 #:translate (cons adjust 0)
 #:override '(thickness . 1.5)
 #:draw-line (cons (- adjust length) 0))
head)))
 (interpret-markup layout props
   (markup
#:rotate ang
arro

\markup {
  \hspace #5
  \arrow #0 #3 ##f
  \arrow #-60 #5 ##t
  \arrow #90 ##f ##t
}___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

2016-12-23 Thread Simon Albrecht

On 23.12.2016 22:36, Alexander Kobel wrote:

The corresponding issue can be found at
https://sourceforge.net/p/testlilyissues/issues/5018/


…which I took the liberty to merge with 
.

Thanks for the work and happy holidays as well!

Best, Simon

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


\arrow markup command

2016-12-23 Thread Simon Albrecht

Hello,

I have just been annoyed by the fact that it takes four commands 
(\combine, \arrow-head, \override, and \draw-line) to draw an acceptable 
arrow-head (\override is to match the thickness of the line to the Feta 
glyph), so I proceeded to code an \arrow markup command simplifying the use.


Find the code with an example attached.

I will put it up for review as normal, but I want to ask one design 
question first:


It struck me as simplest to have this function supersede the \arrow-head 
function. I didn’t fully carry that out in the example, but I think the 
use cases for printing a single arrow-head are much fewer than for 
printing a complete arrow, and there are already so many markup 
functions around, that I think it would be better to have only one 
function. [1]


Though this actually raises a second question: Why does the Feta font 
have one glyph for each of the 4 directions in which an arrow head 
generated with \arrow-head can point? Why not simply rotate one glyph in 
the first place? (I’m sure the Metafont code does just that, though it 
would strike me more logical to do it on a ‘higher’ level.)


Best, Simon

[1] One could probably write a convert-ly rule as well (sorry, I can’t, 
not knowing Python), though such a rule would have to compute a rotation 
angle from the axis and dir properties:


axis 0/X  dir 1/RIGHT  ->  ang 0
axis 0/X  dir -1/LEFT  ->  ang 180
axis 1/Y  dir 1/UP ->  ang 90
axis 1/Y  dir -1/DOWN  ->  ang -90

\version "2.19.53"

#(define (number-or-boolean? arg)
   (or (number? arg)
   (boolean? arg)))

#(define-markup-command (arrow layout props ang length filled)
   (number? number-or-boolean? boolean?)
   #:category graphic
   "Draw an arrow of length @var{length}.
Use filled head if @var{filled} is true.
Rotate by @var{ang} degrees; default points to the right.
In order to draw an arrowhead only, use @code{##f} for @var{length}.

@lilypond[verbatim,quote]
\\markup {
  \\arrow #0 #3 ##f
  \\arrow #-60 #5 ##t
  \\arrow #90 ##f ##t
}
@end lilypond
"
   (let* ((head (markup #:arrow-head X 1 filled))
  (arro (if length
(markup
 #:combine
 head
 #:override '(thickness . 1.5)
 #:draw-line (cons (- length) 0))
head)))
 (interpret-markup layout props
   (markup
#:rotate ang
arro

\markup {
  \arrow #0 #3 ##f
  \arrow #-60 #5 ##t
  \arrow #90 ##f ##t
}___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH [uploaded to Rietveld]] Automatic lyric extenders

2016-12-23 Thread Alexander Kobel

Dear all,

I just uploaded Knut's patch (with minor reformatting, to obey the 
80-char-per-line limit) to Rietveld; see

  https://codereview.appspot.com/313240043
The corresponding issue can be found at
  https://sourceforge.net/p/testlilyissues/issues/5018/

Thanks again Knut for this great contribution!


Since I assume that most of you will devote the next 72 or so hours to 
other stuff than Lily: merry holidays to all of you!



Cheers,
Alexander


On 2016-12-22 15:26, Alexander Kobel wrote:

On 2016-12-22 14:53, Knut Petersen wrote:

Hi Alexander et al.!

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process
now. Knut, are you familiar with the git cl proceedings? If not,
it’s explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just
a few days ago, so my knowledge is scarce, but fresh.


As I will not do it anybody is invited to put that patch on
Rietveld. You might call me pigheaded, but I don't accept to be
forced to use a google account. Of course I will react to any
reasonable change request.


I get your point. I dislike it as well, but gave in to the pressure (not
here, but elsewhere) long ago. I try to keep contact data and calendar
away from the big G as much as possible, and only use the mail address
to forward to another, but still. Go{d,ogle} alone knows what they
harvest...

Anyway, I can take care of uploading the patch. Will do so in the
evening, most probably.


Cheers,
Alexander

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


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


Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

2016-12-23 Thread perpeduumimmobile

Reviewers: ,

Message:
For the sake of completeness: deserves an entry in changes.tely (TBD
when the syntax discussion is over that I expect to start some time
soon...)

Description:
Automatic LyricExtenders

As written and communicated by Knut Peterson.
For reference, see the threads
  http://lists.gnu.org/archive/html/lilypond-devel/2016-12/msg00223.html
  http://lists.gnu.org/archive/html/lilypond-devel/2016-12/msg00121.html
  http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00523.html
  http://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00303.html
(sorry, this discussion grew quite long in the meantime).

This is a genuine Request For Comments at the current point in time.

Please review this at https://codereview.appspot.com/313240043/

Affected files (+235, -188 lines):
  M Documentation/learning/common-notation.itely
  M Documentation/notation/vocal.itely
  M lily/extender-engraver.cc
  M lily/lyric-extender.cc
  M ly/music-functions-init.ly
  M scm/define-grob-properties.scm
  M scm/define-grobs.scm
  M scm/music-functions.scm



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


Re: Delete new LSR-snippet?

2016-12-23 Thread Trevor Daniels

Thomas Morley wrote Friday, December 23, 2016 11:42 AM

> with
> http://lsr.di.unimi.it/LSR/Item?u=1=1049
> a new snippet arrived.
> Though, it only demonstrates how to use 'extra-offset, imho.
> I tend to delete it, otoh I don't want to scare away a possible new
> contributor...
> 
> Opinions?

Not sure how else one would place text to the right of a staff,
but this doesn't seem to be a very reliable method.  So I'd
also recommend deleting it.

I seem to remember a post or maybe an LSR entry for placing
divisi arrows at the end of a staff.  Maybe this could be 
adapted to achieve the same effect more reliably?

Found it  - LSR 650.  It modifies the barline stencil.

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


Re: Delete new LSR-snippet?

2016-12-23 Thread Simon Albrecht

On 23.12.2016 12:42, Thomas Morley wrote:

with
http://lsr.di.unimi.it/LSR/Item?u=1=1049
a new snippet arrived.
Though, it only demonstrates how to use 'extra-offset, imho.


And very poorly – how the staff lines resurface after the text script…
This is definitely not showcase-able and I agree about deleting it.
Maybe you can write a kind of encouraging message to the contributor?

Best, Simon

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


Re: LilyDev 5.0 released

2016-12-23 Thread Paul

On 12/23/2016 12:00 AM, Federico Bruni wrote:

Il giorno gio 22 dic 2016 alle 18:48, Paul  ha 
scritto:
I gave it a try.  Installation seemed to go fine, but then on booting 
it up I get past the GRUB screen and then it goes to a black 
unresponsive screen at "loading initial ramdisk..."  Haven't had a 
chance to troubleshoot it further.  I'm attaching the log file in 
case anyone wants to take a look.


(I'm on Ubuntu 16.04 and Virtual Box version 5.0.24_Ubuntu r108355)  
(I'm using LilyDev on Ubuntu because I'm new to GNU/Linux and already 
familiar with LilyDev.)


Hi Paul

In the log I see this line:

00:00:00.447635   PAE - Physical Address 
Extension   = 0 (0)


which makes me think that you've not enabled PAE?
There's a warning in the CG about this:


Hi Federico, I double-checked and I do/did have the box checked to 
enable PAE.  I tried un-checking it and Virtual Box complained about it 
right away upon starting up the VM.


So when I get a chance I may try James' approach of using a newer 
version of Virtual Box, or else your approach with libvirt.  (No time at 
the moment though...)


Thanks,
-Paul

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


Re: LilyDev 5.0 released

2016-12-23 Thread Paul

On 12/22/2016 01:37 PM, James wrote:
I also tried to install LilyDev 5.0 last week - I use Ubuntu 16.0.4 
with the latest 64 bit vBox 5.1.x test build (112223 w Ext pack 112433).


Hi James,  Thanks for the info and tips.  I may try your approach with a 
newer version of Virtual Box when I get a chance.


Cheers,
-Paul



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


GUB bug in package dependencies determination?

2016-12-23 Thread Hans Aikema
Hello developers,

another topic in my quest for building a minimal dockerized GUB. A first look 
on the following error message makes me suspect that GUB’s package dependency 
management is somewhat broken. The error was obtained by trying to run a make 
lilypond in a succesfully bootstrapped GUB running in my ubuntu:xenial 
container.

The container was built from the official ubuntu:xenial container by using the 
following Dockerfile:

# Lilypond GUB build environment as a Docker container
FROM ubuntu:xenial

# Install prerequisites for GUB
RUN apt-get update && \
apt-get --no-install-recommends install -y \
g++-multilib  \
git  \
ca-certificates  \
zip  \
unzip  \
make  \
python  \
file  \
xz-utils  \
gettext  \
curl  \
p7zip-full  \
texlive-xetex \
&& \
apt-get clean && \
rm -rf /var/lib/apt/lists/* && \
useradd -ms /bin/bash gub

#Switch to gub user
USER gub
WORKDIR /home/gub

# Clone current GUB
#RUN git clone git://github.com/gperciva/gub.git
RUN git clone git://github.com/aikebah/gub.git &&\
# Bootstrap the GUB environment
cd gub && make bootstrap &&\
mkdir -p /home/gub/gub/regtests && \
curl 
http://download.linuxaudio.org/lilypond/binaries/test-output/lilypond-${REGTESTS_CURRENT}.test-output.tar.bz2
 -o regtests/lilypond-${REGTESTS_CURRENT}.test-output.tar.bz2 && \ 
touch regtests/ignore


It appears to me that the error will be triggered by the 
--no-install-recommends option of apt-get install, which leaves out the 
recommended packages (and thus among others the documentation packages of glibc 
in the environment on top of which GUB is being run. Something which most 
developers will not do, as they likely want the glibc doc at hand; but for a 
docker container you’d rather leave out all optional files to keep 
containersize at a minimum (will also likely move GUB out to a mounted volume 
later on, as I suspect it will trigger lots of useless ‘copy-on-write’ space 
consumption when using such a container in practice, but that’s an excercise 
for later when the base container is working fine)

I will look into this further as well, but maybe someone with active knowledge 
of GUB is faster in spotting where the decision stems from to try and uninstall 
a not present glibc-doc package (I still have to find my way in both Python and 
GUB, using my generic programming skills learned in university Computer Science)

(This dockerfile would result in a broken test later on in any case since I 
accidentally removed an environment setting REGTESTS_CURRENT) that makes the 
‘downloaded regtests’ be the text of an http-404 response stored as 
lilypond-.test-output.tar.bz2; but that part has nothing to do with the current 
package-dependencies induced failure of GUB to do a build)



gub.log.gz
Description: GNU Zip compressed data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Delete new LSR-snippet?

2016-12-23 Thread Phil Holmes
- Original Message - 
From: "Thomas Morley" 

To: "lilypond-devel" 
Sent: Friday, December 23, 2016 11:42 AM
Subject: Delete new LSR-snippet?



Hi all,

with
http://lsr.di.unimi.it/LSR/Item?u=1=1049
a new snippet arrived.
Though, it only demonstrates how to use 'extra-offset, imho.
I tend to delete it, otoh I don't want to scare away a possible new
contributor...

Opinions?

Cheers,
 Harm



I think I'd be tempted to delete it.

--
Phil Holmes

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


Delete new LSR-snippet?

2016-12-23 Thread Thomas Morley
Hi all,

with
http://lsr.di.unimi.it/LSR/Item?u=1=1049
a new snippet arrived.
Though, it only demonstrates how to use 'extra-offset, imho.
I tend to delete it, otoh I don't want to scare away a possible new
contributor...

Opinions?

Cheers,
  Harm

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