Re: Doc: improve documentation of Bézier curves (2858) (issue 6561064)

[tdanielsmusic]

On 2012/10/09 05:44:52, J_lowe wrote:

Are there too many 'subs' here?


No.  This is the standard level 5 heading.  See
http://www.lilypond.org/doc/v2.17/Documentation/contributor/sectioning-commands


I only mention it because the headings are bold
_italic_ which really jars on  the eye when it's
not used anywhere else (at
least when I make a quick scroll through the
resulting pdf). Ditto for the other
headings.


It is used elsewhere, although level 5 headings are
quite rare.  For example, see
http://www.lilypond.org/doc/v2.17/Documentation/notation/beams#setting-automatic-beam-behavior
Italics are necessary to distinguish level 5 and level 4
headings.

Trevor


http://codereview.appspot.com/6561064/

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[dak]

Reviewers: lemzwerg,

Message:
On 2012/10/09 05:04:50, lemzwerg wrote:

LGTM, without testing, and without really understanding the change.

However,

simplifications and generalizations are always a good thing.



http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely

File Documentation/de/notation/pitches.itely (right):



http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely#newcode1529

Documentation/de/notation/pitches.itely:1529: \accidentalStyle
StaffGroup."voice"
This looks strange.  I don't expect double quotes after a dot.  Any

better

representation possibility?


Agreed.  _All_ of the following will work:
\accidentalStyle "StaffGroup.voice"
\accidentalStyle StaffGroup.voice
\accidentalStyle "StaffGroup"."voice"

whereas everything involving #"Staffgroup..." will _not_ work (only
LilyPond strings autoconvert to symbols).

I think I'd go for
\accidentalStyle Staffgroup.piano-cautionary
myself as then the temptation to employ Scheme strings by accident is
smaller, but then it seems inconsistent to use
\accidentalStyle "piano-cautionary"
so I'd crank open another convert-ly rule to turn those into
\accidentalStyle piano-cautionary
as well.  Which makes for worse backward-compatibility of scores.

What do people prefer to see?

Description:
Make arguments like Context.GrobName accessible as symbol lists

This is a rather awkward case for a Rietveld review since it consists
of 14 separate commits (listed below).  The principal target was to
allow things like \omit Staff.TimeSignature to work as expected.  The
same treatment has been given to \alterBroken, \hide,
\overrideProperty and \shape, as well as to \accidentalStyle.

For improving backward compatibility, dotted _LilyPond_ strings like
"Staff.TimeSignature" are also accepted in lieu of symbol list.  A
rather surprising corollary is that

  \override Lyrics.LyricText #'font-shape = #'italic

now works without needing to offset . with spaces.  While
Lyrics.LyricText is indeed run into a single LilyPond string in this
case, \override will happily pick that string apart again.

LilyPond strings are also acceptable for symbol? predicates.  The
conversions will only be attempted if the string is not accepted by a
predicate in the form of a string.



Run scripts/auxiliar/update-with-convert-ly.sh


convert-ly rule for \alterbroken, \accidentalStyle, \overrideProperty

This is required since not all of the old call forms can be
automatically recognized anymore, in particular not when the
Scheme-only form #"Context.GrobName" is being used.

Change \accidentalStyle to get a symbol list as argument


Make \alterBroken, \hide, \omit, \overrideProperty, \shape take unquoted
Context.Grob specs


Add symbol-list-or-music? predicate


Allow the string "xxx.yyy" to parse as a symbol list


Allow property and grob paths to be constructed from strings


Add symbol-list? predicate


Allow LilyPond strings to stand in for symbols when parsing


Let accidentalStyle detect its optional context argument by looking at
its letter case


Factor SCM_IDENTIFIER out from embedded_scm_arg*


parser.yy: make is_regular_identifier match the lexer definition


parser.yy: FRACTION does not require a closed expression before it


Assignments can't contain literal lyric music (wrong lexer mode)

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

Affected files:
  M Documentation/de/extending/programming-interface.itely
  M Documentation/de/notation/pitches.itely
  M Documentation/de/notation/spacing.itely
  M Documentation/es/extending/programming-interface.itely
  M Documentation/es/notation/pitches.itely
  M Documentation/es/notation/spacing.itely
  M Documentation/extending/programming-interface.itely
  M Documentation/fr/extending/programming-interface.itely
  M Documentation/fr/notation/pitches.itely
  M Documentation/fr/notation/spacing.itely
  M Documentation/it/notation/pitches.itely
  M Documentation/ja/notation/pitches.itely
  M Documentation/ja/notation/spacing.itely
  M Documentation/notation/pitches.itely
  M Documentation/notation/spacing.itely
  M Documentation/snippets/text-headword.ly
  M input/regression/alignment-vertical-manual-setting.ly
  M input/regression/alter-broken.ly
  M input/regression/page-layout-manual-position.ly
  M input/regression/page-spacing-bass-figures.ly
  M input/regression/page-spacing.ly
  M lily/parser.yy
  M ly/music-functions-init.ly
  M ly/property-init.ly
  M python/convertrules.py
  M scm/c++.scm
  M scm/lily.scm



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

Re: [proposal] easy triplets and tuplets - Draft 3

[Francisco Vila]

2012/10/9 Keith OHara :
> Currently, everyone who thinks of a triplet as a 3:2 ratio, 3 notes in the
> usual time for 2, suffers similar confusion when trying to remember \times
> 2/3.  Triplets are usually written with a simple 3, but 4-note-tuplets are
> often designated 4:3 for clarity, while LilyPond requires the reversed
> fraction in \times 3/4 {}

Here come Spanish students again.
I can think in \times  {} as a mathematical expression and
it has sense, because "times" means multiply, but I have observed that
newcomers hear about a triplet has to be writen as 2/3 and the "times"
part becomes less relevant than the  part. They only think
"times" as being "time" plus an 's' and that the  has to be
reversed.

So, \tuplet y/x with the exact meaning of \times x/y is less confusing
because it's not "times" vs "time" anymore, and the straightforward
fraction is just "music without the maths". So, I predict a widespread
adoption.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

"Keith OHara"  writes:

> duplet =
> #(define-music-function (parser location d music) 
>   ((ly:duration? #f) ly:music? )
>   (if d
>   #{\tuplet 2 $d $music #}
>   #{\tuplet 2 $music #} ))

Just a note here: this can be done quite more concisely by writing
duplet =
#(define-music-function (parser location d music)
  ((ly:duration? *unspecified*) ly:music?)
  #{ \tuplet 2 $d #music #})

I prefer using #music here since it preserves a 1:1 relation between
identifier and function argument (and saves a copying), while the whole
point of $d is to _not_ preserve a 1:1 relation, making $*unspecified*
disappear without a trace as opposed to what #*unspecified* would do.

-- 
David Kastrup


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

Re: [Lilypond-auto] Patchy report

[David Kastrup]

John Mandereau  writes:

> Hi,
>
> I quote some of the logs below...
> Il giorno mar, 09/10/2012 alle 00.33 +, grenoui...@lilynet.net ha
> scritto:
>> 21:58:01 (UTC) Begin LilyPond compile, previous commit at
>> c7a3623a056891d48b13fe14fd6ee042ac666822
>> 21:58:27 Merged staging, now at: c7a3623a056891d48b13fe14fd6ee042ac666822
>> 21:58:29 Success:sudo -u lilybuild ./autogen.sh 
>> --noconfigure
>> 21:59:05 Success:sudo -u lilybuild 
>> /home/lilybuild/staging/configure --disable-optimising
>> 21:59:15 Success:sudo -u lilybuild nice make clean
>> 22:16:12 Success:sudo -u lilybuild nice make -j2 
>> CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
>> 22:38:05 Success:sudo -u lilybuild nice make test -j2 
>> CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
>> 00:33:31 *** FAILED BUILD ***
>>  sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
>>  Previous good commit:   6addf21b5bc485d30e63bf2f04d371c10b902cdb

That's several weeks ago.

>>  Current broken commit:  c7a3623a056891d48b13fe14fd6ee042ac666822

> logfile lilypond-multi-run-1.log (exit 1):
> Processing `/home/lilybuild/build-staging/out/lybook-db/e2/lily-19b5eb79.ly'
> Parsing...
> Interpreting
> music.../home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18:
> In expression (ly:context-property context (quote keySignature)):
> /home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18:
> Unbound variable: ly:context-property
> logfile lilypond-multi-run-0.log (exit 1):
> Processing `/home/lilybuild/build-staging/out/lybook-db/6a/lily-e9632604.ly'
> Parsing...
> Interpreting
> music.../home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18:
> In expression (ly:context-property context (quote keySignature)):
> /home/lilybuild/build-staging/out/share/lilypond/current/scm/music-functions.scm:1599:18:
> Unbound variable: ly:context-property
> fatal error: Children (1 0) exited with errors.

git grep ly:context-property c7a3623a056891d48b13fe14fd6ee042ac666822

[...]
c7a3623a056891d48b13fe14fd6ee042ac666822:lily/context-scheme.cc:LY_DEFINE 
(ly_context_property, "ly:context-property",
[...]

This is defined just fine.  In fact,

git log 
6addf21b5bc485d30e63bf2f04d371c10b902cdb..c7a3623a056891d48b13fe14fd6ee042ac666822
 lily/context-scheme.cc

indicates that it has not changed at all in the (considerable) time span
involved.  Either your build system, your version of Patchy, or your
hardware is broken.

I'd have guessed that possibly the wrong dependencies are autogenerated,
but lily/context-scheme.cc has not changed its location one bit.

-- 
David Kastrup


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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Martin Tarenskeen  writes:

> On Mon, 8 Oct 2012, Trevor Daniels wrote:
>
>>
>> David Kastrup wrote Monday, October 08, 2012 10:45 PM
>>
>>
>>> Thomas Morley  writes:
>>>
 [...]
> So, i believe that LilyPond shouldn't always follow her users'
> intuition, even if they are professional musicians.  In this case, i
> think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time
> of 2), because it corresponds to mathematical ratio, and is similar to
> scaling durations.

 +1
>>>
>>> -1 from me for this one.  We have \times for that already and I can't
>>> count the times it took me to get the fraction right.  And with the name
>>> "\times" there is at least the mnemonic of the name itself.
>
> I am not in favour of allowing different commands \times 2/3 and
> \tuplet 3/2 to do the same job.

Why?  Nobody forces you to use a command you don't like.

> My voice would go to: just keep \times x/y the way it is.

The proposal was not about changing \times.

> I can't see what makes 3/2 easier than 2/3.

3 triplets on the time of 2 normal notes.  That concept is common enough
that one writes 3 (or even 3:2) in order to mark tuplets, not 2/3.  What
is 2/3 supposed to mean?  "Each note will take up 2/3 of its nominal
time, making the total phrase's total time, linearly distributed, a
ratio of 2/3 of its nominal time" -- that's a mathematician's
definition, and it is defective anyhow since it fails to explain the
difference between \times 2/3 and \times 4/6.

\tuplet 6/4 means getting 6 tuplets where 4 notes would be normally.
Now give me a definition of \times 4/6 that is sufficient to
differentiate it meaningfully from \times 2/3

> And having the choice of two commands doing the same job with a
> slightly different syntax only makes things more confusing for me.

Then take the choice once and ignore the existence of the other command
for the rest of your life.

-- 
David Kastrup

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Trevor Daniels]

Graham Percival wrote Tuesday, October 09, 2012 12:12 AM


> On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote:
>> 
>> David Kastrup wrote Monday, October 08, 2012 10:45 PM
>> 
>> > Thomas Morley  writes:
>> > 
>> >>> In this case, i
>> >>> think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time
>> >>> of 2), because it corresponds to mathematical ratio, and is similar to
>> >>> scaling durations.
>> >
>> > -1 from me for this one.  We have \times for that already and I can't
>> > count the times it took me to get the fraction right.  And with the name
>> > "\times" there is at least the mnemonic of the name itself.
>> 
>> Absolutely!  Inverting the fraction for \tuplet was the original reason
>> for inventing it, IIRC.
> 
> Woah, really?  I thought the whole point was to avoid the
> confusion between \time and \times.  

Yes, you're right.  The original suggestion was by Werner, here:
http://article.gmane.org/gmane.comp.gnu.lilypond.devel/7989

> I think it would be
> extremely confusing for "\tuplet x/y" to mean the same thing as
> "\times y/x".

Inverting the fraction so it corresponded to the normal notation
came later from Francisco, referenced here:
http://article.gmane.org/gmane.comp.gnu.lilypond.devel/14554
which makes the point that \times implies multiplication but
\tuplet does not, so the more logical ordering would be better.

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

Re: Make arguments like Context.GrobName accessible as symbol lists(issue 6635050)

[Trevor Daniels]

: Tuesday, October 09, 2012 8:36 AM

> On 2012/10/09 05:04:50, lemzwerg wrote:
>> http://codereview.appspot.com/6635050/diff/1/Documentation/de/notation/pitches.itely#newcode1529
>> Documentation/de/notation/pitches.itely:1529: \accidentalStyle
>> StaffGroup."voice"
>> This looks strange.  I don't expect double quotes after a dot.  Any
> better
>> representation possibility?
> 
> Agreed.  _All_ of the following will work:
> \accidentalStyle "StaffGroup.voice"
> \accidentalStyle StaffGroup.voice
> \accidentalStyle "StaffGroup"."voice"
> 
> whereas everything involving #"Staffgroup..." will _not_ work (only
> LilyPond strings autoconvert to symbols).
> 
> I think I'd go for
> \accidentalStyle Staffgroup.piano-cautionary
> myself as then the temptation to employ Scheme strings by accident is
> smaller, but then it seems inconsistent to use
> \accidentalStyle "piano-cautionary"
> so I'd crank open another convert-ly rule to turn those into
> \accidentalStyle piano-cautionary
> as well.  Which makes for worse backward-compatibility of scores.
> 
> What do people prefer to see?

