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

[Janek Warchoł]

On Wed, Oct 10, 2012 at 3:15 AM, Joseph Rushton Wakeling
 wrote:
> On 10/10/2012 12:08 AM, Joseph Rushton Wakeling wrote:
>> []
>
> All of this (and what follows) seems rather aggressive and blunt on a second
> reading -- wasn't meant to be.  Apologies. :-\

No problem, i didn't consider it offensive.

I suppose we have to agree to disagree - you haven't convinced me
(while i'm all for defining standards, i still want them to be notated
explicitely), and i probably won't convince you.

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:

> 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.

Well, I already met Werner in an ice parlor in Dortmund.  I hope I am
not overstepping the boundaries of politeness by expressing my belief
that I don't consider it likely that he has subjected himself to
anything approaching obsessive-compulsive amounts of cosmetic surgery,
so I hope I have not touched a sensitive spot here.

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

[Werner LEMBERG]

>> 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.

No, it doesn't.  Just think of who is going to do the surgery :-)

Regarding the cosmetics, I think we should always think of the user:
It is a matter of fact that triplets are either marked with a single
digit, or with a ratio like `4:3'.  I think it is not too far
stretched to expect that lilypond should follow such conventions even
in the input.


Werner

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

Re: Still alive

[Marc Hohl]

Am 09.10.2012 10:19, schrieb 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!).

Hey Mike,

congratulations! All the best for both of you!

Marc & Bettina


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




___
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:

>>> 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.
>
> No, it doesn't.  Just think of who is going to do the surgery :-)
>
> Regarding the cosmetics, I think we should always think of the user:
> It is a matter of fact that triplets are either marked with a single
> digit, or with a ratio like `4:3'.  I think it is not too far
> stretched to expect that lilypond should follow such conventions even
> in the input.

I disagree.  We don't write whole, half, and quarter notes as O, d and
*| in spite of superficial visual resemblances.  There is always a
mapping involved between musical notation and LilyPond notation.  This
mapping should be straightforward and predictable: users should have a
good chance, however flimsy, to guess how a certain musical construct
will map to LilyPond.  If the LilyPond language is one amorphous mass of
graphs loosely picked based on visual similarity, this is quite less
likely than if the LilyPond language is composed of a finite set of
recognizable, consistent, and reasonably expressive elements.

It is _exactly_ because I am thinking of the user that I don't want to
open a new bag of syntax for every command.  With the (somewhat
positively acclaimed) proposal of letting standalone durations work for
expressing a note pitch repeat, 4:16 is already a quarter note with
tremolo repeat.  Now people want it to be a fraction as well, but only
when used as an argument to \tuplet.

A pair of numbers used for expressing a positive ratio _not_ in shortest
terms is an idiom expressed as 3/4 in LilyPond.  We even have a
"fraction?" predicate for this idiom, and we have a consistent input
syntax across all modes, to the degree where in ly/engraver-init.ly
you'll find lines like

  timeSignatureFraction = 4/4

Now where is the point in making a single command deviate from that
convention, data structure, input syntax and general support inside of
LilyPond?  How does this make LilyPond easier to comprehend?

-- 
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]

Werner LEMBERG  writes:

