Re: rextend macro sometimes repeats a word

[Graham Percival]

On Sat, Oct 30, 2010 at 01:51:14AM +0200, Francisco Vila wrote:
> 2010/10/30 Francisco Vila :
> > this is to ask if anyone, besides me, has noticed that rextend macro
> > sometimes prints a repeated word before the link, and the word is the
> > last of the phrase argument.

Yes, back in 2008.

> Wait another half a moment! Can arguments to @footnote and/or @rextend
> be split across lines? if not, that could explain it.

Yes, that's the cause.

IIRC nobody has bothered doing enough investigation into the
manual formats that it causes problems in to warrant adding a
tracker issue, so if you're interested, please do so.  But first
check that it really doesn't have a tracker issue already; it
might.

Cheers,
- Graham

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

Re: SVG Point Click

[Patrick McCarty]

On Fri, Oct 29, 2010 at 5:32 AM, Christoph  wrote:
>
> Is there a way to have point-click-behavoir or any semantic
> meta-information about the  correspondending postion in
> the .ly-file in SVGs that a generated with the SVG-Backend (like in PDFs?).

Not currently, but it should be possible to add some metadata about
line/column position by implementing a "grob-cause" procedure in the
SVG backend.

I am interested in working on this eventually, but I can't say when.
So I will add it to the tracker for now:

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

Thanks,
Patrick

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

Re: non-technical help for spacing issues

[Keith E OHara]

On Thu, 28 Oct 2010 05:13:03 -0700,  wrote:




There is now a small set of over-rides is posted on -user, vertical spacing 
only so far, hopefully to be tried out by others over the weekend :


On one thing might surprise -devel.

I assume one goal of the new vertical spacing was to allow graceful stretching of 
systems when ragged-bottom=#f (the default) -- including orchestral scores.  This 
goal cam up in the 'RFC' thread 
 in the 
discussion of how professional scores stretch between the instrument groups.

Also, new system is supposed to replace the old "Two-Pass" vertical spacing, 
and the #'max-stretch option, both of which had the goal of spreading extra vertical 
space within systems in a graceful way. (But neither of which I learned to use.)

The mechanism to distribute space nicely is clearly there, but in order to 
handle orchestral scores with ragged-bottom=#f we need quite a bit more than 
the default 'stretchability' in two places :
   last-bottom-spacing #'stretchability = 120 % the last staff to the 
bottom of the page
   system-system-spacing #'stretchability = 240   % between systems

This has worked just fine on my test set, greatly reducing the unwanted 
stretching in small systems like piano staves (which I found to be too much) 
putting more space between Jan's choral systems, and setting both orchestral 
score and parts reasonably well.

I'll quietly wait for responses over the weekend, and try to finish up a 
checklist of which issues the adjusted defaults can at least mitigate.
=
Keith


P.S. you can get the include-files with (draft) justification comments over on 
-user, but for a snapshot, the only non-comment lines are the two \paper 
overrides above, and this in \layout :

\context { \Staff
   \override VerticalAxisGroup #'skyline-horizontal-padding = #1
   \override VerticalAxisGroup #'default-next-staff-spacing #'space = #11
   \override VerticalAxisGroup #'default-next-staff-spacing #'stretchability = 
#16
   \override VerticalAxisGroup #'default-next-staff-spacing #'minimum-distance 
= #7
}
\context { \StaffGroup
  \override StaffGrouper #'after-last-staff-spacing #'space = #11
  \override StaffGrouper #'after-last-staff-spacing #'stretchability = #16
}
\context { \Lyrics
   \override VerticalAxisGroup #'inter-staff-spacing #'minimum-distance = 4.5
   \override VerticalAxisGroup #'non-affinity-spacing #'space = 5.5
   \override VerticalAxisGroup #'non-affinity-spacing #'minimum-distance = 4.5
}


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

Re: non-technical help for spacing issues

[k-ohara5a5a]

On Thu, 28 Oct 2010 05:13:03 -0700,  wrote:




There is now a small set of over-rides is posted on -user, vertical spacing 
only so far, hopefully to be tried out by others over the weekend :


On one thing might surprise -devel.

I assume one goal of the new vertical spacing was to allow graceful stretching of 
systems when ragged-bottom=#f (the default) -- including orchestral scores.  This 
goal cam up in the 'RFC' thread 
 in the 
discussion of how professional scores stretch between the instrument groups.

Also, new system is supposed to replace the old "Two-Pass" vertical spacing, 
and the #'max-stretch option, both of which had the goal of spreading extra vertical 
space within systems in a graceful way. (But neither of which I learned to use.)

The mechanism to distribute space nicely is clearly there, but in order to 
handle orchestral scores with ragged-bottom=#f we need quite a bit more than 
the default 'stretchability' in two places :
   last-bottom-spacing #'stretchability = 120 % the last staff to the 