As the 2.17 releases appear to be majoring on syntax changes I'd prefer
to go for the most intuitive easily-learned syntax rather than backward
compatibility.  Let's get all the syntax changes incorporated in 2.17,
then we can agree an immutable set ready for release 3.

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

David Kastrup  writes:

> Graham Percival  writes:
>
>> On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote:
>>> 
>>> David Kastrup wrote Monday, October 08, 2012 10:45 PM
>>> 
>>> > Thomas Morley  writes:
>>> > 
>>> >>> In this case, i
>>> >>> think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time
>>> >>> of 2), because it corresponds to mathematical ratio, and is similar to
>>> >>> scaling durations.
>>> >
>>> > -1 from me for this one.  We have \times for that already and I can't
>>> > count the times it took me to get the fraction right.  And with the name
>>> > "\times" there is at least the mnemonic of the name itself.
>>> 
>>> Absolutely!  Inverting the fraction for \tuplet was the original reason
>>> for inventing it, IIRC.
>>
>> Woah, really?  I thought the whole point was to avoid the
>> confusion between \time and \times.
>
> Both "the whole point" impressions are mistaken if you look at the
> original proposal in
> http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/50803>.
> It was one, deliberately separate point to discuss.  It was discussed,
> and a consensus was reached.

Obviously, "a consensus was reached" was inaccurate since at at the time
of writing, Janek had already voted against this.  I actually had to
reread his take on this since the detailed argument he makes _strongly_
argues in favor of \tuplet 3/2, but his conclusion is definitely quite
opposite.

Since then, also Martin has spoken up to express his dislike of a
\tuplet behaving substantially different from \times.  I disagree with
this take since substituting a new command should also give us a chance
to reconsider the best behavior without being bogged down by history.  A
new command name is the best chance of reevaluating the best semantics
for users we get.  We should not lightly waste it.

-- 
David Kastrup


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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Francisco Vila  writes:

> 2012/10/9 Keith OHara :
>> Currently, everyone who thinks of a triplet as a 3:2 ratio, 3 notes in the
>> usual time for 2, suffers similar confusion when trying to remember \times
>> 2/3.  Triplets are usually written with a simple 3, but 4-note-tuplets are
>> often designated 4:3 for clarity, while LilyPond requires the reversed
>> fraction in \times 3/4 {}
>
> Here come Spanish students again.
> I can think in \times  {} as a mathematical expression and
> it has sense, because "times" means multiply,

How does a mathematician explain the difference between \times 2/3 and
\times 4/6 ?

-- 
David Kastrup


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

Still alive

[m...@mikesolomon.org]

Hey list,

Just a quick ping to let you know that I'm not dead - I've been swamped w/ work 
recently and just got engaged so I'm planning out a wedding (w00t!).
I'll be back in the swing of things around mid-November if not sooner.

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Martin Tarenskeen]

On Mon, 8 Oct 2012, Keith OHara wrote:


Martin Tarenskeen  zonnet.nl> writes:

I am not in favour of allowing different commands \times 2/3 and \tuplet3/2 
to do the same job. My voice would go to: just keep \times x/y the wayit 
is. I can't see what makes 3/2 easier than 2/3. And having the choiceof two 
commands doing the same job with a slightly different syntax onlymakes 
things more confusing for me.




Currently, everyone who thinks of a triplet as a 3:2 ratio, 3 notes in the 
usual time for 2, suffers similar confusion when trying to remember \times 
2/3.  Triplets are usually written with a simple 3, but 4-note-tuplets are 
often designated 4:3 for clarity, while LilyPond requires the reversed 
fraction in \times 3/4 {}


The likely outcome would be to document only \tuplet 3/2 (or \tuplet3 or 
\triplet depending on what we choose) and have convert-ly change \times x/y 
to \tuplet y/x, but let LilyPond accept \times x/y from users who have 
developed the habit.  Then there is only one syntax in the documentation.


OK. You convinced me.

--

MT


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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[dak]

On 2012/10/09 08:14:55, t.daniels_treda.co.uk wrote:

: Tuesday, October 09, 2012 8:36 AM



> so I'd crank open another convert-ly rule to turn those into
> \accidentalStyle piano-cautionary
> as well.  Which makes for worse backward-compatibility of scores.
>
> What do people prefer to see?



As the 2.17 releases appear to be majoring on syntax changes I'd

prefer

to go for the most intuitive easily-learned syntax rather than

backward

compatibility.


Here is the rub: what we are currently talking about is a choice between
several convert-ly rules that all lead to valid programs after this
change.

Whether you write
\override TextSpanner #'(bound-details left stencil-align-dir-y) = #-2
or
\override Bottom.TextSpanner #'(bound-details left stencil-align-dir-y)
= #-2
or
\override #'(Bottom TextSpanner) bound-details.left.stencil-align-dir-y
= #-2
it is now all the same to LilyPond.

Now it is nice to have found underlying principles making it possible to
obliterate fine distinctions and remove the necessity of using Scheme
for specifying a grob property path to modify, with mostly cosmetic
backward compatibility consequences.

But since LilyPond is now able to _read_ a lot of different phrasings of
the same material, the question is how we want to be _writing_ this
material.

I'll likely go for the quoteless \accidentalStyle form generally here.

I think I'll prepare a radical convert-ly-only patch on top of this
patch series that demonstrates what "now valid" syntax we _could_ be
using/advertising as input if we wanted to.

We can get rid of a _lot_ of #' style thingies with this patch series.


Let's get all the syntax changes incorporated in 2.17,
then we can agree an immutable set ready for release 3.


"Immutable" as "we guarantee we will be able to process this" rather
than "we guarantee we will write our scores to have input looking like
that"?

http://codereview.appspot.com/6635050/

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

Re: Still alive

[Trevor Daniels]

m...@mikesolomon.org wrote Tuesday, October 09, 2012 9:19 AM

> Just a quick ping to let you know that I'm not dead - I've been swamped w/ 
> work recently and just got engaged so I'm planning out a wedding (w00t!).

Congratulations!  Does she _really_ know what she's letting herself in for ;)

> I'll be back in the swing of things around mid-November if not sooner.

Great!

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Francisco Vila]

2012/10/9 David Kastrup :
> Francisco Vila  writes:
>
>> 2012/10/9 Keith OHara :
>>> Currently, everyone who thinks of a triplet as a 3:2 ratio, 3 notes in the
>>> usual time for 2, suffers similar confusion when trying to remember \times
>>> 2/3.  Triplets are usually written with a simple 3, but 4-note-tuplets are
>>> often designated 4:3 for clarity, while LilyPond requires the reversed
>>> fraction in \times 3/4 {}
>>
>> Here come Spanish students again.
>> I can think in \times  {} as a mathematical expression and
>> it has sense, because "times" means multiply,
>
> How does a mathematician explain the difference between \times 2/3 and
> \times 4/6 ?

There is no difference BUT tuplets have a printed number, and in
lilypond this number is taken from the denominator for your
convenience.

When I learned how to read music, triplets were taught to me as
"always shrinking" groups and you see a "3" but there is an implicit
"2" so we have 3:2. Only the numerator is printed by convention.

Thus, if you write

  \times 2/3 { b16 b b b b b }

or

  \times 4/6 { b8 b b }

this is mathematically perfect but the number you are asking to be
printed is a confusing "3" and a confusing "6" respectively.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Benkő Pál]

2012/10/9 Francisco Vila :
> When I learned how to read music, triplets were taught to me as
> "always shrinking" groups and you see a "3" but there is an implicit
> "2" so we have 3:2. Only the numerator is printed by convention.
>
> Thus, if you write
>
>   \times 2/3 { b16 b b b b b }
>
> or
>
>   \times 4/6 { b8 b b }
>
> this is mathematically perfect but the number you are asking to be
> printed is a confusing "3" and a confusing "6" respectively.

the first is not confusing: it makes sure to read
b16[ b] b[ b] b[ b]
instead of
b16[ b b] b[ b b].

I think I've actually seen such a triplet in Ligeti's Requiem;
will look tonight.

p

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Francisco Vila  writes:

> 2012/10/9 David Kastrup :
>> Francisco Vila  writes:
>>
>>> 2012/10/9 Keith OHara :
 Currently, everyone who thinks of a triplet as a 3:2 ratio, 3 notes in the
 usual time for 2, suffers similar confusion when trying to remember \times
 2/3.  Triplets are usually written with a simple 3, but 4-note-tuplets are
 often designated 4:3 for clarity, while LilyPond requires the reversed
 fraction in \times 3/4 {}
>>>
>>> Here come Spanish students again.
>>> I can think in \times  {} as a mathematical expression and
>>> it has sense, because "times" means multiply,
>>
>> How does a mathematician explain the difference between \times 2/3 and
>> \times 4/6 ?
>
> There is no difference BUT tuplets have a printed number, and in
> lilypond this number is taken from the denominator for your
> convenience.
>
> When I learned how to read music, triplets were taught to me as
> "always shrinking" groups and you see a "3" but there is an implicit
> "2" so we have 3:2. Only the numerator is printed by convention.
>
> Thus, if you write
>
>   \times 2/3 { b16 b b b b b }
>
> or
>
>   \times 4/6 { b8 b b }
>
> this is mathematically perfect but the number you are asking to be
> printed is a confusing "3" and a confusing "6" respectively.

The concept used for printing/grouping tuplets is different than the
concept used for scaling the time.  That's what makes \times such a
confusing interface.

The pure scaling alone is available as \scaleDurations.  I have no beef
with it using 2/3 as input, and I would have trouble coming up with a
justification of using 3/2 here, actually seeing little point in doing
so.  One could use something like \compressMusic 3/2 but I don't see
much of a motivation for that.

But with tuplets, the concept is not really "scale duration by x" but
rather "n to m notes" including all the necessary visual changes, and
\times, including its argument style, expresses this concept poorly.

I don't really think that people consider \times and \scaleDurations as
closely related (and their naming choice is also totally different), so
I don't think that there will be much of an opportunity confusing the
behavior of \scaleDurations with \tuplet.

-- 
David Kastrup

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Benkő Pál]

2012/10/9 David Kastrup :
> The concept used for printing/grouping tuplets is different than the
> concept used for scaling the time.  That's what makes \times such a
> confusing interface.
>
> The pure scaling alone is available as \scaleDurations.  I have no beef
> with it using 2/3 as input, and I would have trouble coming up with a
> justification of using 3/2 here, actually seeing little point in doing
> so.  One could use something like \compressMusic 3/2 but I don't see
> much of a motivation for that.
>
> But with tuplets, the concept is not really "scale duration by x" but
> rather "n to m notes" including all the necessary visual changes, and
> \times, including its argument style, expresses this concept poorly.
>
> I don't really think that people consider \times and \scaleDurations as
> closely related (and their naming choice is also totally different), so
> I don't think that there will be much of an opportunity confusing the
> behavior of \scaleDurations with \tuplet.