>>> 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.
>
> No, it doesn't.  Just think of who is going to do the surgery :-)
>
> Regarding the cosmetics, I think we should always think of the user:
> It is a matter of fact that triplets are either marked with a single
> digit, or with a ratio like `4:3'.  I think it is not too far
> stretched to expect that lilypond should follow such conventions even
> in the input.

If you want a version working _without_ surgery, let \tuplet
_alternatively_ accept a _quoted_ _string_ "4:3" as argument.  \tuplet
will then need to parse this string itself.  If you want to be cute,
override the printing method for tuplet numbers to show "4:3" in this
case.

However, forcing a certain form of input representation for a certain
form of output is a nuisance for programmatically generated music.

I'd rather recommend using something separate like
\tupletStyle "3:2", \tupletStyle "3", \tupletStyle "".

I have _no_ problem with : in _this_ context since it now does not
represent a musical/mathematical concept but indeed a graphical
representation.  In fact, I would _protest_ against using
\tupletStyle "3/2" 
for creating a 3:2 tuplet number.

-- 
David Kastrup


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

Re: Context.Grob considered as symbol list

[David Kastrup]

Colin Campbell  writes:

> 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.

There is rarely such a thing as a "proper discussion".  Three quarter of
the patches in the series are straightforward simple rearrangements that
I'd have no qualms pushing without any indication of interest.  Of the
remaining patches, half create more natural/nicer user interfaces for a
number of existing functions.  The rest introduces conceptually a
uniform concept of LilyPond syntax of which the existing language has
"regional dialects" in different areas which, after this change, can be
exchanged.

Now the question is what the performance impact of this new part of
LilyPond constructs with some ambiguity is.

If you compare the execution time of the classic


#(do ((i 0 (1+ i)))
  ((> i 10))
  #{ \override Accidental #'color = \red #})

with

#(do ((i 0 (1+ i)))
  ((> i 10))
  #{ \override Accidental color = \red #})

of course the cost of calling the LilyPond parser a hundred thousand
times is going to dominate the execution time.  However, there is still
a significant difference (5-10%) between the two.  The latter is faster.

Now of course the comparison is not fair since I was using the same
LilyPond version, and so the machinery for sifting through various types
of strings and symbols was at work in either case.  However, the point
is that switching to the Guile interpreter may be cheap, but it is not
zero price, so for the actually trivial stuff like symbols even with the
necessary resolution of ambiguities, a native LilyPond equivalent to
symbols buys us performance as well.

It is not likely to matter much in practice, but in this case there is
not even a tradeoff between convenience and performance involved, and
that makes for some incentive to move to LilyPond-native representations
even while they are optional.

-- 
David Kastrup


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

The LilyPond Report #28 has been released

[David Kastrup]

The LilyPond Report, the informational column for users and developers
of GNU LilyPond, the GNU music typesetter, has released its 28th issue
at http://news.lilynet.net/?The-LilyPond-Report-28>.

The main excitements are reports about the developer and user meeting
that happened from August 24th to 28th in Waltrop, Germany, culminating
in the release of the long-awaited stable LilyPond release 2.16.0.

There are some articles musing over future work and directions, a report
about the online music editing service Scorio and its use of LilyPond,
and as with previous issues, reports from the ongoing effort of freeing
senior developer David Kastrup for working on LilyPond by financial
contributions of users, an arrangement running for more than half a year
by now.

You are invited to read about the excitement in a small but thriving
community of people enthusiastic about music and its printed
representation.  And of course, feel free to read about and download
GNU LilyPond in its current versions from http://www.lilypond.org>
and use it for typesetting beautiful music.

Authors of the current issue are Dominik Hörnel, Karin Höthker, David
Kastrup, Graham Percival, Valentin Villenave and Janek Warchoł.

All the best

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

[Werner LEMBERG]

>> It is a matter of fact that triplets are either marked with a
>> single digit, or with a ratio like `4:3'.  I think it is not too
>> far stretched to expect that lilypond should follow such
>> conventions even in the input.
> 
> I disagree.  [...]

Good arguments, David!

> Now where is the point in making a single command deviate from that
> convention, data structure, input syntax and general support inside
> of LilyPond?  How does this make LilyPond easier to comprehend?

Playing the advocatus diaboli: I wouldn't mind if we say

  \time 3:4

At least in Germany and Austria a division gets indicated by `3:4' or
`3/4'.  But of course `:' is already in use for tremolos...


   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

[Werner LEMBERG]

> I'd rather recommend using something separate like
> \tupletStyle "3:2", \tupletStyle "3", \tupletStyle "".

This is an excellent idea.


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

[David Kastrup]

Werner LEMBERG  writes:

>>> It is a matter of fact that triplets are either marked with a
>>> single digit, or with a ratio like `4:3'.  I think it is not too
>>> far stretched to expect that lilypond should follow such
>>> conventions even in the input.
>> 
>> I disagree.  [...]
>
> Good arguments, David!
>
>> Now where is the point in making a single command deviate from that
>> convention, data structure, input syntax and general support inside
>> of LilyPond?  How does this make LilyPond easier to comprehend?
>
> Playing the advocatus diaboli: I wouldn't mind if we say
>
>   \time 3:4
>
> At least in Germany and Austria a division gets indicated by `3:4' or
> `3/4'.  But of course `:' is already in use for tremolos...

That's the point.  The current design follows choices taken a long time
ago.  If the choices would have been different, we might have ended up
with 3:4.  I am not opposed to 3:4 based on its visual aesthetics viewed
in isolation, whether we are talking about \time or \tuplet.  And 3:4
would have less potential for confusion with #3/4 (not a number pair or
fraction, but rather a rational number properly embedded into Guile's
numeric stack).

