Re: [frogs] Da Capos, Codas and Segnos

[Marc Hohl]

David Kastrup schrieb:

Marc Hohl  writes:

  

After reading through the other posts, I think that overloading
\repeat would not cover *all* possible
cases. On the other hand, there should be *one* consistent way of
doing any kind of repeats.

David's comparison with goto-like structures seems to be the right
approach, so I revert my
proposal about enhancing \repeat for a more universal structure.



Oh I think we are not communicating.  I liked your proposal quite well,
even though it did not cover "everything conceivable".
  

Oh, obviously I misunderstood your remarks.

What I was talking about that in order not to have a proliferation of
things that work/expand with only a subset of the supported repeats,
that the internal music data structures gain a few "linkages" or
whatever you want to call it that cover the possible sequencing.

For example, one could have an element "multibranch" that contains a
sequence of music list tails (or #t to continue on the printed score).
When this element is passed/played the first time, it takes the first
branch, then the next...  It should be reasonably easy to perform this
with this info, and reasonably easy to produce the right amount of
preannounce material.  Doing cautionary accidentals correctly needs the
reverse information, namely instead of "where can I be going to from
here" the info "where can I be coming from here".

But the point is that "repeat volta" and "coda" and whatever else in the
music list should be just interesting for the grob engraver, and
performer and repeat unfolder and cautionaries and stuff get their info
from a lower-level primitive data structure.
  

I agree. So We need both a data structure flexible enough to cover
all possible cases, and an input mechanism which is consistent and
yet not overwhelmingly complicated from the user's view.

Like a compiler compiling conditionals to jnz, the high level language
with which we specify the structures should be powerful enough to avoid
the explicit use of "goto" whenever possible.

But there might be some user-level description of the logical structure
that can get by without use of "goto" at the input level, even though it
may get compiled to such.
  
In principle, I second this. A perfect implementation should (at least 
in my opinion)
make the input source nearly as readable and understandable as the 
musical output,

so perhaps structuring the input file with

\coda {
...
}

\trio {
...
}

and some \toCoda/\toTrio commands might be necessary, though.

Greetings,

Marc


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

Re: [frogs] Da Capos, Codas and Segnos

[David Kastrup]

Marc Hohl  writes:

> David Kastrup schrieb:
>
>> But the point is that "repeat volta" and "coda" and whatever else in
>> the music list should be just interesting for the grob engraver, and
>> performer and repeat unfolder and cautionaries and stuff get their
>> info from a lower-level primitive data structure.
>>   
> I agree. So We need both a data structure flexible enough to cover
> all possible cases, and an input mechanism which is consistent and
> yet not overwhelmingly complicated from the user's view.
>> Like a compiler compiling conditionals to jnz, the high level language
>> with which we specify the structures should be powerful enough to avoid
>> the explicit use of "goto" whenever possible.
>>
>> But there might be some user-level description of the logical structure
>> that can get by without use of "goto" at the input level, even though it
>> may get compiled to such.
>>   
> In principle, I second this. A perfect implementation should (at least
> in my opinion)
> make the input source nearly as readable and understandable as the
> musical output,
> so perhaps structuring the input file with
>
> \coda {
> ...
> }
>
> \trio {
> ...
> }
>
> and some \toCoda/\toTrio commands might be necessary, though.

Yes, some possibilities for standard situations like that would be
really fine: in general, the user should be able to express the logical
structure of his input, rather than having to mess with placing repeat
sign markups (necessary now) and declaring performance order (not
possible now).

For non-standard notation, being able to do manual markup without losing
the possibility to unfold and/or perform unless you are a magician will
still come in handy.

-- 
David Kastrup



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

Re: [frogs] Da Capos, Codas and Segnos

[Ian Hulin]

On 16/02/10 17:20, reinhold [via LilyPond Frogs] wrote:

Am Dienstag, 16. Februar 2010 18:07:11 schrieb Ian Hulin:

> Kieren MacMillan wrote:
> > Hi all,
> >
> > I've been lurking a bit on this thread, but felt I should comment.
> >
> > I personally think we need a more general structure than \repeat will
> > ever be able to reasonably offer. Essentially, we need to be able 
to say
> > that a single movement/piece [of Lilypond code] consists of one or 
more

> > \section blocks, where a \section would have at least the following
> > independent
> >
> > options:
> > 1. indent value[s] and/or line lengths;
> > 2. section title (e.g. "Trio").
> >
> > Then, each section can or cannot include standard Lilypond \repeat
> > structures, as necessary.
>
> Would it work something like this
>
> \score {
>  \section {
>   %untitled music expressions
>   }
>  \section :#title "Trio" :#indent 1 {
>%title Trio section music indented by 1 position
>   }
> }

