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

[David Wright]

On Mon 07 Nov 2016 at 03:12:15 (-0700), mclaren <address@hidden> wrote:
> 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.

I wasn't aware that anything other than humans played from
conventional scores. Machines use pins, punched holes and, lately,
MIDI files.

> [...] 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.

> [..] You can enter
> this entire score in just a few minutes using this method with any MIDI
> sequencer. It's ridiculously easy.

In other words, what you are saying here is that it is easy to define
the music's essential pitches and durations, but a struggle to notate
it in conventional scoring. I don't disagree.

> 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.

What I think you're saying here is that the score is now used only for
analysis, and the performance is generated by using the compositional
parameters with which you just programmed your MIDI sequencer. That's
may well be correct.

> 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

(...of which I downloaded Orbital Resonance.)

Well, the scoring doesn't seem to help much with analysing the pitches
(the introduction does that better) nor with displaying the simple
rhythms with which the piece opens. Through much of the piece, the
barlines serve merely to complicate printing the rhythms. So I'm left
wondering if a conventional score is the best way of displaying this
sort of music for analysis, or whether one could invent some better
forms of diagram to represent it.

> 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.

I guess you have some problems which are far more serious than those
that arise when playing about with LilyPond or posting here.

Cheers,
David.