lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solution to 7 over sqr(71) time against integer polyrhythms


From: Urs Liska
Subject: Re: Solution to 7 over sqr(71) time against integer polyrhythms
Date: Wed, 16 Nov 2016 09:58:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


Am 16.11.2016 um 07:29 schrieb mclaren:
Nice try, but so obvious I already tried it long ago -- remove the timing
translator and default barline engraver from the Score portion of the layout
and insert it in the Staff portion.  Nope.  Doesn't work with my score. 


"Doesn't work with my score" is something completely different than "Lilypond seems designed to prevent engraving barlines whenever they aren't required by the score. This is bad program design"

The second statement is clearly wrong while the first statement points the finger to yourself. There are established procedures to notice, track down and report bugs in the program, and they usually work out very well as long as they are applied by people with a minimum of social skills.

First you have to sort out your score. Compilation gives a barcheck error which clearly indicates an error in the input file. And as long as you have barcheck errors you can't expect anything to work properly with regard to barlines and line breaks. It should be clear even to you that this isn't something you can blame LilyPond for.

And it's totally clear that you're messing with things you're not up to. I started to look at the file (from the original post on this thread) and stopped very soon because it's not worth digging deeper.
1)
It has been pointed out to you that approximations, be it rational or floating point, are not appropriate when dealing with measure lengths. "Close enough" is not a category in these calculations when you have a program that actually deals with semantic structure. You can notate "close enough" with a drawing program or a pencil, if you need to. Everything else inherently involves ugly hacks.

2)
You start the top staff with \time 7/8, which tells LilyPond to expect a measure to be 7/8 of a whole note long.
Then you wrap your content in \scaleDurations 435/413 {}, which is by all means simply wrong.
With this you tell LilyPond that you will write 7/8 * 413/435 - or rather a total of 2891/3480 - of music to fill one measure. But what you are *actually* writing is plain eight and sixteenth notes, which will never sum up to X/3480.

3)
If you had made use of barchecks - which would have been the *very first thing* when dealing with complicated metric matters - you would have received a "barcheck failed at: 4957/85904" immediately after the first measure. This would have given you a first hint to track down the problem.
Making barlines transparent is clearly not a cure but tampering with the symptoms.

4)
You didn't even \remove "Time_signature_engraver" and "Timing_translator" from the score context, so *everything* else doesn't even get a chance to work out properly.

And this was only starting the analysis (which I won't pursue any further).
It is completely obvious that you are constantly trying to achieve things that are over your head. This results in completely messy code, especially after fiddling around trying to make symptoms disappear.
You are behaving like someone who has only directed RC boats so far and finds himself sitting in the cockpit of an actual Airbus - and then rants that this crappy piece of engineering won't let him even perform such trivial tasks as a proper take-off in a blizzard. (The latter refers to the fact that you are trying to make LilyPond do stuff that it hasn't been conceived for (as has been pointed out). So rather than complaining it would be more appropriate to stand in awe about how far LilyPond actually takes you.)

By the way: Did you ever *look* at the score you produced? If you have any understanding of musical maths you must notice that the four voices completely don't align according to their given time signature. This is one more strong indicator that your input is fundamentally wrong.



By all means, keep spending all your time and energy attacking people who
point out these bugs. And I'll spend all my time and energy finding
workarounds for these bugs in Lilypond.

Nobody is "attacking" you inappropriately, and you can't claim to "point out bugs". So far we have seen only one case where LilyPond actually shows a limitation in its ability to deal with huge rationals in tuplets or time signatures.
Most of the noise you are imposing on this list is caused by the fact that you don't know what you're talking about or rather how LilyPond works. I can only second Kieren's comment so far.
As David Kastrup pointed out it isn't a sin in the first place not to know what one talks about. But insisting on continuing on that track and relentlessly insulting the people you are actually approaching for their voluntary help, is really crazy.

You are obviously lacking the most basic social skills, and it's a miracle that *anyone* on this list is still reading your posts. I think this is something like the car accident behaviour where people just can't stop looking at it. In this case people seem to be just fascinated by the sheer monstrosity of your behaviour.
Which is a pity because I'm sure many of us would have rather been fascinated by the *topic*.

Urs
(trying to make this really a last time bothering with the matter).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]