Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)

2014-01-12 Thread Devon Schudy
David Kastrup wrote:
> At any rate, I'm not really happy with the macro usage at top level
> here: I think it would be better if the basic assembly was rather done
> by music or Scheme functions

I'm not really happy with it either, because users have no hope of
modifying it or learning from it. The macro-generated version is much
shorter, but that's not worth the inability to copy and modify. I
rewrote it using functions, but that's not much easier for users, and
is almost as long as the original version with no attempt to factor
out the repetition.

The reason for the macros is so the definedness of variables can be
checked at macroexpand time, to avoid compiling references to
undefined names — that works in Guile 1.8 but not in Guile 2, and it's
bad style anyway. But we can avoid the `defaulting` macro by simply
defining the variables iff they're not already. Guile 2's define-once
does exactly this, and it's easy to recreate it in Guile 1.8. (This
also fixes the problem with \Layout.)

Using define-once instead of `defaulting` and removing the
staff-making functions leaves it almost identical to Trevor's original
version, except that there's no separate init file, and there's one
conditional for whether to have two voices per staff.

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


Re: 3.0?

2014-01-12 Thread Janek Warchoł
2014/1/12 Carl Peterson :
> What I would *ultimately* like is the ability for someone to visually write
> each part on separate staves (or using two staves with two voices each),
> then those parts are translated into the template without any direct code
> manipulation. The visual interface would be like the single-line view in
> Finale (where it's not trying to deal with line lengths/spacing, etc.). This
> is basically what I do in MuseScore or Finale Notepad from the compositional
> side, but I'm trying to find the most efficient workflow to go from that to
> my template. I don't know if it's practical, possible, or what. I don't know
> whether this would be a Frescobaldi thing or a Denemo thing.


I think this is exactly a Denemo thing.

best,
Janek

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


Re: Issue 3783: track default tremolo type in the parser (issue 50400044)

2014-01-12 Thread benko . pal

LGTM

https://codereview.appspot.com/50400044/

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


Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)

2014-01-12 Thread dak

On 2014/01/12 08:05:30, Devon Schudy wrote:

David Kastrup wrote:
> At any rate, I'm not really happy with the macro usage at top level
> here: I think it would be better if the basic assembly was rather

done

> by music or Scheme functions



I'm not really happy with it either, because users have no hope of
modifying it or learning from it. The macro-generated version is much
shorter, but that's not worth the inability to copy and modify. I
rewrote it using functions, but that's not much easier for users, and
is almost as long as the original version with no attempt to factor
out the repetition.



The reason for the macros is so the definedness of variables can be
checked at macroexpand time, to avoid compiling references to
undefined names — that works in Guile 1.8 but not in Guile 2, and it's
bad style anyway.


Checking for the definedness of variables at macroexpand time?  Ugh.

