Am 07.11.2016 um 11:12 schrieb mclaren: > 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.
But definitely not exact enough. If you want to enter durations in the irrational time signatures you have presented you'll soon see that "any MIDI sequencer" will stop serving you much sooner than LilyPond. > > 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 That may be true, and that's the underlying reason why people on this list actually spend time trying to understand your cases, even when they'd never personally deal with them. > > 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. This is in every part of the statement utter nonsense. 1) It was *you* who started ranting away without any reason behind it. Actually your behaviour so far would warrant a ban from the lists IMO. 2) You bashed the software for failing at "ridiculously simple" tasks - while completely ignoring that there probably is not a single tool our there that would even allow you to fail at that level, because you couldn't even dream of getting near that level. This is not exactly the way to motivate voluntary users and developers to help you. 3) In the vast majority of your cases it was impossible to get to the source of the issue because your input files were blatantly incorrect, both with regard to LilyPond syntax and partially also with regard to the mathematical foundations. Still you bashed on the incompetent program and helpers. 4) As Andrew made clear you have pretty much completely refused to cooperate with us to find the source of your (potential) bugs. There are standard procedures which are in place for good reason (they tend to be the most helpful and direct processes to reaching a goal), and you were directed to them multiple times. Without your preliminary work of sorting out the problem fixes are not possible. Nobody will voluntarily dissect pages of input code where 30-70% are irrelevant to the issue and where there is a 50-80% chance that the input is wrong anyway. And yet you accuse us of making "zero effort"? Come on. 5) How do you think your "assumption" has proven correct? So far already numerous hours of user/developer time have (by now I feel: unjustifiedly) spent on trying to sort our your issues, sometimes even getting your input organized correctly. It is your lack of cooperation that has prevented us so far from identifying any actual bug, let alone fixing it. If you wouldn't be so closed into your own world you would notice that LilyPond is a program with a remarkably (if not exceptionally) short average report-to-solution time (be it a solution to document programming or actual bugs). > 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. Oh, wait a minute, do I understand this correctly: YOU want us to actually HELP you? Seriously, I don't get this, and I won't waste my time with you anymore. Which is a pity, because under your crappy input code and maths there *might* actually be buried some bugs or limitations that would be worth taking care of. And I would be careful with "Laughably Incompetent" remarks when you're throwing extremely complex tasks at LilyPond while not even having clear understanding about the difference between 7 * √71 and 7 / √71. > > 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. Hm. Wouldn't it be possible to make an exception and actually remove this person from the list? Urs _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
