Re: Two different time signatures with different tuplets in 'em

[Urs Liska]

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