How about
define-variables =
#(define-void-function (parser location syms) (symbol-list?)
   (for-each
  (lambda (sym)
(if (null? (ly:parser-lookup parser sym))
(ly:parser-define parser sym *unspecified*)

If you write \name for a variable with value *unspecified*, it simply
disappears in the lexer.


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


Re: 3.0?

2014-01-12 Thread David Kastrup
Janek Warchoł  writes:

> 2014/1/12 Carl Peterson :
>> What I would *ultimately* like is the ability for someone to visually
>> write each part on separate staves (or using two staves with two
>> voices each), then those parts are translated into the template
>> without any direct code manipulation. The visual interface would be
>> like the single-line view in Finale (where it's not trying to deal
>> with line lengths/spacing, etc.). This is basically what I do in
>> MuseScore or Finale Notepad from the compositional side, but I'm
>> trying to find the most efficient workflow to go from that to my
>> template. I don't know if it's practical, possible, or what. I don't
>> know whether this would be a Frescobaldi thing or a Denemo thing.
>
>
> I think this is exactly a Denemo thing.

Well, the question is how much one could pluginize Denemo.  Like,
marking a passage in Emacs which then turns into a small Denemo display
window (the keyboard commands would still travel via Emacs) and back
again...

This could be interesting technology...

-- 
David Kastrup

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


Re: 3.0?

2014-01-12 Thread Urs Liska


"Janek Warchoł"  schrieb:
>2014/1/12 Carl Peterson :
>> What I would *ultimately* like is the ability for someone to visually
>write
>> each part on separate staves (or using two staves with two voices
>each),
>> then those parts are translated into the template without any direct
>code
>> manipulation. The visual interface would be like the single-line view
>in
>> Finale (where it's not trying to deal with line lengths/spacing,
>etc.). This
>> is basically what I do in MuseScore or Finale Notepad from the
>compositional
>> side, but I'm trying to find the most efficient workflow to go from
>that to
>> my template. I don't know if it's practical, possible, or what. I
>don't know
>> whether this would be a Frescobaldi thing or a Denemo thing.
>
>
>I think this is exactly a Denemo thing.

Please add your doubts to the Frescobaldi issue.

Urs

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


-- 
Urs Liska
openlilylib.org

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


Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)

2014-01-12 Thread tdanielsmusic

On 2014/01/12 08:59:46, dak wrote:


How about
define-variables =
#(define-void-function (parser location syms) (symbol-list?)
(for-each
   (lambda (sym)
 (if (null? (ly:parser-lookup parser sym))
 (ly:parser-define parser sym *unspecified*)



If you write \name for a variable with value *unspecified*, it simply

disappears

in the lexer.


Thanks both.  This issue is closed, but I'll check out
this solution and raise a new issue to incorporate it

Trevor


https://codereview.appspot.com/41990043/

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


Patches to push

2014-01-12 Thread Urs Liska
Hi devels,

would please someone push the attached patches to staging?

I've chained them on top of staging
(19fa6068cf3a7c5f02c13d5b57be895665da00bf) by cherry-picking them to
_one_ branch (not single branches for each patch)

and successfully ran make website.

Thanks
Urs
>From f23a749ea217b4d683a7802c3d764d4c16ab30cb Mon Sep 17 00:00:00 2001
From: Urs Liska 
Date: Tue, 7 Jan 2014 12:18:35 +0100
Subject: [PATCH 1/5] Issue 3785: Web:Examples: Enclose in box

I think the pages below Introduction (and probably Community too)
should consistently start with a box and a subheading,
because there is no eye-catching page heading.

This is _one_ option to do that for the Examples page.
Others would be:

- Make that @div only enclose the introductory paragraph
- enclose the introductory paragraph _and_
  - add a headingless div around the examples _or_
  - add a div with @subheading "Gallery"
---
 Documentation/web/introduction.itexi |5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/web/introduction.itexi b/Documentation/web/introduction.itexi
index 5d2f8c6..1ec99ed 100644
--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -296,6 +296,10 @@ already decided to try LilyPond, first read about our
 @node Examples
 @unnumberedsec Examples
 
+@divClass{column-center-top}
+
+@subheading Beautiful examples
+
 LilyPond is a powerful and flexible tool for engraving tasks of
 all kinds.  Please browse our gallery of examples and be inspired!
 
@@ -422,6 +426,7 @@ contributed by Hu Haipeng, a blind composer.
 @exampleImage{orchestra}
 @newsEnd
 
+@divEnd
 
 @divClass{column-center-bottom}
 @subheading Where now?
-- 
1.7.10.4

>From 118023885a557ad8ae177d60ddc00502bb851eb9 Mon Sep 17 00:00:00 2001
From: Urs Liska 
Date: Tue, 7 Jan 2014 12:30:54 +0100
Subject: [PATCH 2/5] Issue 3785: Web:Productions: Add title box

As stated in https://codereview.appspot.com/48450044/
I think the Introduction pages should have a title box
giving the user a first idea about the page.

In this case the visitor (currently) would reach the page,
doesn't see a heading and is faced two boxes,
"Concerts" and "Published sheet music" without further introduction.
---
 Documentation/web/introduction.itexi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/web/introduction.itexi b/Documentation/web/introduction.itexi
index 1ec99ed..bfd02c0 100644
--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -573,6 +573,16 @@ try LilyPond, first read about our @ref{Text input}.
 @node Productions
 @unnumberedsec Productions
 
+@divClass{column-center-top}
+
+@subheading Productions using LilyPond
+
+Here you can read about people who actually use LilyPond
+in their productions, be it for performances of their
+music or as published scores.
+
+@divEnd
+
 @divClass{column-left-top}
 @subheading Concerts
 
-- 
1.7.10.4

>From 609db261fa0c644032a0d63514cb296cfeae02f1 Mon Sep 17 00:00:00 2001
From: Urs Liska 
Date: Tue, 7 Jan 2014 12:35:32 +0100
Subject: [PATCH 3/5] Issue 3785: Web:Reviews: Add title box

Same as https://codereview.appspot.com/38560044/
The Introduction pages should have a "title box"
---
 Documentation/web/introduction.itexi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/web/introduction.itexi b/Documentation/web/introduction.itexi
index bfd02c0..189d567 100644
--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -731,6 +731,12 @@ If you've already decided to try LilyPond, first read about our
 @node Reviews
 @unnumberedsec Reviews
 
+@divClass{column-center-top}
+@subheading What do people say about LilyPond?
+
+@divEnd
+
+
 @divClass{column-left-top}
 @subheading Published articles
 
-- 
1.7.10.4

>From d0a1f2145b6c8335d1cbf1f4aa2baade791829d1 Mon Sep 17 00:00:00 2001
From: Urs Liska 
Date: Tue, 7 Jan 2014 12:51:02 +0100
Subject: [PATCH 4/5] Issue 3785:Web:Background: Reword intr. paragraph

I've always found this page confusing because I didn't understand
why there is this "placeholder" page.
This commit addresses this by making the "manual" issue explicit.

Additionally I consider it more useful to _first_ tell the reader
what it is and _then_ advise him to skip the essay instead of
_immediately_ telling him "Probably you won't want to read this".
If it is necessary to have the link at the end of a paragraph
(and not only of a sentence) I'd simply insert a new paragraph
after the link.
---
 Documentation/web/introduction.itexi |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/web/introduction.itexi b/Documentation/web/introduction.itexi
index 189d567..af0c9f7 100644
--- a/Documentation/web/introduction.itexi
+++ b/Documentation/web/introduction.itexi
@@ -556,9 +556,11 @@ LilyPond, first read about our @ref{Text input}.
 We have an extensive essay describing computational aesthetics:
 the art of creating beauty with a c

Re: Patches to push

2014-01-12 Thread David Kastrup
Urs Liska  writes:

> Hi devels,
>
> would please someone push the attached patches to staging?
>
> I've chained them on top of staging
> (19fa6068cf3a7c5f02c13d5b57be895665da00bf) by cherry-picking them to
> _one_ branch (not single branches for each patch)
>
> and successfully ran make website.

Pushed this to staging as commits

commit b86682d0cd34af40f0436ad97a2659a827a698b5
Author: Urs Liska 
Date:   Tue Jan 7 12:51:02 2014 +0100

Issue 3785:Web:Introduction: Reword "Our Goal" box

The content of this box was somewhat confusing and inconsistent. See
http://lists.gnu.org/archive/html/lilypond-devel/2014-01/msg00011.html

This commit tries to incorporate the suggestions made in this thread
as far as I considered appropriate.

commit 52a5d6c1a6bd722b9f04950b2d9ba6cc7f25d546
Author: Urs Liska 
Date:   Tue Jan 7 12:51:02 2014 +0100

Issue 3785:Web:Background: Reword intr. paragraph

I've always found this page confusing because I didn't understand
why there is this "placeholder" page.
This commit addresses this by making the "manual" issue explicit.

Additionally I consider it more useful to _first_ tell the reader
what it is and _then_ advise him to skip the essay instead of
_immediately_ telling him "Probably you won't want to read this".
If it is necessary to have the link at the end of a paragraph
(and not only of a sentence) I'd simply insert a new paragraph
after the link.

commit b0ec9ceced91d8dc9a2c6a95c71dbf936e33699d
Author: Urs Liska 
Date:   Tue Jan 7 12:35:32 2014 +0100

Issue 3785: Web:Reviews: Add title box

Same as https://codereview.appspot.com/38560044/
The Introduction pages should have a "title box"

commit ec36bdf4bd3a8a2091baa1685fd54a4c6a570fb4
Author: Urs Liska 
Date:   Tue Jan 7 12:30:54 2014 +0100

Issue 3785: Web:Productions: Add title box

As stated in https://codereview.appspot.com/48450044/
I think the Introduction pages should have a title box
giving the user a first idea about the page.

In this case the visitor (currently) would reach the page,
doesn't see a heading and is faced two boxes,
"Concerts" and "Published sheet music" without further introduction.

commit 4eba488b39eb3c262735d33b3e4ea6676a962abb
Author: Urs Liska 
Date:   Tue Jan 7 12:18:35 2014 +0100

Issue 3785: Web:Examples: Enclose in box

I think the pages below Introduction (and probably Community too)
should consistently start with a box and a subheading,
because there is no eye-catching page heading.

This is _one_ option to do that for the Examples page.
Others would be:

- Make that @div only enclose the introductory paragraph
- enclose the introductory paragraph _and_
  - add a headingless div around the examples _or_
  - add a div with @subheading "Gallery"


Please update the issue accordingly.

-- 
David Kastrup

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


Re: PATCHES: Countdown for January 15th - 06:00 GMT

2014-01-12 Thread Janek Warchoł
Hi,

2014/1/12 James 

> Hello
>
> The following patches have been at 'please push' for the last 3 countdowns
> (i.e. over 9 days), and I am not seeing anything obvious that leads me to
> believe that their is 'Needs Work' on them. I am seeing recent emails from
> them on the lists and so assume they would also be getting the tracker
> emails too.
>
> 
> 3761
>  Enhancement
> Keith Ohara push LeftEdge no longer takes up space  
> 3753
>  Enhancement
> Carl Peterson push Patch: Cleanup of ugly MI and SOL shaped noteheads
> 3764
>  Enhancement
> Janek Warchol push Patch: Swap 'polite' and 'l2r' variable definitions
> If the authors don't want to push, can they change the label to something
> more appropriate? Thank you.
>

I'm sorry, i'm very busy and didn't have time to look at it properly :(

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


Re: How many slurs in LilyPond need adjusting? (was: New, more powerful version of \shape!)

2014-01-12 Thread Janek Warchoł
2014/1/11 Kieren MacMillan :
> Hi Janek,
>
> Thank you for all your continuing and wonderful work on curves in particular, 
> and Lilypond in general!

Why, thanks! I'm not sure if you're not exaggerating, i've been
failing to keep up recently and i think i failed some people because
of my lack of time :(

> 1. Would you consider putting all your tweaks and shortcuts in a file — on 
> GitHub, maybe? ;) — so that we can all benefit from your expertise?

If you mean tie and slur tweaks, they were added in a comment under
the post.  As for the rest of the functions, yes, i do intend to
publish them in openlilylib/snippets.

> 2. When might HDLCCO (the "highly-desirable Lilypond curve-code overhaul”) 
> happen?

No idea.  It will definitely not happen before March (end of my
internship), and i don't know how my situation will look like after
that.  I hope that i will have some time no later than summer
sorry :-/

best,
Janek

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


Re: Patches to push

2014-01-12 Thread James

On 12/01/14 09:43, David Kastrup wrote:

Urs Liska  writes:


Hi devels,

would please someone push the attached patches to staging?

I've chained them on top of staging
(19fa6068cf3a7c5f02c13d5b57be895665da00bf) by cherry-picking them to
_one_ branch (not single branches for each patch)

and successfully ran make website.

Pushed this to staging as commits

...


Please update the issue accordingly.


I've done that.

However Urs you will need to close your own reitvelds.

http://codereview.appspot.com/48360044

http://codereview.appspot.com/48450044

http://codereview.appspot.com/38560044

http://codereview.appspot.com/48460044

regards


James

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


Re: Patches to push

2014-01-12 Thread Urs Liska


James  schrieb:
>On 12/01/14 09:43, David Kastrup wrote:
>> Urs Liska  writes:
>>
>>> Hi devels,
>>>
>>> would please someone push the attached patches to staging?
>>>
>>> I've chained them on top of staging
>>> (19fa6068cf3a7c5f02c13d5b57be895665da00bf) by cherry-picking them to
>>> _one_ branch (not single branches for each patch)
>>>
>>> and successfully ran make website.
>> Pushed this to staging as commits
>>
>> ...
>>
>>
>> Please update the issue accordingly.
>>
>I've done that.
>
>However Urs you will need to close your own reitvelds.
>
>http://codereview.appspot.com/48360044
>
>http://codereview.appspot.com/48450044
>
>http://codereview.appspot.com/38560044
>
>http://codereview.appspot.com/48460044
>
>regards
>
>
>James

Thanks.
I'll take care of it ASAP (= when I'm online at the PC again, perhaps not 
today).

Urs

-- 
Urs Liska
openlilylib.org

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


Re: fixing German's Wikipedia entry of LilyPond

2014-01-12 Thread Phil Holmes
- Original Message - 
From: James

To: Werner LEMBERG ; Devel

The pedal symbol clashes with the dynamic in bar 3 and there is a clash
of a tuplets in the second upper bar with accidentals - which I believe is



http://code.google.com/p/lilypond/issues/detail?id=3766



Anyway, I have done as much as I can. Attached the before and
after files for anyone else who wants to finish this off.



James


The pedal / dynamic clash in bar 3 is pretty bad: is this a known bug?

--
Phil Holmes




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


Re: fixing German's Wikipedia entry of LilyPond

2014-01-12 Thread Phil Holmes
- Original Message - 
From: "Phil Holmes" 
To: "James" ; "Werner LEMBERG" ; "Devel" 


Sent: Sunday, January 12, 2014 1:32 PM
Subject: Re: fixing German's Wikipedia entry of LilyPond


- Original Message - 
From: James

To: Werner LEMBERG ; Devel

The pedal symbol clashes with the dynamic in bar 3 and there is a clash
of a tuplets in the second upper bar with accidentals - which I believe 
is



http://code.google.com/p/lilypond/issues/detail?id=3766



Anyway, I have done as much as I can. Attached the before and
after files for anyone else who wants to finish this off.



James


The pedal / dynamic clash in bar 3 is pretty bad: is this a known bug?

--
Phil Holmes



Fairly certain the clash is caused by the crossing music.  I'm working on an 
improved version, closer to the version on youtube.


--
Phil Holmes 



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


Re: fixing German's Wikipedia entry of LilyPond

2014-01-12 Thread Carl Sorensen


On 1/12/14 8:04 AM, "Phil Holmes"  wrote:

>- Original Message -
>From: "Phil Holmes" 
>To: "James" ; "Werner LEMBERG" ; "Devel"
>
>Sent: Sunday, January 12, 2014 1:32 PM
>Subject: Re: fixing German's Wikipedia entry of LilyPond
>
>
>
>Fairly certain the clash is caused by the crossing music.  I'm working on
>an 
>improved version, closer to the version on youtube.

Is there any reason not to put the tuplet brackets on the upper staff in
bar 2 *below* the staff?  It seems to me they would be clearer that way.

Thanks,

Carl


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


Re: fixing German's Wikipedia entry of LilyPond

2014-01-12 Thread pls

On 12.01.2014, at 19:31, Phil Holmes  wrote:

> - Original Message - From: "Phil Holmes" 
> To: "Carl Sorensen" ; "James" ; 
> "Werner LEMBERG" ; "Devel" 
> Sent: Sunday, January 12, 2014 6:24 PM
> Subject: Re: fixing German's Wikipedia entry of LilyPond
> 
> 
>> - Original Message - From: "Phil Holmes" 
>> To: "Carl Sorensen" ; "James" ;
>> "Werner LEMBERG" ; "Devel" 
>> Sent: Sunday, January 12, 2014 3:19 PM
>> Subject: Re: fixing German's Wikipedia entry of LilyPond
>> 
>> 
>>> - Original Message - From: "Carl Sorensen" 
>>> 
 Is there any reason not to put the tuplet brackets on the upper staff in
 bar 2 *below* the staff?  It seems to me they would be clearer that way.
 
 Thanks,
 
 Carl
>>> 
>>> If the version on YouTube is original (see attachment), then this has the
>>> tuplet markings over the staff.
>>> 
>>> It's also got a modern time signature style.  Anyone any idea how to do
>>> this?
>>> 
>>> --
>>> Phil Holmes
>>> 
>> 
>> Latest version is attached.  Needs dotted tuplet brackets, a bit of tidying
>> of positioning, alternative time signature format, move of clef in LH of 2nd
>> bar and I think it's done.
>> 
>> Can anyone help with any of these?
> 
> 
> Dotted tuplet brackets and positions tweaked.  Think this is good to go for 
> now?
Looks good!

Here is a proposal for the positioning of the time signature:
\version "2.18.0"

\relative c'' {
  \override Staff.TimeSignature #'font-size = #20
  \override Staff.TimeSignature #'extra-offset = #'(0 . -20)
  \numericTimeSignature
  c
}

hth
patrick


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


Re: fixing German's Wikipedia entry of LilyPond

2014-01-12 Thread Janek Warchoł
2014/1/12 pls :
>
> On 12.01.2014, at 19:31, Phil Holmes  wrote:
>
>> - Original Message - From: "Phil Holmes" 
>>> Latest version is attached.  Needs dotted tuplet brackets, a bit of tidying
>>> of positioning, alternative time signature format, move of clef in LH of 2nd
>>> bar and I think it's done.
>>>
>>> Can anyone help with any of these?
>>
>>
>> Dotted tuplet brackets and positions tweaked.  Think this is good to go for 
>> now?\
>
> Here is a proposal for the positioning of the time signature:
> \version "2.18.0"
>
> \relative c'' {
>   \override Staff.TimeSignature #'font-size = #20
>   \override Staff.TimeSignature #'extra-offset = #'(0 . -20)
>   \numericTimeSignature
>   c
> }

Let's not use hard-coded offsets please, they are unlilypondish and
will break at first opportunity.  Rather, use a Dynamics context with
Time sig engraver like this:

meter =
\new Dynamics \with {
  \consists "Time_signature_engraver"
} {
  \override Dynamics.TimeSignature #'font-size = #6
  \time 2/8
  s4
  \time 3/8
  s4.*2
  \time 4/8
}

(and remove Time sig engraver from regular staves)

best,
J

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


Re: fixing German's Wikipedia entry of LilyPond

2014-01-12 Thread pls

On 12.01.2014, at 19:31, Phil Holmes  wrote:

> - Original Message - From: "Phil Holmes" 
> To: "Carl Sorensen" ; "James" ; 
> "Werner LEMBERG" ; "Devel" 
> Sent: Sunday, January 12, 2014 6:24 PM
> Subject: Re: fixing German's Wikipedia entry of LilyPond
> 
> 
>> - Original Message - From: "Phil Holmes" 
>> To: "Carl Sorensen" ; "James" ;
>> "Werner LEMBERG" ; "Devel" 
>> Sent: Sunday, January 12, 2014 3:19 PM
>> Subject: Re: fixing German's Wikipedia entry of LilyPond
>> 
>> 
>>> - Original Message - From: "Carl Sorensen" 
>>> 
 Is there any reason not to put the tuplet brackets on the upper staff in
 bar 2 *below* the staff?  It seems to me they would be clearer that way.
 
 Thanks,
 
 Carl
>>> 
>>> If the version on YouTube is original (see attachment), then this has the
>>> tuplet markings over the staff.
>>> 
>>> It's also got a modern time signature style.  Anyone any idea how to do
>>> this?
>>> 
>>> --
>>> Phil Holmes
>>> 
>> 
>> Latest version is attached.  Needs dotted tuplet brackets, a bit of tidying
>> of positioning, alternative time signature format, move of clef in LH of 2nd
>> bar and I think it's done.
>> 
>> Can anyone help with any of these?
> 
> 
> Dotted tuplet brackets and positions tweaked.  Think this is good to go for 
> now?
According to http://www.youtube.com/watch?v=BE2cMxY91rU a couple of dynamics 
are still missing:
-) in LH 1st bar there should be one \f above and one below the staff
-) in LH 2nd bar there should be a \mf under the e#
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Swap 'polite' and 'l2r' variable definitions (issue 42000044)

2014-01-12 Thread janek . lilypond

Reviewers: Keith,

Message:
Keith,

first of all: i apologize for the delay.  I shouldn't have put this up
for review when being too busy to reply in time, it's my mistake.  I
thought the patch was obvious (while it wasn't, and in fact i have
misunderstood the code) - i should know better now...

On 2014/01/01 04:21:51, Keith wrote:

The old variable definitions followed the corresponding words in the

options.


I see the bug in the old code, so left-to-right did not behave

symmetrically to

right-to-left.


Indeed, it seems to be a bug.


If the actual behavior fits the chosen options with your change, then

good

enough.


No, your comments made me realize that i was mistaken.  My patch is
wrong.


https://codereview.appspot.com/4244/diff/1/lily/axis-group-interface.cc

File lily/axis-group-interface.cc (left):



https://codereview.appspot.com/4244/diff/1/lily/axis-group-interface.cc#oldcode739

lily/axis-group-interface.cc:739: || (directive == ly_symbol2scm
("left-to-right-polite")));
The original l2r meant that one of the two "left-to-right-*" options

was chosen.

  Below, it means the objects closer to the left end of a line are

placed before

those further right, so the items on the left tend to go closer to the

staff

when there are overlaps.


I'm dumb as a brick.  I misunderstood the code...


https://codereview.appspot.com/4244/diff/1/lily/axis-group-interface.cc#oldcode790

lily/axis-group-interface.cc:790: if (x_extent[LEFT] <= last_end[dir]

&& polite)

The old "polite" meant that if we are about to place an object that

would

overlap one just placed, ask this object wait politely until we first

to place

all objects that fit without overlap.



Placing each object on the first pass was called "greedy".



(The old logic here was not quite right, because if we are placing

from right to

left -- the old 'ltr==false' -- then the test for overlap concerns the
x_extent[RIGHT] of the object we are about to place.  It should have

been

x_extent[ltr?LEFT:RIGHT] and the converse below.  As it is, the loop

is

quadratic, but does not hurt too badly because it handles objects in

just one

after-breaking line.)


Indeed, old code seems to be wrong, but my patch was wrong as well (i.e.
it was based on a misunderstanding and it's results weren't intended).
Thank goodness you reviewed it and stopped me from pushing!  I've made
an idiot out of myself.

thanks a lot,
Janek

Description:
Swap 'polite' and 'l2r' variable definitions

Obviously they were misplaced before.

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

Affected files (+2, -2 lines):
  M lily/axis-group-interface.cc


Index: lily/axis-group-interface.cc
diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc
index  
0a6155b6eb25ab7b997e87984fcec5f340772a33..11e6ccfce4b03cdbaea5361f3d30a1babf0091b8  
100644

--- a/lily/axis-group-interface.cc
+++ b/lily/axis-group-interface.cc
@@ -735,10 +735,10 @@ add_grobs_of_one_priority (Grob *me,
   SCM directive
 = valid_outside_staff_placement_directive (me);

-  bool l2r = ((directive == ly_symbol2scm ("left-to-right-greedy"))
+  bool polite = ((directive == ly_symbol2scm ("left-to-right-greedy"))
   || (directive == ly_symbol2scm ("left-to-right-polite")));

-  bool polite = ((directive == ly_symbol2scm ("left-to-right-polite"))
+  bool l2r = ((directive == ly_symbol2scm ("left-to-right-polite"))
  || (directive == ly_symbol2scm ("right-to-left-polite")));

   vector boxes;



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


Re: PATCHES: Countdown for January 15th - 06:00 GMT

2014-01-12 Thread Janek Warchoł
2014/1/12 Janek Warchoł 

> Hi,
>
> 2014/1/12 James 
>
>> Hello
>>
>> The following patches have been at 'please push' for the last 3
>> countdowns (i.e. over 9 days), and I am not seeing anything obvious that
>> leads me to believe that their is 'Needs Work' on them. I am seeing recent
>> emails from them on the lists and so assume they would also be getting the
>> tracker emails too.
>>
>> 
>> 3761
>>  Enhancement
>> Keith Ohara push LeftEdge no longer takes up space  
>> 3753
>>  Enhancement
>> Carl Peterson push Patch: Cleanup of ugly MI and SOL shaped noteheads
>> 3764
>>  Enhancement
>> Janek Warchol push Patch: Swap 'polite' and 'l2r' variable definitions
>> If the authors don't want to push, can they change the label to something
>> more appropriate? Thank you.
>>
>
> I'm sorry, i'm very busy and didn't have time to look at it properly :(
>
>
Resolved 3764 now - turns out it was moot...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: PATCHES: Countdown for January 15th - 06:00 GMT

2014-01-12 Thread Carl Peterson
On Sun, Jan 12, 2014 at 1:34 AM, James  wrote:

>  Hello
>
> The following patches have been at 'please push' for the last 3 countdowns
> (i.e. over 9 days), and I am not seeing anything obvious that leads me to
> believe that their is 'Needs Work' on them. I am seeing recent emails from
> them on the lists and so assume they would also be getting the tracker
> emails too.
>
>  
> 3753
>  Enhancement
> Carl Peterson push Patch: Cleanup of ugly MI and SOL shaped noteheads
>
>
>
>
> Patch attached, if someone can push. I apologize for the delay...I haven't
had my dev machine on for a bit now, so just now getting this together.

Regards,

Carl P.
From 85438eca8044ed67a207e2163dca959df6986df8 Mon Sep 17 00:00:00 2001
From: Carl Peterson 
Date: Mon, 23 Dec 2013 17:04:13 -0500
Subject: [PATCH] Cleanup of ugly MI and SOL shaped noteheads

1. Reducing width of MI notehead, for both "regular" (Aiken, etc.)
   and "small" (Funk/Walker) heads. When Funk/Walker heads were
   introduced, a special width variable was introduced to both
   sets and the mi heads were made wider than the other noteheads.
   This does not seem to be the practice of available examples
   (Sacred Harp, Southern Harmony books, etc.) and causes issues
   with alignment, particularly with stems up, and is visually odd.
   The variables have been removed from the metafont code, making
   the MI noteheads the same width as the other shaped notes in
   their respective sets.

2. Changing the SOL notehead to more closely match the normal round
   notehead (as advertised in the mf code). The previous code uses
   the shape of the open (half note) notehead, which is visually
   unappealing. The open notehead has been defined so that it
   matches visually with both the normal Aiken/Sacred Harp heads,
   as well as the thin variants (in keeping with observed practice,
   which uses the regular open roundhead even when thin variants
   are used).
---
 mf/feta-noteheads.mf |   41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index 2ebf537..6881837 100644
--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -1222,66 +1222,65 @@ def draw_mi_head (expr width_factor, thickness_factor, mirror) =
 enddef;
 
 
-save mi_weight, mi_width;
+save mi_weight;
 mi_weight := 2;
-mi_width := 1.2;
 
 fet_beginchar ("Whole mihead", "s0mi");
-	draw_mi_head (mi_width * solfa_whole_width, mi_weight, false);
+	draw_mi_head (solfa_whole_width, mi_weight, false);
 	fill path_out;
 	unfill path_in;
 fet_endchar;
 
 
 fet_beginchar ("Half mihead", "s1mi");
-	draw_mi_head (mi_width * solfa_quarter_width, mi_weight, false);
+	draw_mi_head (solfa_quarter_width, mi_weight, false);
 	fill path_out;
 	unfill path_in;
 fet_endchar;
 
 
 fet_beginchar ("Quarter mihead", "s2mi");
-	draw_mi_head (mi_width * solfa_quarter_width, mi_weight, false);
+	draw_mi_head (solfa_quarter_width, mi_weight, false);
 	fill path_out;
 fet_endchar;
 
 
 fet_beginchar ("Whole mirror mihead", "s0miMirror");
-	draw_mi_head (mi_width * solfa_whole_width, mi_weight, true);
+	draw_mi_head (solfa_whole_width, mi_weight, true);
 	fill path_out;
 	unfill path_in;
 fet_endchar;
 
 
 fet_beginchar ("Half  mirror mihead", "s1miMirror");
-	draw_mi_head (mi_width * solfa_quarter_width, mi_weight, true);
+	draw_mi_head (solfa_quarter_width, mi_weight, true);
 	fill path_out;
 	unfill path_in;
 fet_endchar;
 
 
 fet_beginchar ("Quarter mirror mihead", "s2miMirror");
-	draw_mi_head (mi_width * solfa_quarter_width, mi_weight, true);
+	draw_mi_head (solfa_quarter_width, mi_weight, true);
 	fill path_out;
 fet_endchar;
 
 
 fet_beginchar ("Whole thin mihead", "s0miThin");
-	draw_mi_head (mi_width * solfa_whole_width, 1, false);
+	draw_mi_head (solfa_whole_width, 1, false);
 	fill path_out;
 	unfill path_in;
 fet_endchar;
 
 
 fet_beginchar ("Half thin mihead", "s1miThin");
-	draw_mi_head (mi_width * solfa_quarter_width, 1, false);
+	draw_mi_head (solfa_quarter_width, 1, false);
 	fill path_out;
 	unfill path_in;
 fet_endchar;
 
 
 fet_beginchar ("Quarter thin mihead", "s2miThin");
-	draw_mi_head (mi_width * solfa_quarter_width, 1, false);
+	draw_mi_head (solfa_quarter_width, 1, false);
 	fill path_out;
 fet_endchar;
 
@@ -1446,9 +1445,10 @@ fet_endchar;
 %   so we can't just use the standard note font.
 %
 def draw_sol_head (expr filled) =
-	draw_outside_ellipse (1.53 - puff_up_factor / 3.0, 34, 0.66, 0.17);
+	draw_outside_ellipse (1.49 - puff_up_factor / 3.0, 31, 0.707, 0);
 	if not filled:
-	  undraw_inside_ellipse (3.25, 33, 0.81, 2.5 stafflinethickness#);
+	  undraw_inside_ellipse (2.5 - puff_up_factor / 3.0, 31, 0.707, 
+