Once we recognize the need to hear the same drum-type PLAYED using a limited selection of different kinds and levels of attack, we naturally ask next: How and to what extent these gradations can best be DISPLAYED in the pattern-editor, without compromising the usability and economy of our notation system. Apropos, it's tempting to offer a few off-the-cuff observations: 1) Not everything that is played needs to be displayed--at least, not on the same screen view. 2) To notate any kind of music always implies reduction, i.e., leaving out a whole lot of what the performers (or the computer) must then put back into the intended audible result. 3) Only a notation that is simple, logical, and easy to learn will be used by a lot of people to WRITE with. A complete specification of the actual sounds desired is of course needed at some level somewhere along the line, and a few of the more ambitious early computer music languages actually proposed using such a thing as the ideal composing tool of the future. Thank goodness Doggiebox doesn't, and in my view shouldn't. 4) A typical late-19th-century orchestral score goes pretty far in attempting to show (albeit in highly relative terms) almost every significant parameter, employing dozens of different systems of representation in the process, including Italian words, letters, diacritical marks, trills, numbers, and so on. Computers, on the other hand, can switch quickly among alternate representations of the same "score" so easily that we have become used to a multiple-screens approach, allowing each particular, single-purpose view to be simpler to read, less cluttered, and far easier on the eyes. But any kind of readable "score" must still be a far cry from an actual "performance", whether in the realm of live or of digital percussion. 5) The crucial question then becomes: How much can we afford NOT to see? How LITTLE by way of graphic support can we manage to work with in capturing our musical ideas? -Sterling Beckwith