Re: critical issues

[Graham Percival]

On Sat, Jan 01, 2011 at 12:31:23AM -, Trevor Daniels wrote:
> 
> Graham Percival wrote Friday, December 31, 2010 11:20 PM
> 
> >However, lilypond never intentionally tried to
> >avoid those objects colliding -- in fact, intentionally avoiding
> >this collision would require a fair chunk of extra code.  Should
> >we hold back a stable release just for this?
> 
> Well, I don't intend to die in the ditch over this,
> but the concern I had was this.  Quite a lot of the
> documentation was written, not by inspecting the code
> to see what was intended, but by experimenting and
> writing up what was found.

Yep.

> I certainly worked that
> way, and I think Mark and Keith did recently in
> documenting the new spacing stuff.  In doing that we
> had no idea whether the things we find are intentional
> or a happy coincidence of bugs.

Welcome to lilypond development.  :(

> Now if you can work
> in something about "working as intended or documented"
> wrt determining critical bugs

Nope, for precisely the reason you gave earlier: our documentation
generally has zero input from programmers, so it's not at all a
good representation of "what's intended".

We have a set of "intended to be working" examples.  They're
called the regression tests.  No more, no less.  If a patch breaks
those, then we reject the patch.  If we notice in time.


...

Look, we simply *cannot* offer users anything that would be
"reasonable" by most standards.  We have "highly embarrassing"
bugs from 2006 that we're not even *pretending* to be working on.
We've been in "release crunch" mode for at least six months.  The
only glimmer of hope on the horizon is that, under the most strict
interpretation of "critical regression", almost none of those bugs
were introduced recently.  So there's a chance that once we "catch
up" on the old critical regressions, we won't have many new ones,
and thus we can move forward with a stable foundation.

As a long-time observer and developer, the only honest thing we
can offer users is this:
1. lilypond is distributed without warrantee, including the
implied warantee of fitness for a particular purpose.
(paraphrased from the license)
2. if you find a bug, and make a perfect bug report, then there's
a 90% chance that no programmer will ever look at it.  That chance
increases if you make an imperfect bug report.
3. if you want stability, then never upgrade your lilypond
version.

In my idle moments, I like to discourage myself by trying to
figure out how long it would take to achieve something
"reasonable" for users.  Let's play this game now, and start
making some unrealistic-but-just-possible assumptions:
1. "reasonable" means 100 bugs.  Let's also assume that these can
be the 100 most problematic bugs (i.e. we can fix the easy ones
first without penalizing this "reasonable" goal).
2. with the new lilydev iso, we can gather 10 new programmers.
Keith, Phil, Janek, etc.
3. each of those 10 programmers can fix an average of 1 issue
every 10 days.  By "fix", I mean "understand the problem, read the
code, produce patches for review, respond to comments, make new
drafts, and have somebody push the final fix".
4. the existing developers are capable of doing all the reviewing
for all these patches.
5. we continue to get approximately 1 new issue every 3 days.

I think the above assumptions are unrealistic, but just about
possible.  How long will it take us to reach 100 issues?

Well, we fix 356 issues a year (10 issues per 10 days); let's call
that 350 to make it even.  We add 100 issues a year (1/3*356).  So
our "bug debt" reduces by 250 a year.  We currently have 528
issues, so it'll take us slightly less than 2 years to fix the
easiest 80% of bugs.  Given all those unrealistic assumptions.

Really, things are going to get worse before they get better.  I
fully expect to hit 800 open issues before we manage to start
fixing more issues than we add.

I think our best bet is:
1. stabilize and release 2.14, using the most restrictive
interpretation of "stabilize" and "critical issue" we can.
2. drastically reduce (or abandon entirely) development for 3
months while we sort out the GOP policy questions (many of which
should ease future development)
3. start picking up the pieces and try to recruit more
contributors.

We might achieve "issue count balance" by mid-2011, and if we're
*really* lucky (and/or work hard), we might be able to reduce the
open issue count to less than 500 (and keep it there!) by the end
of 2011.  I know that sounds like a really modest goal, but at the
moment I'm not even optimistic about reaching /that/ target.

- Graham

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

a plea to new contributors

[Graham Percival]

We are, yet again, about 10-20 hours of work away from having 0
critical issues.  This is a familiar position; we've been like
this since mid-August.  There's a tiny chance of releasing 2.14 in
January, and only a small chance of having it in Feb.  As we
slowly fix Critical issues, people discover more.  

I see no reason why this will change in the near future.  I was
hopeful that over the Christmas vacation, we'd manage to get
ahead, but that hasn't happened.  We simply have an imbalance
between the energy/interest of developers and the amount of
Critical issues.  I'm not saying that there's anything wrong with
our energy/interests!  Reviewing patches and the like is very
important (I'd actually say it's more important than fixing
Critical issues), and more than anything else, this is a volunteer
project.  Nobody is obligated to do anything.  But that doesn't
change the epirical fact that there has been an imbalance between
our energy/interest and critical issues for the past six months.

That's where the new contributors come in.  By assumption (the
"new" part), you're not part of the balance for the past 6 months.
So any effort you put towards fixing Critical issues will help fix
them sooner, which in turn will make 2.14 happen sooner.

Don't be discouraged from working on them just because other
people aren't.  Issue 1290 involves a change to a 20-line
function.  You'll probably need to read more of the file to
understand how that function works, but still, it's not terribly
complicated.  The next step in issue 1464 is just to create a
backtrace.  There's instructions in the CG for that.  I don't know
what issue 1465 needs right now, but if you start dumping
printf()s around, you should find a few clues.

The release is never going to happen if nobody works on it.  New
contributors, please consider working on it.  All it takes is time
and energy.

Cheers,
- Graham

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

Re: Change stringTunings entries from semitones to pitches (issue3842041)

[Carl . D . Sorensen]

I've responded to all the commandments and put up a new patch.

Thanks for all of your input.

Please review.

Carl