But in the design of LilyPond, a number of design decisions have been
taken forming the language, and side-stepping this design is expensive.
It would probably be less annoying for everybody if I stated flatly
"this is impossible" in such cases.  But of course, one can always bolt
on a few exceptions and overrides before things start really breaking
apart.

So I start panicking whenever people make really expensive proposals.
Part of the saving grace is, of course, that somebody has to actually
implement things.  But it is not rare that a 90% solution can be hacked
up pretty fast, and then the pressure mounts: "somebody else did 90% of
the work, why do you refuse to fill in the missing 10% if you are
convinced that there is something missing?  And don't you dare break any
of the 90% with unrelated work."

And it is not that this sort of thing does not happen.

-- 
David Kastrup


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

Nice to have - manage differing number of syllables in verses, choir etc.

[Esa Erola]

Hi,

For a chosen verse in multi-verse choir etc. sould there be any chances with 
reasonable enough effort to create a command to be used inside lyrics to skip 
once a slur

There is a nice snippet do to this, just a bit hard to use in multi voice 
choir.

It would be nice to include before a syllable something along the 
lines "...this \once \skip \slur nice cat..." ( while the other verse would 
have "... that yel -- low dog..."  - one more syllable )

the snippet:
http://lsr.dsi.unimi.it/LSR/Item?id=308

Thanks!
br
esa



___
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/10 Werner LEMBERG :
>
>> I'd rather recommend using something separate like
>> \tupletStyle "3:2", \tupletStyle "3", \tupletStyle "".
>
> This is an excellent idea.

And it is cheap, it admits a single string argument.

-- 
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: Still alive

[Thomas Morley]

2012/10/9 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

Hi Mike,

CONGRATULATIONS !!

Best,
  Harm

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

Re: Nice to have - manage differing number of syllables in verses, choir etc.

[Trevor Daniels]

Esa Erola wrote Wednesday, October 10, 2012 1:54 PM

> For a chosen verse in multi-verse choir etc. sould there be any chances with 
> reasonable enough effort to create a command to be used inside lyrics to skip 
> once a slur
> 
> There is a nice snippet do to this, just a bit hard to use in multi voice 
> choir.
> 
> It would be nice to include before a syllable something along the 
> lines "...this \once \skip \slur nice cat..." ( while the other verse would 
> have "... that yel -- low dog..."  - one more syllable )

I may have misunderstood, but doesn't \skip 1 do exactly what you
want?  (Note that \skip must be followed by a number but that this
number is ignored in lyrics.)  So you'd write

this \skip 1 nice cat

Alternatively, you can just use an empty syllable - "".

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

Re: Context.Grob considered as symbol list

[David Kastrup]

Ok, here are a few followup thoughts.  One: response to the on-list
posting of the patches, intended to be more useful for per-patch review,
has resulted in zero followups.

I'll put out the next iteration to the lilypond-auto list for that
reason, at least I'll attempt doing so (the list page sounds like
postings not made by bots might get auto-grounded).  Barring that, again
on the developer list.

I've made a much more radical patch converting all \override/\revert to
use the now available syntax.  Now I've hit another snag: \tweak.

\tweak has an optional grob argument (now a string) situated before its
target symbol.  This obviously won't survive upon converting the second
argument to string as well.  What this means is that
\tweak Accidental #'color #red cis
will have to get converted to
\tweak Accidental.color #red cis
in order to preserve the optional character of Accidental.  Contrasting
this with
\override Accidental color #red or
\override Voice.Accidental color #red

This is a bit unsatisfactory.  Basically, the optional component is
separated by a period.  While that is reasonably understandable, the
difference in syntax is a bit of a nuisance.  Also, \override syntax is
backwards compatible, the grob-augmented \tweak syntax (granted, just
available since 2.16) is not.

Sigh.

-- 
David Kastrup


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

Re: Context.Grob considered as symbol list

[Werner LEMBERG]

> One: response to the on-list posting of the patches, intended to be
> more useful for per-patch review, has resulted in zero followups.

Well I've already checked your changes on Rietveld, so I simply
skipped the patches sent to lilypond-devel.

