"We don't require this level of detail in music expressions for dynamic ramps."
You don't -- many other composers do. 11 dynamic markings (ppppp, pppp, ppp, pp, p, mf, f, ff, fff, ffff, fffff) allow a granularity of only 11 velocity levels, not nearly sufficient for complex ramps like the ones in Terry Riley's "In C." Likewise, inability to specify tempo changes as real numbers (from tempo 73.241 to tempo 74.856, for example) makes Nancarrowesque tempo changes impossible. For instance, if you want each note of a melody to speed up by 4%, at a starting tempo of 73, tempo of the next nite would have to be 1.04 times 73, which is a real number, not an integer The real number non-fractional tempo represents a workaround for the alternative multiple embedded tuplets -- viz. 104:100(104:100(104:100(104:100 ...))))) across multiple notes. Naturally Lilypond makes that impossible since durations are represented as integers, even 64-bit integers quickly run out of room to accommodate embedded 104:100 tuplets. We now pause for the usual explanations that no composer would ever want to do this, by programmers who don't write music. Finished? Good. Let's continue. As always, the entire focus of the discussion must center on why no changes can ever be made to Lilypond, and why every suggestion is either impossible or pointless. Zero energy for coding, but limitless furious frenzy explaining why nothing can be done.