I, for one, consider \times a visually enhanced variant of \scaleDurations.
regardless how it's written, to me both mean metric change (and metric
is represented poorly in graphic anyway).

p

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Francisco Vila]

2012/10/9 Benkő Pál :
> 2012/10/9 Francisco Vila :
>> When I learned how to read music, triplets were taught to me as
>> "always shrinking" groups and you see a "3" but there is an implicit
>> "2" so we have 3:2. Only the numerator is printed by convention.
>>
>> Thus, if you write
>>
>>   \times 2/3 { b16 b b b b b }
>>
>> or
>>
>>   \times 4/6 { b8 b b }
>>
>> this is mathematically perfect but the number you are asking to be
>> printed is a confusing "3" and a confusing "6" respectively.
>
> the first is not confusing: it makes sure to read
> b16[ b] b[ b] b[ b]

Yes, but I think it is more common to print a "6" here with the same meaning.

> instead of
> b16[ b b] b[ b b].


-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Benkő Pál  writes:

> 2012/10/9 David Kastrup :
>> The concept used for printing/grouping tuplets is different than the
>> concept used for scaling the time.  That's what makes \times such a
>> confusing interface.
>>
>> The pure scaling alone is available as \scaleDurations.  I have no beef
>> with it using 2/3 as input, and I would have trouble coming up with a
>> justification of using 3/2 here, actually seeing little point in doing
>> so.  One could use something like \compressMusic 3/2 but I don't see
>> much of a motivation for that.
>>
>> But with tuplets, the concept is not really "scale duration by x" but
>> rather "n to m notes" including all the necessary visual changes, and
>> \times, including its argument style, expresses this concept poorly.
>>
>> I don't really think that people consider \times and \scaleDurations as
>> closely related (and their naming choice is also totally different), so
>> I don't think that there will be much of an opportunity confusing the
>> behavior of \scaleDurations with \tuplet.
>
> I, for one, consider \times a visually enhanced variant of \scaleDurations.
> regardless how it's written, to me both mean metric change (and metric
> is represented poorly in graphic anyway).

Do you feel that the changed fraction gender of \tuplet would be a
potential source of confusion for you in the light of your view of
\scaleDurations?

-- 
David Kastrup


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

Re: Still alive

[m...@mikesolomon.org]

On 9 oct. 2012, at 11:39, Trevor Daniels  wrote:

> 
> m...@mikesolomon.org wrote Tuesday, October 09, 2012 9:19 AM
> 
>> Just a quick ping to let you know that I'm not dead - I've been swamped w/ 
>> work recently and just got engaged so I'm planning out a wedding (w00t!).
> 
> Congratulations!  Does she _really_ know what she's letting herself in for ;)

She's NUTS!

> 
>> I'll be back in the swing of things around mid-November if not sooner.
> 
> Great!
> 
> Trevor

See ya'll in a bit,
~Mike
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Still alive

[Trevor Daniels]

m...@mikesolomon.org: Tuesday, October 09, 2012 10:29 AM

On 9 oct. 2012, at 11:39, Trevor Daniels  wrote:
>> 
>> m...@mikesolomon.org wrote Tuesday, October 09, 2012 9:19 AM
>> 
>>> Just a quick ping to let you know that I'm not dead - I've been swamped w/ 
>>> work recently 
>>> and just got engaged so I'm planning out a wedding (w00t!).
>> 
>> Congratulations!  Does she _really_ know what she's letting herself in for ;)
>
> She's NUTS!

Sounds like an excellent match, then!  I'm sure you'll be great for each other.

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

Re: Still alive

[David Kastrup]

"m...@mikesolomon.org"  writes:

> On 9 oct. 2012, at 11:39, Trevor Daniels  wrote:
>
>> 
>> m...@mikesolomon.org wrote Tuesday, October 09, 2012 9:19 AM
>> 
>>> Just a quick ping to let you know that I'm not dead - I've been
>>> swamped w/ work recently and just got engaged so I'm planning out a
>>> wedding (w00t!).
>> 
>> Congratulations!  Does she _really_ know what she's letting herself in for ;)
>
> She's NUTS!

Good that you did not bring her to Waltrop then.  There would have been
a few squirrels wanting to talk to her.

-- 
David Kastrup


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

Re: [proposal] easy triplets and tuplets - Draft 3

[Reinhold Kainhofer]

On 2012-10-09 11:14, Francisco Vila wrote:> 2012/10/9 Benkő Pál 
:

>> 2012/10/9 Francisco Vila :
>>> When I learned how to read music, triplets were taught to me as
>>> "always shrinking" groups and you see a "3" but there is an implicit
>>> "2" so we have 3:2. Only the numerator is printed by convention.
>>>
>>> Thus, if you write
>>>
>>>\times 2/3 { b16 b b b b b }
>>>
>>> or
>>>
>>>\times 4/6 { b8 b b }
>>>
>>> this is mathematically perfect but the number you are asking to be
>>> printed is a confusing "3" and a confusing "6" respectively.
>>
>> the first is not confusing:

I think the point here was not that the tuplet notation on paper is 
confusing per se. Actually, both are VERY common (the 6:4 tuplets appear 
e.g. in Schubert's Stabat Mater, in several pieces by Preindl or Eybler, 
etc.)

What is confusing is that "3" is printed, when you actually write 2/3.
Also, Gould explains tuplets m:n as "m in the time of n" and calls m:n 
(i.e. 3:2) the tuplet ratio...



>> it makes sure to read
>> b16[ b] b[ b] b[ b]
>
> Yes, but I think it is more common to print a "6" here with the same
> meaning.

Not that I know.

A triplet (i.e. 3:2) means that there are three beats in the tuplet, the 
first might get a slight accent, while a sextuplet means there are two 
groups of three notes.

Also compare Gould, p. 213, regarding the subdivision of beams:

"A triplet is always a tripartite division, whereas a sextuplet is two 
groups each of three notes, a bipartite division."


Cheers,
Reinhold

--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Benkő Pál]

2012/10/9 David Kastrup :
> Benkő Pál  writes:
>
>> 2012/10/9 David Kastrup :
>>> I don't really think that people consider \times and \scaleDurations as
>>> closely related (and their naming choice is also totally different), so
>>> I don't think that there will be much of an opportunity confusing the
>>> behavior of \scaleDurations with \tuplet.
>>
>> I, for one, consider \times a visually enhanced variant of \scaleDurations.
>> regardless how it's written, to me both mean metric change (and metric
>> is represented poorly in graphic anyway).
>
> Do you feel that the changed fraction gender of \tuplet would be a
> potential source of confusion for you in the light of your view of
> \scaleDurations?

definitely not, I'm fine with the \tuplet proposal, it mimics better the
engraved representation.  BTW do we still have \compressMusic or
only \scaleDurations?

p

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[Trevor Daniels]

d...@gnu.org: Tuesday, October 09, 2012 9:38 AM


> Here is the rub: what we are currently talking about is a choice between
> several convert-ly rules that all lead to valid programs after this
> change.
> 
> Whether you write
> \override TextSpanner #'(bound-details left stencil-align-dir-y) = #-2
> or
> \override Bottom.TextSpanner #'(bound-details left stencil-align-dir-y)
> = #-2
> or
> \override #'(Bottom TextSpanner) bound-details.left.stencil-align-dir-y
> = #-2

and presumably even
\override Voice.TextSpanner   bound-details.left.stencil-align-dir-y = #-2
(which I prefer)

> it is now all the same to LilyPond.
> 
> Now it is nice to have found underlying principles making it possible to
> obliterate fine distinctions and remove the necessity of using Scheme
> for specifying a grob property path to modify, with mostly cosmetic
> backward compatibility consequences.
> 
> But since LilyPond is now able to _read_ a lot of different phrasings of
> the same material, the question is how we want to be _writing_ this
> material.

Indeed.  We need to define a canonical form for the bulk of the manuals,
although we should explain the flexibility and available variants once.
 
> I'll likely go for the quoteless \accidentalStyle form generally here.

Good.
 
> I think I'll prepare a radical convert-ly-only patch on top of this
> patch series that demonstrates what "now valid" syntax we _could_ be
> using/advertising as input if we wanted to.

It's only right and just that you get first go at suggesting a canonical form,
and a patch would be a good way of expressing your preference.
(Regexp tutorial, anyone?  Although we can always apply the patch and 
run it on the manuals.)

> We can get rid of a _lot_ of #' style thingies with this patch series.

The more the better.

>> Let's get all the syntax changes incorporated in 2.17,
>> then we can agree an immutable set ready for release 3.
> 
> "Immutable" as "we guarantee we will be able to process this" rather
> than "we guarantee we will write our scores to have input looking like
> that"?

I meant the former; the latter would be just an aspiration.  As with 
the documentation, this will need an agreement on the canonical form.

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Benkő Pál  writes:

> 2012/10/9 David Kastrup :
>> Benkő Pál  writes:
>>
>>> 2012/10/9 David Kastrup :
 I don't really think that people consider \times and \scaleDurations as
 closely related (and their naming choice is also totally different), so
 I don't think that there will be much of an opportunity confusing the
 behavior of \scaleDurations with \tuplet.
>>>
>>> I, for one, consider \times a visually enhanced variant of \scaleDurations.
>>> regardless how it's written, to me both mean metric change (and metric
>>> is represented poorly in graphic anyway).
>>
>> Do you feel that the changed fraction gender of \tuplet would be a
>> potential source of confusion for you in the light of your view of
>> \scaleDurations?
>
> definitely not, I'm fine with the \tuplet proposal, it mimics better the
> engraved representation.  BTW do we still have \compressMusic or
> only \scaleDurations?

Huh.

@newsItem
@subsubheading LilyPond 2.11.48 released.  @emph{June 9, 2008}

LilyPond 2.11.48 is out.  This release fixes a few bugs, and
@code{\compressMusic} has been renamed
to @code{\scaleDurations}.
@*

I was not actually aware that there ever _was_ a \compressMusic, and it
would appear that it had the _same_ fraction interpretation as
\scaleDurations.  Probably that was the reason for renaming it.

Reintroducing it with inversed meaning might not be the hottest idea,
then.  The underlying Scheme primitive, by the way, is called
ly:music-compress:

LY_DEFINE (ly_music_compress, "ly:music-compress",
   2, 0, 0, (SCM m, SCM factor),
   "Compress music object@tie{}@var{m} by moment @var{factor}.")

It ultimately calls

Duration::compressed (Rational m) const
{
  Duration d (*this);
  d.factor_ *= m;
  return d;
}

so we have this misnomer of "compress" for what is actually "scale"
(namely making things longer for factors > 1) throughout the whole
Scheme API and C++ layer.

It's just the user interface that has apparently been relieved of this
embarrassing name choice.  Reintroducing it with inversed meaning would
make a bit of isolated sense in the user interface, but would be
horribly confusing in light of all the other layers employing different
terminology.

So if we want to introduce a "scale Durations by 1/x" user level
function at some point of time, \compressMusic seems to be an awfully
bad naming choice for that, for historical as well as continuing
reasons.

I was not aware of that.

-- 
David Kastrup

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

Re: [Lilypond-auto] Patchy report

[John Mandereau]

Il giorno mar, 09/10/2012 alle 09.57 +0200, David Kastrup ha scritto:
> John Mandereau  writes:
> 
> > Hi,
> >
> > I quote some of the logs below...
> > Il giorno mar, 09/10/2012 alle 00.33 +, grenoui...@lilynet.net ha
> > scritto:
> >> 21:58:01 (UTC) Begin LilyPond compile, previous commit at  
> >> c7a3623a056891d48b13fe14fd6ee042ac666822
> >> 21:58:27 Merged staging, now at:   c7a3623a056891d48b13fe14fd6ee042ac666822
> >> 21:58:29   Success:sudo -u lilybuild ./autogen.sh 
> >> --noconfigure
> >> 21:59:05   Success:sudo -u lilybuild 
> >> /home/lilybuild/staging/configure --disable-optimising
> >> 21:59:15   Success:sudo -u lilybuild nice make clean
> >> 22:16:12   Success:sudo -u lilybuild nice make -j2 
> >> CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
> >> 22:38:05   Success:sudo -u lilybuild nice make test -j2 
> >> CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
> >> 00:33:31 *** FAILED BUILD ***
> >>sudo -u lilybuild nice make doc -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1
> >>Previous good commit:   6addf21b5bc485d30e63bf2f04d371c10b902cdb
> 
> That's several weeks ago.

