documentation size

2010-04-25 Thread James Bailey
I realize that downloading and reading the documentation offline is  
not for everyone, but is there a way to make a documentation for  
download that isn't so large? Looking at it, the size increased more  
than 30 MB between 2.13.1 and 2.13.2. I don't know usually work with  
the unstable docs, but even the stable version docs increased by more  
than 20MB between 2.12.2 and 2.12.3. Did something wonky happen, or  
is this just the way it is now?


Alternatively, is there an option for the documentaiton that doesn't  
have absolutely everything (maybe one without regression tests and  
snippets) for download purposes, for someone who just likes to have  
the documentation offline?



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


Re: documentation size

2010-04-25 Thread Martin Tarenskeen



On Sun, 25 Apr 2010, James Bailey wrote:

I realize that downloading and reading the documentation offline is not for 
everyone, but is there a way to make a documentation for download that isn't 
so large? Looking at it, the size increased more than 30 MB between 2.13.1 
and 2.13.2. I don't know usually work with the unstable docs, but even the 
stable version docs increased by more than 20MB between 2.12.2 and 2.12.3. 
Did something wonky happen, or is this just the way it is now?


Alternatively, is there an option for the documentaiton that doesn't have 
absolutely everything (maybe one without regression tests and snippets) for 
download purposes, for someone who just likes to have the documentation 
offline?


I have been thinking about that also. I build my own updated lilypond-doc 
rpm package for my Fedora 12 system, because I want a copy that doesn't 
take to much disk space on my EeePC. I have modified my fedora spec file 
to only package the English documentation. I removed all the translations. 
This already shrinks the size of the package.


Another thing that can be removed if you want to read the documentation 
offline with your browser is the PDF versions of the manual. They contain 
exactly the same information as the html version, right ?


And why should everything be available both as "big-page" and separate 
html files ?


If you then also remove the regression tests and snippets ( but keep links 
to the online versions ) it should be possible to create a "light" version 
of the Lilypond documentation.


--

Martin


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


Re: [PATCH] Re: syntax change for \cresc

2010-04-25 Thread Reinhold Kainhofer
Am Samstag, 24. April 2010 11:50:20 schrieben Sie:
> Hi Reinhold, Graham,
> 
> 2010/4/23 Graham Percival :
> > As far as I'm concerned, yes.  Maybe wait 24 hours in case anybody
> > objects?  But then go ahead.
> > 
> > For anybody skimming this: the patch includes a convert-ly rule
> > which changes any current \cresc into \deprecatedcresc, so this
> > change doesn't require any manual attention to ly files.
> 
> Sorry I missed the 24 hours objection deadline...

No problem, I've been busy preparing my OrchestralLily presentation, anyway.

> I'm not a programmer but if I understand well Reinhold's proposal this
> new \cresc command would be to text cresc *with spanners*, right?
> (the equivalent to the current \crescTextCresc c2\< )

Exactly. The old cresc did also this exact thing, with the only exception that 
it applied to the next note instead of the previous one.


> I would have preferred to have cresc *without spanners* as default
> behaviour for the \cresc (and so \dim) command.
>
> There are a few reason of this, the main one being that it's like that
> I'm already redefining the \cresc command for now  ;D
>   cresc = #(make-dynamic-script
> (markup #:line (#:left-align
> #:normal-text
> #:italic "cresc.")))

You can continue using that definition, of course.

However, your approach has the problem(s) that (1) it only creates something 
that looks like a crescendo, but lilypond does not know this internally, so 
(2) MIDI won't be affected at all, and (3) should we ever get a MusicXML 
backend (or any converter to any other format), it will also not properly 
export the crescendo.

The \cresc, \dim, \decresc commands need to produce spanners internally, 
otherwise lilypond won't have that information available. Lilypond does not 
necessarily have to print a spanner line, though.

> But I see other reasons why \cresc should be used for the one without
> extender line:
> 
>   – cresc without spanners is far most common in the scores I have
>(and in the ones I write);

You know that you can (globally or locally) override the spanner type and even 
hide the line?
\override DynamicTextSpanner #'dash-period = #-1.0

It's just a question whether this should be made the default or not...

>   – the behaviour of the previous \cresc command was without spanners;

No, \cresc created a dashed spanner.
\version "2.12.0"
\relative c' {
  \cresc d1\mf d1 d1  d1\!\f
}