> \tweak has an optional grob argument (now a string) situated before
> its target symbol.  This obviously won't survive upon converting the
> second argument to string as well.  What this means is that
>
>   \tweak Accidental #'color #red cis
>
> will have to get converted to
>
>   \tweak Accidental.color #red cis
>
> in order to preserve the optional character of Accidental.
> Contrasting this with
>
>   \override Accidental color #red or
>   \override Voice.Accidental color #red

Would it be possible to have

  \override Accidental.color #red
  \override Voice.Accidental.color

?  For me, this feels most natural.  In case a convert-ly rule is
feasible, I don't mind changing the syntax.


 Werner

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

Re: Context.Grob considered as symbol list

[David Kastrup]

Werner LEMBERG  writes:

>> One: response to the on-list posting of the patches, intended to be
>> more useful for per-patch review, has resulted in zero followups.
>
> Well I've already checked your changes on Rietveld, so I simply
> skipped the patches sent to lilypond-devel.
>
>> \tweak has an optional grob argument (now a string) situated before
>> its target symbol.  This obviously won't survive upon converting the
>> second argument to string as well.  What this means is that
>>
>>   \tweak Accidental #'color #red cis
>>
>> will have to get converted to
>>
>>   \tweak Accidental.color #red cis
>>
>> in order to preserve the optional character of Accidental.
>> Contrasting this with
>>
>>   \override Accidental color #red or
>>   \override Voice.Accidental color #red
>
> Would it be possible to have
>
>   \override Accidental.color #red
>   \override Voice.Accidental.color
>
> ?  For me, this feels most natural.

Won't work since you can't distinguish
\override Voice.Accidental.color

from

\override Accidental.bound-details.left

and I really don't want to try picking this apart based on
uppercase/lowercase letter distinctions.

-- 
David Kastrup

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

Re: Context.Grob considered as symbol list

[Werner LEMBERG]

>> Would it be possible to have
>>
>>   \override Accidental.color #red
>>   \override Voice.Accidental.color
>>
>> ?  For me, this feels most natural.
> 
> Won't work since you can't distinguish
> \override Voice.Accidental.color
> 
> from
> 
> \override Accidental.bound-details.left
> 
> and I really don't want to try picking this apart based on
> uppercase/lowercase letter distinctions.

In other words, `.' is used for two different purposes, namely to
indicate hierarchy of Contexts and accessing properties of grobs.
What about to disunify these two purposes, introducing a different
symbol?  Something like

  \override Voice>Accidental.color
  \override Accidental.bound-details.left


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

[Joseph Rushton Wakeling]

On 10/10/2012 09:52 AM, David Kastrup wrote:

However, forcing a certain form of input representation for a certain
form of output is a nuisance for programmatically generated music.

I'd rather recommend using something separate like
\tupletStyle "3:2", \tupletStyle "3", \tupletStyle "".


That's fair enough, but I'm still inclined to think that whatever the display 
style used, there may be some value in allowing tuplets to be entered not just 
as ratios of numbers, but as ratios of musical durations: e.g. {8*7}/{4*3}, or 
{16*6}/{8.~8}.


Note that unlike my earlier suggestion I'm _not_ proposing this as a way to 
force a particular display style, although it might be useful in _enabling_ some 
display choices (hope that distinction is clear).


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

Re: Context.Grob considered as symbol list

[David Kastrup]

Werner LEMBERG  writes:

>>> Would it be possible to have
>>>
>>>   \override Accidental.color #red
>>>   \override Voice.Accidental.color
>>>
>>> ?  For me, this feels most natural.
>> 
>> Won't work since you can't distinguish
>> \override Voice.Accidental.color
>> 
>> from
>> 
>> \override Accidental.bound-details.left
>> 
>> and I really don't want to try picking this apart based on
>> uppercase/lowercase letter distinctions.
>
> In other words, `.' is used for two different purposes, namely to
> indicate hierarchy of Contexts and accessing properties of grobs.

No, it is used for tying several symbols into one list.  \override takes
one list for specifying the grob, and one list for specifying the
property/subproperty of the grob.

\tweak takes just a single list for specifying the property, but that
list may include a grob at its start.

It's just that the lists for \override and \tweak are structured
differently when \tweak takes an optional grob specification.  But the
purpose of '.' is the same in each case.

> What about to disunify these two purposes, introducing a different
> symbol?  Something like
>
>   \override Voice>Accidental.color
>   \override Accidental.bound-details.left