Isn't this exactly the same as using different \score blocks in a file?

Sort of (see below)
At least David's case of  multiple movements should be written with 
different
scores for each movement. I'm using different scores for different 
movements
all the time, they use the piece header property for the title, use 
proper

intendation, etc.

Each of these movements can have any repeat structure, of course.

Currently, we have the following hierarchy:

-) Book
-) Bookpart
-) Score

I think that suffices all scores. I haven't yet seen a work, where a 
movement

is further split into separate submovements that need to be scores by
themselves.

I think you're right, \bookpart and \score blocks within these provide 
most of what Kieran wanted.


But what about a movement Minuet- Trio then D.C to Fine in Minuet 
(generally done as one movement), or likewise Scherzo, Trio, Scherzo 
reprise (done via Da Capo) and then a Coda?  Is this all covered by 
using \bookpart containing multiple \score blocks? I'm not sure it is, 
quite.


Looking at the hierarchy in terms of engraved (pdf) output:

   * Book produces a separate output file
   * Bookpart produces a compulsory page break and allows modification
 of \header element
   * Score represents a continuous chunk of musical notation covering a
 contiguous timespan
   * Section could mean "a group of score blocks within a bookpart with
 markups at the start and/or end which reference each other"

I think we current;y nearly have enough to handle coda/segno-type stuff 
with this sort of idea.