Indeed, this is crazy, because you can see on lilypond-auto list that
Patchy successfully built the same Git committish
c7a3623a056891d48b13fe14fd6ee042ac666822 one day ago.


> indicates that it has not changed at all in the (considerable) time span
> involved.  Either your build system, your version of Patchy, or your
> hardware is broken.

This could be well a hardware problem (again).  The system administrator
of the MSHPN may propose a replacement computer this month or in
November.

John


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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[dak]

On 2012/10/09 10:03:59, t.daniels_treda.co.uk wrote:

d...@gnu.org: Tuesday, October 09, 2012 9:38 AM



> I think I'll prepare a radical convert-ly-only patch on top of this
> patch series that demonstrates what "now valid" syntax we _could_ be
> using/advertising as input if we wanted to.



It's only right and just that you get first go at suggesting a
canonical form, and a patch would be a good way of expressing your
preference.


Well, I am a programmer.  I know what symbols are and what strings are
and can deal with the differences just fine.

The main point of such a radical convert-ly-only patch (which is going
to convert valid syntax into also valid syntax) is to provide one
extreme outlook as a reference point for discussion.  The main
obstacles will be the need to redocument, to rethink, to reeducate,
and to talk with those who have to deal with scores written by others,
and with those who teach others about LilyPond.

In all of those areas my voice carries less rather than more weight
than that of others.


>> Let's get all the syntax changes incorporated in 2.17,
>> then we can agree an immutable set ready for release 3.
>
> "Immutable" as "we guarantee we will be able to process this" rather
> than "we guarantee we will write our scores to have input looking

like

> that"?



I meant the former; the latter would be just an aspiration.  As with
the documentation, this will need an agreement on the canonical form.


Perhaps \displayLilyMusic and its underlying primitives at some point
of time will need to allow specifying a preferred printing style to
use.

At least those that use \displayMusic and its ilk for harvesting
LilyPond's interpretation of an input file will not be affected.


http://codereview.appspot.com/6635050/

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[Werner LEMBERG]

> \accidentalStyle StaffGroup.voice

This is my preferred form.  However, some time ago we decided (more or
less) to say e.g.

  \clef "bass"

In the light of your syntax improvements/simplifications, shouldn't we
start to use

  \clef bass

instead, making data in double quotes really user strings only?


Werner

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[David Kastrup]

Werner LEMBERG  writes:

>> \accidentalStyle StaffGroup.voice
>
> This is my preferred form.  However, some time ago we decided (more or
> less) to say e.g.
>
>   \clef "bass"
>
> In the light of your syntax improvements/simplifications, shouldn't we
> start to use
>
>   \clef bass
>
> instead, making data in double quotes really user strings only?

\clef bass_8 won't work, neither will \clef treble^8, and I see no
sensible way to make them work.  As long as that is our naming choice,
using quotes for clefs is the only way to keep the syntax consistent.

-- 
David Kastrup

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

Re: Still alive

[Ian Hulin]

On 09/10/12 09:19, m...@mikesolomon.org wrote:
> Hey list,
> 
> Just a quick ping to let you know that I'm not dead - I've been swamped w/ 
> work recently and just got engaged so I'm planning out a wedding (w00t!).

CONGRATULATIONS TO YOU BOTH
(to Mike (Han) Solo and Princess Leia)

Cheers,
Ian


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

Re: Still alive

[David Kastrup]

Ian Hulin  writes:

> On 09/10/12 09:19, m...@mikesolomon.org wrote:
>> Hey list,
>> 
>> Just a quick ping to let you know that I'm not dead - I've been
>> swamped w/ work recently and just got engaged so I'm planning out a
>> wedding (w00t!).
>
> CONGRATULATIONS TO YOU BOTH
>   (to Mike (Han) Solo and Princess Leia)

Isn't that Han-Wen Solo?

-- 
David Kastrup


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

Re: [proposal] easy triplets and tuplets - Draft 3

[Janek Warchoł]

Hi,

wow, many more emails arrived!  Let me send my thoughts written in the
meantime, and go back offline for a few hours.

i've found a reason why i could support "reversed" tuplet ratio: if we
decide to allow arbitrary integer durations (so that a3 would mean a
third of the whole note), it would make more sense to have { a3 b6 }
equivalent to \tuplet 3/2 { a2 b4 } rather than have it equivalent to
\tuplet 2/3 { a2 b4 }.  In other words, in LilyPond we express
duration using the /denominator/ of the fraction, so it makes sense to
multiply duration 2 (half note) by 3/2 to get duration 3 (a triplet).
Do you see what i mean?

However, if we reverse the argument in \tuplet, we definitely should
deprecate \times.  Having both \times 2/3 and \tuplet 3/2 for
specifying triplets would be *very* confusing.

I agree that specifying not just x/y ratio but also x/y "of what?" is
a good idea.  I don't have any idea on how the actual syntax might
look like, though.

As for transposing clefs, i play guitar a bit myself, and i have once
typeset a piece using both G and G_8 clefs.  Maybe it was a bad idea,
but for me it was perfectly fine.

On Tue, Oct 9, 2012 at 1:16 AM, Joseph Rushton Wakeling
 wrote:
> If you _did_ insist on the distinction between those clefs being important,
> it would be very problematic because then as a guitarist (or piccolist, or
> bass player, or conductor) you'd have to spend lots of time worrying about
> whether the omission of that "8" on the clef actually meant something or was
> just a typo.  Whereas as things are, you can just ignore it.
>
> Now think about extending that to other transposing instruments.  Should a
> bass clarinet be notated in \treble sounding a 12th below what is written,
> or in \treble_8 sounding a 2nd below?  Isn't the important thing (as player
> or conductor) that you never have to worry about it?

It seems that our opinions on this subject are totally opposite.
While i definitely agree that the important thing is that performers
don't have to worry about this issue, in my opinion the *only* way to
ensure this is to state clef transpositions explicitely.  After all,
it doesn't cost you anything to write them.
For me, what we currently have is a holly mess.  There are some areas
where ambiguity can be your goal, but i don't see how it could be
here.  In my opinion it is *infinitely* better to write down the
information than to leave it to the performer to guess it based on
tradition.
For example, despite the fact that i'm an amateur musician (guitar &
voice), i had learned note names quickly.  However, for *many years* i
had no idea that some instruments are transposed.  Had i tried to play
a transposed instrument, i would play exactly what was written.  When
i learned that some instruments are transposed *and that the
transposition isn't marked in the notation*, i felt it was outrageous.
 I still believe it was a foolish idea to start notating transposing
instruments in this way, i.e. without any indication next to the clef
(no idea who started it, though :P).
For example, the horn transposition can be either a fourth or a fifth.
 For me this is nonsense: you want to play from some old score, but
you have to ask a musicologist to be sure what the notes actually are
:(

I hope that this email hadn't become too sarcastic or disparaging :/


On Tue, Oct 9, 2012 at 1:16 AM, Joseph Rushton Wakeling
 wrote:
> Don't know about you, but I find they always seem to be most tempting to
> write whenever I have something else really important (work, study,
> planning, big life change ...) upcoming that I should really be
> concentrating on :-P

true :P  but my conscience is clean this time, as i wrote this email
when commuting, without internet access :)

cheers,
Janek

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Janek Warchoł  writes:

> wow, many more emails arrived!  Let me send my thoughts written in the
> meantime, and go back offline for a few hours.
>
> i've found a reason why i could support "reversed" tuplet ratio: if we
> decide to allow arbitrary integer durations (so that a3 would mean a
> third of the whole note), it would make more sense to have { a3 b6 }
> equivalent to \tuplet 3/2 { a2 b4 } rather than have it equivalent to
> \tuplet 2/3 { a2 b4 }.  In other words, in LilyPond we express
> duration using the /denominator/ of the fraction, so it makes sense to
> multiply duration 2 (half note) by 3/2 to get duration 3 (a triplet).
> Do you see what i mean?

With the same kind of logic, s2 + s2 should be s4, so I hope this reason
will not remain the only one you can find.

> However, if we reverse the argument in \tuplet, we definitely should
> deprecate \times.  Having both \times 2/3 and \tuplet 3/2 for
> specifying triplets would be *very* confusing.

I agree that using them interchangeably in the documentation would not
be helpful.  I see no reason to _remove_ \times, however.  It would
likely be more than enough to have its documentation string point out
the existence of \tuplet.  Using a convert-ly rule for a blanket
conversion \times->\tuplet would be something I would consider
appropriate.

-- 
David Kastrup

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[lemzwerg]

LGTM.


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

