David Kastrup remarked:
"Music is not a video game."
That's true. Video games must work in real time. Lilypond doesn't have to
work in real time, meaning that it should be much easier to code for
Lilypond than for the typical video game. Yet we're seeing the kinds of
problems in Lilypond that don't happen in videogames, a far more demanding
environment. To take a specific example: reflecting objects facing one
another require a theoretically infinite number of calculations to render
properly. In reality, video game programmers work around this problem with
kludges involving precalculated renders and reflective estimates and they
manage to get a reasonable approximation working in real time. They do not
do it by brute-force calculation integer fractions to a very large power,
because they know better. That stuff just won't work. You must make do with
approximations.
David Kastrup went on to aver: "LilyPond needs to know whether two events
line up in time (only then are they aligned or have a common stem, and only
the first such event gets an accidental and so on). Once arithmetic does no
longer guarantee
1/3 + 1/3 + 1/3 = 1
it becomes impossible to reliably synchronize matters."
This is just not correct. It's not even close to being correct. In fact,
it's so far off from the reality that it's baffling that David Kastrup would
make this claim.
Lilypond only needs to know whether two events line up in time for MIDI
output to the nearest (time signature / 960 parts per quarternote). The most
typical time signature is 4/4, and the highest current time resolution
supported by MIDI appears to be the 960 ppq used in Logic and Cubase. So
the finest time resolution MIDI currently allows is 4 seconds/(4*960) =
0.001041666... seconds, a little less than a millisecond worth of time
resolution. This makes sense, because as a matter of practical reality, the
best hardware/software MIDI resolution allowed by any computer platform is
the ~ 1 msec of MIDI jitter found on the old Atari ST. Apparently the new
Logic 8 software from Apple running on a recent Intel Mac with the proper
MIDI interface will rival that 1 msec MIDI jitter. But about 1 msec of MIDI
precision is as much as the current hardware + software (sequencer +
operating system) allows, so it's really pointless to try for MIDI timing
resolution better than 1 msec.
This means that Lilypond only needs to know or care whether events line up
to within about 1 millisecond in time for MIDI purposes. Calculating
Lilypond sychronization to any finer value for the pursposes of MIDI is
utterly pointless.
For engraved output, a reasonable visual maximum resolution would be tabloid
output = 11 x 17 inches with 1200 dpi. Since there are 16.5 printable
inches horizontally on a tabloid sheet, 1200 dpi * 16.5 inches = 19800. So
for purposes of engraving, Lilypond only needs to know or care whether two
events line up to within (say) 1 part in 40,000. That's a precision of
twice what you need for even the most fine-grained printed output on tabloid
paper.
So let's figure Lilypond needs to know whether events line up to within one
part in 40,000. Shoot, let's be generous, a part in 100,000. That means
that as long as 1/3 + 1/3 + 1/3 = something in between 0.99999 and 1.00001,
you're fine. In fact, 1 part in 100,000 is so much better resolution than
you need for printed output (5 times better) that even in the extremely
unlikely event that you multiply errors and get, say, 10 times worse
precision than assumed, you'll still only be off on lining musical events by
1 pixel out of 1200.
Can you see a 1-pixel horizontal alignment error at 1200 dpi on a printed
tabloid-size score? I doubt it. Mechanical offset printing presses often
exhibit such errors, and no one complains -- you find these kinds of
mechanical printing errors all the time, but no one is unable to recognize
an illustration because of such trivial errors. In fact, it's reasonable to
assume that with mechanical backlash and other mechanical sources of
imprecision in the physical laser printing process, it's very likely that
the mechanical jitter and laser printing error will probably be somewhere in
the ballpark of 1 pixel out of 1200 dpi. So requiring more precision than
that for printing is likely pointless as well as burdensome.
For SVG output, you are only going to see a difference if you enlarge the
vector output by a factor of 20,000. That would require enlarging the
musical score to the size of a football field. Surely we can discount that
possibility.
David Kastrup goes on to claim: "You can't tell a musician `10000 beats, and
you are out since then our fixed point numbers overflow.' Or `10000 beats
and you can't use triplets any more since then our floating point numbers
get too grainy.'
"For better or worse, written music requires exactness to work reliably."
That just doesn't make sense. You're talking about cumulative error here,
not about synchronization. A floating point error buildup will eventually
add or subtract tiny bits of time to the start time of a note compared to
the very beginning of the score, but will not audibly or in any other
meaningful way affect the synchronization of notes, as long as you maintain
accuracy to within 1 part in 100,000.
To see this is true, just do the math. 10,000 beats at a sprightly tempo of
mm = 120 means 10,000 * 1 second per quarter note at mm = 60/ 120 = 5000
seconds, which adds up to 1 hour and 23.4 minutes. So after about an hour
and half of continuous music, in this example David Kastrup is saying you
may be off by some very small value in the start-time of a note as measured
from the beginning of the piece. But who can possibly hear this? No one
hears that kind of absolute timing, people hear relative time to the notes
around the note that's currently sounding. And as long as you maintain an
accuracy of 1 part in 100,000, you can't possibly be sounding simultaneous
MIDI notes that are not synchronized by any more than 1/10 of the actual
MIDI jitter (~ 1 msec) found in the best hardware/software MIDI
sequencer/computer combos.
If what David Kastrup were saying was really true, the ~ 1 msec of MIDI
jitter found in the very best computer + MIDI interface setups would make
musical listeners run from the room screaming because of the horrible lack
of synchronization, since MIDI notes only synchronize by at best 1
millisecond. But no listeners hear this 1 millisecond accuracy as a problem.
That's because human hearing isn't accurate enough to be able to detect when
two musicians sound a note one millisecond apart rather than exactly
simultaneously.
In fact, what David Kastrup claims were true, no symphony orchestra or
chamber ensemble could ever play music. The reality of music performed by
real musicians in the real world is that acoustic events that occur within a
couple of milliseconds of one another sound simultaneous. This was
determined quite a while ago, along with the finding that musicians using
variable-pitch instruments typically can't get any closer than about 15
cents to the pitches they're supposed to be playing, and in the real world
even the most highly-trained symphony orchestra musicians often sound
pitches as far off as 50 cents, yet are heard as playing "in perfect tune"
by other highly trained musicians. All this falls under categorical
perception, a very well-known area of cognitive science. Without categorical
perception, humans couldn't function. We perceptually discount small
difference in sensory input and sort perceptual inputs into mental
categories in order to function. Thus listeners discount region accents
when listening to speech, they don't hear microscopic differences ~ several
milliseconds in the onset of putatively simultaneous musical notes, and
people don't notice small differences in color tone in photographic
reproduction or computer or television monitor displays compared to the real
colors.
So it's perfectly clear from the 150-year-plus history of psychoacoustics
and cognitive psychology that what David Kastrup is claiming cannot possibly
be true. In reality, there's lots of slop and error and the human ear/brain
system's perception of musical timing, just as there is lots of slop and
error in the human eye-brain system's perception of color, and so on. None
of this matters as long as we get close enough for perceptual purposes. And
the science on the limits of human auditory and visual perception was nailed
down very solidly many years ago. 24 frames per second was decided upon as
the standard for motion picture projection because even back in the 1930s it
was well known that visual events 1/50 of a second (20 milliseconds) apart
were perceived as visually simultaneous, so a motion picture projection
system with about half that resolution was good enough for all practical
purposes. Likewise, it was determined long ago that for purposes of musical
timing, a MIDI keyboard scanning rate of about 1/10 of a millisecond was
good enough to capture all the perceptual nuances of a live musical
performance. And so on. None of this stuff is new or controversial. The
perceptual limits of the human ear and the human ear are well known and old
news.
So as long as you maintain a precision of 1 part in 100,000, which should be
easy to do in Lilypond even with floating point, you are going to be just
fine perceptually. There's nothing novel about this statement. It's not
controversial. It's perfectly well documented in the psychoacoustic
literature going back to the 1930s.
You can see a summary of research on human perception of time here:
http://www.sciencedirect.com/science/article/pii/S0928425711000349
And a precis of recent research on the perception of musical time in this
article:
http://nautil.us/issue/9/time/how-music-hijacks-our-perception-of-time
For a pretty good summary of the research done over the last 100 years into
the musical perception of time, see the book "Music in Time: Phenomenology,
Perception, Performance (Harvard Publications in Music)" edited by Suzannah
Clark and Alexander Rehding.
https://www.amazon.com/Music-Time-Phenomenology-Performance-Publications/dp/0964031760
None of this peer-reviewed published research suggests that exactitude plays
any role in the perception of musical synchronization. On the contrary,
human perception of music is pervasively INexact: we do not hear frequency,
we hear pitch (which is often perceived quite differently from frequency --
listen to the well-known Shephard Tone if you don't believe me:
https://www.youtube.com/watch?v=BzNzgsAE4F0 ); we do not hear amplitude,
rather, we hear loudness (which are quite different depending on the
frequency of the pitch involved, as witness the well-known Fletcher-Munson
curve). We do not hear exact synchronization of musical notes nor do we hear
precise interonset timings, rather we hear notes perceived as sounding at
the same time when they really don't, and we hear a general tempo despite
persistent (and often expressively large) microvariations in the note
interonset times. Bruno Repp has done vast amounts of research about the
perceptual interaction of tempo and interonset note timing in actual music:
http://mp.ucpress.edu/content/19/4/565. Peter Desain authored a classic
paper "Tempo Curves Considered Harmful" back in the 1980s:
http://cf.hum.uva.nl/mmm/papers/dh-93-f.pdf
All these research findings converge on the conclusion that exactitude is
the enemy of good musical performance. In a good musical performance, timing
varies according to hierarchical categories which mirror the structure of
the music itself, so that inter-note timing varies considerably over the
course of the musical performance in ways that bring out the basic phrasing
and formal structure of the music. Recent cognitive neuroscience research
using techniques like fMRI has confirmed this by producing rhythmograms that
square with the predictions of Lerdahl and Jackendoff in their 1983 book "A
Generative Theory of Tonal Music." See the neuroscience research summarized
here: "The neural processing of hierarchical structure in music and speech
at different timescales," Front Neurosci. 2015; 9: 157, May 2015.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4429236/
Exactitude plays no role in any of this musical perception.
MIDI has a lot worse timing resolution than 1 part in 100,000, by the way.
The earliest MIDI sequences start out with a timing resolution of 24 parts
per quarter note. Yet Mikel Rouse wrote his polyrhythmic piece "Quorum" for
the Linn Drum Machine in 1984 using a timing accuracy of 24 ppq. You can
download Quorum from iTunes and listen to it. It sounds fine. There are
problems with timing despite the miserable timing resolution of 24 ppq,
despite all the complex polyrhythms Rouse uses. Why? Because the human
ear/brain system uses categorical perception, and when we hear 5:4 or 9:8
even in the miserable 1980s-technology timing resolution of 24 parts per
quarternote at a tempo of mm = 120, we don't have any problem with the
timing because our ear/brain system automatically discounts any tiny timing
errors because we know what the composer means. It's exactly the same as
small deviations from exact timing in music performed by live musicians.
Once again, we don't notice or care about the timing deviations due to
categorical perception.
David Kastrup went on to assert:
"There are deliberate reasons and tradeoffs involved in LilyPond's design.
There may be some programming mistakes, and some of the reasons and
tradeoffs might be based on history that is no longer immanent. But all in
all, there is a reason for everything that cannot even remotely be
characterized as `people just weren't as smart as mclaren or they'd have
done it better.'"
No one ever said I was smarter than anyone else, certainly not me. Smart
isn't the issue. The problem is that if you use fixed point to represent
moments, you're very quickly going to run into overflow problems even with
common musical examples, like relatively prime tuplets (which crop up all
the time in real music). If this wasn't obvious in the design phase of
Lilypond, it should have been. Figure out the least common demoninator of
say, 10 different tuplets like 5:3, 7:4, 11:9, 13:12, 17:16, 23:19 and so
on, and you'll find that least common denominator quickly grows large.
Likewise, nested tuplets with any values beyond very small values like 4:3
will quickly grow large for the obvious reason that you're taking ever high
powers of that tuplet. So 20 nested tuplets of 4:3 wind up requiring a
calculation of (3/4)^20, whereas for larger tuplets like 100:99, 20 nested
tuplets requires a calculation of (99/100)^20. A simple back-of-the-envelope
calculation you can do in 30 seconds shows that s^64 is in the ballpark of 1
x 10^19, so using fixed point to represent durations in Lilypond will blow
up if you get 20 nested tuplets.
Is it reasonable to limit Lilypond to less than 19 nested tuplets? I guess
you could argue that it is, but that doesn't sound reasonable to me. Surely
you wouldn't want to kind of limitation to get baked into the program code
if you could help it, would you?
Kastrup then asserts:
"If you want something done, do it. You are of the opinion that you can do
better than those who worked so far on LilyPond, do it. Don't beat your
chest, do it."
Now we've got a contradiction. This entire forum exists presumably because
the attitude of the Lilypond designers was NOT that anyone who had a problem
with Lilypond crashing or hanging should just go off somewhere and hack the
millions of lines of source code. If that's really the philosophy behind
Lilypond, this forum should shut down right now and post the following
message:
IF YOU ENCOUNTER ANY PROBLEM OR CRASH OR PROGRAM HANG WITH LILYPOND, FIX IT
YOURSELF. DON'T BEAT YOUR CHEST COMPLAINING, JUST DO IT YOURSELF.
Somehow I don't see that message being sent. Instead, there's a recognition
that Lilypond is a piece of code that may have limitations. And those
limitations may affect real musicians in the real world. So you've got a
community of people who will try to help out when someone encounters a
problem.
The fact that this forum exists seems a clear refutation of David Kastrup's
assertion that if anyone encounters a problem with Lilypond, they should
just rewrite the code themselves and shut up about it.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Solution-to-7-over-sqr-71-time-against-integer-polyrhythms-tp196671p196983.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
