David Wright remarked: "What I can't understand is why you would want to print out a score that is basically impossible to play, and is, in any case, written in a notation that is debatably incapable of expressing it."
This score might be impossible for _humans_ to play. That doesn't mean that the score can't be played. It can be entered with trivial ease into a MIDI sequencer, and a MIDI sequencer can play it without any trouble at all. In fact, the big dichotomy here involves the huge gap between how easy it is to enter this kind of score into a MIDI sequencer, and how nearly impossible it is to generate this kind of score using a computer-based music notation program. To enter this kind of score using a MIDI sequencer, you simply choose STEP ENTRY and then figure out the number of ticks of each tuplet. In the case of an 11:9 eighth note, for example, if the timebase is 480 ticks per quarter note, then an 11:9 eighth note is 9/11*(240) = 196.3636 ticks. To round things off, add an extra tick every three 11:9 eighth notes. You can enter this entire score in just a few minutes using this method with any MIDI sequencer. It's ridiculously easy. Musical scores have two functions: analysis and performance. When electronic instruments and electromechanical devices like the Disklavier piano from Yamaha appeared, the combined function of analysis + musical performance split into two separate streams. One of the earliest examples of such a score is Mikel Rouse's Quorum (1984), a polyrhythmic piece for the Linn Drum Machine. You can get Quorum on iTunes here: https://itunes.apple.com/us/album/quorum-remastered-quorum-music/id264549486 More recently, composer Kyle Gann has produced nearly an hour of polyrhythmic microtonal piano pieces for the Yamaha Disklavier. You can hear them, and study the scores, here: http://www.artsjournal.com/postclassic/2016/08/another-do-it-yourselfer.html David Wright went on to mention: "I've also not met many people who enjoy making programs crash and yet don't seem to be interested in exactly why they crash under those circumstances. In my day, I loved working with people who used my software in ways far beyond the capabilities I had designed into it, and when they ran into problems, we would work together on improving the design or implementation for their benefit, and for future users." Given the acid contempt with which I've been treated, my working assumption as a musician is that Lilypond programmers will make zero effort to fix any bug in the Lilypond program, and so far my assumption has proven correct. Experience shows that programmers are usually distinguished by their ignorance and incompetence, and spend far more time denying that any bugs exist than actually correcting them. Experience suggests that LISP stands for "Laughably Incompetent So-called Programmer." If you want to add 2 + 2 and get 3, give the problem to a LISP programmer. Fifty percent of all large programming projects in any language end in failure. Computer "science" is still in the dark ages, at the level of alchemy or the phlogiston theory of heat. Anyone who expects a programmer to actually help fix any bugs in a large program is badly deluded, and as a result, all end users must expect to be ridiculed, disdained, sneered at and jeered at by programmers whenever they report a bug in a large program. Thus end users must go it alone and find workarounds for themselves. Programmers will never lift a finger to help you when things go wrong. Instead, the programmer will typically blame the victim: "Oh, the program is supposed to work that way. That's a feature, not a bug." Or: "You shouldn't want to do that, no user would ever want to do what you're doing." Musicians must develop a very thick skin and learn to expect this. The crucial issue is to get a score, by whatever means possible, and then move on. Practicing musicians quickly learn to regard programmers as a form of damage and route around them. -- View this message in context: http://lilypond.1069038.n5.nabble.com/Two-different-time-signatures-with-different-tuplets-in-em-tp196202p196256.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