http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/3842041/diff/6001/Documentation/notation/fretted-strings.itely#newcode524
Documentation/notation/fretted-strings.itely:524: chord construct must
be in absolute note mode, and the string
On 2010/12/29 09:13:24, pkx166h wrote:

Hello, referred to 'Absolute octave entry' in the NR, not 'Absoulte

note mode'.

The heading is "Absolute octave entry".  The mode is "absolute octave
mode" or "absolute mode" -- see "Relative octave entry".

I've changed to "absolute octave mode".


Could we also have an @ref{} here too please (and thus an addition to

the

@seealso).


Done.

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly
File ly/string-tunings-init.ly (right):

http://codereview.appspot.com/3842041/diff/6001/ly/string-tunings-init.ly#newcode43
ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
I've added a new music function contextStringTunings (the name is
negotiable) that does the property set as well.

It sets stringTunings for both TabStaff and FretBoards.

I don't want to call it setStringTuning because it will be confused with
\set stringTunings.

http://codereview.appspot.com/3842041/

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

Re: critical issues

[Keith OHara]

On Fri, 31 Dec 2010 16:31:23 -0800, Trevor Daniels  
wrote:

... the concern I had was this.  Quite a lot of the
documentation was written, not by inspecting the code
to see what was intended, but by experimenting and
writing up what was found.  I certainly worked that
way, and I think Mark and Keith did recently in
documenting the new spacing stuff.


Pretty much.  If it makes you feel better, I did read a fair bit of the code to 
help build up a mental model of how things worked.  You remember that we 
rejected documenting those cross-staff collisions, until the code made it clear 
to me that some collisions were intentional, and possibly unavoidable.  More 
generally, we naturally sort our experimental findings into possible-bugs and 
oh-that's-how-it-works-s


Now if you can work
in something about "working as intended or documented"


That sounds good, and natural.
In most people's minds, documented implies intended.


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

Re: default .ly file in Windows Install seems to be

[Jonathan Kulp]

On Fri, Dec 31, 2010 at 5:59 PM, Graham Percival
 wrote:
> On Wed, Dec 29, 2010 at 11:30:29AM +, James Lowe wrote:
>> I have just downloaded and installed the windows version of 2.13.44-1 and 
>> the 'welcome to lilypond' default file seems to have completely changed.
>
> I can't reproduce on linux with wine; the initial file looks like
> normal to me, and the ly/welcome_to_lilypond.ly file is still
> present in the uncompressed exe, and has the contents I expect.
>

I can test it here if you want me too, but I don't know what it was
supposed to look like in the first place. I don't think I've ever seen
it.

Jon
-- 
Jonathan Kulp
http://www.jonathankulp.com

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

CG: out-of-tree building in main compile chapter. (issue3823045)

[percival . music . ca]

Reviewers: ,

Message:
Please review.

Description:
CG: out-of-tree building in main compile chapter.

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

Affected files:
  M Documentation/included/compile.itexi


Index: Documentation/included/compile.itexi
diff --git a/Documentation/included/compile.itexi  
b/Documentation/included/compile.itexi
index  
683326dd903ea46da3a7ed9b8d9268603e01567f..731aa58c0c288f09832a5d798aa7f52dfcd8bd37  
100644

--- a/Documentation/included/compile.itexi
+++ b/Documentation/included/compile.itexi
@@ -282,7 +282,7 @@ download and install the free-software

 @menu
 * Running ./autogen.sh::
-* Running ./configure::
+* Running ../configure::
 @end menu


@@ -298,50 +298,65 @@ Next, you need to create the generated files; enter  
the following

 command from your top source directory:

 @example
-./autogen.sh
+./autogen.sh --noconfigure
 @end example

-This will:
-
-...@enumerate
-...@item generate a number of files and directories to aid
+This will generate a number of files and directories to aid
 configuration, such as @file{configure}, @file{README.txt}, etc.

-...@item automatically run the @command{./configure} command.
-...@end enumerate
+Next, create the build directory with:
+
+...@example
+mkdir build/
+cd build/
+...@end example
+
+We heavily recommend building lilypond inside a separate directory
+with this method.


-...@node Running ./configure
-...@subsection Running @command{./configure}
+...@node Running ../configure
+...@subsection Running @command{../configure}
+

 @menu
 * Configuration options::
 * Checking build dependencies::
 * Configuring target directories::
-* Making an out-of-tree build::
 @end menu


 @node Configuration options
 @unnumberedsubsubsec Configuration options