>   – from what I remember from the previous discussion, it was said that
> \cresc , \dim , \decresc , ... would produce text (de)cresc without
> spanners by default.  And for that with spanners a syntax like
> \<"cresc. poco a poco" would be used.

That won't work without modifying the parser and complicating the syntax. I 
don't think we have han-wen's support for this.

AFAIR, there was no consensus about the exact output, so what you remember was 
a statement by one person, not a general agreement.

> But I think something like \crescTextSpan "cresc. poco a poco"
> should be fine too as a syntax (and for custom cresc text witout
> span we could use \crescText "cresc. blabla" for example).

See input/regression/dynamics-custom-text-spanner-postfix.ly for how to create 
dynamic text spanners with arbitrary texts.

> In every case the command should be inserted *after* the note, as
> everybody agreed I think (and as Reihold's proposal).
> I hate these commands that requires to place something before the note!

Me too.


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: [PATCH] Re: syntax change for \cresc

2010-04-25 Thread Xavier Scheuer
Thanks for this very useful reply.

2010/4/25 Reinhold Kainhofer :

>
> [...]
>
> You can continue using that definition, of course.
>
> However, your approach has the problem(s) that (1) it only creates
> something that looks like a crescendo, but lilypond does not know
> this internally, so (2) MIDI won't be affected at all, and (3) should
> we ever get a MusicXML backend (or any converter to any other format)
> it will also not properly export the crescendo.

I basically knew all this, but (1) since it looks like what I want it's
ok for me, (2) I use LilyPond for its PDF output, I don't really care
about the MIDI and (3) I have never used MusicXML so far.  :)

But of course you are right and it would be better if this was handled
correctly.

Note that the same problem occurs with custom dynamics like "p subito",
"più f", "mp dolce", ...
Though I think Valentin told me that Graham's "make-dynamic-extra"
function take care of that (at least points (1) and (2)).

http://lilypond-french-users.1298960.n2.nabble.com/Texte-aligne-sur-dynamic-was-Utilisation-de-la-commande-make-dynamic-script-tp4105476p4105706.html

[Dreams} It would be great to have a simpler, more user-friendly way
to align text with dynamics.  [\Dreams]


> The \cresc, \dim, \decresc commands need to produce spanners
> internally, otherwise lilypond won't have that information available.
> Lilypond does not necessarily have to print a spanner line, though.

Well, I think I can trust you: words like "spanners" and "lilypond
internals" still sound like "dark mystic magic" for me.  ;D


> You know that you can (globally or locally) override the spanner type
> and even hide the line?
>    \override DynamicTextSpanner #'dash-period = #-1.0

Yes, I know.
But the problem is: what if I have a score with both "spanned" and
"non-spanned" textual crescendi?
I mean I don't want to add
  \once \override DynamicTextSpanner #'dash-period = #-1.0
before each that does not have an extension line.
And this still requires the \crescTextCresc, *each time* you switch from
"hairpin" to "text".

And above all both (\once \override ... and \crescTextCresc) need to be
placed *before* the note.
But, as I said:

> I hate these commands that requires to place something before the note!

:p


> It's just a question whether this should be made the default or not..

If there is a poll I definitely vote "yes".

But I still think it would be great to have 2 different syntaxes for
spanned and non-spanned crescendo texts.
Just to avoid to play with \once \override ... before the note.

And also a simple, user-friendly syntax for custom crescendo texts
(your music function is great but is Scheme-based and I was thinking at
a "LiliPond"-based syntax).
Hence the \crescText "cresc. blabla" and \crescTextSpan "cresc. poco a
poco" proposal, to be discussed during the GLISS?


> No, \cresc created a dashed spanner.

I was quite sure it didn't.
I haven't used the non-modified \cresc command for dozen of months now.

I should have checked before posting.


>
> [...]
>
> That won't work without modifying the parser and complicating the
> syntax. I don't think we have han-wen's support for this.
>
> AFAIR, there was no consensus about the exact output, so what you
> remember was a statement by one person, not a general agreement.

Again, you are right.
It was Frédéric's proposal.
http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00662.html
(another part of the discussion here, for the ones that may be
interested:
http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00426.html )


> See input/regression/dynamics-custom-text-spanner-postfix.ly for how
> to create dynamic text spanners with arbitrary texts.

