Re: parser.yy: remove STRING_IDENTIFIER token (issue 6542057)

[dak]

Reviewers: lemzwerg, joeneeman, janek,

Message:
On 2012/09/26 05:35:16, janek wrote:

David wrote:
> ...and where the semantics indeed require a plain string,
> an error is generated explicitly in the action instead
> of leaving it to the parser to complain about bad grammar.



I'm not sure i understand.  Does this mean that in some situations

there will be

errors that were not present before this change?  I.e, will something

stop

working?


No.  The error messages and recovery will just be different.  When the
parser proper detects something that it can't use in its current state,
it throws a cryptic error message and starts throwing material away
until it thinks it can reasonably recover.

After the change, the parser proper accepts non-trivial markups where
only a string would be allowed, and the code executed on behalf of the
parser will throw the error instead without aborting.

In short, instead of a cryptic error message and dubious error recovery,
the user gets a human-understandable error message and a recovery more
likely not to cause follow-up errors.

This is for the case where things were working fine previously.  As
mentioned in the issue description, there were several situations where
things broke totally counterintuitively (namely where markups were
accepted only when they consisted of non-trivial strings, but plain
strings were rejected).

In other words: after contemplating your review, I don't see that the
countdown should be affected, but if you want to suggest a rewording of
the commit message soonish, I can of course incorporate it.

A code comment to that effect does not make all that much sense in
comparison since there is little point in writing a comment for the
replacement of code that is not even there anymore when the replacement
is, in itself, quite self-explanatory.

Description:
parser.yy: remove STRING_IDENTIFIER token

A STRING_IDENTIFIER always was a special case of a MARKUP_IDENTIFIER
without being treated equally at top level.  That led to craziness
like

xxx=\markup "test"
\xxx

being invalid, while

xxx=\markup \italic "test"
\xxx

was valid code.  This change just removes the STRING_IDENTIFIER
category altogether.  Where it was used previously, MARKUP_IDENTIFIER
is accepted now syntactically, and where the semantics indeed require
a plain string, an error is generated explicitly in the action instead
of leaving it to the parser to complain about bad grammar.

Please review this at http://codereview.appspot.com/6542057/

Affected files:
  M lily/parser.yy


Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
94227e8715ee5c72ac796ee00b1d65284539fa9a..52640be0b80cfdf9f6722753e04d4d88df55c238  
100644

--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -380,7 +380,6 @@ If we give names, Bison complains.
 %token SCM_TOKEN
 %token SCORE_IDENTIFIER
 %token STRING
-%token STRING_IDENTIFIER
 %token TONICNAME_PITCH

 %left '-' '+'
@@ -473,7 +472,6 @@ embedded_scm_bare:
 embedded_scm_bare_arg:
embedded_scm_bare
| STRING
-   | STRING_IDENTIFIER
| full_markup
| full_markup_list
| context_modification
@@ -576,7 +574,6 @@ identifier_init:
| FRACTION
| string
 | embedded_scm
-   | full_markup
| full_markup_list
 | context_modification