-The @command{./configure} command (generated by
+...@warning{make sure that you are in the @file{build/} subdirectory
+of your source tree.}
+
+The @command{../configure} command (generated by
 @command{./autogen.sh}) provides many options for configuring
 @command{make}.  To see them all, run:

 @example
-./configure --help
+../configure --help
 @end example


 @node Checking build dependencies
 @unnumberedsubsubsec Checking build dependencies

-When @command{./configure} is run without any arguments, it will
+...@warning{make sure that you are in the @file{build/} subdirectory
+of your source tree.}
+
+When @command{../configure} is run without any arguments, it will
 check to make sure your system has everything required for
-compilation.  This is done automatically when
-...@command{./autogen.sh} is run.  If any build dependency is
-missing, @command{./configure} will return with:
+compilation:
+
+...@example
+../configure
+...@end example
+
+If any build dependency is missing, @command{../configure} will
+return with:

 @example
 ERROR: Please install required programs:  @var{foo}
@@ -357,7 +372,7 @@ WARNING: Please consider installing optional programs:   
@var{bar}

 If you intend to build the documentation locally, you will need to
 install or update these programs accordingly.

-...@warning{@command{./configure} may fail to issue warnings for
+...@warning{@command{../configure} may fail to issue warnings for
 certain documentation build requirements that are not met.  If you
 experience problems when building the documentation, you may need
 to do a manual check of @ref{Requirements for building
@@ -367,10 +382,13 @@ documentation}.}
 @node Configuring target directories
 @unnumberedsubsubsec Configuring target directories

+...@warning{make sure that you are in the @file{build/} subdirectory
+of your source tree.}
+
 If you intend to use your local build to install a local copy of
 the program, you will probably want to configure the installation
 directory.  Here are the relevant lines taken from the output of
-...@command{./config...@tie{}--help}:
+...@command{../config...@tie{}--help}:

 @quotation
 By default, `...@command{make@tie{}install}' will install all the
@@ -382,7 +400,7 @@ using `...@code{--prefix}', for instance  
`...@code{--prefix=$home}'.

 A typical installation prefix is @file{$HOME/usr}:

 @example
-./configure --prefix=$HOME/usr
+../configure --prefix=$HOME/usr
 @end example

 Note that if you plan to install a local build on a system where
@@ -399,28 +417,11 @@ already included.

 It is also possible to specify separate installation directories
 for different types of program files.  See the full output of
-...@command{./config...@tie{}--help} for more information.
+...@command{../config...@tie{}--help} for more information.

 If you encounter any problems, please see @ref{Problems}.


-...@node Making an out-of-tree build
-...@unnumberedsubsubsec Making an out-of-tree build
-
-It is possible to compile LilyPond in a build tree different from
-the source tree, using the @option{--srcdir} option of
-...@command{configure}.  Note that in some cases you may need to
-remove the output of a previous @command{configure} command by
-running @c

Re: critical issues

[Trevor Daniels]

Graham Percival wrote Friday, December 31, 2010 11:20 PM



On Thu, Dec 30, 2010 at 08:43:36PM +, Keith OHara wrote:

Trevor Daniels  treda.co.uk> writes:
> Graham Percival wrote Thursday, December 30, 2010 3:56 AM
> >
> > I want to keep the word "intentionally", though -- if 
> > something
> > only happened to work because of a happy coincidence of bugs, 
> > then

> > "breaking" that should not be a Critical bug.
>
> I'm not sure about this.  The purpose of selecting
> out bugs to be critical is to ensure the user who
> keeps up to date with the stable series of releases
> can be sure nothing in the new release is going to
> break his scores.  He doesn't care whether something
> worked just by a happy coincidence of bugs. [...]


Suppose we have a pair of memory leaks.  One leak writes junk to
memory as part of the guile initalization, and another leak reads
junk from memory as part of the spacing algorithm.  This pair of
bugs happens to result in a pair of objects not colliding.  When
we fix one of these bugs, the objects happen to collide.  Oh no,
it's a regression!  However, lilypond never intentionally tried to
avoid those objects colliding -- in fact, intentionally avoiding
this collision would require a fair chunk of extra code.  Should
we hold back a stable release just for this?


Well, I don't intend to die in the ditch over this,
but the concern I had was this.  Quite a lot of the
documentation was written, not by inspecting the code
to see what was intended, but by experimenting and
writing up what was found.  I certainly worked that
way, and I think Mark and Keith did recently in
documenting the new spacing stuff.  In doing that we
had no idea whether the things we find are intentional
or a happy coincidence of bugs.  Now if you can work
in something about "working as intended or documented"
wrt determining critical bugs I'd be happier.

Also, without the filter of intentionality, you end up arguing 
about whether the

feature is important, which is much more subjective.


Yes.


It is, but it might be relevant if fixing a minor
bug exposed a more serious one.

Trevor



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

Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

Hello,

I will be away for about three days, so you might have to wait
for replies to any questions to me addressed. When I'm back
I'll read every post in this thread, and answer the relevant
questions.

Happy New Gregorian Year!

Felipe

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

Re: default .ly file in Windows Install seems to be

[Graham Percival]

On Wed, Dec 29, 2010 at 11:30:29AM +, James Lowe wrote:
> I have just downloaded and installed the windows version of 2.13.44-1 and the 
> 'welcome to lilypond' default file seems to have completely changed.

I can't reproduce on linux with wine; the initial file looks like
normal to me, and the ly/welcome_to_lilypond.ly file is still
present in the uncompressed exe, and has the contents I expect.

Cheers,
- Graham

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

Re: critical issues

[Graham Percival]

On Thu, Dec 30, 2010 at 08:43:36PM +, Keith OHara wrote:
> Trevor Daniels  treda.co.uk> writes:
> > Graham Percival wrote Thursday, December 30, 2010 3:56 AM
> > >
> > > I want to keep the word "intentionally", though -- if something
> > > only happened to work because of a happy coincidence of bugs, then
> > > "breaking" that should not be a Critical bug.
> > 
> > I'm not sure about this.  The purpose of selecting
> > out bugs to be critical is to ensure the user who
> > keeps up to date with the stable series of releases
> > can be sure nothing in the new release is going to
> > break his scores.  He doesn't care whether something
> > worked just by a happy coincidence of bugs. [...]

Suppose we have a pair of memory leaks.  One leak writes junk to
memory as part of the guile initalization, and another leak reads
junk from memory as part of the spacing algorithm.  This pair of
bugs happens to result in a pair of objects not colliding.  When
we fix one of these bugs, the objects happen to collide.  Oh no,
it's a regression!  However, lilypond never intentionally tried to
avoid those objects colliding -- in fact, intentionally avoiding
this collision would require a fair chunk of extra code.  Should
we hold back a stable release just for this?

This isn't a theoretical example.  I can't remember if the cause
was a pair of memory leaks, but we *have* introduced collision
"bugs" due to general spacing improvements, where the lack of
collisions was never intentional.

> Also, without the filter of intentionality, you end up arguing about whether 
> the 
> feature is important, which is much more subjective.

Yes.

I'm not saying that the new behaviour wouldn't be a bug; just that
this bug should not delay a new stable release.

Cheers,
- Graham

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

Re: Updates to bagpipe.ly

[Graham Percival]

On Thu, Dec 30, 2010 at 05:35:43PM +0100, Sven Axelsson wrote:
> Perhaps a starting point would be if someone could have a look at what
> I'm doing in https://github.com/svenax/bagpipemusic/. The relevant
> file is bagpipe_new.ly, and there are lots of examples on how to use
> it in the repo as well.
> 
> The new mode is not backwards compatible with the old one, so I would
> have to include some convert-ly rules if approved.

Are there any parts of your new file that can be added without
tweaking the score and layout?  If so, why not prepare a patch for
those "un-controversial" parts, and get those accepted first?

Are your layout tweaks any less severe than stuff we do for
gregorian?  If so, that could be a good reason to accept them.  If
not, you could just make a few macros which do the tweaks, so that
users only have to do
\include "bagpipe.ly"
\paper {
  \bagpipeSpacing
}

Cheers,
- Graham

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

Re: Towards a new pitch representation

[Carl Sorensen]

On 12/31/10 10:28 AM, "Felipe Gonçalves Assis" 
wrote:

> Ok, Carl,
> 
> You vote for a list of integers, with arbitrary length.

I'm not sure I vote, yet.  I'm still in discussion mode.

I *do* vote for either a number or a list, so that the current behavior can
continue.

I *do* vote for a list, rather than a pair, for the alterations, because
that allows extension to arbitrary levels of alterations.

I *think* I vote for separating the scale degree from the alterations.  The
approach of including degree and alterations in a combined list has
mathematical elegance, most musicians will think in terms of scale degree
with alterations (e.g. d flat is scale degree d with an alteration of flat).
I think the current interface is good from the user point of view.

Thanks,

Carl

P.S.  I'm so impressed that you came along *making* the change, instead of
asking somebody else to make the change for you.  That's a great
contribution!



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

Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

Ok, Carl,

You vote for a list of integers, with arbitrary length.

There is actually no complication in not specifying its size.
Te midi engraver, for example, would just ignore entries
for which no value was specified. And in transpositions,
the unspecified values would just be considered zero.

In makam.ly, as I understand it, we would not need
longer lists, just one-sized lists with a different
magnitude specification, as in my current patch.
At least in order to maintain the current behaviour
with regards to transposition.

In general, anything that should behave the old way,
should use a single alteration level.

I look forward to hearing more opinions.

Thanks,
Felipe

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

Re: Towards a new pitch representation

[Hans Aberg]

On 31 Dec 2010, at 16:19, Felipe Gonçalves Assis wrote:


Thanks for the code, Hans!

There are many things I am curious about. Now that I have the sources,
I will spend some time analysing them, and then contact you.

While I need some time to study your considerations, what I can say  
now is:


. If, under a given musical system, what is printed on the score is  
enough to
 determine the precise tuning of a pitch, and if LilyPond supports  
the notation
 used, then it is possible to write an engraver that produces the  
correct sound
 output without changing the pitch representation. As I said, using  
the number

 1/2 to represent a sharp does not bind you to ET.

. Otherwise, I need to carefully study tuning systems and their use.

So, while I am proposing a somewhat fundamental change, it is still  
something
relatively simple, that will hopefully not break much user code, and  
might

make some microtonalists happy. I have good hope that this job may be
finished before the Equinox.


Graham Breed haas already extended it to arbitrary ETs within the  
current LilyPond pitch model - I have added some of his stuff to the  
link I put up before. In the file regular.ly, he somehow recomputes  
it. I do not know how it works, only that for key signatures of the  
form \key ..., there is a problem if the accidentals are not in E24.  
So those must be written out explicitly.


That being pointed, I must express that I would very much appreciate  
to

further bridge your ideas into LilyPond so as to make it an even more
powerful software. We actually have plenty of time for that, since  
work for

2.15 has not even officially started yet.


My proposal involve an entirely new model, but I think it would be  
simpler to use, and also be able to make the most of the staff  
typesetting system.


I then suggest we proceed with this conversation in a different  
branch,
in private or in public, as you prefer, and keep this thread to  
discuss

how the simpler ideas I am proposing might get into LilyPond.


Post it to this list so others know, but cc me if you want to be sure  
I see it.



I look forward to keeping in contact with you.


Just shoot.

  Hans



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

Re: Towards a new pitch representation

[Carl Sorensen]

On 12/31/10 8:46 AM, "David Kastrup"  wrote:

> Carl Sorensen  writes:
> 
>> No need to decide how many of them.  Just make the argument a list,
>> instead of a cons cell, and give the user access to change the length
>> of the list if they want to.
> 
> Huh?  "Access to change the length of the list"?  We are talking about a
> list, don't we?  Not an array?  The list is whatever length you need at
> any particular point of time.  If it is a list of alterations, quite
> possibly length 0.

As long as we're talking about a list, not a pair.  The current test
implementation is a pair.

> 
>> For the default distribution, the list length should be two, because
>> we have symbols for quarter-tone alterations, but no symbols for
>> anything smaller.
> 
> Huh?  What point is there in declaring a certain list length in advance
> rather than just using what is needed?

No point in general.  For the midi conversion, the list that defines the
magnitude of the alterations needs to be defined at the maximum allowed
alteration resolution.

If we go with a list of rationals, then there is no need to define any list
length in advance.

There does need to be some correspondence between the list of alterations
and the symbols used for displaying the alterations.

Thanks,

Carl


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

Re: Towards a new pitch representation

[David Kastrup]

Carl Sorensen  writes:

> No need to decide how many of them.  Just make the argument a list,
> instead of a cons cell, and give the user access to change the length
> of the list if they want to.

Huh?  "Access to change the length of the list"?  We are talking about a
list, don't we?  Not an array?  The list is whatever length you need at
any particular point of time.  If it is a list of alterations, quite
possibly length 0.

> For the default distribution, the list length should be two, because
> we have symbols for quarter-tone alterations, but no symbols for
> anything smaller.

Huh?  What point is there in declaring a certain list length in advance
rather than just using what is needed?

-- 
David Kastrup


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

Broken Link in CG to http://kainhofer.com/~lilypond/linkdoc/

[James Lowe]

Hello,



In CG 5.4.3 Checking Cross References there is a para that refers to



http://kainhofer.com/~lilypond/linkdoc/



This link however gives a 404.



Thanks



James

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

Re: Towards a new pitch representation

[Carl Sorensen]

On 12/31/10 1:31 AM, "Felipe Gonçalves Assis" 
wrote:

> Hi,
> 
>> 
>> Are you using a two-element list, or a cons cell?  The two are not the same.
>> 
>> I seem to remember looking in the code, and seeing scm_cadr calls, which
>> implies that your alterations would be (1 -1), not (1 . -1).
>> 
> 
> In scheme I am using a cons cell, in C++ I am using a new struct with
> overloaded
> operators. I was using the terms "list" and "pair" in an informal way. Sorry
> for
> the confusion.
> 
>> 
>> If we are going to move to a list for alterations, the list should probably
>> be rationals, rather than integers, in order to be most general.  Thus it
>> should most likely be (1/2 -1/4), rather than (1 -1).
>> 
>> Alternatively, you will need a property somewhere which is a list of the
>> base units for each alteration, so that an alteration would be (1 -1), and
>> the alterationMagnitude would be (1/2 1/4).
>> 
> 
> Right. In my patch this alterationMagnitude was sneaked in as new arguments
> for make-scale. So, by redefining the default-scale, you get what you want
> (see ly/makam.ly in the patch and dodecaphonic-adapted.ly in my previous
> message).
> 
> As I said, if you are going to use only a finite number of rationals, you
> can always accomplish the same results by using integers and scaling
> them accordingly. This scaling is only used for things like midi and
> ambitus. For transposition, and engraving, you only need the integers.
> 
>> In the current patch, you force all alterations to be lists (or cons cells,
>> whichever you have implemented).  This will break lots of old scores.  It
>> would be cleaner to allow alterations to be numbers (as they were in the
>> past) or lists.  Then the old code would work.  Otherwise, you'll need to
>> make a convert-ly rule which may be a bit tricky.
>> 
>> I think that as long as you *allow* but don't require the extended pitch
>> representation, it's likely to be very well accepted.
>> 
> 
> That is an important point. Below is what can be argued in defense
> of this.
> 
> . For code that only uses 1/4 alterations, and does not redefine the
>   default scale, convert-ly will be enough.
> . The only snippet in the LSR that calls ly:set-default-scale is
>   precisely dodecaphonic.ly.
> . Integers are faster than rationals.

For some large percentage of music written (certainly greater than 90%,
probably more like 99%), quarter-tone accidentals are irrelevant.  If you
keep the standard notation for this case, I think you'll get the best
possible performance, and you'll make code entry as easy as possible for
people -- they can keep doing it the way they've always done it.  And it's
not hard to code.  Why not do it?

> 
> So, admittedly, this idea of using a list of rationals, simple as at is,
> only occurred to me while writing towards123, yesterday.
> 
> If the community decides for that, I will start working on a new patch
> as soon as the order is given.
> 
> So, unless someone comes up with a completely new idea, what we
> have to decide is
> 
> a. Rationals or Integers?

Probably integers, with a rational magnitude list that is used to convert to
midi.

> ais. How many of them?

No need to decide how many of them.  Just make the argument a list, instead
of a cons cell, and give the user access to change the length of the list if
they want to.  For the default distribution, the list length should be two,
because we have symbols for quarter-tone alterations, but no symbols for
anything smaller.

In makam.ly, we may want to have a different list length.  I don't know,
because I haven't done anything with turkish music.

Thanks,

Carl


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

Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

Thanks for the code, Hans!

There are many things I am curious about. Now that I have the sources,
I will spend some time analysing them, and then contact you.

While I need some time to study your considerations, what I can say now is:

. If, under a given musical system, what is printed on the score is enough to
  determine the precise tuning of a pitch, and if LilyPond supports the notation
  used, then it is possible to write an engraver that produces the correct sound
  output without changing the pitch representation. As I said, using the number
  1/2 to represent a sharp does not bind you to ET.

. Otherwise, I need to carefully study tuning systems and their use.

So, while I am proposing a somewhat fundamental change, it is still something
relatively simple, that will hopefully not break much user code, and might
make some microtonalists happy. I have good hope that this job may be
finished before the Equinox.

That being pointed, I must express that I would very much appreciate to
further bridge your ideas into LilyPond so as to make it an even more
powerful software. We actually have plenty of time for that, since work for
2.15 has not even officially started yet.

I then suggest we proceed with this conversation in a different branch,
in private or in public, as you prefer, and keep this thread to discuss
how the simpler ideas I am proposing might get into LilyPond.

I look forward to keeping in contact with you.

Thanks,
Felipe

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

Re: Change stringTunings entries from semitones to pitches (issue3842041)

[Carl . D . Sorensen]

On 2010/12/29 05:18:07, Keith wrote:


ly/string-tunings-init.ly:43: (make-music 'SequentialMusic 'void #t)))
> We need to save the string tuning in a Scheme variable...
But if it is possible to set the variable as you do now, and then

return a

PropertySet instead of the void event,
(begin
   (chord->tuning parser tuning chord)
   (context-spec-music
 (make-property-set 'stringTunings tuning )
   'TabStaff)
)
then we could
\new TabStaff {
  \setStringTuning #'a-fiddle-tuning 



I'll add a \setStringTuning function.  I can see its utility.

Thanks,

Carl


http://codereview.appspot.com/3842041/

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

Re: Change stringTunings entries from semitones to pitches (issue3842041)

[Carl . D . Sorensen]

On 2010/12/29 05:18:07, Keith wrote:

Agreed. My earlier 'arbitrary' was a mental slip. I was thinking the

choice was

sensible, but even if it were arbitrary I would be scared of change.



> The order for the chord entry was requested by the users.  Chords

are

generally
> entered lowest note first.



Yes, but were the users right?  I would have asked for that order of

entry, too,

but would have changed my mind for fear of bugs when reminded that the

old way

to specify tuning was in order of string numbering.  (Bugs made by me

in my .ly

files, that is)
If you found this reversal not too error-prone, then maybe the users

were right.

As far as old files go, the convert-ly rule automatically does the
conversion, so you don't even need to think about it.

As far as new files go, I think the user can learn whatever syntax is
necessary.

Thanks,

Carl


http://codereview.appspot.com/3842041/

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

Re: Towards a new pitch representation

[Hans Aberg]

On 31 Dec 2010, at 10:59, Felipe Gonçalves Assis wrote:

I made a proposal for a representation, and there is Haskell code  
available

if you are interested.



Hi Hans. I would very much appreciate that code.


I have put it up here.
https://www-lagring.telia.se/Shares/Home.aspx?ShareID=069b86e6-3f8d-4d4e-a328-f7e9d4a6c121

I run it in Hugs ; start it using from the  
directory above the unpacked one by

  hugs Score.Staff
On a Mac, I add -Eopen, so ':e' opens the file in an editor.

This is the file that computes the accidentals from a staff system.  
Get back to here if you want more info.


There is another module Score.Scale with the pitch model. Those are  
not entirely synced together. The module Score.Intervals contains  
intervals I got from Scala.



I should remark
that your emails are what inspired me to start this. I take this  
opportunity

to thank you for everything.


It would be nice if it can serve as an inspiration for you tom  
implement something in LilyPond.


In it, the staff positions are expressed by a linear combinations  
of a
sequence of seconds m, M, n_0, ..., n_k (whatever names you want to  
give
them). If one only has a minor second m and a major second M, then  
sharps

raise with the interval M - m and the flats lower with that interval.

So I generalized this as to compute for any set of accidentals. The
algorithm will depend on the typesetting preferences, but it is  
possible to

compute them without any reference to pitches at all.



So, my idea is the same, except that I use the differences between the
seconds, so that the degree is just the coefficient of the major  
second,
and the calculation of accidentals is simpler (again, see notes on  
section

2.1 of towards123.txt).


Yes - it gets more complicated when having more accidentals.  
Musically, one plays on the seconds, and the accidentals only show up  
to express differences between them:


Define a tuning system by some intervals like the fifth P5 having the  
interval 3/2 and the octave P8 2, which gives the Pythagorean tuning,  
or replace the fifth with the major third M3 set to 5/4, which gives  
quarter-comma tuning.


Then express these intervals algebraically without their values in  
linear combinations of the minor second m and the major second M: P5 =  
m + 3M, P8 = 2m + 5M, M3 = 2M.


When computing the tuning system, one expresses the intervals  
abstractly like this, which is also what the staff system expresses:  
these algebraic relations. Then this leads to a matrix which should be  
inverted in order to get actual values for m and M.


So what I do is a generalization of this.

Rational numbers are not sufficient for the theoretically given:  
one must be

able to take roots, for example when computing meantone values.


Firstly, I repeat that the use of rational numbers would be  
algebraically
equivalent to integers, so this does not come to the theoretical  
discussion
here, it would be just convenient with regards to backwards  
compatibility.


Secondly, taking roots does not change the situation. You can  
represent

that just using one more integer in your representation for each root.

Finally, we are primarily concerned with notation here, so the fact  
that we
represent a sharp by +1/2 does not forbid you to write a midi  
engraver that
implements your favourite temperament (as close as midi can get to  
that).


I'm not sure exactly what model you have in mind, but this is mostly  
necessary in order to produce sound files, and possibly if one would  
want to impose algebraic relation, though for example E12 (12-ET)  
enharmonic equivalences can be introduced by adding/subtracting  
muliplse of M - 2m.


LilyPond has now 2^r, where is rational, thought that is not fully  
implemented for example for key signatures, which only accept E24.


So I extend this to 2^r_1 3^r_2 5^r_3 ..., which I represent as a map  
(associative array)

  (2, r_2) (3, r_3) (5, r_5) ...
Since one does not need to add these numbers, one mostly just has to  
add exponents.


This data type then includes not only the rationals, but also all ETs  
as well other systems like the Bohlen-Pierce scale.


So, for the exact given values, I added those roots. This suffices,  
as one
is never going to add the numbers of the intervals - interval  
addition
correspond to multiplication of numbers. The implementation  
representation I
chose was as a prime factorization - a map from prime numbers to  
rational
numbers. This seems to work well, as one is typically just working  
with a

few small prime numbers.


Oh, I see. That is actually what I was talking about in towards123  
when

I pointed the isomorphism between Z^(inf) and Q*, but that sounds like
unnecessary trouble to go with, even though it might look beautiful in
your Haskell code.


Yes, I think this may be a good candidate. The only practical problem  
would be if one would encounter a large prime, which would happen if  
say 

Re: flags, beams and stem length in forced directions - output improvement

[Janek Warchoł]

2010/12/31 Carl Sorensen :
>
> On 12/29/10 4:32 PM, "Janek Warchoł" 
> wrote:
>> I prefer B because it is the most balanced one - the 16ths don't look
>> cramped, and the 8ths don't look 'airy' when compared to 16ths
>> (especially the beamed variant. I think that beamed and flagged stems
>> of the same rhythmic values should have the same length, unlike the
>> current LilyPond behaviour).
>>
>
> I don't like the fact that the beam on the 8th notes lies at the same level
> as the space between the beams on the 16th notes in B.  That seems wrong to
> me.

That's funny, because currently LilyPond engraves beams of 8th and
16th notes just like that :) See the attachment, it was made with
default settings.

> Before we junk the existing engraving rules, I want to be sure that we have
> a *very* good reason for doing it.  I will grant you that flags were stamps,
> and they couldn't easily have lots of different flags.  But stems were
> engraved, and could be engraved to any desired length.

Yes... But maybe the differencies were too small for them to measure
and execute (despite being big enough to be noticeable for the eye)?
For example, we are discussing whether the stem on a middle-line note
should be 3.25 (B) or 3.33 (C) staff spaces long. The difference is
1/12 staff space, that's about 0.15 mm on the regular-sized score!
Human eye can see this difference, but i doubt any human would be able
to execute it consistently *by hand* (and within the limited time -
after all they didn't make one score per lifetime)! I suppose this is
the reason why engravers used more general rules like "the stem ends
should rise and fall with their respective noteheads" which worked
fine for them (perhaps also because printing technologies were less
precise back then).
Therefore, i think we can do even better then engravers in this area too :)
Nevertheless, i won't push it. Let's wait until more people give their opinions.

2010/12/31 Xavier Scheuer :
> I have a general thought, Janek.
>
> All the examples you show us are very simple minimal examples consisting
> of repeating the same note and/or scales.
> In real-life scores there is a melody and notes are usually going up
> and down (not randomly but you see what I mean).  Also we usually have
> a mix of beamed and unbeamed, sometimes mix of single voice / polyphony
> and I'm not sure your minimal examples take this into account.

Ok, it's a valid concern. Ideally i'd implement my solutions into a
experimental version and you'd test in on a large body of scores.
However before this can be done, what about you posting me some
examples and i'll manually tweak them to show how my proposals will
look in real life?
(preferably with the pitches in absolute mode).

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

Re: Can't get info and docs together - fixed

[Dave Plater]

On 12/31/2010 11:06 AM, Graham Percival wrote:
> Well, all the files that used to be in input/lsr/ are now in
> Documentation/snippets/ , and anything that was in
> Documentation/user/ is now in Documentation/notation/ .  However,
> when we changed the directories, various other things in the
> makefiles changed, so this might not help.
>
>   
This is very embarrassing, I had a 2.12.3 patch that removed
"$(foreach d, $(INFO_DIRECTORIES),$(MAKE) -C $(d) install-info && ) true" from
the "install-info-WWW:" section of the make file.
I now get identical documentation to the doc tarball. Thanks for the
links, I can get lots of usefull info from them.
Dave P

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

Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

2010/12/31 Hans Aberg :
> On 30 Dec 2010, at 23:16, Felipe Gonçalves Assis wrote:
>
> I made a proposal for a representation, and there is Haskell code available
> if you are interested.
>

Hi Hans. I would very much appreciate that code. I should remark
that your emails are what inspired me to start this. I take this opportunity
to thank you for everything.

> In it, the staff positions are expressed by a linear combinations of a
> sequence of seconds m, M, n_0, ..., n_k (whatever names you want to give
> them). If one only has a minor second m and a major second M, then sharps
> raise with the interval M - m and the flats lower with that interval.
>
> So I generalized this as to compute for any set of accidentals. The
> algorithm will depend on the typesetting preferences, but it is possible to
> compute them without any reference to pitches at all.
>

So, my idea is the same, except that I use the differences between the
seconds, so that the degree is just the coefficient of the major second,
and the calculation of accidentals is simpler (again, see notes on section
2.1 of towards123.txt).

>
> Rational numbers are not sufficient for the theoretically given: one must be
> able to take roots, for example when computing meantone values.
>

Firstly, I repeat that the use of rational numbers would be algebraically
equivalent to integers, so this does not come to the theoretical discussion
here, it would be just convenient with regards to backwards compatibility.

Secondly, taking roots does not change the situation. You can represent
that just using one more integer in your representation for each root.

Finally, we are primarily concerned with notation here, so the fact that we
represent a sharp by +1/2 does not forbid you to write a midi engraver that
implements your favourite temperament (as close as midi can get to that).

> So, for the exact given values, I added those roots. This suffices, as one
> is never going to add the numbers of the intervals - interval addition
> correspond to multiplication of numbers. The implementation representation I
> chose was as a prime factorization - a map from prime numbers to rational
> numbers. This seems to work well, as one is typically just working with a
> few small prime numbers.
>

Oh, I see. That is actually what I was talking about in towards123 when
I pointed the isomorphism between Z^(inf) and Q*, but that sounds like
unnecessary trouble to go with, even though it might look beautiful in
your Haskell code.

> But when working with inexact intervals, like in pitch bends or given s
> cents, etc., this proved inconvenient.
>
> So I added an inexact part, a floating point number (double). The
> representation is thus (r, x), where r is the exact number above, and x a
> floating point number. When x = 1.0, the representation is considered exact.
>

That is fine. But once more I remark that we are interested here in notation.
What you are attaining is to represent frequencies in a way that is virtually
always exact for music concerns (which looks quite promising, by the way).

Thank you very much for all the thoughts you have put in this.

Cheers,
Felipe

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

Re: Can't get info and docs together. was Building info with images in 2.13.44

[Graham Percival]

On Thu, Dec 30, 2010 at 01:29:45PM +0200, Dave Plater wrote:
> 
> In the 2.12.3 doc build "info/lilypond" was a symlink to
> "doc/lilypond/html/Documentation/user" and "info/lilypond-snippets" was
> a link to "doc/packages/lilypond/html/input/lsr" I've read through all
> the building documentation references I can find and am still in the
> dark. I did see this :

Well, all the files that used to be in input/lsr/ are now in
Documentation/snippets/ , and anything that was in
Documentation/user/ is now in Documentation/notation/ .  However,
when we changed the directories, various other things in the
makefiles changed, so this might not help.

> Maybe the person who
> compiles the documentation tar ball can let me in on the secret,

That person is me, but all I do is run the relevant scripts from
GUB.
http://github.com/janneke/gub

it's a huge build process, but the lilypond-specific stuff might
be more helpful:
https://github.com/janneke/gub/blob/master/gub/specs/lilypond-doc.py
https://github.com/janneke/gub/blob/master/gub/specs/lilypond.py

https://github.com/janneke/gub/blob/master/gub/specs/lilypond-installer.py
https://github.com/janneke/gub/blob/master/gub/specs/lilypond-test.py


Cheers,
- Graham

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

Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

On 31 December 2010 04:43, David Kastrup  wrote:
> Carl Sorensen  writes:
>
>> If we are going to move to a list for alterations, the list should probably
>> be rationals, rather than integers, in order to be most general.  Thus it
>> should most likely be (1/2 -1/4), rather than (1 -1).
>
> In that case, it would appear that "alteration" as a separate concept
> could be eliminated, and instead of pitch x with alteration (y z ...),
> we could just write (x y z ...).

That is a very fine idea! By the way, I look forwards to hearing more
advice on how to implement and organize things in Scheme, since
I am a beginner in that.

>
> It is just a pity that x is not (logarithmically) equispaced in physical
> pitch.
>

Hey, do not regret that yet! There is a simple procedure f such that
pitch (x y z ...) means exactly

x tones, (+ y (f x)) semitones, z whatever, etc.

This is what is actually implemented by class Scale. This does not change
much with the use of rational numbers.

You may enjoy checking function Pitch::transpose in lily/pitch.cc:142,
as well as the call to ly:set-default-scale in scm/lily.scm:387.

Cheers,
Felipe

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

Re: Towards a new pitch representation

[Hans Aberg]

On 30 Dec 2010, at 23:16, Felipe Gonçalves Assis wrote:


1. How should we represent alterations?

It is clear to me that the most general representation would be as
a list of integers of arbitrary length (see sections 1 and 2 of the
attachment).


I made a proposal for a representation, and there is Haskell code  
available if you are interested.


In it, the staff positions are expressed by a linear combinations of a  
sequence of seconds m, M, n_0, ..., n_k (whatever names you want to  
give them). If one only has a minor second m and a major second M,  
then sharps raise with the interval M - m and the flats lower with  
that interval.


So I generalized this as to compute for any set of accidentals. The  
algorithm will depend on the typesetting preferences, but it is  
possible to compute them without any reference to pitches at all.



1.1. How do we implement the mapping from alterations to tones?

A simple idea is to replace the list of integers by a list of  
rationals,

corresponding to the value of the alteration in tones. This is the
current approach, except for the fact that the list has length 1.


Rational numbers are not sufficient for the theoretically given: one  
must be able to take roots, for example when computing meantone values.


So, for the exact given values, I added those roots. This suffices, as  
one is never going to add the numbers of the intervals - interval  
addition correspond to multiplication of numbers. The implementation  
representation I chose was as a prime factorization - a map from prime  
numbers to rational numbers. This seems to work well, as one is  
typically just working with a few small prime numbers.


But when working with inexact intervals, like in pitch bends or given  
s cents, etc., this proved inconvenient.


So I added an inexact part, a floating point number (double). The  
representation is thus (r, x), where r is the exact number above, and  
x a floating point number. When x = 1.0, the representation is  
considered exact.



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

Re: Towards a new pitch representation

[Felipe Gonçalves Assis]

Hi,

>
> Are you using a two-element list, or a cons cell?  The two are not the same.
>
> I seem to remember looking in the code, and seeing scm_cadr calls, which
> implies that your alterations would be (1 -1), not (1 . -1).
>

In scheme I am using a cons cell, in C++ I am using a new struct with overloaded
operators. I was using the terms "list" and "pair" in an informal way. Sorry for
the confusion.

>
> If we are going to move to a list for alterations, the list should probably
> be rationals, rather than integers, in order to be most general.  Thus it
> should most likely be (1/2 -1/4), rather than (1 -1).
>
> Alternatively, you will need a property somewhere which is a list of the
> base units for each alteration, so that an alteration would be (1 -1), and
> the alterationMagnitude would be (1/2 1/4).
>

Right. In my patch this alterationMagnitude was sneaked in as new arguments
for make-scale. So, by redefining the default-scale, you get what you want
(see ly/makam.ly in the patch and dodecaphonic-adapted.ly in my previous
message).

As I said, if you are going to use only a finite number of rationals, you
can always accomplish the same results by using integers and scaling
them accordingly. This scaling is only used for things like midi and
ambitus. For transposition, and engraving, you only need the integers.

> In the current patch, you force all alterations to be lists (or cons cells,
> whichever you have implemented).  This will break lots of old scores.  It
> would be cleaner to allow alterations to be numbers (as they were in the
> past) or lists.  Then the old code would work.  Otherwise, you'll need to
> make a convert-ly rule which may be a bit tricky.
>
> I think that as long as you *allow* but don't require the extended pitch
> representation, it's likely to be very well accepted.
>

That is an important point. Below is what can be argued in defense
of this.

. For code that only uses 1/4 alterations, and does not redefine the
  default scale, convert-ly will be enough.
. The only snippet in the LSR that calls ly:set-default-scale is
  precisely dodecaphonic.ly.
. Integers are faster than rationals.

So, admittedly, this idea of using a list of rationals, simple as at is,
only occurred to me while writing towards123, yesterday.

If the community decides for that, I will start working on a new patch
as soon as the order is given.

So, unless someone comes up with a completely new idea, what we
have to decide is

a. Rationals or Integers?
ais. How many of them?

I look forward to hearing from you.

Cheers,
Felipe

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

Re: flags, beams and stem length in forced directions - output improvement

[Xavier Scheuer]

2010/12/31 Carl Sorensen :
>
> I think I agree, but this rule does not agree with the engraving books.  So
> if we go this way we're breaking new ground.  That makes me nervous.  I
> certainly wouldn't want to do this without get agreement from a larger
> number of the core developers.

Hi!

Sorry I'm not a guru of engraving practices, nor a core developer (not
even a developer).
But I have a general thought, Janek.

All the examples you show us are very simple minimal examples consisting
of repeating the same note and/or scales.
In real-life scores there is a melody and notes are usually going up
and down (not randomly but you see what I mean).  Also we usually have
a mix of beamed and unbeamed, sometimes mix of single voice / polyphony
and I'm not sure your minimal examples take this into account.

Hence the reference to engraving books and/or what reputable editions
do, simply because that's what a musician is used to (or should, since
we now find more and more poorly engraved scores using "famous"
proprietary softwares).

Cheers,
Xavier

-- 
Xavier Scheuer 

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