Nice!
Is it possible to have the same without the extension line to be
printed?  I am never satisfied but I also would like to use it without
having to add the '-' before the \mycresc command.  As I use \p , \f or
\< without '-'.

Should I say that it would be useful for many people to see this in the
LSR and in the doc?
Or maybe you are just waiting for it to be implemented by default?


> Me too.
:D

Many many thanks,
Xavier

--
Xavier Scheuer 


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


Re: documentation size

2010-04-25 Thread Graham Percival
On Sun, Apr 25, 2010 at 11:41:30AM +0200, Martin Tarenskeen wrote:
>
> On Sun, 25 Apr 2010, James Bailey wrote:
>
>> I realize that downloading and reading the documentation offline is not 
>> for everyone, but is there a way to make a documentation for download 
>> that isn't so large?

Download individual pdfs?

>> Alternatively, is there an option for the documentaiton that doesn't 
>> have absolutely everything (maybe one without regression tests and 
>> snippets) for download purposes, for someone who just likes to have the 
>> documentation offline?

Individual pdfs would do that, but I suppose we could try making
the html docs without the regtests.  Snippets are a main manual,
so I'm reluctant to omit them.  Although I suppose we could make a
"totally lightweight" version of only Notation and Internals, for
advanced users who want docs for each latest version.


> I have modified my fedora spec file  
> to only package the English documentation. I removed all the 
> translations.

Oh, that's a good idea, too.

> Another thing that can be removed if you want to read the documentation  
> offline with your browser is the PDF versions of the manual. They contain 
> exactly the same information as the html version, right ?

Yes.

> And why should everything be available both as "big-page" and separate  
> html files ?

That's been planned for over a year, and it's in the tracker as
http://code.google.com/p/lilypond/issues/detail?id=946


I'll add the new ideas from this thread to that issue.  Of course,
this issue isn't going to be completed for months, so don't hold
your breath.

If a Frog wanted to try it, he should expect 10-20 hours.  But
even that's probably an underestimate -- and be warned that
they'll be some of the most confusing, annoying 10-20 hours that
you've ever spent on lilypond contributing.  You'll be dealing
with the most broken part of lilypond development, you'll be
asking simple questions and get little or no response, you'll be
cursing all the previous developers... I really don't recommend a
Frog attempting this.


Cheers,
- Graham


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


Re: Change lilypond-book's LaTeX environment option placement (issue813048)

2010-04-25 Thread David Kastrup
David Kastrup  writes:

> Graham Percival  writes:
>
>> On Tue, Apr 20, 2010 at 08:10:15AM -0600, Carl Sorensen wrote:
>>> 
>>> On 4/20/10 7:57 AM, "Graham Percival"  wrote:
>>> 
>>> > Once it *is* tested, does anybody know how to apply the
>>> > patch?  I see a "download raw patch set", but we should obviously keep
>>> > David's name and changelog entries.  I feel as though I'm missing
>>> > something obvious, but I've spent a few minutes poking around on
>>> > Rietveld without finding anything.
>>> 
>>> Download the raw patch set.
>>> 
>>> Then apply it to your repository:
>>> git apply downloaded-patch
>>> git commit -a --author="David A. Kastrup "
>>
>> Ick.  I came up with something like that myself (although I used
>> patch -p1 < downloaded-patch  ), but I figured there had to be a
>> better way.  Oh well.
>
> Sure.  Commit access for David.  But I don't see that the Rietveld
> process facilitates a reasonable workflow for non-committers.

q.e.d.

So what's up with the patch series?

-- 
David Kastrup



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


Re: Change lilypond-book's LaTeX environment option placement (issue813048)

2010-04-25 Thread Graham Percival
On Sun, Apr 25, 2010 at 5:19 PM, David Kastrup  wrote:
>
> So what's up with the patch series?

Sorry, it was still sitting in my "most urgent" mail folder.  I'm
testing "make" right now; should start a "make doc" in 5 minutes, and
will push as soon as that's finished provided that there's no problems
(in which case I'll respond).  ETA 1 hour for either a push or problem
report.

Cheers,
- Graham


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


Re: Change lilypond-book's LaTeX environment option placement (issue813048)

2010-04-25 Thread Graham Percival
On Sun, Apr 25, 2010 at 5:28 PM, Graham Percival
 wrote:
> On Sun, Apr 25, 2010 at 5:19 PM, David Kastrup  wrote:
>>
>> So what's up with the patch series?
>
> Sorry, it was still sitting in my "most urgent" mail folder.

Pushed now as d43f0a2575409659fbdd21b9b17b5f8440cc7268.  I even
managed to resist the temptation to use the "@gnu.ork" joke.  :)

