Am 04.11.2016 um 03:29 schrieb mclaren:
> Hans;
>
> You mentioned:
> "LilyPond doesn't require all the barlines to align in order to be able
> to break a line, it only requires an arbitrary *moment* to align. If you
> have such a moment you can break lines, and the manual tells you how to
> achieve that."
>
> Sorry, no, the Lilypond manual does _not_ tell you how to achieve that. The
> Lilypond manual is a mess. If the Lilypond manual were adequate, there
> wouldn't be any need for a forum like this. The very existence of this forum
> shows that the Lilypond manual is disorganized, incomplete, and inadequate.
> I'm not the only person who has mentioned this. It's common knowledge, and
> uncontroversial.
Again: If LilyPond doesn't meet your standards go find a better tool.
>
> You go on to claim:
>
> "This clearly indicates that you have a timing error *within a single
> voice*, which obviously stems from the fact that 800/898 don't match
> 735/713. One measure is 0,890868597 whole notes long and seven eight
> notes stretched by 735/413 equal 0,921610169 whole notes."
>
> Now we're getting to the real issue. You assert that one measure of 7
> sqr(71) is
> 0.890868597 whole notes long. Sorry, that is incorrect.
Of course it is incorrect. The point is that *your* file pretends it with
\set Timing.measureLength = #(ly:make-moment 800/898)
And *you* are stretching notes by 735/713 with
\scaleDurations 435/413 {
And these two settings don't match. This is why I suggest *you* are
doing the maths first. This wouldn't match even if your basic assumption
about the length of a measure were correct.
>
> Let's do the math:
>
> The length of one measure is 7*square root of 71. Let's do this one
> step at a time so there's no mistake. Square root of 71 = 8.42614977318.
> 7 of these makes 7*8.42614977318 = 58.9830484122.
>
> Agreed?
No.
> You can check on your calculator or by typing this stuff into
> WolframAlpha or google.com
> to verify that this is correct.
Your calculation is correct. But to verify this it is actually more
useful to use LilyPond's capabilities itself. Especially as it offers
tools to actually work with fractions instead of floats.
But what I don't agree with is your basic assumption. The length of one
measure is *not* 7*square root of 71.
The length of a measure is in fact 7 times 1 /divided/ by square root of 71.
If you have \time 7/8 the length is 7 * 1/8, in \time 7/9 it is 7 * 1/9,
and in \time 7/√71 it is 7 * 1/√71.
This can be conveniently expressed in Scheme as
(* 7 (/ 1 (sqrt 71))) => 0.830747160735697
You can actually express that as a proper rational fraction:
(inexact->exact (* 7 (/ 1 (sqrt 71)))) => 58458634430131/70368744177664
You can easily verify that by comparing this result to the length of a
7/8 and a 7/9 measure (your measure length should be in between):
7/8 => 0.875
7/√71 => 0.830747160735697
7/9 => 0.777...
So consequently all your following calculations are moot.
>
> If square root of 71 has a value of 8.42614977318, and a single eighth note
> has a value of 8,
> then logically 7*8.42614977318 = 58.9830484122 while a whole note contains 8
> eighth notes,
> so a whole note = 64
> .
> This means that the ratio of 7/sqr(71) to one whole note is given by
>
> [7*8.42614977318]/(8*8).
>
> Are you with me so far?
I am following you but you're on the wrong track.
> You can verify this with a calculator or with
> WolframAlpha.
>
> [7*8.42614977318]/(8*8) = 58.9830484122/64 = 0.92161013144.
>
> You asserted above that "seven eight notes stretched by 735/413 equal
> 0.921610169 whole notes."
This is of course correct. But irrelevant as it doesn't even closely
match the length of a measure.
>
> That is correct. Please compare 0.921610169 whole notes to 0.92161013144
> whole notes, the actual value of 7*sqr(71). As you can verify, they are very
> close, to within a couple of parts per million. To be exact, the difference
> between 0.921610169 and 0.92161013144 is 3.756 parts in 100 million.
But in music we actually calculate with fractions, and therefore
floating point numbers are inappropriate for this kind of things.
>
> This is as close as I could reasonably come using rational approxmation.
> Lilypond crashes and gives me an error message if I try to use a rational
> fraction with really large numerators and denominators, in the tens of
> millions or hundreds of millions, so as a practical matter, we must stick
> with rational fractions which are in the hundreds or tens of thousands to
> approximate these irrational values.
>
> As an aside, I would say that yes, it is crazy to arbitrarily limit the
> value of the Lilypond moment to rational fraction approximations. Why not
> just allow floats? What's the problem with that? Why must a moment be a
> rational fraction? Why can't it just be a floating point number?
Because no one has ever considered thinking musically like this.
I don't want to argue that it is nonsensical to allow such a thinking
(because that would actually be the line of argumentation of those who
say that already 1/6 values are nonsensical). But if a program does not
support such a way of thinking it's totally inappropriate to call that
"crazy".
>
> In any case, let's return to the issue at hand -- which is your claim
>
> "One measure is 0.890868597 whole notes long."
NO. YOUR FILE CLAIMS THAT:
\set Timing.measureLength = #(ly:make-moment 800/898)
> You are incorrect, sir. One measure of 7 sqr(71) is 0.92161013144 whole
> notes long. You can check my math above. You will find that my arithmetic is
> correct.
Well, I have sufficiently shown that you have started right from a false
assumption. No use having correct arithmetic then.
>
> If you are saying that one measure of 7 sqr(71) is 0.890868597 whole notes
> long, that's simply not right. If Lilypond is saying one measure of 7
> sqr(71) is 0.890868597 whole notes long, that's also not right.
>
> You can follow through and veryify my math at each stage. I haven't made a
> mathematical error. Lilypond is misbehaving.
Bullshit. Sorry to become impolite but that privilege shouldn't be
completely on your side.
>
> When you say "As long as you haven't got this sorted out there's not point
> in discussing" you're just wrong. I have got the math sorted out and you can
> verify at each step that my arithmetic is correct.
>
> It sounds like you don't know how to get Lilypond to force page breaks in a
> score like this, and I think I can prove it.
>
> 0.890868597 is approximated by 400/449 to an error of 53 parts in 449
> billion. So I entered 400/449 into the make-moment command instead of the
> values I was using.
>
> And guess what, Hans?
Ah, BTW, you might start with reading properly who you're communicating
with.
>
> Lilypond _still_ won't create a page break. No wonder, of course --
> 0.890868597 whole notes is the wrong value for the length of a measure in
> whole notes, way off from the actual length of a measure of 7 sqr(71), which
> as we calculated above is 0.92161013144 whole notes long.
>
> Aside from the arithmetic errors in your answer, your reply seems like a
> complicated way of saying "I don't know how to fix your problem with
> Lilypond."
>
> In future, you may just want to say "I don't know how to fix your problem
> with Lilypond," Hans. It's a lot simpler.
You know what? Just fuck off. I had done the math even before your
reply, only to realize that your file is completely messed up because
you obviously don't even understand how expressions have to be nested in
LilyPond. Before these basics are working there *really* is no use
bothering with complex polymetrics.
>
>
>
>
> --
> View this message in context:
> http://lilypond.1069038.n5.nabble.com/Can-t-get-page-breaks-for-7-over-square-root-of-71-meter-tp196099p196114.html
> Sent from the User mailing list archive at Nabble.com.
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