;
@@ -1859,10 +1856,16 @@ string:
STRING {
$$ = $1;
}
-   | STRING_IDENTIFIER {
-   $$ = $1;
-   }
+   | full_markup
| string '+' string {
+   if (!scm_is_string ($1)) {
+   parser->parser_error (@1, (_ ("simple string 
expected")));
+   $1 = scm_string (SCM_EOL);
+   }
+   if (!scm_is_string ($3)) {
+   parser->parser_error (@3, (_ ("simple string 
expected")));
+   $3 = scm_string (SCM_EOL);
+   }
$$ = scm_string_append (scm_list_2 ($1, $3));
}
;
@@ -1873,8 +1876,23 @@ simple_string: STRING {
| LYRICS_STRING {
$$ = $1;
}
-   | STRING_IDENTIFIER {
-   $$ = $1;
+   | MARKUP_IDENTIFIER
+   {
+   if (scm_is_string ($1)) {
+   $$ = $1;
+   } else {
+   parser->parser_error (@1, (_ ("simple string 
expected")));
+   $$ = scm_string (SCM_EOL);
+   }
+   }
+   | LYRIC_MARKUP_IDENTIFIER
+   {
+   if (scm_is_string ($1)) {
+   $$ = $1;
+   } else {
+   parser->parser_error (@1, (_ ("simple string 
expected")));
+   $$ = scm_string (SCM_EOL);
+   }
}
;

@@ -2309,7 +2327,13 @@ gen_text_def:
t->set_property ("text", $1);
$$ = t->unprotect ();
}
-   | simple_string {
+   | STRING {
+   Music *t =

Re: Replacing the r1 glyph

[Janek Warchoł]

Hi Oscar,

On Wed, Sep 26, 2012 at 2:30 AM, Oscar Dub  wrote:
> I'm trying to typeset a score that uses the notation shown in the attached 
> image to represent whole rests.
>
> As I see it there are two stages to achieving this in LilyPond:
> – Creating the necessary glyph (I assume the simplest way would be
> to edit scripts.ufermata from Feta, but am completely unsure where to start).
> – Writing and implementing a scheme function to engrave the glyph in place of 
> the standard 'r1' output.
>
> As a relatively new LilyPond user, I'm struggling with both tasks. Any 
> pointers would be appreciated!

as you want to add something to LilyPond herself, i think this message
will fit better on the developer list (lilypond-devel@gnu.org), so i'm
forwarding it.

Have you tried modifying LilyPond source code before, do you know how
to access it?  If not, take a look at
http://lilypond.org/doc/v2.17/Documentation/contributor/overview-of-work-flow
and then
http://lilypond.org/doc/v2.17/Documentation/contributor/quick-start

As for modifying Feta font, there is some introduction here:
http://lilypond.org/doc/v2.17/Documentation/contributor/modifying-the-feta-font

Let us know when you encounter any problems (as a rule of thumb, if
you haven't found a solution after 20 minutes of searching, it's fine
to ask.  Developers may occasionally overlook some emails, but they
are generally helpful when you ask specific questions).

cheers :)
Janek

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

Re: [GLISS] facilitate changes of the (default-) drumStyleTable

[Marc Hohl]

Am 26.09.2012 02:25, schrieb Thomas Morley:

Hi,

sometimes I heard users complaining about the difficulty of changing
the appearance of customized percussion staves,

The NR "Custom percussion staves"
states: "If you do not like any of the predefined lists you can define
your own list at the top of your file." and demonstrates the use of
\set DrumStaff.drumStyleTable = #(alist->hash-table )
http://lilypond.org/doc/v2.17/Documentation/notation-big-page#custom-percussion-staves

But if you only want to change _one_ value in the predefined lists you
have no other chance than to follow the method mentioned above, i.e.
_completely_ redefine the whole list.

What do you think about providing a music-function, faciltating this, perhaps:
I like the idea of giving the user the ability to change only parts of 
the list
without having to rewrite the full list; I think that this concept could 
be of
use in other parts of lilypond as well, so perhaps it would be more 
general to

have something like

\changeTable 'drumStyleTable (...)

I'd like to avoid to have different commands with a different syntax; it 
makes

it harder for the user to remember ...

Oh, but a git grep "aslist->hash-table" shows that only 'drumStyleTable
seems to have a hash-table structure, so my proposal is probably useless.

+1

Marc


%%

\version "2.17.0"

changeDrumStyleTable =
#(define-music-function (parser location custom-style)(list?)
   (make-music
 'ApplyContext
 'procedure
 (lambda (x)
  (let* ((ctx (ly:context-property-where-defined x 'drumStyleTable))
 (dr-st-tab (ly:context-property ctx 'drumStyleTable)))
  (if (list? (car custom-style))
(for-each (lambda (x) (hashq-set! dr-st-tab (car x) (cdr x)))
custom-style)
(hashq-set! dr-st-tab (car custom-style) (cdr custom-style)))

%--- Test

customChanges =
\with {
 % changing single value:
 \changeDrumStyleTable #'(lowtom () #t 30)
 % changing a list of values:
 \changeDrumStyleTable
 #'(
(triangle doThin #f 16)
(bassdrum faThin #f -15)
(snare () #f 0)
)
}

\layout {
 \context {
\DrumStaff
\customChanges
}
}


mus = \drummode {
 bd4  sn  bd toml8 tri
 bd ssh ss ssl  sna sn hh hh
 hhc4 r sn tri
}

\new DrumStaff {
 \mus
 <<
 \new DrumVoice { \voiceOne \mus }
 \new DrumVoice { \voiceTwo \mus }
 >>
}

%%

-Harm

___
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

Re: Set up indent-tabs-mode in lexer.ll and parser.yy (issue 6551050)

[janek . lilypond]

On 2012/09/26 06:32:15, dak wrote:

will do.


thanks, and LGTM

http://codereview.appspot.com/6551050/

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

Re: Fix vertical position of Kievan dots (issue 6570047)

[janek . lilypond]

LGTM

http://codereview.appspot.com/6570047/

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

Re: Set up indent-tabs-mode in lexer.ll and parser.yy (issue 6551050)

[dak]

Reviewers: joeneeman, janek,

Message:
On 2012/09/26 05:24:37, janek wrote:

Do i understand correctly that this is something for Emacs' sake?
If so, please add this information to the commit message, so that

non-emacs

people like me will immediately know what's it about.


Oops.  Sorry for the oversight, will do.

Description:
Set up indent-tabs-mode in lexer.ll and parser.yy

indent-tabs-mode has been switched off for C++ files with
directory-local variables.

However, for lack of working better indentation modes that cooperate
well with Bison and Flex files, lexer.ll and parser.yy are using a
tab-based indentation style oriented on the Linux kernel indentation
style.  In order to not cause an even greater inconsistent mess, local
file variables are used for switching tab-based indentation back on in
those files.

Please review this at http://codereview.appspot.com/6551050/

Affected files:
  M lily/lexer.ll
  M lily/parser.yy


Index: lily/lexer.ll
diff --git a/lily/lexer.ll b/lily/lexer.ll
index  
0d3f7599d899a09aab95f6800960c4e790ae6535..1caf8a5ee6f5fd8184d8ece280aaf8f5b024d04b  
100644

--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -1,4 +1,4 @@
-%{ // -*- mode: c++; c-file-style: "linux" -*-
+%{ // -*- mode: c++; c-file-style: "linux"; indent-tabs-mode: t -*-
 /*
   This file is part of LilyPond, the GNU music typesetter.

Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
981cf40bab5a40570601b3a2b517714b5755c88d..94227e8715ee5c72ac796ee00b1d65284539fa9a  
100644

--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -1,4 +1,4 @@
-/* -*- mode: c++; c-file-style: "linux" -*- */
+/* -*- mode: c++; c-file-style: "linux"; indent-tabs-mode: t -*- */
 /*
   This file is part of LilyPond, the GNU music typesetter.




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

Re: Web: Add Elysium to Easier Editing section (issue 6546059)

[graham]

LGTM

http://codereview.appspot.com/6546059/

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

Web: Add Elysium to Easier Editing section (issue 6546059)

[janek . lilypond]

lgtm

http://codereview.appspot.com/6546059/

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

Get along with use of grob-property instead of grob-property-path in overrides (issue 6544060)

[janek . lilypond]

Do i understand correctly that grob-property-path is just a list of
properties, like '('thickness 'gap 'color)?  If so, i find the name
misleading.

Anyway, i don't feel competent to give an "LGTM" to a Scheme patch i
don't understand - but i had certainly not noticed anything wrong.


http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly#newcode1073
ly/music-functions-init.ly:1073: (ly:music-property m
'grob-property-path)
Scheme syntax pwned me again, but i suppose this just uses either
grob-property or grob-property-path depending on need.

http://codereview.appspot.com/6544060/

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

Re: PATCH: Countdown to 20120925

[Janek Warchoł]

Reviews done - thanks for waiting!
Janek

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

Re: note-collision: retain upper voice dot when merging dots (issue 6550056)

[janek . lilypond]

lgtm :)

http://codereview.appspot.com/6550056/

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

Re: spacing-spanner: rods for non-adjacent paper-columns; issue 1700 (issue 6489107)

[janek . lilypond]

lgtm, i think.

http://codereview.appspot.com/6489107/

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

Re: parser.yy: remove STRING_IDENTIFIER token (issue 6542057)

[janek . lilypond]

David wrote:

...and where the semantics indeed require a plain string,
an error is generated explicitly in the action instead
of leaving it to the parser to complain about bad grammar.


I'm not sure i understand.  Does this mean that in some situations there
will be errors that were not present before this change?  I.e, will
something stop working?
I guess an example should be enough for me to understand.

thanks,
Janek

http://codereview.appspot.com/6542057/

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

Re: Set up indent-tabs-mode in lexer.ll and parser.yy (issue 6551050)

[janek . lilypond]

Do i understand correctly that this is something for Emacs' sake?
If so, please add this information to the commit message, so that
non-emacs people like me will immediately know what's it about.

thanks,
Janek

http://codereview.appspot.com/6551050/

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

PATCH: Countdown to 20120927

[Colin Campbell]

For 22:00 MDT Thursday Sept 27 (04:00 UTC 20120928)

Defect:
Issue 2856 
: Patch: Get 
along with use of grob-property instead of grob-property-path in 
overrides - R 6544060 


Documentation:
Issue 2817 
: list Elysium 
on Easier Editing webpage - R 6546059 



Enhancement:
Issue 2801 
: Patch: 
Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. - 
R 6498077 
Issue 2717 
: Implement 
\single, \omit and \hide - R 6495135 



Patch:
Issue 2823 
: Patch: Fixes 
position of mensural c clef - R 6503091 



Ugly:
Issue 2857 
: Placement of 
Kievan dots - R 6570047 



Cheers,
Colin




--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: PATCH: Countdown to 20120925

[Colin Campbell]

On 12-09-25 02:36 PM, Janek Warchoł wrote:

Hi,

On Mon, Sep 24, 2012 at 4:44 AM, Colin Campbell  wrote:

For 21:00 MDT Tuesday September 25

Enhancement:
 Issue 2717: Implement \single, \omit and \hide - R 6495135
 Issue 2853: Patch: Set up indent-tabs-mode in lexer.ll and parser.yy - R
6551050
 Issue 2854: Patch: parser.yy: remove STRING_IDENTIFIER token - R 6542057

Ugly:
 Issue 1700: Chord names collide when several note-columns lay in between
- R 6489107
 Issue 2841: Augmentation dot Y position on merged note heads - R 6550056

I wanted to review at least some of these, but i was too tired today,
and i have to go to sleep now.  If you're willing to wait, i'm going
to wake up at 5 UTC (by the way - could we specify time in UTC,
please?) and give them a try.

best,
Janek



I'm delighted to encourage reviews, Janek!  I feel very uncomfortable 
setting patches to "push" with no real evidence that anyone has looked 
at them.  Still, I'm in UTC-6, so why don't we follow the spirit of 
David's comment downthread, and if the items on the list qualify, I'll 
set them to "push after 18:00 UTC Sept 26"? That'll allow a middle-aged 
beancounter to get to bed early enough to be coherent at the division 
meeting in the morning.


Cheers, and thanks for caring about the reviews!

Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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

[GLISS] facilitate changes of the (default-) drumStyleTable

[Thomas Morley]

Hi,

sometimes I heard users complaining about the difficulty of changing
the appearance of customized percussion staves,

The NR "Custom percussion staves"
states: "If you do not like any of the predefined lists you can define
your own list at the top of your file." and demonstrates the use of
\set DrumStaff.drumStyleTable = #(alist->hash-table )
http://lilypond.org/doc/v2.17/Documentation/notation-big-page#custom-percussion-staves

But if you only want to change _one_ value in the predefined lists you
have no other chance than to follow the method mentioned above, i.e.
_completely_ redefine the whole list.

What do you think about providing a music-function, faciltating this, perhaps:

%%

\version "2.17.0"

changeDrumStyleTable =
#(define-music-function (parser location custom-style)(list?)
  (make-music
'ApplyContext
'procedure
(lambda (x)
 (let* ((ctx (ly:context-property-where-defined x 'drumStyleTable))
(dr-st-tab (ly:context-property ctx 'drumStyleTable)))
 (if (list? (car custom-style))
   (for-each (lambda (x) (hashq-set! dr-st-tab (car x) (cdr x)))
custom-style)
   (hashq-set! dr-st-tab (car custom-style) (cdr custom-style)))

%--- Test

customChanges =
\with {
% changing single value:
\changeDrumStyleTable #'(lowtom () #t 30)
% changing a list of values:
\changeDrumStyleTable
#'(
   (triangle doThin #f 16)
   (bassdrum faThin #f -15)
   (snare () #f 0)
   )
}

\layout {
\context {
\DrumStaff
\customChanges
}
}


mus = \drummode {
bd4  sn  bd toml8 tri
bd ssh ss ssl  sna sn hh hh
hhc4 r sn tri
}

\new DrumStaff {
\mus
<<
\new DrumVoice { \voiceOne \mus }
\new DrumVoice { \voiceTwo \mus }
>>
}

%%

-Harm

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

note-collision: retain upper voice dot when merging dots (issue 6550056)

[joeneeman]

lgtm


http://codereview.appspot.com/6550056/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/6550056/diff/1/lily/note-collision.cc#newcode251
lily/note-collision.cc:251: dot_wipe_head = head_down;
Comment, please? (eg. it would make a nice addition to the existing
comment at line 232)

http://codereview.appspot.com/6550056/

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

Re: parser.yy: remove STRING_IDENTIFIER token (issue 6542057)

[joeneeman]

lgtm

http://codereview.appspot.com/6542057/

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

Set up indent-tabs-mode in lexer.ll and parser.yy (issue 6551050)

[joeneeman]

lgtm

http://codereview.appspot.com/6551050/

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

Re: PATCH: Countdown to 20120925

[David Kastrup]

David Kastrup  writes:

>>> Issue 2853: Patch: Set up indent-tabs-mode in lexer.ll and parser.yy - R
>>> 6551050
>>> Issue 2854: Patch: parser.yy: remove STRING_IDENTIFIER token - R 6542057
>
> Those two are stopping me from submitting further work to the parser.
> The first one is a nuisance to keep uncommitted since it is pretty much
> necessary to work on parser.yy without making the spacing go even more
> haywire.
>
> The second one is a prerequisite for more parser work that will go on
> review as soon as this is committed.
>
> I don't expect there to be much of a reviewable angle to either.  To
> accommodate you, I can refrain from any "can't sleep anyway" commits
> before breakfast, meaning that they won't go in before something like 9
> UTC.

Wrong time.  I mean 7UTC (9am locally).


-- 
David Kastrup


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

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[benko . pal]

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1059
Documentation/notation/expressive.itely:1059:
@lilypond[verbatim,quote,relative=2]
On 2012/09/25 21:07:06, Trevor Daniels wrote:

This example shows a beam extending from a stem to the
final note of the glissando.  Is this correct, or would
it be better to suppress the beam?


just like ordinary duration display: either a beam or a flag.  Bartók's
String Quartet no. 4. has examples for both.
I find your example fine.  is it mentioned that glissando is not
standardised?  e.g. Bartók wanted all glissandi start immediately, while
others use the headless stem notation, reserving full headed notes to
mean fixed pitch through the whole duration.

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

Re: PATCH: Countdown to 20120925

[David Kastrup]

Janek Warchoł  writes:

> Hi,
>
> On Mon, Sep 24, 2012 at 4:44 AM, Colin Campbell  wrote:
>> For 21:00 MDT Tuesday September 25
>>
>> Enhancement:
>> Issue 2717: Implement \single, \omit and \hide - R 6495135

This one had been resubmitted and consequently is back to Patch-review.
The change is not one really requiring a recountdown, but it is not like
there is anything waiting for it.

>> Issue 2853: Patch: Set up indent-tabs-mode in lexer.ll and parser.yy - R
>> 6551050
>> Issue 2854: Patch: parser.yy: remove STRING_IDENTIFIER token - R 6542057

Those two are stopping me from submitting further work to the parser.
The first one is a nuisance to keep uncommitted since it is pretty much
necessary to work on parser.yy without making the spacing go even more
haywire.

The second one is a prerequisite for more parser work that will go on
review as soon as this is committed.

I don't expect there to be much of a reviewable angle to either.  To
accommodate you, I can refrain from any "can't sleep anyway" commits
before breakfast, meaning that they won't go in before something like 9
UTC.  But I think it would make more sense to take a look at the last
two:

>> Ugly:
>> Issue 1700: Chord names collide when several note-columns lay in between
>> - R 6489107
>> Issue 2841: Augmentation dot Y position on merged note heads - R 6550056
>
> I wanted to review at least some of these, but i was too tired today,
> and i have to go to sleep now.  If you're willing to wait, i'm going
> to wake up at 5 UTC (by the way - could we specify time in UTC,
> please?) and give them a try.

All the best

-- 
David Kastrup

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

Re: Feature request

[David Kastrup]

Jean-Charles Malahieude  writes:

> Le 24/09/2012 22:18, Janek Warchoł disait :
>> On Monday, September 24, 2012, David Kastrup wrote:
>>> We get about 1 request per month of the kind in
>>> http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00600.html>
>>> "I can't get the automated beams to look like the manual beams in
>>> measure 1".
>>>
>>> Can we just get a command
>>> \beaming { c8[ c] c r c[ c c c] }
>>> which converts its argument into overrides for beatStructure and
>>> beamExceptions?
>>
>> +1 in general, i'm not sure about the specifics except for the part
>> about subdivisions: if it would be possible to make things work in a
>> way that would allow [[ to specify a subdivison, i would like it.
>>
>
> Why not "mimic" the difference between phrasing slur and slur:
>
> \beaming 4/4 { c16\[[ c c c] c[ c c c]\] c8[ c] c[ c] }

It's not like one _couldn't_ use nested beams for specifying the
subdivisions.  It is just that it does not match normal usage.

Now what you are proposing is basically an abuse of ligatures.  That
would only make sense if ligatures were first brought in line with all
the other post-event phrasings (ligatures aren't a post-event right now
and stick out somewhat) and actually used for beam subdivision in the
main code.  But if I remember correctly, beam subdivision is a
multi-level problem, not just two-level.

-- 
David Kastrup

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

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[tdanielsmusic]

One more question (sorry, I'm not familiar with
this notation, and I'd like to be sure it's right.)

Trevor



http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1059
Documentation/notation/expressive.itely:1059:
@lilypond[verbatim,quote,relative=2]
This example shows a beam extending from a stem to the
final note of the glissando.  Is this correct, or would
it be better to suppress the beam?

http://codereview.appspot.com/6529043/

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

Re: PATCH: Countdown to 20120925

[Janek Warchoł]

Hi,

On Mon, Sep 24, 2012 at 4:44 AM, Colin Campbell  wrote:
> For 21:00 MDT Tuesday September 25
>
> Enhancement:
> Issue 2717: Implement \single, \omit and \hide - R 6495135
> Issue 2853: Patch: Set up indent-tabs-mode in lexer.ll and parser.yy - R
> 6551050
> Issue 2854: Patch: parser.yy: remove STRING_IDENTIFIER token - R 6542057
>
> Ugly:
> Issue 1700: Chord names collide when several note-columns lay in between
> - R 6489107
> Issue 2841: Augmentation dot Y position on merged note heads - R 6550056

I wanted to review at least some of these, but i was too tired today,
and i have to go to sleep now.  If you're willing to wait, i'm going
to wake up at 5 UTC (by the way - could we specify time in UTC,
please?) and give them a try.

best,
Janek

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

Re: [GLISS] basics

[Joseph Rushton Wakeling]

On 24/09/12 14:07, Janek Warchoł wrote:

I suggest to ask more for complaints than for ideas: what users find
confusing, inconvenient and difficult to express in Lily syntax.  I
think this will be more valuable information than proposals "let's
have a syntax like this".


Actually, rather than "what users find difficult" (which I agree is important in 
and of itself), perhaps it's better to take a different tack: to try and prepare 
a systematic specification for the musical notations that Lilypond should support.


Then, go through each one and identify the extent Lilypond supports that 
notation, e.g.:


   (1) Lilypond syntax does not adequately support this notation without
   significant user effort, whether it's writing Scheme code, creating new
   glyphs, needing to create a new system of pitches and accidentals, ...

  EXAMPLE: arrowed quarter-tone notation.  For details, see:
  https://code.google.com/p/lilypond/issues/detail?id=1278

   (2) Lilypond syntax theoretically supports this notation, but the actual
   engraving results are unreasonably imperfect.

  EXAMPLE: hairpin notation where the hairpin is meant to start or
  terminate part-way through a note.  See:
  
https://lists.gnu.org/archive/html/lilypond-devel/2012-09/msg00690.html

  Also applies to placement of ornaments where they do not fall
  precisely on the note.

   (3) Lilypond supports this notation, but the syntax is excessively verbose
   compared to the simplicity or regularity of the notation itself.

  TENTATIVE EXAMPLE (I haven't really thought this through:-): slight
  horizontal and/or vertical offsets of dynamics, as is commonly found
  in many scores.  See e.g. Janek's example of the Mozart Requiem
  engraved by Bärenreiter:
  
http://news.lilynet.net/?The-LilyPond-Report-26#lilypond_output_analysis

   (4) Lilypond supports this notation, but the documentation is poor,
   confusing, or difficult to find.

Note that more than one of (2), (3) and (4) might apply to some notations.

That's going to give you a lot more information than what people _think_ are the 
problems, because the scope of notation that most Lilypond users engage with is 
probably much narrower than the scope of notation Lilypond needs to support in 
order to be a really effective engraving solution.


I don't have a copy of the Elaine Gould book you mentioned earlier, but that, 
together with Keith Stone and Gardner Read might be a good starting point.  It's 
also probably worth taking a reflective sample of compositions from different 
periods and seeing how readily they can be engraved; from contemporary music, 
for example, I think that Boulez, Stockhausen and Ferneyhough will probably give 
a good reflection of what Lilypond's limits are.


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

Re: [talk] easy tuplets

[David Kastrup]

Ian Hulin  writes:

> Advantages:
> 1. Quicker note entry for triplet quaver and crotchet groups.
> 2. It is considerably less opaque and cryptic-looking than the other
> alternative to \times 2/3 { ... }
> c8*2/3 c c .
>
> Drawbacks:

The main drawback I see is that the specification is "in lowest terms".
It would be a full nuisance to have tuplets oscillating between 15th,
5th, and 3rd tuplets depending on their distribution.  Sixtuplets are
plain out, it is not clear why and when duols will be notated with dots
and when not, and the subdivision to pick for duols/quartols is totally
unclear as it competes with normal note lengths.

-- 
David Kastrup


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

Re: Feature request

[Jean-Charles Malahieude]

Le 25/09/2012 19:11, Ian Hulin disait :

On 25/09/12 18:02, Jean-Charles Malahieude wrote:


Why not "mimic" the difference between phrasing slur and slur:

\beaming 4/4 { c16\[[ c c c] c[ c c c]\] c8[ c] c[ c] }


Je suis désolé, mais

\[ \] are already spoken for as delimiters for early-music melismata.



Too bad! Just forgot to not forget...

Cheers,
Jean-Charles



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

Re: Feature request

[Ian Hulin]

On 25/09/12 18:02, Jean-Charles Malahieude wrote:
> 
> Why not "mimic" the difference between phrasing slur and slur:
> 
> \beaming 4/4 { c16\[[ c c c] c[ c c c]\] c8[ c] c[ c] }
> 
Je suis désolé, mais

\[ \] are already spoken for as delimiters for early-music melismata.

Cheers,

Ian


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

Re: Fixes position of mensural c clef (issue 6503091)

[lemzwerg]

If you do

  mf '\mode:=proof; input parmesan20'
  gftodvi parmesan20.2602gf

and view the resulting parmesan20.dvi with xdvi, go to your glyph, then
press `10 s' to set the shrink factor to 10.  This makes the image small
enough that you can see even the part of the glyph which is below the
lower edge of the paper (indicated by the red box).


http://codereview.appspot.com/6503091/

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

Re: [talk] easy tuplets

[Ian Hulin]

On 23/09/12 22:45, Graham Percival wrote:
> This is an informal chat idea, following David's latest suggestion 
> that such emails could go on -devel instead of requiring a separate
> mailing list.  I fully expect this not to work.
> 
But let's give it a go anyway.

I have a few concerns, but these are mostly semantic i.e. "what is
this in terms of what we are trying to express in the language.
> 
> Currently, durations are limited to powers of 2 (plus dots). Making
> a triplet involves the wordy \times x/y { ... } or a *x/y scaling
> factor.  We could avoid this (in common cases) by allowing 
> arbitrary integer durations.
> 
> c4 e \times 2/3 { c4 e g } into: c4 e c6 e g
> 
> The general rule is that the duration x is (whole note)/x.  So in 
> addition to the current 1 2 4 8 we have 3 => \times 2/3 { c2 }
> (whole note divided by 3) 6 => \times 2/3 { c4 }(whole note
> divided by 6) ... etc.
You need at least three in your new series to make it unambiguous
   12 => \times 2/3 { c8 }(whole note divided by 12)
> 
> These notes can be grouped together like we do for beaming, and 
> produce tuplet brackets according to tuplet-beaming rules.
> 

Advantages:
1. Quicker note entry for triplet quaver and crotchet groups.
2. It is considerably less opaque and cryptic-looking than the other
alternative to \times 2/3 { ... }
c8*2/3 c c .

Drawbacks:
1. The current wordy syntax is explicit.  You specify the ratio of
notes contained in the tuplet as a / b where the fraction determines
how many written notes (fraction denominator) are written in the time
of how many 'real' notes in the current time signature.  This change
only accommodates triplets.
2. The current syntax is delimited. You specify exactly how many notes
are to form the tuplet by enclosing them in sequential music
delimiters '{' and '}'.  The proposed syntax does not explicitly
indicate where the 'tupleted' notes begin and end.
3. The proposition may not explicitly address the commonest triplet group
\times 2/3 {c8 c c}, would it cater for this as c12 c c ?
4. Other common tuplets are not handled by this proposition (e.g.
\times 4/5 { ... } - obvious, but needs stating).
5. How do these 'implicit triplet' durations interact with \times,
e.g. when they are nested as in the N.R. 1.2.1 example 2:

\autobeamOff
c4 \times 4/5 { f8 e f  e6[ f g] } f4

6. How do we make it clear to new users that 'c6' is different from
'c4.'? After all, the duration of the note is the same as our
durations are an implicit 1/n  (i.e. c4 = c with 1/4 note duration),
and the . means 150% of 1/n.
7. Are the new triplet duration-lengths consistent, extensible and
easily explicable to new LilyPond users in the LR?  I suspect the
answer to this is yes as we only support powers of two (2, 4, 8 ...)
to represent durations now, and I presume we would also have a
parallel 'triplet' series (2*1.5, 4*1.5, 8*1.5 ... ) to represent the
'tripleted' durations.

Opportunities:
1. Implement as a \triplet music function to give
triplet = (define-music-function
 (parser location tuplet-music) (ly:music)
#{ \times 2/3 $tuplet-music }#


\triplet {c2 c c} ; (for c3 c c in the proposition) or
\triplet {c4 c c} ; (for c6 c c in the proposition) and
\triplet {c8 c c} ; (not mentioned explicitly in the proposition)

Threats:
1. Is LilyPond's conception of note duration extensible enough to cope
with the new note lengths?
2. Interaction with beaming and auto-beaming, are we going to generate
a whole slew of properties needing to bet \overridden or \set in order
to control how the implicit tuplet notes are beamed?

> 
> I know that this idea has been floated at least twice in the past 
> ten years, but since this is only a [talk] idea, I'm not going to 
> bother looking up those discussions in the archives.  Remember that
> you're not allowed to call me a lazy idiot for not looking up those
> discussions because this isn't a formal proposal.  This email
> thread should have "the casual atmosphere of a friendly discussion
> at a pub or coffee house", and that nobody "will complain about
> technically infeasible ideas, wasting developer’s time, having to
> defend the parser, or anything like that".
> 
> - Graham

I think we have potentially two propositions which could emerge from
this.  Both of these can co-exist together.

1. Provide a triplet shorthand - discussion point, do we add a whole
slew of new duration values for users to learn which are relevant to
triplets, but which can save them some typing, or do we add a \triplet
command?

2. Make the \times command more musician-friendly and less of a
potential confusion with \time. Potentially replace with a \tuplet
command
e.g.
  \times 2/3 {c8 c8 c8] becomes
  \tuplet 3/2 {c8 c8 c8}  % because musicians think of the tuplet as
 %   three-eighth-notes-in-the-time-of-two.
or
   \tuplet 2/3 {c8 c8 c8} % if we want to preserve 'this is a better
 % way of writing c8*2/3 c c'

Hope this hasn't torpedoe

Re: Feature request

[Jean-Charles Malahieude]

Le 24/09/2012 22:18, Janek Warchoł disait :

On Monday, September 24, 2012, David Kastrup wrote:

We get about 1 request per month of the kind in
http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00600.html>
"I can't get the automated beams to look like the manual beams in
measure 1".

Can we just get a command
\beaming { c8[ c] c r c[ c c c] }
which converts its argument into overrides for beatStructure and
beamExceptions?


+1 in general, i'm not sure about the specifics except for the part
about subdivisions: if it would be possible to make things work in a
way that would allow [[ to specify a subdivison, i would like it.



Why not "mimic" the difference between phrasing slur and slur:

\beaming 4/4 { c16\[[ c c c] c[ c c c]\] c8[ c] c[ c] }

Cheers,
Jean-Charles



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

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[benko . pal]

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1074
Documentation/notation/expressive.itely:1074:
@lilypond[verbatim,quote,relative=2,line-width=4.0\cm]
http://www.iannis-xenakis.org/partitions/Syrmos.jpg

http://codereview.appspot.com/6529043/

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

Re: [talk] easy tuplets

[James]

On 25 September 2012 16:49, Joseph Rushton Wakeling
 wrote:
> On 25/09/12 06:48, Keith OHara wrote:
>>
>> Try it out.  Enter some Debussy using 12th-notes, 9th notes, etc.
>> 
>
>
> If nested tuplets are your intended testing ground, try engraving
> Ferneyhough. All else is playground stuff. :-)

For those too lazy to look an example up

http://broadbandnoise.wordpress.com/tag/new-complexity/

PAH!

I bet Mike Solo would eat Ferneyhough for breakfast

;)

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

Re: [talk] easy tuplets

[Joseph Rushton Wakeling]

On 25/09/12 06:48, Keith OHara wrote:

Try it out.  Enter some Debussy using 12th-notes, 9th notes, etc.



If nested tuplets are your intended testing ground, try engraving Ferneyhough. 
All else is playground stuff. :-)



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

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[benko . pal]

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1074
Documentation/notation/expressive.itely:1074:
@lilypond[verbatim,quote,relative=2,line-width=4.0\cm]
On 2012/09/25 15:31:17, Trevor Daniels wrote:

In this example and the previous one the skipped notes
have durations, so the visible notes in a bar don't
add up to the measure length.  Is this the usual practice?


I'm just singing Xenakis' Nuits, and it's notated this way.


And a second point: it would be better to use \hideNotes
and then make the stem visible, otherwise ledger lines
and dots remain visible.


ugh, I don't have the score at hand; I think I haven't seen ledger
lines; I'm absolutely unsure about dots.  will check tonight.

http://codereview.appspot.com/6529043/

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

Re: [talk] easy tuplets

[Joseph Rushton Wakeling]

On 24/09/12 18:27, David Kastrup wrote:

I don't like it since it does not match musical concepts.  You would not
talk about "12th notes" to other musicians.


That's not entirely true.  Contemporary composers (I think Ferneyhough started 
it, others have continued it) have used time signatures like x/10, x/6, etc. 
(which Lilypond already supports) where the base unit is a quintuplet-eighth, a 
triplet-quarter, etc.


(There are earlier examples of equivalent time signatures, e.g. in Boulez, but 
they don't use the simple ratio -- Boulez writes things like (4 + 2/3)/4 where 
Ferneyhough would have written 7/6.)


Given such a musical context, it may make more sense to write,

\time 4/10
c'10 \times 2/3 { c'10 c' c' } c'20 c'

than,

\time 4/10
\times 4/5 { c'8 \times 2/3 { c'8 c' c' } c'16 c' }



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

Fix vertical position of Kievan dots (issue 6570047)

[aleksandr . andreev]

Reviewers: ,

Message:
Please review.

Description:
Fix vertical position of Kievan dots

Dots in Kievan notation should be placed at the same Y_AXIS position as
the note, even if they occur on a line.

Issue 2857.

Please review this at http://codereview.appspot.com/6570047/

Affected files:
  M lily/dot-column.cc


Index: lily/dot-column.cc
diff --git a/lily/dot-column.cc b/lily/dot-column.cc
index  
1aa0b728c0657618f6839be6818691cee898848a..6cba432639deb7f8fd899a53a577987253787762  
100644

--- a/lily/dot-column.cc
+++ b/lily/dot-column.cc
@@ -187,7 +187,8 @@ Dot_column::calc_positioning_done (SCM smob)

   cfg.remove_collision (p);
   cfg[p] = dp;
-  if (Staff_symbol_referencer::on_line (dp.dot_, p))
+  if (Staff_symbol_referencer::on_line (dp.dot_, p) &&
+  dp.dot_->get_property ("style") != ly_symbol2scm ("kievan"))
 cfg.remove_collision (p);
 }




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

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[tdanielsmusic]

I'm reworking these examples ready for insertion in
the NR, but I'd like to see responses to my comment
below first.

Trevor



http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):

http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1074
Documentation/notation/expressive.itely:1074:
@lilypond[verbatim,quote,relative=2,line-width=4.0\cm]
In this example and the previous one the skipped notes
have durations, so the visible notes in a bar don't
add up to the measure length.  Is this the usual practice?

And a second point: it would be better to use \hideNotes
and then make the stem visible, otherwise ledger lines
and dots remain visible.

http://codereview.appspot.com/6529043/

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

Re: Fixes position of mensural c clef (issue 6503091)

[PhilEHolmes]

On 2012/09/25 14:04:03, lemzwerg wrote:

LGTM, except one small issue.



http://codereview.appspot.com/6503091/diff/20001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):



http://codereview.appspot.com/6503091/diff/20001/mf/parmesan-clefs.mf#newcode816

mf/parmesan-clefs.mf:816: 2.2 reduced_il#);
The bbox is still too small.


Agreed.  Will fix this in the next patch.  I tried a variety of ways of
displaying the bounding box, but can only seem to be able show the right
edge.  Is there a way of showing the whole box?



http://codereview.appspot.com/6503091/

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

Re: Fixes position of mensural c clef (issue 6503091)

[lemzwerg]

LGTM, except one small issue.


http://codereview.appspot.com/6503091/diff/20001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):

http://codereview.appspot.com/6503091/diff/20001/mf/parmesan-clefs.mf#newcode816
mf/parmesan-clefs.mf:816: 2.2 reduced_il#);
The bbox is still too small.  I suggest that you define z2 like this:

  x2l = 0;
  top y2 = 2.2 reduced_il;

This makes the left vertical element a bit shorter which shouldn't be
noticeable, however.

http://codereview.appspot.com/6503091/

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

Re: Fixes position of mensural c clef (issue 6503091)

[PhilEHolmes]

Please review

http://codereview.appspot.com/6503091/

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

Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)

[ianhulin44]

Closing Rietveld issue now that Tracker Issue 2758 has been verified.
Ian

http://codereview.appspot.com/6458159/

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