Cheers,
- Graham


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


Re: music-functions: #$var1 or just $var1 ?

2010-04-25 Thread Mark Polesky
Nicolas Sceaux wrote:
> Inside the #{ ... #} construct, you have to use #$variable
> where a scheme token is required, but you use $variable
> where \variable could be used.  Behind the scenes,
> $variable is actually replaced by something like \tmpvar
> before being parsed.

Can you provide an example of a case where #$ is required
within #{ #} ?  I can't find one.  $ seems to always work.

In fact, I'm probably missing something obvious, but I'm
unable even to find a case where a scheme token (with #) is
actually required in a regular music block.  I've found I
can even do such bizarre things as this:

  voiceCtx = Voice
  noteGrob = NoteHead
  colorSym = #'color
  redVal = #red

  { \override \voiceCtx.\noteGrob \colorSym = \redVal c'' }

and by extension, I can also do this (without using `#$'):

  overrideAlias =
  #(define-music-function
(parser location ctx grob prop-sym prop-val)
(scheme? scheme? scheme? scheme?)
#{
  \override $ctx . $grob $prop-sym = $prop-val
#})

  { \overrideAlias Voice NoteHead #'color #red c'' }

So, two things:
1) what is a case where omitting the # causes an error?
2) what is the danger of omitting the # otherwise?

Thanks!
- Mark


  


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


Re: Change lilypond-book's LaTeX environment option placement (issue813048)

2010-04-25 Thread David Kastrup
Graham Percival  writes:

> On Sun, Apr 25, 2010 at 5:28 PM, Graham Percival
>  wrote:
>> On Sun, Apr 25, 2010 at 5:19 PM, David Kastrup  wrote:
>>>
>>> So what's up with the patch series?
>>
>> Sorry, it was still sitting in my "most urgent" mail folder.
>
> Pushed now as d43f0a2575409659fbdd21b9b17b5f8440cc7268.  I even
> managed to resist the temptation to use the "@gnu.ork" joke.  :)

Appreciated.

-- 
David Kastrup



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


PATCH: Doc: Reorganize music functions material.

2010-04-25 Thread Mark Polesky
Here's a patch to reorganize the music functions material in
Notation and Extending.  This also includes (finally) some
code to auto-document the available type predicates in
type-p-name-alist.

Before I finish the re-editing, however, I'd like to see how
this question gets answered:
http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00350.html

Notwithstanding that specific issue, any suggestions,
objections, etc?

- Mark


  From 1117e3e62b740f513a8372a10a6fec32dbf012be Mon Sep 17 00:00:00 2001
From: Mark Polesky 
Date: Sun, 25 Apr 2010 17:33:58 -0700
Subject: [PATCH] Doc: Reorganize music functions material.

* Remove nodes from Extending that are covered in
  Notation:
2.1.1 Music function syntax
2.1.2 Simple substitution functions

* In Extending 2.1, move `Void functions' to end
  of section, so `Functions without arguments'
  comes first.

* Use a consistent indentation format for music
  functions.

* Make some minor formatting/wording changes.

* Create type-predicates-doc-string to document
  type-p-name-alist automatically.

* Add notation appendix
  `Music function type predicates' to include
  type-predicates-doc-string.
---
 .../extending/programming-interface.itely  |  259 ++-
 Documentation/notation/changing-defaults.itely |  113 +
 Documentation/notation/notation-appendices.itely   |7 +
 scm/c++.scm|2 +-
 scm/documentation-generate.scm |9 +-
 5 files changed, 156 insertions(+), 234 deletions(-)

diff --git a/Documentation/extending/programming-interface.itely b/Documentation/extending/programming-interface.itely
index 7045b49..e8e44cf 100644
--- a/Documentation/extending/programming-interface.itely
+++ b/Documentation/extending/programming-interface.itely
@@ -30,137 +30,25 @@ not familiar with Scheme, you may wish to read our
 @node Music functions
 @section Music functions
 
-Music functions are scheme functions that are used to
-automatically create music expressions.  They can be used to
-greatly simplify the input file.
+...@emph{music functions} are scheme procedures that can create music
+expressions automatically.  They can be used to greatly simplify
+the input file.  This section assumes that you are already
+familiar with simple substitution functions, which are described
+in @ruser{Using music functions}.
 
 @menu
-* Music function syntax::
-* Simple substitution functions::
 * Intermediate substitution functions::
 * Mathematics in functions::
-* Void functions::
 * Functions without arguments::
+* Void functions::
 @end menu
 
-...@node Music function syntax
-...@subsection Music function syntax
-
-The general syntax of a music function is:
-
-...@example
-myFunction =
-#(define-music-function (parser location @var{var_1} @var{var_2}...@var{var_n})
-(@var{var_1-type?} @var{var_2-type?}...@var{var_n-type?})
-@var{...valid music expression...})
-...@end example
-
-...@noindent
-where
-
-...@multitable @columnfractions .33 .66
-...@item @var{var_i} @tab @var{i}th variable
-...@item @var{var_i-type?}   @tab type of @var{i}th variable
-...@item @var{...valid music expression...}  @tab expression that returns
-valid music, generally in the form of a Scheme expression.  There is
-also special syntax that allows LilyPond input code in this music
-expression.
-...@end multitable
-
-The variable type checkers are scheme procedures that will return
-...@code{#t} if a variable is of a given type.  Some common types
-are shown in the table below.  Other types can be found in the files
-...@file{lily/music-scheme.cc} and @file{scm/c++.scm}.  The complete
-list of named type checkers for LilyPond is found in the
-...@var{type-p-name-alist} of @file{scm/lily.scm}.
-
-...@c TODO -- automatically document type-p-name-alist
-
-...@multitable @columnfractions .33 .66
-...@headitem Input type  @tab @var{vari-type?} notation
-...@item Integer @tab @code{integer?}
-...@item Float (decimal number)  @tab @code{number?}
-...@item Text string @tab @code{string?}
-...@item Markup  @tab @code{markup?}
-...@item Music expression@tab @code{ly:music?}
-...@item A pair of variables @tab @code{pair?}
-...@end multitable
-
-The @code{parser} and @code{location} arguments are mandatory.
-The @code{parser} argument is used in the body of the function
-to gain access to the value of another LilyPond variable.
-The @code{location} argument is used to set the @q{origin}
-of the music expression that is built by the music function,
-so that in case of a syntax error LilyPond
-can tell the user an appropriate place to look in the input file.
-
-...@node Simple substitution functions
-...@subsection Simple substitution functions
-
-A simple substitution function is a music function whose output music
-expression is written in LilyPond code, but with an input variable
-substituted into the LilyP

Re: PATCH: Doc: Reorganize music functions material.

2010-04-25 Thread Carl Sorensen



On 4/25/10 7:34 PM, "Mark Polesky"  wrote:

> Here's a patch to reorganize the music functions material in
> Notation and Extending.  This also includes (finally) some
> code to auto-document the available type predicates in
> type-p-name-alist.
> 
> Before I finish the re-editing, however, I'd like to see how
> this question gets answered:
> http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00350.html
> 
> Notwithstanding that specific issue, any suggestions,
> objections, etc?

Can you post it on Rietveld?  It's much easier to review there.

Thanks,

Carl



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


Re: music-functions: #$var1 or just $var1 ?

2010-04-25 Thread Carl Sorensen



On 4/25/10 11:51 AM, "Mark Polesky"  wrote:

> Nicolas Sceaux wrote:
>> Inside the #{ ... #} construct, you have to use #$variable
>> where a scheme token is required, but you use $variable
>> where \variable could be used.  Behind the scenes,
>> $variable is actually replaced by something like \tmpvar
>> before being parsed.
> 
> Can you provide an example of a case where #$ is required
> within #{ #} ?  I can't find one.  $ seems to always work.

As I understand it, in LilyPond input, the # is a token that indicates a
Scheme expression follows.

In a #{ #} expression, $ is a token that indicates a Scheme expression to be
evaluated follows.

I don't think that #$ is ever required inside of #{ #}.

And there are some places where we use # that it is not strictly required,
i.e. where the argument needs to be a string, and it can be either a
LilyPond string (no #) or a Scheme string (start with a #).

We made a decision a number of years ago to always put # in if it was
accepted, even when it wasn't required, in order to be more consistent.

Similarly, we made a decision to put { after \new Staff, even if it wasn't
required, for consistency.  So we do

\new Staff {
  \new Voice {
   c d e f
  }
}

even though

\new Staff \new Voice {
  c d e f
}

would also work.

In my opinion, we should not request that the user use #$, but we should
just indicate that inside a #{ #} block $ is used to indicate a Scheme
expression to be evaluated.

> 
> In fact, I'm probably missing something obvious, but I'm
> unable even to find a case where a scheme token (with #) is
> actually required in a regular music block.  I've found I
> can even do such bizarre things as this:
> 
>   voiceCtx = Voice
>   noteGrob = NoteHead
>   colorSym = #'color
>   redVal = #red
> 
>   { \override \voiceCtx.\noteGrob \colorSym = \redVal c'' }
> 
> and by extension, I can also do this (without using `#$'):
> 
>   overrideAlias =
>   #(define-music-function
> (parser location ctx grob prop-sym prop-val)
> (scheme? scheme? scheme? scheme?)
> #{
>   \override $ctx . $grob $prop-sym = $prop-val
> #})
> 
>   { \overrideAlias Voice NoteHead #'color #red c'' }
> 
> So, two things:
> 1) what is a case where omitting the # causes an error?

I doubt there is one -- see above.

> 2) what is the danger of omitting the # otherwise?

I don't think there is any.

Carl



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


Re: PATCH: Doc: Reorganize music functions material.

2010-04-25 Thread Mark Polesky
Carl Sorensen wrote:
>> Here's a patch to reorganize the music functions [...]
>
> Can you post it on Rietveld?  It's much easier to review
> there.

Sure.  I accidentally left out a file in the previous patch
anyway.  Here it is on Rietveld:
http://codereview.appspot.com/970044

- Mark


  


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


Re: music-functions: #$var1 or just $var1 ?

2010-04-25 Thread Mark Polesky
Carl Sorensen wrote:
> As I understand it, in LilyPond input, the # is a token
> that indicates a Scheme expression follows.
>
> In a #{ #} expression, $ is a token that indicates a
> Scheme expression to be evaluated follows.

And all this time I thought $ was only for referencing the
function's arguments.  Perhaps we should always prefer $
over # inside music function definitions?  Like so:

colorNote =
#(define-music-function
  (parser location color-value)
  (scheme?)
  #{
\once \override NoteHead $'color = $color-value
  #})

\relative c' { c d \colorNote #red e f }


> I don't think that #$ is ever required inside of #{ #}.
>
> And there are some places where we use # that it is not
> strictly required, i.e. where the argument needs to be a
> string, and it can be either a LilyPond string (no #) or a
> Scheme string (start with a #).
>
> We made a decision a number of years ago to always put #
> in if it was accepted, even when it wasn't required, in
> order to be more consistent.

That's nice, but in this particular case, I think most users
will find this *inconsistent*.  Far easier to remember to
always use a $ than to get bogged down with #-correctness.


> In my opinion, we should not request that the user use #$,
> but we should just indicate that inside a #{ #} block $ is
> used to indicate a Scheme expression to be evaluated.

+1

- Mark


  


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


"always specify initial duration within { ... }" ?

2010-04-25 Thread Mark Polesky
The implicit initial duration of a { music } block is 4
(quarter note), unless that block is preceded by a block
which ends with a different duration, even if the preceding
music block is within another \book scope included from a
different file!  The docs don't do a good job of addressing
this, and it still trips me up sometimes (like when I
copy/paste { music } blocks that don't specify durations).

Both
  LM 1.2.1 "Simple notation" and
  NR 1.2.1 "Writing rhythms"
include these two sentences:

  If the duration is omitted, it is set to the previously
  entered duration.  The default for the first note is a
  quarter note.

I think this is needlessly misleading.  In context, this
implies that the duration of the first note of a { music }
block is a quarter note, though it may be more accurate to
say "each time lilypond is invoked, the default duration for
the first note read by the parser is a quarter note."

Of course, putting that kind of language in the tutorial is
out of the question in my opinion, and I think this is a
case where its better if the user doesn't know too much.

I'd like to reword both instances of this paragraph to:

  If the duration is omitted, it is set to the previously
  entered duration.  The duration of the first note in every
  { music } block should always be specified explicitly.

Any objections?

- Mark


  


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