http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly#newcode105
ly/music-functions-init.ly:105: (ly:input-warning location (_ "not a
spanner name, `~a'") name)
Wouldn't

  "`~a' is not a spanner name"

be more appropriate?

http://codereview.appspot.com/6635050/

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[dak]

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

http://codereview.appspot.com/6635050/diff/7002/ly/music-functions-init.ly#newcode105
ly/music-functions-init.ly:105: (ly:input-warning location (_ "not a
spanner name, `~a'") name)
On 2012/10/09 16:44:16, lemzwerg wrote:

Wouldn't



   "`~a' is not a spanner name"



be more appropriate?


No idea, I just copied the existing error message.  And the
corresponding regression test already expects this warning.

http://codereview.appspot.com/6635050/

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

[PATCH 05/16] Let \accidentalStyle detect its optional context argument by looking at its letter case

[David Kastrup]

This is a fishy stopgap measure to let \accidentalStyle able to
distinguish #'Voice "default" from "default" alone while we generate
symbols from from #'Voice as well as "default".  If the first letter
is uppercase, the symbol is considered to be a context specification.
---
 ly/property-init.ly |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/ly/property-init.ly b/ly/property-init.ly
index e36c3c0..caf6ad0 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -13,10 +13,16 @@ defaultNoteHeads =
(_i "Revert to the default note head style.")
(revert-head-style '(NoteHead TabNoteHead)))
 
+#(define (context-name? c)
+  "A stopgap measure until dotted lists become available as arguments.
+Distinguish context names from accidental styles by virtue of their
+first letter being uppercase."
+  (and (symbol? c)
+   (char-upper-case? (string-ref (symbol->string c) 0
 
 accidentalStyle =
 #(define-music-function
-   (parser location context style) ((symbol?) string?)
+   (parser location context style) ((context-name?) string?)
(_i "Set accidental style to @var{style}, a string.  If an optional
 @var{context} symbol is given, e.g. @code{#'Staff} or @code{#'Voice},
 the settings are applied to that context.  Otherwise, the context
-- 
1.7.9.5


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

[PATCH 08/16] Allow property and grob paths to be constructed from strings

[David Kastrup]

---
 lily/parser.yy |  242 
 1 file changed, 175 insertions(+), 67 deletions(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index 270961f..6a087d8 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -381,6 +381,7 @@ If we give names, Bison complains.
 %token SCM_TOKEN
 %token SCORE_IDENTIFIER
 %token STRING
+%token SYMBOL_LIST
 %token TONICNAME_PITCH
 
 %left '-' '+'
@@ -1158,6 +1159,34 @@ grouped_music_list:
  MUSIC_FUNCTION EXPECT_PITCH EXPECT_SCM EXPECT_SCM EXPECT_NO_MORE_ARGS
 and this rule returns the reversed list of arguments. */
 
+/* Function argument lists come in a number of flavors.  Whenever
+ * LilyPond has to pick between different flavors, the decision is
+ * either made because of tokens it has already seen, or it is
+ * postponed until tokens suitable for making the decision come up.
+ * For postponing decisions, it may be necessary that the competing
+ * rules are written in a way making them compatible until a decision
+ * can be made.  Sometimes this is done by putting common traits into
+ * a separate "common" rule set.
+ *
+ * function_arglist: a full argument list.  Optional arguments at the
+ * end of the list can only be skipped by writing \default in their
+ * place.
+ *
+ * function_arglist_backup: an argument list ending in an optional
+ * argument that may be skipped depending on its predicate.
+ *
+ * function_arglist_skip: an argument list _not_ ending in an optional
+ * argument that is actually taken.
+ *
+ * function_arglist_nonbackup: an argument list ending in an optional
+ * argument that may not be skipped because it is in end position and
+ * has not been shortcircuited with \default.
+ *
+ * function_arglist* / function_arglist_closed*: The closed variants
+ * don't end in simple music expressions that might still accept
+ * things like a duration or a postevent.
+ */
+
 function_arglist_skip:
function_arglist_common
| EXPECT_OPTIONAL EXPECT_PITCH function_arglist_skip
@@ -1260,6 +1289,46 @@ function_arglist_closed_nonbackup:
}
;
 
+symbol_list_arg:
+   SYMBOL_LIST
+   | SYMBOL_LIST '.' symbol_list_rev
+   {
+   $$ = scm_append (scm_list_2 ($1, scm_reverse_x ($3, SCM_EOL)));
+   }
+   ;
+
+symbol_list_rev:
+   symbol_list_part
+   | symbol_list_rev '.' symbol_list_part
+   {
+   $$ = scm_append_x (scm_list_2 ($3, $1));
+   }
+   ;
+
+symbol_list_part:
+   symbol_list_element
+   {
+   SCM sym_l_p = ly_lily_module_constant ("symbol-list?");
+   if (scm_is_true (scm_call_1 (sym_l_p, $1)))
+   $$ = scm_reverse ($1);
+   else {
+   $$ = try_string_variants (sym_l_p, $1);
+   if (SCM_UNBNDP ($$)) {
+   parser->parser_error (@1, _("not a symbol"));
+   $$ = SCM_EOL;
+   }
+   }
+   }
+   ;
+
+
+symbol_list_element:
+   STRING
+   | LYRICS_STRING
+   | embedded_scm_bare
+   ;
+
+
 function_arglist_nonbackup:
function_arglist_nonbackup_common
| EXPECT_OPTIONAL EXPECT_SCM function_arglist embedded_scm_arg
@@ -1270,14 +1339,6 @@ function_arglist_nonbackup:
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist STRING
-   {
-   SCM res = try_string_variants ($2, $4);
-   if (SCM_UNBNDP (res))
-   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
-   else
-   $$ = scm_cons (res, $3);
-   }
| function_arglist_nonbackup_reparse REPARSE SCM_ARG
{
$$ = check_scheme_arg (parser, @3, $3, $1, $2);
@@ -1286,6 +1347,10 @@ function_arglist_nonbackup:
{
$$ = check_scheme_arg (parser, @3, $3, $1, $2);
}
+   | function_arglist_nonbackup_reparse REPARSE symbol_list_arg
+   {
+   $$ = check_scheme_arg (parser, @3, $3, $1, $2);
+   }
;
 
 function_arglist_nonbackup_reparse:
@@ -1294,7 +1359,10 @@ function_arglist_nonbackup_reparse:
$$ = $3;
SCM res = try_string_variants ($2, $4);
if (!SCM_UNBNDP (res))
-   MYREPARSE (@4, $2, SCM_ARG, res);
+   if (scm_is_pair (res))
+   MYREPARSE (@4, $2, SYMBOL_LIST, res);
+   else
+   MYREPARSE (@4, $2, SCM_ARG, res);
else if (scm_is_true
 (scm_call_1
  ($2, make_music_from_simple
@@ -1308,7 +1376,10 @@ function_arglist_nonbackup_reparse:
$$ = $3;
SCM res = try_string_variants ($2, $4);
if (!SCM_UNBNDP (res))
-   MYREPARSE (@4, $2, S

[PATCH 07/16] Add symbol-list? predicate

[David Kastrup]

---
 scm/c++.scm  |3 +++
 scm/lily.scm |1 +
 2 files changed, 4 insertions(+)

diff --git a/scm/c++.scm b/scm/c++.scm
index 444a3e9..d627481 100644
--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -48,6 +48,9 @@
 (define-public (boolean-or-symbol? x)
   (or (boolean? x) (symbol? x)))
 
+(define-public (symbol-list? x)
+  (and (list? x) (every symbol? x)))
+
 (define-public (string-or-symbol? x)
   (or (string? x) (symbol? x)))
 
diff --git a/scm/lily.scm b/scm/lily.scm
index b8b0216..a74d6af 100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -578,6 +578,7 @@ messages into errors.")
 (,string-or-pair? . "string or pair")
 (,string-or-music? . "string or music")
 (,string-or-symbol? . "string or symbol")
+(,symbol-list? . "symbol list")
 (,void? . "void")
 ))
 
-- 
1.7.9.5


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

[PATCH 11/16] Replace the rather fuzzy list-or-symbol? with symbol-list-or-symbol?

[David Kastrup]

list-or-symbol? was previously used in the meaning of
symbol-list-or-symbol? only, and there is no point in not checking the
list members for actually being symbols, in order to avoid ugly
surprises later.
---
 ly/music-functions-init.ly |2 +-
 ly/property-init.ly|2 +-
 scm/c++.scm|6 --
 scm/lily.scm   |3 +--
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index 2180b89..3c60565 100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -1227,7 +1227,7 @@ the `parameters' assoc list.")
 
 styledNoteHeads =
 #(define-music-function (parser location style heads music)
-   (symbol? list-or-symbol? ly:music?)
+   (symbol? symbol-list-or-symbol? ly:music?)
(_i "Set @var{heads} in @var{music} to @var{style}.")
(style-note-heads heads style music))
 
diff --git a/ly/property-init.ly b/ly/property-init.ly
index caf6ad0..3a88098 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -365,7 +365,7 @@ back to the lilypond source statement.")
(make-music 'SequentialMusic 'void #t))
 
 pointAndClickTypes =
-#(define-void-function (parser location types) (list-or-symbol?)
+#(define-void-function (parser location types) (symbol-list-or-symbol?)
   (_i "Set a type or list of types (such as @code{#'note-event}) for which 
point-and-click info is generated.")
   (ly:set-option 'point-and-click types))
 
diff --git a/scm/c++.scm b/scm/c++.scm
index 12c38a3..8d1df2a 100644
--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -74,8 +74,10 @@
 (define-public (cheap-list? x)
   (or (pair? x) (null? x)))
 
-(define-public (list-or-symbol? x)
-  (or (cheap-list? x) (symbol? x)))
+(define-public (symbol-list-or-symbol? x)
+  (if (list? x)
+  (every symbol? x)
+  (symbol? x)))
 
 (define-public (scheme? x) #t)
 
diff --git a/scm/lily.scm b/scm/lily.scm
index 268fd1c..4263ab4 100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -562,8 +562,6 @@ messages into errors.")
 (,fraction? . "fraction, as pair")
 (,grob-list? . "list of grobs")
 (,index? . "non-negative integer")
-;; this is built on cheap-list
-(,list-or-symbol? . "list or symbol")
 (,markup? . "markup")
 (,markup-command-list? . "markup command list")
 (,markup-list? . "markup list")
@@ -580,6 +578,7 @@ messages into errors.")
 (,string-or-symbol? . "string or symbol")
 (,symbol-list? . "symbol list")
 (,symbol-list-or-music? . "symbol list or music")
+(,symbol-list-or-symbol? . "symbol list or symbol")
 (,void? . "void")
 ))
 
-- 
1.7.9.5


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

[PATCH 13/16] Change \accidentalStyle to get a symbol list as argument

[David Kastrup]

This changes the syntax of \accidentalStyle to accept specs like
Voice.piano-cautionary .
---
 ly/property-init.ly |   29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/ly/property-init.ly b/ly/property-init.ly
index 3a88098..28a13e3 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -13,24 +13,21 @@ defaultNoteHeads =
(_i "Revert to the default note head style.")
(revert-head-style '(NoteHead TabNoteHead)))
 
-#(define (context-name? c)
-  "A stopgap measure until dotted lists become available as arguments.
-Distinguish context names from accidental styles by virtue of their
-first letter being uppercase."
-  (and (symbol? c)
-   (char-upper-case? (string-ref (symbol->string c) 0
-
 accidentalStyle =
 #(define-music-function
-   (parser location context style) ((context-name?) string?)
-   (_i "Set accidental style to @var{style}, a string.  If an optional
-@var{context} symbol is given, e.g. @code{#'Staff} or @code{#'Voice},
-the settings are applied to that context.  Otherwise, the context
-defaults to @samp{Staff}, except for piano styles, which use
-@samp{GrandStaff} as a context." )
-   (if context
-   (set-accidental-style (string->symbol style) context)
-   (set-accidental-style (string->symbol style
+   (parser location style) (symbol-list?)
+   (_i "Set accidental style to symbol list @var{style} in the form
+@samp{piano-cautionary}.  If @var{style} has a form like
+@samp{Staff.piano-cautionary}, the settings are applied to that
+context.  Otherwise, the context defaults to @samp{Staff}, except for
+piano styles, which use @samp{GrandStaff} as a context." )
+   (case (length style)
+((1) (set-accidental-style (car style)))
+((2) (set-accidental-style (cadr style) (car style)))
+(else
+ (ly:parser-parse-error parser (_ "not an accidental style")
+  location)
+ (make-music 'Music
 
 %% arpeggios
 
-- 
1.7.9.5


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

[PATCH 03/16] parser.yy: make is_regular_identifier match the lexer definition

[David Kastrup]

is_regular_identifier checks now for valid identifiers employing the
definition of words that is also used in the lexer: letters, and
characters outside of the ASCII range, interspersed with single - and
_ characters.
---
 lily/parser.yy |   27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index d6dcf11..3fda842 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -3199,19 +3199,22 @@ bool
 is_regular_identifier (SCM id)
 {
   string str = ly_scm2string (id);
-  char const *s = str.c_str ();
 
-  bool v = true;
-#if 0
-  isalpha (*s);
-  s++;
-#endif
-  while (*s && v)
-   {
-v = v && isalnum (*s);
-s++;
-   }
-  return v;
+  bool middle = false;
+
+  for (string::iterator it=str.begin(); it != str.end (); it++)
+  {
+ int c = *it & 0xff;
+ if ((c >= 'a' && c <= 'z')
+ || (c >= 'A' && c <= 'Z')
+ || c > 0x7f)
+ middle = true;
+ else if (middle && (c == '-' || c == '_'))
+ middle = false;
+ else
+ return false;
+  }
+  return middle;
 }
 
 SCM
-- 
1.7.9.5


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

Context.Grob considered as symbol list

[David Kastrup]

Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.

Let's see how we fare.

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

[PATCH 14/16] convert-ly rule for \alterbroken, \accidentalStyle, \overrideProperty

[David Kastrup]

This is required since not all of the old call forms can be
automatically recognized anymore, in particular not when the
Scheme-only form #"Context.GrobName" is being used.
---
 python/convertrules.py |   13 +
 1 file changed, 13 insertions(+)

diff --git a/python/convertrules.py b/python/convertrules.py
index b8921a0..3da8459 100644
--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -3398,6 +3398,19 @@ def conv (str):
   matcharg + ")", r"\\shape\2\1", str)
 return str
 
+@rule ((2, 17, 5), r"""\accidentalStyle #'Context "style" -> \accidentalStyle 
Context.style
+\alterBroken "Context.grob" -> \alterBroken Context.grob
+\overrideProperty "Context.grob" -> \overrideProperty Context.grob""")
+def conv (str):
+str = re.sub (r'''(\\accidentalStyle\s+)#?"([-A-Za-z]+)"''',
+  r"\1\2", str)
+str = re.sub 
(r'''(\\accidentalStyle\s+)#'([A-Za-z]+)\s+#?"?([-A-Za-z]+)"?''',
+  r"\1\2.\3", str)
+str = re.sub 
(r'''(\\(?:alterBroken|overrideProperty)\s+)#?"([A-Za-z]+)\s*\.\s*([A-Za-z]+)"''',
+  r"\1\2.\3", str)
+return str
+
+
 # Guidelines to write rules (please keep this at the end of this file)
 #
 # - keep at most one rule per version; if several conversions should be done,
-- 
1.7.9.5


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

[PATCH 16/16] Let \overrideProperty accept nested properties

[David Kastrup]

---
 ly/music-functions-init.ly |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index ef93fab..c32645a 100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -712,10 +712,10 @@ of @var{base-moment}, @var{beat-structure}, and 
@var{beam-exceptions}.")
 (override-time-signature-setting time-signature setting)))
 
 overrideProperty =
-#(define-music-function (parser location name property value)
-   (symbol-list? symbol? scheme?)
+#(define-music-function (parser location name property-path value)
+   (symbol-list? symbol-list-or-symbol? scheme?)
 
-   (_i "Set @var{property} to @var{value} in all grobs named @var{name}.
+   (_i "Set @var{property-path} to @var{value} in all grobs named @var{name}.
 The @var{name} argument is a symbol list of the form @code{Context.GrobName}
 or @code{GrobName}.")
(if (<= 1 (length name) 2)
@@ -727,11 +727,20 @@ or @code{GrobName}.")
  (if (equal?
   (cdr (assoc 'name (ly:grob-property grob 'meta)))
   (last name))
- (set! (ly:grob-property grob property) value
+ (if (symbol? property-path)
+ (ly:grob-set-property! grob property-path value)
+ (case (length property-path)
+   ((0))
+   ((1)
+(ly:grob-set-property!
+ grob (car property-path) value))
+   (else
+(ly:grob-set-nested-property!
+ grob property-path value)))
(begin
  (ly:parser-error parser (_ "bad grob name") location)
  (make-music 'Music
-   
+
 
 
 
-- 
1.7.9.5


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

[PATCH 02/16] parser.yy: FRACTION does not require a closed expression before it

[David Kastrup]

FRACTION items can't trail any other valid expression without
separating '*' or similar, so the argument list before them does not
need to be of "closed" type.
---
 lily/parser.yy |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index 193655c..d6dcf11 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -1177,7 +1177,7 @@ function_arglist_nonbackup_common:
| EXPECT_OPTIONAL EXPECT_DURATION function_arglist_closed 
duration_length {
$$ = scm_cons ($4, $3);
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed FRACTION
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist FRACTION
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
@@ -1319,7 +1319,7 @@ function_arglist_backup:
MYBACKUP (NUMBER_IDENTIFIER, $4, @4);
}
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed_keep FRACTION
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_keep FRACTION
{
if (scm_is_true (scm_call_1 ($2, $4)))
{
@@ -1410,7 +1410,7 @@ function_arglist_common:
$$ = check_scheme_arg (parser, @3,
   $3, $2, $1);
}
-   | EXPECT_SCM function_arglist_closed_optional FRACTION
+   | EXPECT_SCM function_arglist_optional FRACTION
{
$$ = check_scheme_arg (parser, @3,
   $3, $2, $1);
@@ -1549,7 +1549,7 @@ function_arglist_closed_common:
$$ = check_scheme_arg (parser, @3,
   $3, $2, $1);
}
-   | EXPECT_SCM function_arglist_closed_optional FRACTION
+   | EXPECT_SCM function_arglist_optional FRACTION
{
$$ = check_scheme_arg (parser, @3,
   $3, $2, $1);
-- 
1.7.9.5


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

[PATCH 12/16] Make \alterBroken, \hide, \omit, \overrideProperty, \shape take unquoted Context.Grob specs

[David Kastrup]

This changes the syntax of the named commands to accept
Voice.Accidental and similar specifications without any quoting.
---
 ly/music-functions-init.ly |  100 +++-
 1 file changed, 44 insertions(+), 56 deletions(-)

diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index 3c60565..f1af3e4 100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -87,34 +87,23 @@ markups), or inside a score.")
 
 alterBroken =
 #(define-music-function (parser location name property arg)
-  (string? scheme? list?)
+  (symbol-list? symbol? list?)
   (_i "Override @var{property} for pieces of broken spanner @var{name} with
 values @var{arg}.")
-  (let* ((name (string-delete name char-set:blank)) ; remove any spaces
- (name-components (string-split name #\.))
- (context-name "Bottom")
- (grob-name #f))
-
-(if (> 2 (length name-components))
-(set! grob-name (car name-components))
-(begin
-  (set! grob-name (cadr name-components))
-  (set! context-name (car name-components
-
 ;; only apply override if grob is a spanner
-(let ((description
-(assoc-get (string->symbol grob-name) all-grob-descriptions)))
-  (if (and description
-   (member 'spanner-interface
-   (assoc-get 'interfaces
-  (assoc-get 'meta description
-  #{
-\override $context-name . $grob-name $property =
-  #(value-for-spanner-piece arg)
-  #}
-  (begin
-(ly:input-warning location (_ "not a spanner name, `~a'") 
grob-name)
-(make-music 'SequentialMusic 'void #t))
+  (let ((description
+ (assoc-get (last name) all-grob-descriptions)))
+(if (and description
+ (member 'spanner-interface
+ (assoc-get 'interfaces
+(assoc-get 'meta description
+#{
+  \override $name $property =
+  #(value-for-spanner-piece arg)
+#}
+(begin
+  (ly:input-warning location (_ "not a spanner name, `~a'") name)
+  (make-music 'SequentialMusic 'void #t)
 
 appendToTag =
 #(define-music-function (parser location tag more music)
@@ -476,16 +465,17 @@ given through @var{ratio}.")
   #})
 
 hide =
-#(define-music-function (parser location item) (string-or-music?)
+#(define-music-function (parser location item) (symbol-list-or-music?)
(_i "Set @var{item}'s @samp{transparent} property to @code{#t},
 making it invisible while still retaining its dimensions.
 
-If @var{item} is a string, the result is an override for the grob name
+If @var{item} is a symbol list of form @code{GrobName} or
+@code{Context.GrobName}, the result is an override for the grob name
 specified by it.  If @var{item} is a music expression, the result is
 the same music expression with an appropriate tweak applied to it.")
-   (if (string? item)
-   #{ \override $item #'transparent = ##t #}
-   #{ \tweak #'transparent ##t $item #}))
+   (if (ly:music? item)
+   #{ \tweak #'transparent ##t $item #}
+   #{ \override $item #'transparent = ##t #}))
 
 inStaffSegno =
 #(define-music-function (parser location) ()
@@ -677,16 +667,17 @@ octaveCheck =
'pitch pitch))
 
 omit =
-#(define-music-function (parser location item) (string-or-music?)
+#(define-music-function (parser location item) (symbol-list-or-music?)
(_i "Set @var{item}'s @samp{stencil} property to @code{#f},
 effectively omitting it without taking up space.
 
-If @var{item} is a string, the result is an override for the grob name
+If @var{item} is a symbol list of form @code{GrobName} or
+@code{Context.GrobName}, the result is an override for the grob name
 specified by it.  If @var{item} is a music expression, the result is
 the same music expression with an appropriate tweak applied to it.")
-   (if (string? item)
-   #{ \override $item #'stencil = ##f #}
-   #{ \tweak #'stencil ##f $item #}))
+   (if (ly:music? item)
+   #{ \tweak #'stencil ##f $item #}
+   #{ \override $item #'stencil = ##f #}))
 
 once =
 #(define-music-function (parser location music) (ly:music?)
@@ -722,30 +713,27 @@ of @var{base-moment}, @var{beat-structure}, and 
@var{beam-exceptions}.")
 
 overrideProperty =
 #(define-music-function (parser location name property value)
-   (string? symbol? scheme?)
+   (symbol-list? symbol? scheme?)
 
(_i "Set @var{property} to @var{value} in all grobs named @var{name}.
-The @var{name} argument is a string of the form @code{\"Context.GrobName\"}
-or @code{\"GrobName\"}.")
-
-   (let ((name-components (string-split name #\.))
-(context-name 'Bottom)
-(grob-name #f))
+The @var{name} argument is a symbol list of the form @code{Context.GrobName}
+or @code{GrobName}.")
+   (if (<= 1 (length name) 2)
+   (make-music 'ApplyOutputEvent
+   

[PATCH 01/16] Assignments can't contain literal lyric music (wrong lexer mode)

[David Kastrup]

Since assignments can't happen in lyrics mode (only in INITIAL mode or
the initial music mode), there is no point in supporting
non-mode-switching items on the right side of assignments that can
only occur in lyrics mode.
---
 lily/parser.yy |1 -
 1 file changed, 1 deletion(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index 13f071a..193655c 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -1033,7 +1033,6 @@ music_arg:
 music_assign:
simple_music
| composite_music %prec COMPOSITE
-   | lyric_element_music
;
 
 repeated_music:
-- 
1.7.9.5


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

[PATCH 09/16] Allow the string "xxx.yyy" to parse as a symbol list

[David Kastrup]

This changes the parser to let xxx.yyy be a valid way of specifying a
function argument required to be #'(xxx yyy).
---
 lily/parser.yy |   48 ++--
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index 6a087d8..121b059 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -231,7 +231,7 @@ SCM make_chord_elements (Input loc, SCM pitch, SCM dur, SCM 
modification_list);
 SCM make_chord_step (SCM step, Rational alter);
 SCM make_simple_markup (SCM a);
 bool is_duration (int t);
-bool is_regular_identifier (SCM id);
+bool is_regular_identifier (SCM id, bool multiple=false);
 SCM try_string_variants (SCM pred, SCM str);
 int yylex (YYSTYPE *s, YYLTYPE *loc, Lily_parser *parser);
 
@@ -1309,15 +1309,15 @@ symbol_list_part:
symbol_list_element
{
SCM sym_l_p = ly_lily_module_constant ("symbol-list?");
-   if (scm_is_true (scm_call_1 (sym_l_p, $1)))
-   $$ = scm_reverse ($1);
-   else {
+   if (scm_is_false (scm_call_1 (sym_l_p, $1)))
+   {
$$ = try_string_variants (sym_l_p, $1);
if (SCM_UNBNDP ($$)) {
parser->parser_error (@1, _("not a symbol"));
$$ = SCM_EOL;
}
}
+   $$ = scm_reverse ($$);
}
;
 
@@ -3413,27 +3413,47 @@ SCM loc_on_music (Input loc, SCM arg)
 SCM
 try_string_variants (SCM pred, SCM str)
 {
+   // a matching predicate is always ok
if (scm_is_true (scm_call_1 (pred, str)))
return str;
-   if (scm_is_string (str))
-   {
-   if (!is_regular_identifier (str))
-   return SCM_UNDEFINED;
-
-   str = scm_string_to_symbol (str);
+   // a symbol may be interpreted as a list of symbols if it helps
+   if (scm_is_symbol (str)) {
+   str = scm_list_1 (str);
if (scm_is_true (scm_call_1 (pred, str)))
return str;
-   } else if (!scm_is_symbol (str))
return SCM_UNDEFINED;
+   }
+
+   // If this cannot be a string representation of a symbol list,
+   // we are through.
+
+   if (!is_regular_identifier (str, true))
+   return SCM_UNDEFINED;
+
+   str = scm_string_split (str, SCM_MAKE_CHAR ('.'));
+   for (SCM p = str; scm_is_pair (p); p = scm_cdr (p))
+   scm_set_car_x (p, scm_string_to_symbol (scm_car (p)));
+
+   // Let's attempt the symbol list interpretation first.
 
-   str = scm_list_1 (str);
if (scm_is_true (scm_call_1 (pred, str)))
return str;
+
+   // If there is just one symbol in the list, we might interpret
+   // it as a single symbol
+
+   if (scm_is_null (scm_cdr (str)))
+   {
+   str = scm_car (str);
+   if (scm_is_true (scm_call_1 (pred, str)))
+   return str;
+   }
+
return SCM_UNDEFINED;
 }
 
 bool
-is_regular_identifier (SCM id)
+is_regular_identifier (SCM id, bool multiple)
 {
   if (!scm_is_string (id))
  return false;
@@ -3449,7 +3469,7 @@ is_regular_identifier (SCM id)
  || (c >= 'A' && c <= 'Z')
  || c > 0x7f)
  middle = true;
- else if (middle && (c == '-' || c == '_'))
+ else if (middle && (c == '-' || c == '_' || (multiple && c == '.')))
  middle = false;
  else
  return false;
-- 
1.7.9.5


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

[PATCH 04/16] Factor SCM_IDENTIFIER out from embedded_scm_arg*

[David Kastrup]

SCM_IDENTIFIER indicates "active Scheme" introduced with $ that is
subject to copying and reinterpretation.  While the parser had its own
*_IDENTIFIER category for everything interpreted specially, the
fallback SCM_IDENTIFIER itself never needed special or different
treatment from material generated with # (SCM_TOKEN).  As the various
*_IDENTIFIER types are faded out, this is changing.  As a consequence,
SCM_IDENTIFIER no longer shares the non-terminals with other
Scheme-type definitions.
---
 lily/parser.yy |   42 --
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index 3fda842..de47a59 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -492,8 +492,11 @@ embedded_scm_active:
;
 
 embedded_scm_bare_arg:
-   embedded_scm_bare
-   | STRING
+   STRING
+   | SCM_TOKEN
+   {
+   $$ = parser->lexer_->eval_scm_token ($1);
+   }
| full_markup
| full_markup_list
| context_modification
@@ -1221,6 +1224,10 @@ function_arglist_closed_nonbackup:
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist SCM_IDENTIFIER
+   {
+   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   }
| EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed bare_number_closed
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
@@ -1233,6 +1240,10 @@ function_arglist_nonbackup:
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist SCM_IDENTIFIER
+   {
+   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   }
| EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed bare_number
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
@@ -1260,6 +1271,16 @@ function_arglist_backup:
MYBACKUP (SCM_IDENTIFIER, $4, @4);
}
}
+   EXPECT_OPTIONAL EXPECT_SCM function_arglist_keep SCM_IDENTIFIER
+   {
+   if (scm_is_true (scm_call_1 ($2, $4)))
+   {
+   $$ = scm_cons ($4, $3);
+   } else {
+   $$ = scm_cons (loc_on_music (@3, $1), $3);
+   MYBACKUP (SCM_IDENTIFIER, $4, @4);
+   }
+   }
| EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed_keep 
post_event_nofinger
{
if (scm_is_true (scm_call_1 ($2, $4)))
@@ -1386,6 +1407,11 @@ function_arglist_backup:
$$ = check_scheme_arg (parser, @3,
   $3, $1, $2);
}
+   | function_arglist_backup REPARSE SCM_IDENTIFIER
+   {
+   $$ = check_scheme_arg (parser, @3,
+  $3, $1, $2);
+   }
| function_arglist_backup REPARSE bare_number
{
$$ = check_scheme_arg (parser, @3,
@@ -1405,6 +1431,11 @@ function_arglist_common:
$$ = check_scheme_arg (parser, @3,
   $3, $2, $1);
}
+   | EXPECT_SCM function_arglist_optional SCM_IDENTIFIER
+   {
+   $$ = check_scheme_arg (parser, @3,
+  $3, $2, $1);
+   }
| EXPECT_SCM function_arglist_closed_optional bare_number
{
$$ = check_scheme_arg (parser, @3,
@@ -1511,6 +1542,11 @@ function_arglist_closed_common:
$$ = check_scheme_arg (parser, @3,
   $3, $2, $1);
}
+   | EXPECT_SCM function_arglist_optional SCM_IDENTIFIER
+   {
+   $$ = check_scheme_arg (parser, @3,
+  $3, $2, $1);
+   }
| EXPECT_SCM function_arglist_closed_optional bare_number
{
$$ = check_scheme_arg (parser, @3,
@@ -1945,6 +1981,7 @@ simple_string: STRING {
 
 scalar:
embedded_scm_arg
+   | SCM_IDENTIFIER
| bare_number
| FRACTION
| lyric_element
@@ -1952,6 +1989,7 @@ scalar:
 
 scalar_closed:
embedded_scm_arg_closed
+   | SCM_IDENTIFIER
| bare_number
| FRACTION
| lyric_element
-- 
1.7.9.5


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

[PATCH 06/16] Allow LilyPond strings to stand in for symbols when parsing

[David Kastrup]

Bare words and quote-enclosed words meeting word syntax can now be
used when a function argument expects to see a symbol.
---
 lily/parser.yy |  384 +++-
 1 file changed, 239 insertions(+), 145 deletions(-)

diff --git a/lily/parser.yy b/lily/parser.yy
index de47a59..270961f 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -232,6 +232,7 @@ SCM make_chord_step (SCM step, Rational alter);
 SCM make_simple_markup (SCM a);
 bool is_duration (int t);
 bool is_regular_identifier (SCM id);
+SCM try_string_variants (SCM pred, SCM str);
 int yylex (YYSTYPE *s, YYLTYPE *loc, Lily_parser *parser);
 
 %}
@@ -374,6 +375,7 @@ If we give names, Bison complains.
 %token OUTPUT_DEF_IDENTIFIER
 %token REAL
 %token RESTNAME
+%token SCM_ARG
 %token SCM_FUNCTION
 %token SCM_IDENTIFIER
 %token SCM_TOKEN
@@ -492,7 +494,7 @@ embedded_scm_active:
;
 
 embedded_scm_bare_arg:
-   STRING
+   SCM_ARG
| SCM_TOKEN
{
$$ = parser->lexer_->eval_scm_token ($1);
@@ -1224,11 +1226,35 @@ function_arglist_closed_nonbackup:
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist SCM_IDENTIFIER
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed bare_number_closed
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed bare_number_closed
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist SCM_IDENTIFIER
+   {
+   SCM res = try_string_variants ($2, $4);
+   if (SCM_UNBNDP (res))
+   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   else
+   $$ = scm_cons (res, $3);
+   }
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist STRING
+   {
+   SCM res = try_string_variants ($2, $4);
+   if (SCM_UNBNDP (res))
+   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   else
+   $$ = scm_cons (res, $3);
+   }
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist LYRICS_STRING
+   {
+   SCM res = try_string_variants ($2, $4);
+   if (SCM_UNBNDP (res))
+   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   else
+   $$ = scm_cons (res, $3);
+   }
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist lyric_markup
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
@@ -1240,13 +1266,69 @@ function_arglist_nonbackup:
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist SCM_IDENTIFIER
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed bare_number
{
$$ = check_scheme_arg (parser, @4, $4, $3, $2);
}
-   | EXPECT_OPTIONAL EXPECT_SCM function_arglist_closed bare_number
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist STRING
{
-   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   SCM res = try_string_variants ($2, $4);
+   if (SCM_UNBNDP (res))
+   $$ = check_scheme_arg (parser, @4, $4, $3, $2);
+   else
+   $$ = scm_cons (res, $3);
+   }
+   | function_arglist_nonbackup_reparse REPARSE SCM_ARG
+   {
+   $$ = check_scheme_arg (parser, @3, $3, $1, $2);
+   }
+   | function_arglist_nonbackup_reparse REPARSE lyric_element_music
+   {
+   $$ = check_scheme_arg (parser, @3, $3, $1, $2);
+   }
+   ;
+
+function_arglist_nonbackup_reparse:
+   EXPECT_OPTIONAL EXPECT_SCM function_arglist SCM_IDENTIFIER
+   {
+   $$ = $3;
+   SCM res = try_string_variants ($2, $4);
+   if (!SCM_UNBNDP (res))
+   MYREPARSE (@4, $2, SCM_ARG, res);
+   else if (scm_is_true
+(scm_call_1
+ ($2, make_music_from_simple
+  (parser, @4, $4
+   MYREPARSE (@4, $2, LYRICS_STRING, $4);
+   else
+   MYREPARSE (@4, $2, SCM_ARG, $4);
+   }
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglist LYRICS_STRING
+   {
+   $$ = $3;
+   SCM res = try_string_variants ($2, $4);
+   if (!SCM_UNBNDP (res))
+   MYREPARSE (@4, $2, SCM_ARG, res);
+   else if (scm_is_true
+(scm_call_1
+ ($2, make_music_from_simple
+  (parser, @4, $4
+   MYREPARSE (@4, $2, LYRICS_STRING, $4);
+   else
+   MYREPARSE (@4, $2, SCM_ARG, $4);
+   }
+   | EXPECT_OPTIONAL EXPECT_SCM function_arglis

[PATCH 10/16] Add symbol-list-or-music? predicate

[David Kastrup]

This is of interest for commands like \hide which accept either music
(to see an override) or a grob specification like Accidental or
Voice.Accidental.
---
 scm/c++.scm  |5 +
 scm/lily.scm |1 +
 2 files changed, 6 insertions(+)

diff --git a/scm/c++.scm b/scm/c++.scm
index d627481..12c38a3 100644
--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -51,6 +51,11 @@
 (define-public (symbol-list? x)
   (and (list? x) (every symbol? x)))
 
+(define-public (symbol-list-or-music? x)
+  (if (list? x)
+  (every symbol? x)
+  (ly:music? x)))
+
 (define-public (string-or-symbol? x)
   (or (string? x) (symbol? x)))
 
diff --git a/scm/lily.scm b/scm/lily.scm
index a74d6af..268fd1c 100644
--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -579,6 +579,7 @@ messages into errors.")
 (,string-or-music? . "string or music")
 (,string-or-symbol? . "string or symbol")
 (,symbol-list? . "symbol list")
+(,symbol-list-or-music? . "symbol list or music")
 (,void? . "void")
 ))
 
-- 
1.7.9.5


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

Re: [proposal] easy triplets and tuplets - Draft 3

[Graham Percival]

On Tue, Oct 09, 2012 at 09:45:09AM +0200, Francisco Vila wrote:
> So, \tuplet y/x with the exact meaning of \times x/y is less confusing
> because it's not "times" vs "time" anymore, and the straightforward
> fraction is just "music without the maths". So, I predict a widespread
> adoption.

Do we really need to use the same fraction notation, though?  I
mean, in music we see 3:2 (if people are being pedantic).  I'd be
much happier with
  \tuplet 3:2 { }
meaning the same thing as
  \times 2/3 { }

- Graham

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Martin Tarenskeen]

On Tue, 9 Oct 2012, Graham Percival wrote:


On Tue, Oct 09, 2012 at 09:45:09AM +0200, Francisco Vila wrote:

So, \tuplet y/x with the exact meaning of \times x/y is less confusing
because it's not "times" vs "time" anymore, and the straightforward
fraction is just "music without the maths". So, I predict a widespread
adoption.


Do we really need to use the same fraction notation, though?  I
mean, in music we see 3:2 (if people are being pedantic).  I'd be
much happier with
 \tuplet 3:2 { }
meaning the same thing as
 \times 2/3 { }


I think I like this idea.

--

MT

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Graham Percival  writes:

> On Tue, Oct 09, 2012 at 09:45:09AM +0200, Francisco Vila wrote:
>> So, \tuplet y/x with the exact meaning of \times x/y is less confusing
>> because it's not "times" vs "time" anymore, and the straightforward
>> fraction is just "music without the maths". So, I predict a widespread
>> adoption.
>
> Do we really need to use the same fraction notation, though?

You mean, like 3/4 meaning 3 notes to 4 parts of a measure?

> I mean, in music we see 3:2 (if people are being pedantic).  I'd be
> much happier with \tuplet 3:2 { } meaning the same thing as \times 2/3
> { }

3/2 is a FRACTION, which is a lexical item available as a music function
argument.  The proposed \tuplet implementations were presented as Scheme
code that could just be used in a document without recompilation.

In contrast, : is being used for chord and tremolo notation.  It has no
relation to music function arguments.  The price for using it would be
making \tuplet a reserved word specially treated in the parser and
dealing with the interference of : with its other meanings in the
parser, and having the command hardwired and not user-serviceable and
not documented as a music function.

That's not a reasonable price to pay for a one-off command.

-- 
David Kastrup


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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[Janek Warchoł]

I'm just skimming the discussion (the patch is big and non-trivial, so
i will have problems reviewing it), but i spotted one interesting
sentence...

On Tue, Oct 9, 2012 at 10:38 AM,   wrote:
> We can get rid of a _lot_ of #' style thingies with this patch series.

A!!!  So this is the patch i've been waiting for for about 5 years now! :D
As Trevor said, the more the better.  Pity that \clef treble_8 won't
work... if you stumble upon an idea for supporting something like
this, let us know!

best,
Janek

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

Re: Still alive

[Janek Warchoł]

Hey Mike!

On Tue, Oct 9, 2012 at 10:19 AM, m...@mikesolomon.org
 wrote:
> Hey list,
>
> Just a quick ping to let you know that I'm not dead - I've been swamped w/ 
> work recently and just got engaged so I'm planning out a wedding (w00t!).

Whoah, you're FAST!  Congratulations!! :)
When and where will the wedding be?  I'd love to be there, but it will
probably be difficult..


On Tue, Oct 9, 2012 at 3:25 PM, David Kastrup  wrote:
> Isn't that Han-Wen Solo?

:D

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Werner LEMBERG]

>> much happier with
>>  \tuplet 3:2 { }
>> meaning the same thing as
>>  \times 2/3 { }
> 
> I think I like this idea.

Me too.  However, this requires surgery in the parser, so I think this
feature gets postponed until someone (hehe, David :-) has time to
analyze possible side effects.


Werner

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

Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[Eluze]

Werner LEMBERG wrote
>> \accidentalStyle StaffGroup.voice
> 
> This is my preferred form.  However, some time ago we decided (more or
> less) to say e.g.
> 
>   \clef "bass"
> 
> In the light of your syntax improvements/simplifications, shouldn't we
> start to use
> 
>   \clef bass
> 
> instead, making data in double quotes really user strings only?

putting bass in double quotes will disable hiliting the correct way in most
editors!

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Make-arguments-like-Context-GrobName-accessible-as-symbol-lists-issue-6635050-tp134433p134518.html
Sent from the Dev mailing list archive at Nabble.com.

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Janek Warchoł]

On Tue, Oct 9, 2012 at 5:36 PM, David Kastrup  wrote:
> Janek Warchoł  writes:
>> i've found a reason why i could support "reversed" tuplet ratio: if we
>> decide to allow arbitrary integer durations (so that a3 would mean a
>> third of the whole note), it would make more sense to have { a3 b6 }
>> equivalent to \tuplet 3/2 { a2 b4 } rather than have it equivalent to
>> \tuplet 2/3 { a2 b4 }.  In other words, in LilyPond we express
>> duration using the /denominator/ of the fraction, so it makes sense to
>> multiply duration 2 (half note) by 3/2 to get duration 3 (a triplet).
>> Do you see what i mean?
>
> With the same kind of logic, s2 + s2 should be s4, so I hope this reason
> will not remain the only one you can find.


but i didn't consider Durations to be a field.  I was treating it just
like an abelian group, without addition. :P


btw, s2 + s2 = s1*1/2 + s1*1/2 = s1 * (1/2 + 1/2) = s1 as we expect
(note the transition from LilyPondDuration to fractions of whole
notes), and \tuplet 3/2 { s2 } = s1*1/(2 * 3/2) = s1*1/3 = s3
:)

>> However, if we reverse the argument in \tuplet, we definitely should
>> deprecate \times.  Having both \times 2/3 and \tuplet 3/2 for
>> specifying triplets would be *very* confusing.
>
> I agree that using them interchangeably in the documentation would not
> be helpful.  I see no reason to _remove_ \times, however.  It would
> likely be more than enough to have its documentation string point out
> the existence of \tuplet.  Using a convert-ly rule for a blanket
> conversion \times->\tuplet would be something I would consider
> appropriate.

Since we have \scaleDurations, i don't see any compelling reason to
keep \times.  But i don't insist; your suggestion above is ok.

As for Graham's question about \tuplet 3:2, i think that the
difficulties David outlined far outweigh the "user-friendliness"
gained.

cheers,
Janek

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Werner LEMBERG]

> In contrast, : is being used for chord and tremolo notation.  It has
> no relation to music function arguments.  The price for using it
> would be making \tuplet a reserved word specially treated in the
> parser and dealing with the interference of : with its other
> meanings in the parser, and having the command hardwired and not
> user-serviceable and not documented as a music function.
> 
> That's not a reasonable price to pay for a one-off command.

I'm not sure about the validity of your conclusion.  Writing tuplets
is such a central element of inputting music that a special treatment
is probably justified, even at the cost of hardwiring.  However, this
is nothing I suggest for immediate implementation; as mentioned in
another mail, I think this can be safely postponed.


 Werner

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

Re: [proposal] easy triplets and tuplets - Draft 3

[Janek Warchoł]

On Tue, Oct 9, 2012 at 11:30 PM, Werner LEMBERG  wrote:
>>> much happier with
>>>  \tuplet 3:2 { }
>>> meaning the same thing as
>>>  \times 2/3 { }
>>
>> I think I like this idea.
>
> Me too.  However, this requires surgery in the parser, so I think this
> feature gets postponed until someone (hehe, David :-) has time to
> analyze possible side effects.

He already did:
http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00333.html

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

Re: [proposal] easy triplets and tuplets - Draft 3

[David Kastrup]

Werner LEMBERG  writes:

>> In contrast, : is being used for chord and tremolo notation.  It has
>> no relation to music function arguments.  The price for using it
>> would be making \tuplet a reserved word specially treated in the
>> parser and dealing with the interference of : with its other
>> meanings in the parser, and having the command hardwired and not
>> user-serviceable and not documented as a music function.
>> 
>> That's not a reasonable price to pay for a one-off command.
>
> I'm not sure about the validity of your conclusion.  Writing tuplets
> is such a central element of inputting music that a special treatment
> is probably justified, even at the cost of hardwiring.

We are talking about writing \tuplet 3:2 { ... } instead of \tuplet 3/2
{ ... } here.  Whether tuplets are central or not, this single-character
difference is purely cosmetic, and it is well-known that
obsessive-compulsive cosmetic surgery is not exactly guaranteed to
maximize the obtained output of beauty.

In the end, LilyPond needs to fit together like a fugue; local
beautification without consideration of the whole is painting yourself
into corners that become increasingly harder to get out of again.

> However, this is nothing I suggest for immediate implementation; as
> mentioned in another mail, I think this can be safely postponed.

Implementing syntax not in harmony with the rest of the syntax is not
really desirable, so "safely postponed" may deliver a wrong message as
it implies an eventual delivery and may keep people from thinking how to
make best use of the existing framework.

This paragraph was supposed to contain some more pompous platitudes, but
I need to sleep right now.

-- 
David Kastrup

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

Clefs and transposition [was: Re: [proposal] easy triplets and tuplets - Draft 3]

[Joseph Rushton Wakeling]

On 10/09/2012 05:23 PM, Janek Warchoł wrote:

As for transposing clefs, i play guitar a bit myself, and i have once
typeset a piece using both G and G_8 clefs.  Maybe it was a bad idea,
but for me it was perfectly fine.


Yes, definitely a bad idea.  Use 8va.  brackets instead when you want to 
send everything up an octave like that.  It was fine for _you_ because you wrote 
it and knew what you wanted anyway, but it would have probably been confusing 
for anyone else who had to read it, at least at initial glance.


Anyway, _most_ of the time you shouldn't need to do any such octave shifts -- 
it's only at the very extreme upper end of the instrumental register (and 
sometimes lower, e.g. on piano) that you would bother.



It seems that our opinions on this subject are totally opposite.
While i definitely agree that the important thing is that performers
don't have to worry about this issue, in my opinion the *only* way to
ensure this is to state clef transpositions explicitely.  After all,
it doesn't cost you anything to write them.


No, the only way to do it is to ensure that you have a well-defined standard for 
how music is written for a given instrument, and ensure that composers, 
publishers etc. know these standards and use them.  To a large extent that's 
what happens, but there are grey areas round some edges, usually where you're 
seeing new areas of technique or even new instruments introduced.


Insisting on a strict employment of \treble or \treble_8 is in practice a good 
way to increase the number of grey areas rather than reduce them, because it 
increases the likelihood of multiple different non-uniform practices, and also 
simply of errors -- errors in writing the part, and errors in playing it, 
because \treble and \treble_8 are not visually distinct enough for a musician 
reading the piece in real time.


In any case the player shouldn't have to face the question because as a matter 
of course they should never encounter two clefs an octave apart in the same 
piece -- you change clef to change the _staff_ pitches, not the relative octave.



For me, what we currently have is a holly mess.  There are some areas
where ambiguity can be your goal, but i don't see how it could be
here.  In my opinion it is *infinitely* better to write down the
information than to leave it to the performer to guess it based on
tradition.


It's not just "tradition" -- there are well-defined notational standards for 
different instruments' notation, particularly for pitch, which you can find in 
any decent orchestration manual.


The problems happen when composers or arrangers don't follow the rules, which 
unfortunately happens more frequently than you'd like, and which to some extent 
is exacerbated by reliance on music notation software (i.e., trusting that the 
computer knows what it's doing rather than understanding and properly 
researching the notational standards).



For example, despite the fact that i'm an amateur musician (guitar &
voice), i had learned note names quickly.  However, for *many years* i
had no idea that some instruments are transposed.  Had i tried to play
a transposed instrument, i would play exactly what was written.  When
i learned that some instruments are transposed *and that the
transposition isn't marked in the notation*, i felt it was outrageous.


But it _is_ usually marked in the notation -- you'll get a part marked for 
"Clarinet in B flat" or "Trumpet in D" or whatever, which tells you what the 
transposition is.  Albeit in some modern parts the instrument's transposition is 
so standardized (e.g. alto sax is _always_ in E flat, though historically they 
existed in F and other keys) that it isn't always written, but if you're a 
composer, conductor or arranger it's reasonable to expect you to have read up on 
the standards and to know them by heart.



  I still believe it was a foolish idea to start notating transposing
instruments in this way, i.e. without any indication next to the clef
(no idea who started it, though :P).


You might want to read some of Schoenberg's writings :-)  He made some proposals 
for an alternative staff and clef system designed to better cope with the trend 
towards atonal music.  (Many of the potential ambiguities of transposition 
actually resolve rather simply in a tonal setup.)


I think his ideas probably failed because apart from the weight of lock-in, the 
main purpose of _individual_ instrumental notation is to make the easiest 
possible mapping between what is written on the page and what the player has to 
do.  In the case of brass instruments that mapping basically needs to be common 
to the overtone series of the instrument.  In the case of woodwind instruments, 
the notation needs to be common to the fingering -- whether I'm playing clarinet 
in B flat, A, C or E flat, or bass clarinet, or alto clarinet, or basset horn, 
if I see a written middle C I know to put down the thumb and first 3 fingers of 
my left hand.  I don'

Re: Clefs and transposition [was: Re: [proposal] easy triplets and tuplets - Draft 3]

[Joseph Rushton Wakeling]

On 10/10/2012 12:08 AM, Joseph Rushton Wakeling wrote:

Yes, definitely a bad idea.  Use 8va.  brackets instead when you want to
send everything up an octave like that.  It was fine for _you_ because you wrote
it and knew what you wanted anyway, but it would have probably been confusing
for anyone else who had to read it, at least at initial glance.

Anyway, _most_ of the time you shouldn't need to do any such octave shifts --
it's only at the very extreme upper end of the instrumental register (and
sometimes lower, e.g. on piano) that you would bother.


All of this (and what follows) seems rather aggressive and blunt on a second 
reading -- wasn't meant to be.  Apologies. :-\


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

Re: Context.Grob considered as symbol list

[Colin Campbell]

On 12-10-09 12:59 PM, David Kastrup wrote:

Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.

Let's see how we fare.





How do you want to handle countdowns for this patch, David?  I suspect 
the discussion might get rather technical, and I would have to rely on 
your judgement as to when sufficient consensus has been reached for the 
countdown step.  There are several reviewers commenting on Rietveld, 
which would ordinarily be enough for me to go to countdown, but are you 
looking for explicit comment on each element in the series?  I wouldn't 
think it inappropriate if you put the patch on countdown yourself, when 
you feel it has had proper discussion.


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

PATCH: Countdown to 20121011

[Colin Campbell]

For 20:00 MDT Thursday October 11th

Documentation:

Issue 2858 
: Document 
\shape music function - R 6561064 


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: [proposal] easy triplets and tuplets - Draft 3

[Janek Warchoł]

On Wed, Oct 10, 2012 at 12:00 AM, David Kastrup  wrote:
>> I'm not sure about the validity of your conclusion.  Writing tuplets
>> is such a central element of inputting music that a special treatment
>> is probably justified, even at the cost of hardwiring.
>
> We are talking about writing \tuplet 3:2 { ... } instead of \tuplet 3/2
> { ... } here.  Whether tuplets are central or not, this single-character
> difference is purely cosmetic, and it is well-known that
> obsessive-compulsive cosmetic surgery is not exactly guaranteed to
> maximize the obtained output of beauty.

Uh, it /sounds like/ you're suggesting that Werner has
obsessive-compulsive disorder.
I'm pretty sure that's you didn't mean this, but it might be worth clarifying.

> In the end, LilyPond needs to fit together like a fugue; local
> beautification without consideration of the whole is painting yourself
> into corners that become increasingly harder to get out of again.

+1

Janek

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