That does not map to anything useful at the Scheme level.  Nor does it
map to any useful concept.

-- 
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]

Joseph Rushton Wakeling  writes:

> On 10/10/2012 09:52 AM, David Kastrup wrote:
>> However, forcing a certain form of input representation for a certain
>> form of output is a nuisance for programmatically generated music.
>>
>> I'd rather recommend using something separate like
>> \tupletStyle "3:2", \tupletStyle "3", \tupletStyle "".
>
> That's fair enough, but I'm still inclined to think that whatever the
> display style used, there may be some value in allowing tuplets to be
> entered not just as ratios of numbers, but as ratios of musical
> durations: e.g. {8*7}/{4*3}, or {16*6}/{8.~8}.

For that kind of special application, a specially and separately named
tuplet command taking several durations as argument would be appropriate
rather than trying to cram everything into the standard 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)

[dak]

On 2012/10/09 21:08:47, janek wrote:

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

Well, I uploaded a version of the patch with a heavy-handed conversion
rule for demonstration purposes.  Now you can probably wait for about 5
years before the patch downloads...

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

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

2.17.4 regtests

[Phil Holmes]

On my pixels comparator, they pretty much look OK.  Lots of changes where 
accidentals are involved, which is Mike's tuning of accidental spacing, I 
reckon.  The one I don't understand is markup-special-characters.ly. I've 
attached the difference image, but the summary is that with 17.2 there's a 
visible hyphen in in-nocent, and this disappears with 17.4.


--
Phil Holmes

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

Re: 2.17.4 regtests

[Keith OHara]

Phil Holmes  philholmes.net> writes:

> The one I don't understand is markup-special-characters.ly. I've 
> attached the difference image, but the summary is that with 17.2 there's a 
> visible hyphen in in-nocent, and this disappears with 17.4.
>

That changed with the first commit (1 of 2) in the patch for issue 1700.

The input is a line Lyrics with no notes to follow. There is nothing
in the input that requests a hyphen in that place, so it seemed correct
to let the space close.


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

Re: Context.Grob considered as symbol list

[Werner LEMBERG]

>> Would it be possible to have
>>
>>   \override Accidental.color #red
>>   \override Voice.Accidental.color
>>
>> ?  For me, this feels most natural.
>
> Won't work since you can't distinguish
> \override Voice.Accidental.color
>
> from
>
> \override Accidental.bound-details.left
>
> and I really don't want to try picking this apart based on
> uppercase/lowercase letter distinctions.

After some thinking I wonder why not?  For example, Haskell does
something similar, this is, some elements (type names) of this
programming language must start with an uppercase letter.

IMHO, it would elegantly solve this problem.


Werner

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

Re: Context.Grob considered as symbol list

[David Kastrup]

Werner LEMBERG  writes:

>>> Would it be possible to have
>>>
>>>   \override Accidental.color #red
>>>   \override Voice.Accidental.color
>>>
>>> ?  For me, this feels most natural.
>>
>> Won't work since you can't distinguish
>> \override Voice.Accidental.color
>>
>> from
>>
>> \override Accidental.bound-details.left
>>
>> and I really don't want to try picking this apart based on
>> uppercase/lowercase letter distinctions.
>
> After some thinking I wonder why not?

X-offset anyone?

> For example, Haskell does something similar, this is, some elements
> (type names) of this programming language must start with an uppercase
> letter.
>
> IMHO, it would elegantly solve this problem.

-- 
David Kastrup

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

Re: 2.17.4 regtests

[Phil Holmes]

- Original Message - 
From: "Keith OHara" 

To: 
Sent: Wednesday, October 10, 2012 6:44 PM
Subject: Re: 2.17.4 regtests



Phil Holmes  philholmes.net> writes:


The one I don't understand is markup-special-characters.ly. I've
attached the difference image, but the summary is that with 17.2 there's 
a

visible hyphen in in-nocent, and this disappears with 17.4.



That changed with the first commit (1 of 2) in the patch for issue 1700.

The input is a line Lyrics with no notes to follow. There is nothing
in the input that requests a hyphen in that place, so it seemed correct
to let the space close.


Thanks Keith

--
Phil Holmes 



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

Re: Context.Grob considered as symbol list

[Werner LEMBERG]

>>> [...] I really don't want to try picking this apart based on
>>> uppercase/lowercase letter distinctions.
>>
>> After some thinking I wonder why not?
> 
> X-offset anyone?