\book {
\header {
title = "The Overall Opus"
}
\bookpart {
%First Movement
}
\bookpart {
%Second Movement
}
\bookpart {
% 3. Scherzo
\header {
title = "3. Scherzo"
}
% Start of section
\score {
% Music for Section A of Scherzo
% End with markup stating goto Coda if you've finished 
performing the Da Capo

}
\score {
\header {
title = "Trio"
}
% Music for Section B of Scherzo, aka Trio, ending with
% "Da Capo" type markup
}
\score {
\header {
title = "Coda" % or \markup to generate ¤ (the 
hot-cross-bun sign)

}
% Music for Section C of Scherzo, the Coda
}
% End of section
}

We could have \section with this syntax:
\section title-markup-list lastbar-markup-list list-of-music-expressions
e.g.
\section {"" "Trio" "Coda"} %markups 
to use as titles in \header within the score
 {"Al Coda 2a volta" "Da Capo al Coda" ""} %markups to 
print at the start of the last bar in each score
 {
   %the music expression for each score

{% Music for Section A of Scherzo}
{% Music for Section B, aka Trio}
{% Music for Coda}
 }

\section could use a new lastbar-markup property for \score which would 
be text to be printed at the start of the last bar of a score block, 
otherwise it would expand to the above idea.


Doable? Desirable? Or just me diving off down a gopher-hole?

Cheers,

Ian

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

Re: Determining location of the staff lines

[Eric Knapp]

On Mon, Feb 15, 2010 at 11:54 AM, Carl Sorensen  wrote:
>
>
> I think it's not yet possible to do this in a Scheme engraver.
>
> Han-Wen indicated that it could be done here:
>
> http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00594.html
>
> But I don't think it's been implemented yet.  Perhaps Han-Wen will do so,
> now that we've identified a need.
>

This is good to know. I thought I was losing my chops for learning new
languages! Now I'm relieved to know that it's not just me and that
might be a new feature. When Han-Wen says "I had thought the Scheme
engravers to use context properties to store internal state" what was
envisioned? Can arbitrary properties be added to the context or are
there properties that can be used for new data?


> Exactly.  You'll have a listener for note-events and for string-number
> events.

I had figured this out but was stuck on collecting the data to do what I need.

>
>>
>> How do I create the vectors in Scheme so that they are persistent?
>> Everything I've tried has resulted in only having the last item in the
>> vector there once I'm done.
>
> We need to have the capability to store private data in Scheme engravers.
> Hopefully we can get that implemented.
>

I'm assuming that context properties can't be used for this?

>
> The grob will be created in the process-music function, which occurs after
> all of the notes at the current moment.
>
> You should create StaffTabStringIndicator grobs  (you'll need to create a
> new grob type for that -- see scm/define-grobs.scm).

Thanks, I'll look into this for the time being.

>
> HTH,
>
> Carl
>

This is helping greatly and I sincerely appreciate your detailed and
clear answers.

-Eric


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

Re: Determining location of the staff lines

[Carl Sorensen]

On 2/17/10 9:08 AM, "Eric Knapp"  wrote:

> On Mon, Feb 15, 2010 at 11:54 AM, Carl Sorensen  wrote:
>> 
>> 
>> I think it's not yet possible to do this in a Scheme engraver.
>> 
>> Han-Wen indicated that it could be done here:
>> 
>> http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00594.html
>> 
>> But I don't think it's been implemented yet.  Perhaps Han-Wen will do so,
>> now that we've identified a need.
>> 
> 
> This is good to know. I thought I was losing my chops for learning new
> languages! Now I'm relieved to know that it's not just me and that
> might be a new feature. When Han-Wen says "I had thought the Scheme
> engravers to use context properties to store internal state" what was
> envisioned? Can arbitrary properties be added to the context or are
> there properties that can be used for new data?
> 
Yes, arbitrary properties can be added to the context.  Context properties
are stored as scheme alists.  So that is a potential workaround that you
could use now -- store the private data in a context property (which makes
it not private, but nobody else is using it so it's pseudo-provate).

>>> 
>>> How do I create the vectors in Scheme so that they are persistent?
>>> Everything I've tried has resulted in only having the last item in the
>>> vector there once I'm done.
>> 
>> We need to have the capability to store private data in Scheme engravers.
>> Hopefully we can get that implemented.
>> 
> 
> I'm assuming that context properties can't be used for this?

They probably can, but it's not the normal way of working.

> 
> This is helping greatly and I sincerely appreciate your detailed and
> clear answers.


You're welcome.  I'm a little nervous sometimes that my answers may not be
strictly correct, but I'm doing my best.

Thanks,

Carl



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

Re: Determining location of the staff lines

[David Kastrup]

Carl Sorensen  writes:

> Yes, arbitrary properties can be added to the context.  Context
> properties are stored as scheme alists.  So that is a potential
> workaround that you could use now -- store the private data in a
> context property (which makes it not private, but nobody else is using
> it so it's pseudo-provate).

It is not really prohibited to use an engraver more than once in one
context, is it?

-- 
David Kastrup



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

Re: Determining location of the staff lines

[Carl Sorensen]

On 2/17/10 10:18 AM, "David Kastrup"  wrote:

> Carl Sorensen  writes:
> 
>> Yes, arbitrary properties can be added to the context.  Context
>> properties are stored as scheme alists.  So that is a potential
>> workaround that you could use now -- store the private data in a
>> context property (which makes it not private, but nobody else is using
>> it so it's pseudo-provate).
> 
> It is not really prohibited to use an engraver more than once in one
> context, is it?

It's probably not prohibited, but it can hardly be desired behavior, since
the engraver would duplicate its work and you'd get multiple identical grobs
(because the engraver is controlled solely by music events and context
properties).

Thanks,

Carl



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

website translation build: got blah.xy.html files

[Graham Percival]

We're now building the fr and es translations of the website:
http://lilypond.org/~graham/website/index.es.html

The next steps are:
1) es+fr translators: if you do "make website", you'll see a huge
number of warnings.  Mostly because you've changed the node names of
Changes and Old downloads.  Please fix your web/news.itexi to refer to
the right node names.

2) me and/or John: making the automatic translation thingie work.

3) anybody who wants a laugh: take a look at website.make.  This is an
example of how NOT to do a loop in a makefile.  Especially not a loop
that involves a sed command.  It's funny.  Laugh.  If you complain
about how bad it is, I'll rudely invite you to send a patch that fixes
it, while complaining about how much of a loser you are/were for
leaving this build stuff up to me, when *obviously* I can't be trusted
to write a decent makefile.

Cheers,
- Graham


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

Re: Determining location of the staff lines

[Neil Puttock]

On 17 February 2010 16:36, Carl Sorensen  wrote:

> Yes, arbitrary properties can be added to the context.  Context properties
> are stored as scheme alists.  So that is a potential workaround that you
> could use now -- store the private data in a context property (which makes
> it not private, but nobody else is using it so it's pseudo-provate).

As David Pounder suggested here,
http://lists.gnu.org/archive/html/lilypond-devel/2010-01/msg00597.html,
it might be easier to use let binding.  This should work fine assuming
you don't require the scheme engraver to be added to more than one
context.

Regards,
Neil


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

[PATCH] Change default to NOT ignore bass figures on rests

[Reinhold Kainhofer]

Are there any objections to setting ignoreFiguredBassRests to ##f by default?
Bass figures on rests occur every now and then, and they have a well-defined 
meaning: They are taken relative to the following bass note...

I don't don't see any reason at all to have this option in the first place.
I don't know what Han-Wen's reasons were in his commit 
1ade176d77575b5b04f626c8f3a2adce3bc900f0 (25.09.06 02:58) to add this property 
and set it to ##t by default, but I don't understand it.

So, it is okay to apply this patch:

http://codereview.appspot.com/212042/show

Thanks,
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: Issue 659: alternate segno symbol (issue181144)

[n . puttock]

Hi Marc,

LGTM, though I still think this is a lot of effort for a very obscure
and little-used symbol.

Cheers,
Neil


http://codereview.appspot.com/181144/diff/5028/4010
File input/regression/bar-line-segno.ly (right):

http://codereview.appspot.com/181144/diff/5028/4010#newcode2
input/regression/bar-line-segno.ly:2: \header { texidoc = "Segno bar
lines can be used to mark
newline for texidoc

http://codereview.appspot.com/181144/diff/5028/4010#newcode7
input/regression/bar-line-segno.ly:7: \paper {  ragged-right = ##t }
{ ragged-right

http://codereview.appspot.com/181144/diff/5028/4011
File lily/bar-line.cc (right):

http://codereview.appspot.com/181144/diff/5028/4011#newcode97
lily/bar-line.cc:97: Stencil segno;
I'd move this back to a separate if { } block (like Reinhold suggested
for your original patch)

(see below)

http://codereview.appspot.com/181144/diff/5028/4011#newcode210
lily/bar-line.cc:210: else if (str == "S")
(as mentioned above)

else if (str.find ("S") != NPOS || str = "|._.|")
  {
Stencil segno
...

if (str == "S")
  {
...

http://codereview.appspot.com/181144/show


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

Life of a Grob

[Carl Sorensen]

Joe,

I stumbled across your "Life of a Grob" feature while I was looking up stuff
on Figured Bass.



I think this would be really good to add to either the CG or the Extending
LilyPond manual.

Can you tell me what the current status of this is?

Thanks,

Carl



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

Can't build today's git pull

[Peter Chubb]

...
chmod 755 out/convert-ly
/usr/src/lilypond/scripts/build/out/help2man out/convert-ly > out/convert-ly.1
out/convert-ly:341: Warning: 'as' will become a reserved keyword in Python 2.6
  File "out/convert-ly", line 341
except InvalidVersion as ex:
   ^
SyntaxError: invalid syntax
help2man: can't get `--help' info from out/convert-ly

...

This is with python version 2.5.5

I suggest this patch, which *should* work with both 2.6 and 2.5
(but warning: I am *not* a python programmer).

Signed-off-by: Peter Chubb 
---
 scripts/convert-ly.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: lilypond/scripts/convert-ly.py
===
--- lilypond.orig/scripts/convert-ly.py 2010-02-18 09:16:54.522166613 +1100
+++ lilypond/scripts/convert-ly.py  2010-02-18 09:36:01.082161642 +1100
@@ -319,7 +319,7 @@
 do_one_file (f)
 except UnknownVersion:
 error (_ ("%s: Unable to determine version.  Skipping") % f)
-except InvalidVersion as ex:
+except InvalidVersion, ex:
 error (_ ("%s: Invalid version string `%s' \n"
   "Valid version strings consist of three numbers, "
   "separated by dots, e.g. `2.8.12'") % (f, ex.version) )

--
Dr Peter Chubbwww.nicta.com.au  peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au   ERTOS within National ICT Australia
From Imagination to Impact   Imagining the (ICT) Future


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

Re: [PATCH] Change default to NOT ignore bass figures on rests

[Carl Sorensen]

On 2/17/10 2:51 PM, "Reinhold Kainhofer"  wrote:

> Are there any objections to setting ignoreFiguredBassRests to ##f by default?
> Bass figures on rests occur every now and then, and they have a well-defined
> meaning: They are taken relative to the following bass note...
> 
> I don't don't see any reason at all to have this option in the first place.
> I don't know what Han-Wen's reasons were in his commit
> 1ade176d77575b5b04f626c8f3a2adce3bc900f0 (25.09.06 02:58) to add this property
> and set it to ##t by default, but I don't understand it.

As far as I can see, this is likely to have come out of the change Erik
Sandberg made to implement music streams.

The initial bug report is here:

http://lists.gnu.org/archive/html/bug-lilypond/2006-09/msg00027.html

Han-Wen had some discussion about the fix on -devel here:

http://lists.gnu.org/archive/html/lilypond-devel/2006-09/msg00126.html

Based on what I've read, I'd say that you're the expert on Figured Bass, and
we should make it do what you think is best.

Changing the default is not that big a deal, I think, as long as it's
documented in NEWS.

But this may require changes to the documentation as well.

Thanks,

Carl



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

Re: Can't build today's git pull

[John Mandereau]

Neither can I.  Sorry for top-posting but it seems this error is
unrelated to the one you reported:

error: cannot find description for property originalMiddleCPosition 
(translation)
/home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm
make[1]: *** [out/internals.texi] Error 1

Cheers,
John


Il giorno gio, 18/02/2010 alle 09.47 +1100, Peter Chubb ha scritto: 
> ...
> chmod 755 out/convert-ly
> /usr/src/lilypond/scripts/build/out/help2man out/convert-ly > out/convert-ly.1
> out/convert-ly:341: Warning: 'as' will become a reserved keyword in Python 2.6
>   File "out/convert-ly", line 341
> except InvalidVersion as ex:
>^
> SyntaxError: invalid syntax
> help2man: can't get `--help' info from out/convert-ly
> 
> ...
> 
> This is with python version 2.5.5
> 
> I suggest this patch, which *should* work with both 2.6 and 2.5
> (but warning: I am *not* a python programmer).
> 
> Signed-off-by: Peter Chubb 
> ---
>  scripts/convert-ly.py |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: lilypond/scripts/convert-ly.py
> ===
> --- lilypond.orig/scripts/convert-ly.py   2010-02-18 09:16:54.522166613 
> +1100
> +++ lilypond/scripts/convert-ly.py2010-02-18 09:36:01.082161642 +1100
> @@ -319,7 +319,7 @@
>  do_one_file (f)
>  except UnknownVersion:
>  error (_ ("%s: Unable to determine version.  Skipping") % f)
> -except InvalidVersion as ex:
> +except InvalidVersion, ex:
>  error (_ ("%s: Invalid version string `%s' \n"
>"Valid version strings consist of three numbers, "
>"separated by dots, e.g. `2.8.12'") % (f, ex.version) )
> 
> --
> Dr Peter Chubbwww.nicta.com.au  peter DOT chubb AT nicta.com.au
> http://www.ertos.nicta.com.au   ERTOS within National ICT Australia
> From Imagination to Impact   Imagining the (ICT) Future



signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Can't build today's git pull

[Neil Puttock]

2010/2/17 John Mandereau :
> Neither can I.  Sorry for top-posting but it seems this error is
> unrelated to the one you reported:
>
> error: cannot find description for property originalMiddleCPosition 
> (translation)
> /home/lilydev/git/lily/master/out/share/lilypond/current/scm/lily.scm
> make[1]: *** [out/internals.texi] Error 1

Sorry John, that one's my fault.  I've already pushed a fix.

Cheers,
Neil


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

Re: Can't build today's git pull

[Graham Percival]

On Thu, Feb 18, 2010 at 09:47:21AM +1100, Peter Chubb wrote:
> ...
> chmod 755 out/convert-ly
> /usr/src/lilypond/scripts/build/out/help2man out/convert-ly > out/convert-ly.1
> out/convert-ly:341: Warning: 'as' will become a reserved keyword in Python 2.6
>   File "out/convert-ly", line 341
> except InvalidVersion as ex:
>^
> SyntaxError: invalid syntax
> help2man: can't get `--help' info from out/convert-ly

Are you sure that's a build **failure**, and not just a
**warning**?  I think I remember seeing the "help2man: can't get
--help" error for years.


I know that having serious-looking warnings in the build system
isn't ideal; we've had an open bug tracker item for this for ages.

> This is with python version 2.5.5
> 
> I suggest this patch, which *should* work with both 2.6 and 2.5
> (but warning: I am *not* a python programmer).

I'm not a python programmer either, but git must (and has been)
compile with python 2.4.5.  (unless anybody updates the package in
GUB)

2.13.13 definitely compiled with 2.4.5, and I can't remember any
changes to convert-ly since then.

Cheers,
- Graham


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

Re: [PATCH] Change default to NOT ignore bass figures on rests

[Graham Percival]

On Wed, Feb 17, 2010 at 03:51:21PM -0700, Carl Sorensen wrote:
> 
> Changing the default is not that big a deal, I think, as long as it's
> documented in NEWS.

Documentation/changes.tely

> But this may require changes to the documentation as well.

I'm not familiar with our figured bass docs, so I can't comment on
that.

Cheers,
- Graham


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

Re: Can't build today's git pull

[Peter Chubb]

> "Graham" == Graham Percival  writes:

Graham> On Thu, Feb 18, 2010 at 09:47:21AM +1100, Peter Chubb wrote:
>> ...  chmod 755 out/convert-ly
>> /usr/src/lilypond/scripts/build/out/help2man out/convert-ly >
>> out/convert-ly.1 out/convert-ly:341: Warning: 'as' will become a
>> reserved keyword in Python 2.6 File "out/convert-ly", line 341
>> except InvalidVersion as ex: ^ SyntaxError: invalid syntax
>> help2man: can't get `--help' info from out/convert-ly

Graham> Are you sure that's a build **failure**, and not just a
Graham> **warning**?  I think I remember seeing the "help2man: can't
Graham> get --help" error for years.

It's a build failure -- make just stops at that point.



>> This is with python version 2.5.5
>> 
>> I suggest this patch, which *should* work with both 2.6 and 2.5
>> (but warning: I am *not* a python programmer).

Graham> I'm not a python programmer either, but git must (and has
Graham> been) compile with python 2.4.5.  (unless anybody updates the
Graham> package in GUB)

Graham> 2.13.13 definitely compiled with 2.4.5, and I can't remember
Graham> any changes to convert-ly since then.


Reinhold made a change to convert-ly as the last change in the stack
before I pulled this morning (my time), to add an exception for a
malformed version string.  But he used a Python 3.0 feature, which my
patch fixes:
  
  commit 55ee5f274895295ae79d555d6dcc9ab84ecf270e
  Author: Reinhold Kainhofer 
  Date:   Thu Dec 31 12:20:41 2009 +0100

convert-ly: Raise an error message if version number is not a
three-entry tuple 

This fixes crashes with things like
   \version "2.10"
or
   \version "2.10.4.3.21"
and instead gracefully reminds the user that version strings should have a
form like `2.8.12'


--
Dr Peter Chubbwww.nicta.com.au  peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au   ERTOS within National ICT Australia
From Imagination to Impact   Imagining the (ICT) Future


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

Re: Life of a Grob

[Joe Neeman]

On Wed, 2010-02-17 at 15:21 -0700, Carl Sorensen wrote:
> Joe,
> 
> I stumbled across your "Life of a Grob" feature while I was looking up stuff
> on Figured Bass.
> 
> 
> 
> I think this would be really good to add to either the CG or the Extending
> LilyPond manual.
> 
> Can you tell me what the current status of this is?

I don't really make use of it anymore, since I've become familiar enough
with the source that it isn't really useful. But it should still work
(there is a regression test, graphviz.ly, and it seems to be ok). I'd
suggest the CG as a more appropriate place than Extending, because the
feature is really only helpful if you want to dig into the C++ source.

If this sort of feature is still useful to anyone, it might be cool to
extend it to parent/child relationships (ie. to allow scheme breakpoints
whenever a parent/child bond is added or changed) since such
relationships aren't documented anywhere and they're a bit hard to
trace.

Cheers,
Joe




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

[PATCH] Support multi-slash and mixed-duration beat repeats

[Neil Puttock]

Hi everybody,

I've posted a patch on Rietveld which enhances the behaviour of
\repeat percent by allowing single-beat repeats to be shown with
multiple slashes (if all durations are equal and duration >=
semiquaver) or as double-percent glyphs (varying durations).

I've moved the handling of the different percent repeat types out of
the Percent_repeat_engraver and in to the Percent_repeat_iterator,
which now sends synthetic events for each of the repeat styles:
PercentEvent, DoublePercentEvent and RepeatSlashEvent.

One thing I'm a bit unsure about is where to calculate the
slash-count: though I've settled for calling a (for the time being
inefficient and lazily coded :) scheme proc from the iterator, I
wonder whether this is the best approach (it would of course be easy
to do this in C++ instead).

Please review here: http://codereview.appspot.com/212048

Thanks,
Neil
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: new smaller installers to test

[Han-Wen Nienhuys]

On Fri, Feb 12, 2010 at 4:57 PM, Graham Percival
 wrote:
> I've tweaked the list of dirs to remove from
> share/ghostscript/Resources.  The resulting files are (on average) 5
> megs smaller.  linux-x86 works here for me.

It looks as if this directory contains various character encoding
related stuff.  Can you run this through a couple of CJK files to see
if that keeps working?

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


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