bottom of the page
   system-system-spacing #'stretchability = 240   % between systems

This has worked just fine on my test set, greatly reducing the unwanted 
stretching in small systems like piano staves (which I found to be too much) 
putting more space between Jan's choral systems, and setting both orchestral 
score and parts reasonably well.

I'll quietly wait for responses over the weekend, and try to finish up a 
checklist of which issues the adjusted defaults can at least mitigate.
=
Keith


P.S. you can get the include-files with (draft) justification comments over on 
-user, but for a snapshot, the only non-comment lines are the two \paper 
overrides above, and this in \layout :

\context { \Staff
   \override VerticalAxisGroup #'skyline-horizontal-padding = #1
   \override VerticalAxisGroup #'default-next-staff-spacing #'space = #11
   \override VerticalAxisGroup #'default-next-staff-spacing #'stretchability = 
#16
   \override VerticalAxisGroup #'default-next-staff-spacing #'minimum-distance 
= #7
}
\context { \StaffGroup
  \override StaffGrouper #'after-last-staff-spacing #'space = #11
  \override StaffGrouper #'after-last-staff-spacing #'stretchability = #16
}
\context { \Lyrics
   \override VerticalAxisGroup #'inter-staff-spacing #'minimum-distance = 4.5
   \override VerticalAxisGroup #'non-affinity-spacing #'space = 5.5
   \override VerticalAxisGroup #'non-affinity-spacing #'minimum-distance = 4.5
}


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

Re: rextend macro sometimes repeats a word

[Francisco Vila]

2010/10/30 Francisco Vila :
> Hello all,
>
> this is to ask if anyone, besides me, has noticed that rextend macro
> sometimes prints a repeated word before the link, and the word is the
> last of the phrase argument.  It's so strange!
>
> e.g. @rextend{Tutorial de Scheme} produces 'Scheme Tutorial de Scheme' in 
> HTML.
>
> My rextend macro mimics the original English version correctly.
>
> Oh wait: The lilypond index has an entry "Tutorial de" which leads to
> out-www/offline-root/Documentation/notation-big-page.es.html#index-Tutorial-de
> , it lacks the last word! So I've found the missing word miles away
> from where it should be.
>
> Smells to a texi2html bug. PDFs don't show the problem.

Wait another half a moment! Can arguments to @footnote and/or @rextend
be split across lines? if not, that could explain it.