... should be renamed IMHO.  Regardless of our discussion, it doesn't
fit into the current naming scheme.


Werner

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

Re: Context.Grob considered as symbol list

[David Kastrup]

Werner LEMBERG  writes:

 [...] I really don't want to try picking this apart based on
 uppercase/lowercase letter distinctions.
>>>
>>> After some thinking I wonder why not?
>> 
>> X-offset anyone?
>
> ... should be renamed IMHO.  Regardless of our discussion, it doesn't
> fit into the current naming scheme.

The corresponding axis is called X, and using x for a constant in the
expectation that the user would not attempt naming a variable after it
would seem rather optimistic.

-- 
David Kastrup

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

Re: Context.Grob considered as symbol list

[David Kastrup]

David Kastrup  writes:

> Werner LEMBERG  writes:
>
> [...] I really don't want to try picking this apart based on
> uppercase/lowercase letter distinctions.

 After some thinking I wonder why not?
>>> 
>>> X-offset anyone?
>>
>> ... should be renamed IMHO.  Regardless of our discussion, it doesn't
>> fit into the current naming scheme.
>
> The corresponding axis is called X, and using x for a constant in the
> expectation that the user would not attempt naming a variable after it
> would seem rather optimistic.

In other words: I don't think that we want types be decided by letter.
This sort of implicit declaration is going to cause surprises.

-- 
David Kastrup


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

Re: Context.Grob considered as symbol list

[Werner LEMBERG]

>>> X-offset anyone?
>>
>> ... should be renamed IMHO.  Regardless of our discussion, it
>> doesn't fit into the current naming scheme.
> 
> The corresponding axis is called X, and using x for a constant in
> the expectation that the user would not attempt naming a variable
> after it would seem rather optimistic.

I think a big fat bold sentence which says

  Variables *must* start with a lowercase letter, contexts with an
  uppercase letter.

should make everything clear.

What do others think?


Werner

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

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

[Marc Hohl]

Am 06.10.2012 11:23, schrieb Janek Warchoł:

On Fri, Oct 5, 2012 at 9:42 PM, Thomas Morley
 wrote:

2012/10/5  :

It just occured to me: is there any way to specify different span bar
lines (at the end of the line and at the beginning of the line)?

Marc and me, we discussed this some time ago and decided not to
provide that functionality.
It would make things more complicated for the user and I think it is a
rarely needed feature.

Sorry for missing that part of the discussion.
If it's not too late to speak my mind, i think that it would be a
shame to have such an awesome and powerful barline interface without
giving users simple way to choose span barline behaviour.

Thinking *a lot* more about that and trying to recode my work to
fit your needs I stumbled upon quite a lot of problems:

The internal structure of the properties and its names does not
allow for this extension in a clean way. We have BarLine #'glyph
(that's the string given by the user) and BarLine #'glyph-name
(which is the string for the bar line to be drawn, i.e. after line
breaking decisions).
We have SpanBar #'glyph-name which is computed by
ly:span-bar::calc-glyph-name and the glyph-name we use here
will be that of the corresponding bar line, because we need both
informations about the bar line and the span bar line to get
the spacing correctly.

If I store a span bar triple '(span-bar-glyph end-of-line begin-next-line),
I'll have to carry the whole direction computation stuff in almost
every callback, and moreover, ly:span-bar::calc-glyph-name would
either return a list or the BarLine #'glyph, not the #'glyph-name,
so to be 100% clean, one would have to rename the property into
SpanBar#'glyph-list or SpanBar #'glyph.

Just a side remark: have a look at scm/define-grob-properties.scm.
(glyph-name ,string? "The glyph name within the font.") Huh?
(At least there is some clarification on this issue included in my patch ;-)

Being realistic, there are two possibilities:
a) I just leave the span bar stuff as it is. If it turns out that one 
wants to

change the appearance of span bars depending on the line breaking,
he has to write a custom callback similar to Harm's proposal or has to
rewrite parts of the interface again.
b) I try to get this done in a concise and clean way. This will probably 
take

half a year (just an assumption based on the time I spent on the patch
upto now and the estimated time available for lilypond) – probably I will
fail, but even if not: is it worth the effort? Who needs such span bars?

If no-one convinces me to do otherwise, I'll take (a).

Regards,

Marc



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