Documentation/es/notation/changing-defaults.itely: (line 45)
el símbolo de cuadradillo @code{...@footnote{@rextend{Tutorial de

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

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

rextend macro sometimes repeats a word

[Francisco Vila]

Hello all,

this is to ask if anyone, besides me, has noticed that rextend macro
sometimes prints a repeated word before the link, and the word is the
last of the phrase argument.  It's so strange!

e.g. @rextend{Tutorial de Scheme} produces 'Scheme Tutorial de Scheme' in HTML.

My rextend macro mimics the original English version correctly.

Oh wait: The lilypond index has an entry "Tutorial de" which leads to
out-www/offline-root/Documentation/notation-big-page.es.html#index-Tutorial-de
, it lacks the last word! So I've found the missing word miles away
from where it should be.

Smells to a texi2html bug. PDFs don't show the problem.

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

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

Re: renaming "vertical spacing inside systems" props

[Carl Sorensen]

On 10/29/10 4:27 PM, "Mark Polesky"  wrote:

> Guys,
> 
> Here are my proposals for renaming the properties related to
> "Vertical spacing inside systems".
> 
> * * * * * * * * * * * * * * *
> 
> I've thought about it, and I think I slightly favor the term
> "loose line" over "non-staff line"; the word "loose" is
> distinctive and much less likely to get tangled up with the
> word "staff" (in the user's head, that is).

I think I do too.  I couldn't come up with any better variable than
loose-line-spacing, so that's when I decided that calling them loose lines
might be the best.

> 
> On the other hand, "nonstaff-staff-spacing" may be more
> intuitive than "loose-staff-spacing".  But if we call the
> property "nonstaff-staff-spacing", I'd want to replace all
> references to "loose lines" with "non-staff lines" (or maybe
> "nonstaff lines", without the hyphen?).

I don't think it should be unhyphenated in the text; in the variable name
it's fine.

> 
> Lastly, one property resists the "item1-item2-spacing" name
> format: currently named 'between-staff-spacing, it controls
> the spacing between staves within a staffgroup.  I don't
> like the current name because it sounds like it controls the
> spacing between ungrouped staves too, but it doesn't.  I'm
> proposing 'inside-staffgroup-spacing, which is clearer (I
> think) but not consistent with the "item1-item2-spacing"
> format.

I'd be OK with inside-staffgroup-spacing, but I think I prefer
grouped-staff-spacing or grouped-staves-spacing.

> 
> Please share your thoughts about these proposals.  I want
> the prop names to be consistent and intuitive, and I'd like
> to come as close as possible to a general consensus.
> Hopefully this thread won't be as thorny as the last time:
> http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html
> 
> If it helps, the current prop-names are explained in some
> detail in this (unfinished) patch:
> http://codereview.appspot.com/2642043/
> 
> Thanks!
> - Mark
> 
> * * * * * * * * * * * * * * *
> 
> Except for the 'inside-staffgroup property, the names of
> these properties follow the format "item1-item2-spacing".
> Note that item2 is not necessarily below item1; for example,
> 'loose-staff-spacing will measure upwards from the loose
> line if 'staff-affinity = #UP.
> 
> (I've omitted the "-spacing" suffix to save space.)
> 
> CURRENT NAME   PROPOSED NAME   ALTERNATE PROPOSAL
>    -   --
> next-staff staff-staff
> default-next-staff default-staff-staff
> 

Note: The names below also don't match the standard, because the standard is
that item1-item2 applies with item1 on the top, and item2 on the bottom.
However, for loose items, the affinity controls where the spacing applies.
So I think calling it loose-* makes sense.
> inter-staffloose-staff [nonstaff-staff]
> inter-loose-line   loose-loose [nonstaff-nonstaff]
> non-affinity   loose-nonaffinity   [nonstaff-nonaffinity]


> 
> between-staff  inside-staffgroup
 grouped-staff
> after-last-staff   staffgroup-staff

Thanks,

Carl


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

Re: renaming "vertical spacing inside systems" props

[Trevor Daniels]

Mark Polesky wrote Friday, October 29, 2010 11:27 PM


Here are my proposals for renaming the properties related to
"Vertical spacing inside systems".

* * * * * * * * * * * * * * *

I've thought about it, and I think I slightly favor the term
"loose line" over "non-staff line"; the word "loose" is
distinctive and much less likely to get tangled up with the
word "staff" (in the user's head, that is).

On the other hand, "nonstaff-staff-spacing" may be more
intuitive than "loose-staff-spacing".  But if we call the
property "nonstaff-staff-spacing", I'd want to replace all
references to "loose lines" with "non-staff lines" (or maybe
"nonstaff lines", without the hyphen?).


I dislike "loose lines".  It doesn't immediately make me think,
Ah, yes, that means my lyrics.  Also loose-staff-spacing sounds
too much like something that gives staves a loose spacing
(rather than a tight spacing) to anyone coming to this for the 
first time.  "Nonstaff lines" is definitely better, I think,

and, yes, without the hyphen for consistency with the names of
the spacing properties.  


Lastly, one property resists the "item1-item2-spacing" name
format: currently named 'between-staff-spacing, it controls
the spacing between staves within a staffgroup.  I don't
like the current name because it sounds like it controls the
spacing between ungrouped staves too, but it doesn't.  I'm
proposing 'inside-staffgroup-spacing, which is clearer (I
think) but not consistent with the "item1-item2-spacing"
format.


groupstaff-groupstaff-spacing ?
groupedstaff-groupedstaff-spacing ?
 
But I'm not unhappy with inside-staffgroup-spacing.


BTW, what happens to nonstaff lines within staff groups?

Trevor



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

\layout vs. \paper

[Mark Polesky]

Is it true that some \paper variables can be set in a
\layout block without a problem, and vice versa?  Are there
any variables that will only work in a \paper block?  Are
there any that only work in a \layout block?  If so, what
are they?  Is there a system to this?

Thanks.
- Mark


  

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

renaming "vertical spacing inside systems" props

[Mark Polesky]

Guys,

Here are my proposals for renaming the properties related to
"Vertical spacing inside systems".

* * * * * * * * * * * * * * *

I've thought about it, and I think I slightly favor the term
"loose line" over "non-staff line"; the word "loose" is
distinctive and much less likely to get tangled up with the
word "staff" (in the user's head, that is).

On the other hand, "nonstaff-staff-spacing" may be more
intuitive than "loose-staff-spacing".  But if we call the
property "nonstaff-staff-spacing", I'd want to replace all
references to "loose lines" with "non-staff lines" (or maybe
"nonstaff lines", without the hyphen?).

Lastly, one property resists the "item1-item2-spacing" name
format: currently named 'between-staff-spacing, it controls
the spacing between staves within a staffgroup.  I don't
like the current name because it sounds like it controls the
spacing between ungrouped staves too, but it doesn't.  I'm
proposing 'inside-staffgroup-spacing, which is clearer (I
think) but not consistent with the "item1-item2-spacing"
format.

Please share your thoughts about these proposals.  I want
the prop names to be consistent and intuitive, and I'd like
to come as close as possible to a general consensus.
Hopefully this thread won't be as thorny as the last time:
http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html

If it helps, the current prop-names are explained in some
detail in this (unfinished) patch:
http://codereview.appspot.com/2642043/

Thanks!
- Mark

* * * * * * * * * * * * * * *

Except for the 'inside-staffgroup property, the names of
these properties follow the format "item1-item2-spacing".
Note that item2 is not necessarily below item1; for example,
'loose-staff-spacing will measure upwards from the loose
line if 'staff-affinity = #UP.

(I've omitted the "-spacing" suffix to save space.)

CURRENT NAME   PROPOSED NAME   ALTERNATE PROPOSAL
   -   --
next-staff staff-staff
default-next-staff default-staff-staff

inter-staffloose-staff [nonstaff-staff]
inter-loose-line   loose-loose [nonstaff-nonstaff]
non-affinity   loose-nonaffinity   [nonstaff-nonaffinity]

between-staff  inside-staffgroup
after-last-staff   staffgroup-staff


  

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

Re: Doc: NR 4.4.1: Rewrite. (issue2642043)

[Keith E OHara]

On Fri, 29 Oct 2010 01:17:00 -0700, Ian Hulin  wrote:


On 29/10/10 05:12, Keith wrote:

Documentation/notation/spacing.itely:1513: * Inter-system spacing
properties::
Within-system


You said: inter = between, intra = within  [...]
or do you mean the original "Inter-system spacing" should have read
"Intra-system spacing"?



I believe the Latin prefixes were wrong in the original.

I am confident in my Latin-Germanic translation,
 but could possibly have missed a subtlety in the distinctions that Mark was 
explaining.
-Keith


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

[PATCH] Allow music identifiers in \addlyrics (no need for braces any more)

[Reinhold Kainhofer]

Allow music identifiers in \addlyrics (no need for braces any more)

In particular, so far the following did not work:
\new Staff { \m \addlyrics \l }
Instead, one had to use braces around \m and \l:
\new Staff { {\m} \addlyrics {\l} }

This patch extends the parser to allow music identifiers, too,
so that no braces are needed any more.

http://codereview.appspot.com/2740044

Okay to push?

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: Music function extension...

[David Kastrup]

Valentin Villenave  writes:

> On Fri, Oct 29, 2010 at 12:46 PM, David Kastrup  wrote:
>>
>> Are there good reasons left for not allowing music functions to take
>> pitches as arguments?  That would allow implementing something like
>> \transpose as a music function.  The alternative, letting it take a
>> music event and not checking its duration and hoping that it is a single
>> note, seems quite less elegant.
>
> Music functions *can* take a ly:pitch as argument:
>
> toto =
> #(define-music-function (parser location pitch) (ly:pitch?)
>(make-music 'NoteEvent
>  'duration (ly:make-duration 2 0 1 1)
>  'pitch pitch))
>
> { a \toto #(ly:make-pitch 0 0 0) b }
>
> However, having to type #(ly:make-pitch x x x) is hardly convenient
> from a user point of view.

That is taking a scheme expression, not a pitch as argument.

>> Since argument signatures of music functions and markup functions are
>> by now processed as lists instead of fixed combinations, adding new
>> argument types does not seem to have significant drawbacks.
>
> I may be totally wrong, but it seems to me that what you're suggesting
> amounts to actually create a new type, that would be a one-note
> ly:music type whose duration is disregarded. (I'm not saying it would
> be a bad idea, though.)

That is exactly what I don't want.  I could already have that.  I want
something that takes a pitch as an argument and complains about getting
anything else with it: duration, accents, whatever.

Just like \transpose would complain about getting anything but a pitch
as its transposition pitch argument.

-- 
David Kastrup


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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[Graham Percival]

On Fri, Oct 29, 2010 at 01:12:13PM +, tdanielsmu...@googlemail.com wrote:
> OK, it's an improvement so go ahead and push, but "musics" grates so
> much I'd definitely have removed it as part of this patch.

:)

Ok, we're agreed.  We *all* hate the material which is moving into
world.itely, but since none of us wrote it, let's just shove it
into world.itely and leave it for somebody else to fix.  I mean,
it definitely makes the "real" (i.e. non-ghetto-ized) part of the
manual better.

Cheers,
- Graham

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[Valentin Villenave]

On Fri, Oct 29, 2010 at 3:12 PM,   wrote:
> OK, it's an improvement so go ahead and push,

Thanks. Will do.

> but "musics" grates so
> much I'd definitely have removed it as part of this patch.

I hear you. This will be part of my next patch, which I'm preparing right now.

Cheers!
Valentin.

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[Carl . D . Sorensen]

On 2010/10/29 13:12:13, Trevor Daniels wrote:

OK, it's an improvement so go ahead and push, but "musics" grates so

much I'd

definitely have removed it as part of this patch.


Musics grates on me, too, but I have found it as an accepted use, e.g.



Carl

http://codereview.appspot.com/2735044/

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

SVG Point Click

[Christoph]

dear lilypond-developers,

Is there a way to have point-click-behavoir or any semantic
meta-information about the  correspondending postion in 
the .ly-file in SVGs that a generated with the SVG-Backend (like in PDFs?).

thank you and regards

Christoph


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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[v . villenave]

http://codereview.appspot.com/2735044/diff/8001/Documentation/music-glossary.tely
File Documentation/music-glossary.tely (right):

http://codereview.appspot.com/2735044/diff/8001/Documentation/music-glossary.tely#newcode2008
Documentation/music-glossary.tely:2008:
@uref{http://en.wikipedia.org/wiki/Common_practice_period,
On 2010/10/29 12:07:02, Graham Percival wrote:

Ouch.  I don't like seeing links to wikipedia, since it makes it hard

for people

to take us seriously when we do that.


pff. OK, I'll remove it.

(Picture me shrugging, looking at the ceiling and saying "whatever..."
like a teenager. :-)


Could this just be "this is a stub." ?  The @section makes the intent

pretty

clear.


Will do.

Whatever.

http://codereview.appspot.com/2735044/diff/8001/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):

http://codereview.appspot.com/2735044/diff/8001/Documentation/notation/world.itely#newcode42
Documentation/notation/world.itely:42: @notation{Turkish classical
music}, or Ottoman music,
On 2010/10/29 12:53:41, Carl wrote:

Why put this here, instead of in the section on Turkish classical

music?

Because it was part of the fragment that I cut-&-pasted :)
This is by no means a definitive version of world.itely; for now I'm
just moving raw stuff around.

http://codereview.appspot.com/2735044/

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[Carl . D . Sorensen]

LGTM, but I have an organization question.

Carl



http://codereview.appspot.com/2735044/diff/8001/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):

http://codereview.appspot.com/2735044/diff/8001/Documentation/notation/world.itely#newcode42
Documentation/notation/world.itely:42: @notation{Turkish classical
music}, or Ottoman music,
Why put this here, instead of in the section on Turkish classical music?

http://codereview.appspot.com/2735044/

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[tdanielsmusic]

OK, it's an improvement so go ahead and push, but "musics" grates so
much I'd definitely have removed it as part of this patch.

http://codereview.appspot.com/2735044/

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

Re: Music function extension...

[Valentin Villenave]

On Fri, Oct 29, 2010 at 12:46 PM, David Kastrup  wrote:
>
> Are there good reasons left for not allowing music functions to take
> pitches as arguments?  That would allow implementing something like
> \transpose as a music function.  The alternative, letting it take a
> music event and not checking its duration and hoping that it is a single
> note, seems quite less elegant.

Music functions *can* take a ly:pitch as argument:

toto =
#(define-music-function (parser location pitch) (ly:pitch?)
   (make-music 'NoteEvent
 'duration (ly:make-duration 2 0 1 1)
 'pitch pitch))

{ a \toto #(ly:make-pitch 0 0 0) b }

However, having to type #(ly:make-pitch x x x) is hardly convenient
from a user point of view.

> Since argument signatures of music functions and markup functions are by
> now processed as lists instead of fixed combinations, adding new
> argument types does not seem to have significant drawbacks.

I may be totally wrong, but it seems to me that what you're suggesting
amounts to actually create a new type, that would be a one-note
ly:music type whose duration is disregarded. (I'm not saying it would
be a bad idea, though.)

Cheers,
Valentin.

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[percival . music . ca]

LGTM.  My nitpick doesn't require a new draft version; if there are no
other complaints, go ahead and push in 23 hours.

I still don't like seeing TODOs, and in a few months we'll be going
through and removing all TODOs from the code... but since these TODOs
weren't yours, I can't blame you for keeping them with your copy&paste
job.


http://codereview.appspot.com/2735044/diff/8001/Documentation/music-glossary.tely
File Documentation/music-glossary.tely (right):

http://codereview.appspot.com/2735044/diff/8001/Documentation/music-glossary.tely#newcode2008
Documentation/music-glossary.tely:2008:
@uref{http://en.wikipedia.org/wiki/Common_practice_period,
Ouch.  I don't like seeing links to wikipedia, since it makes it hard
for people to take us seriously when we do that.

Could this just be "this is a stub." ?  The @section makes the intent
pretty clear.

http://codereview.appspot.com/2735044/

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[v . villenave]

Hi guys,

here's a new patch set.  In case that wasn't clear, this commit is
mainly intended as a structural change (hence the de/es/fr docs update):
as suggested by Graham, the new subsection in world.itely was blindly
copied from pitches.itely and hasn't been adapted *at all* yet.


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

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode459
Documentation/notation/pitches.itely:459: @item @file{nederlands}
On 2010/10/29 10:15:46, Trevor Daniels wrote:

As these and the following similar cases are no longer files I think
@code{nederlands} would be more appropriate.


Indeed.

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode538
Documentation/notation/pitches.itely:538: for quarter tones in various
languages; here the prefixes
On 2010/10/29 10:37:16, Graham Percival wrote:

why remove the hyphen?  It should be "quarter-tones", or more strictly
"quarter-tone accidentals".


Indeed.

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode564
Documentation/notation/pitches.itely:564: Western classical music, also
referred to as @q{Common Practice
On 2010/10/29 10:15:46, Trevor Daniels wrote:

It would be good to have a Glossary entry for CPP


Indeed.

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

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode28
Documentation/notation/world.itely:28: @c TODO: adapt & expand. -vv
On 2010/10/29 10:37:16, Graham Percival wrote:

Delegate this to somebody who knows about this stuff, and make it more

obvious

that we could use help with this.  Eliminate the TODO, and just add a

new issue

for "write stuff about non-common period practice tuning systems".



I'm not sure that eliminating the TODO is a good idea, at least not yet.
 I'd suggest to add a new issue for "write stuff about that, and
eliminate the TODO when you're done."

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode31
Documentation/notation/world.itely:31: traditional musics) employ
alternative or extended tuning
On 2010/10/29 10:15:46, Trevor Daniels wrote:

Don't use 'musics' - it's not English.  'Many non-Western styles of

music (and

some Western folk and traditional styles) employ ...'


It's not mine.  In case you guys haven't noticed, all I did so far is a
blind cut&paste.  I do plan to work on this subsec once this patch is
approved (if ever).

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode55
Documentation/notation/world.itely:55: @c TODO: can we include the
actual accidentals in this table?
On 2010/10/29 10:37:16, Graham Percival wrote:

Eliminate the TODO, and what do you actually mean by this?


Don't know. Ask Joseph?
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=bd762aff5a079bc585a3233c09b62bb2c1c3d312

http://codereview.appspot.com/2735044/

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

Re: convert-ly on lilypondTool under GNU/Linux

[Francisco Vila]

2010/10/29 Bertalan Fodor (LilyPondTool) :
> Yeah, it uses python only if convert-ly command (in Plugins>Plugin
> properties) is set to convert-ly.py (It looks for the py extension)
> If you change that to just convert-ly that should work (at least that's the
> intention, though I don't have linux so I can't test that.)

No luck.
Plugins>Plugin options>LilyPondTool>Commands>convert-ly command:
is set to convert-ly alone

and it still tries to call python.

Can not run program "usr/local/bin/python"

However, you're right in that it depends on the content of that
setting. If I put /usr/local/bin/convert-ly then complains with "Can
not run /usr/local/bin/usr/local/bin/convert-ly", i.e. not about
Python this time. Are you sure it looks for the py extension?

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

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

Music function extension...

[David Kastrup]

Are there good reasons left for not allowing music functions to take
pitches as arguments?  That would allow implementing something like
\transpose as a music function.  The alternative, letting it take a
music event and not checking its duration and hoping that it is a single
note, seems quite less elegant.

Since argument signatures of music functions and markup functions are by
now processed as lists instead of fixed combinations, adding new
argument types does not seem to have significant drawbacks.

-- 
David Kastrup


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

Re: convert-ly on lilypondTool under GNU/Linux

[Bertalan Fodor (LilyPondTool)]

Yeah, it uses python only if convert-ly command (in Plugins>Plugin
properties) is set to convert-ly.py (It looks for the py extension)
If you change that to just convert-ly that should work (at least that's the
intention, though I don't have linux so I can't test that.)

On Tue, Oct 26, 2010 at 1:16 PM, Francisco Vila wrote:

> Hello Bert,
>
> The convert-ly function in LilyPondTool tries to call python
> convert-ly.py ; this could be correct for Windows, but in GNU/Linux
> the command is just "convert-ly -e"; is there a way to avoid this
> function from calling python and instead issue the command directly?
>
> Thanks
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: move non-Western languages to world.itely (issue2735044)

[percival . music . ca]

Generally ok, but I don't know why you're changing the translations
before the English docs are done.


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

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode538
Documentation/notation/pitches.itely:538: for quarter tones in various
languages; here the prefixes
why remove the hyphen?  It should be "quarter-tones", or more strictly
"quarter-tone accidentals".

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode564
Documentation/notation/pitches.itely:564: Western classical music, also
referred to as @q{Common Practice
On 2010/10/29 10:15:46, Trevor Daniels wrote:

It would be good to have a Glossary entry for CPP


Yes, and then make this a @notation{Common Practice Period}.

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

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode28
Documentation/notation/world.itely:28: @c TODO: adapt & expand. -vv
Delegate this to somebody who knows about this stuff, and make it more
obvious that we could use help with this.  Eliminate the TODO, and just
add a new issue for "write stuff about non-common period practice tuning
systems".

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode55
Documentation/notation/world.itely:55: @c TODO: can we include the
actual accidentals in this table?
Eliminate the TODO, and what do you actually mean by this?

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode138
Documentation/notation/world.itely:138: tailored as discussed in
@ref{Note names in other languages}.
This part will need changing.

http://codereview.appspot.com/2735044/

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

Re: Doc: move non-Western languages to world.itely (issue2735044)

[tdanielsmusic]

Looks fine generally, but some editorial changes are needed.

Trevor



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

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode459
Documentation/notation/pitches.itely:459: @item @file{nederlands}
As these and the following similar cases are no longer files I think
@code{nederlands} would be more appropriate.

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/pitches.itely#newcode564
Documentation/notation/pitches.itely:564: Western classical music, also
referred to as @q{Common Practice
It would be good to have a Glossary entry for CPP

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

http://codereview.appspot.com/2735044/diff/1/Documentation/notation/world.itely#newcode31
Documentation/notation/world.itely:31: traditional musics) employ
alternative or extended tuning
Don't use 'musics' - it's not English.  'Many non-Western styles of
music (and some Western folk and traditional styles) employ ...'

http://codereview.appspot.com/2735044/

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

Doc: move non-Western languages to world.itely (issue2735044)

[v . villenave]

Reviewers: ,

Message:
Greetings,

new patch.

Description:
Doc: move non-Western languages to world.itely

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

Affected files:
  M Documentation/de/notation/pitches.itely
  M Documentation/de/notation/world.itely
  M Documentation/es/notation/pitches.itely
  M Documentation/es/notation/world.itely
  M Documentation/fr/notation/pitches.itely
  M Documentation/fr/notation/world.itely
  M Documentation/notation/pitches.itely
  M Documentation/notation/world.itely



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

Re: Allow predefined diagrams regardless of note names language. (issue2791041)

[n . puttock]

http://codereview.appspot.com/2791041/diff/1/ly/predefined-guitar-fretboards.ly
File ly/predefined-guitar-fretboards.ly (right):

http://codereview.appspot.com/2791041/diff/1/ly/predefined-guitar-fretboards.ly#newcode20
ly/predefined-guitar-fretboards.ly:20: #(set! pitchnames
default-language)
On 2010/10/29 08:11:00, Valentin Villenave wrote:


(BTW: In these fretboard files, I'm not actually using \language since

I

don't need to change the parser's note names, but merely the

pitchnames

definition that's used by chordmode.)


I think you should add a comment to this effect for these files, just in
case somebody looks at them and wonders why.

http://codereview.appspot.com/2791041/

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

Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)

[Marc Hohl]

Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com:

LGTM.

However, I'm a bit nervous about putting bends as well into the
Tab_tie_follow_engraver.  Not that the engraver won't work, but that the
Tab_tie_follow_engraver won't be part of the documentation.

Currently, I view Scheme engravers as a way for users (and snippets) to
add engraver functionality, but not as an optimal way to add core
functionality.

I'm not asking you to change your code, but I'm trying to send up a
caution flag to see what others might say about it.

Thanks,

Carl



http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly 


File input/regression/tablature-tie-slur-glissando.ly (right):

http://codereview.appspot.com/2191042/diff/17001/input/regression/tablature-tie-slur-glissando.ly#newcode1 


input/regression/tablature-tie-slur-glissando.ly:1: \version "2.13.37"
2.13.38

Done.


http://codereview.appspot.com/2191042/




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

Re: Tablature: proper support for tie/slur- and tie/glissando-constellations (issue2191042)

[Neil Puttock]

On 28 October 2010 23:55, Carl Sorensen  wrote:
> Well, as far as I can see, Scheme engravers are really engravers, so they
> ought to be documented in the IR along with the C++ engravers, not in an
> appendix of the NR along with Scheme functions.
>
> Although the approach you suggest is better than having nothing at all.

I haven't tested Marc's latest patch yet (and I'm sorry this issue
didn't cross my mind when I originally suggested using a Scheme
engraver), but I don't think Valentin's approach is possible without
also changing the doc infrastructure for C++ engravers: I think you'll
find \consist-ing a Scheme engraver in engraver-init.ly will cause
`make doc' to fail.

Cheers,
Neil

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

Re: (tuplet . around) causes regtests to fail to compile

[Neil Puttock]

On 29 October 2010 09:18, Werner LEMBERG  wrote:

> in file lily-guile.cc; for the above lilypond call it gets passed a
> value of 0x204 for `val'.[1] This is obviously a special constant,
> however, I haven't found out what guile symbol this corresponds to due
> to the extremely cryptic definitions in libguile's `tags.h' file.

It's SCM_UNDEFINED, corresponding to this:

?: 19* [number? #]

ERROR: In procedure number?:
ERROR: Wrong number of arguments to #

It might be useful to follow the suggestion here,

http://www.mail-archive.com/guile-de...@gnu.org/msg03863.html

and add GDB macros for these SCM values to the .gdbinit example in the
Contributor's Guide.

Cheers,
Neil

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

Re: (tuplet . around) causes regtests to fail to compile

[Werner LEMBERG]

> lilypond -dcheck-internal-types input/regression/slur-tuplet.ly
> 
> It appears that there is some internal error in LilyPond that is
> causing -dcheck-internal-types not to work properly.

Yep.

> I'm afraid this is over my head, although I'll look around a bit
> more at it.

I did a bit of debugging, and the offending routine is

  type_check_assignment

in file lily-guile.cc; for the above lilypond call it gets passed a
value of 0x204 for `val'.[1] This is obviously a special constant,
however, I haven't found out what guile symbol this corresponds to due
to the extremely cryptic definitions in libguile's `tags.h' file.
Eventually, the function calls `scm_call_1' using `val' as an
argument, and guile doesn't like this.

My conclusion is that `type_check_assignment' isn't prepared to handle
special value `0x204', whatever it is.


Werner


[1] I've set a breakpoint to `add_boxes', run the program, continued
twice, then I've set a breakpoint to `type_check_assignment', and
continued once.

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

Re: Doc: NR 4.4.1: Rewrite. (issue2642043)

[Ian Hulin]

On 29/10/10 05:12, k-ohara5...@oco.net wrote:
> 
> http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
> 
> File Documentation/notation/spacing.itely (right):
> 
> http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1509
> 
> Documentation/notation/spacing.itely:1509: available.  Then, the
> staff-like contexts are distributed between
> This seems to say that staff-like contexts cannot influence the spacing
> of staffs.  Line 1711 about non-affinity-spacing, though, implies that
> staff-like contexts can influence the spacing to both their neighbors,
> pushing them apart if need be.  (I do not yet understand the behavior
> well enough to suggest better text.)
> 
> http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1513
> 
> Documentation/notation/spacing.itely:1513: * Inter-system spacing
> properties::
> Within-system

You said: inter = between, intra = within  ==> Between-system,
or do you mean the original "Inter-system spacing" should have read
"Intra-system spacing"?

> 
> http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1520
> 
> Documentation/notation/spacing.itely:1520: @node Inter-system spacing
> properties
> Within-system
> 

See the comment above.

> http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1624
> 
> Documentation/notation/spacing.itely:1624: size) will always reset all
> its default key-values.
> On 2010/10/27 08:44:41, Mark Polesky wrote:
>> Can anyone think of a good place for this?
> End of section 5.3.1 Overview of modifying properties
> 
> http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1662
> 
> Documentation/notation/spacing.itely:1662:
> @code{after-last-staff-spacing}).
> On 2010/10/27 08:44:41, Mark Polesky wrote:
>> What's a better way to word it?
> "... leave this property unset, because if set it will be used instead
> of any StaffGrouper property that would have otherwise applied."
> 
> http://codereview.appspot.com/2642043/



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

Re: Allow predefined diagrams regardless of note names language. (issue2791041)

[v . villenave]

OK, will push.


http://codereview.appspot.com/2791041/diff/1/ly/predefined-guitar-fretboards.ly
File ly/predefined-guitar-fretboards.ly (right):

http://codereview.appspot.com/2791041/diff/1/ly/predefined-guitar-fretboards.ly#newcode20
ly/predefined-guitar-fretboards.ly:20: #(set! pitchnames
default-language)
On 2010/10/29 06:17:52, Graham Percival wrote:

Cool!  Is there any way to make this easy for normal users to use?

(then again,

can we think of any case where a composer would want to be switching

input

languages?  not in normal circumstances, but would anybody ever want

to define

some music to be used in a \include file ?  ... hmm, that seems a bit
far-fetched.  ok, ignore this idea)


Hmm. At most, we could just document that in order to include a file
with another language, one has to do:
\language "newlanguage"
\include "my_included_file.ly"
\language "previouslanguage"

Also note that unlike \include "blah.ly", \language may even be used
inside a music expression!

(BTW: In these fretboard files, I'm not actually using \language since I
don't need to change the parser's note names, but merely the pitchnames
definition that's used by chordmode.)

http://codereview.appspot.com/2791041/

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