[Coco] Re: [Long] [OT] That Big Shadow Over Your Shoulder, Part 2,

[Dennis Bathory-Kitsz]

I hope folks aren't minding these long discussions. I'm enjoying them
(especially with John's knowledge and articulate manner, and Alex's strong
opinions)! It goes to our ways of working, and for me, it goes to the
reason I once used the CoCo and other earlier machines and, of course, why
I no longer do. It also goes to the needs of specialists vs. generalists,
and how a public drags along technology in directions that are neither
expected nor always comfortable.

At 07:37 AM 3/1/04 -0500, John E. Malmberg wrote:
>In 1997, I was at a Microsoft TechED conference.  One of the Microsoft 
>session presenters stated that according to their surveys, notepad was 
>the most popular way to build HTML web pages, in spite of all their 
>efforts to provide GUI tools for this.  I do not know if that has changed.

It has changed.

Use of scripting, style sheets, and other features has become very
widespread, and these are increasingly difficult to do without a GUI (and
often automated page-generation tools), unless you're a crack scripting maven.

This change has resulted in a period of serious problems in page size,
display expectations, handicapped access, and browser rendering. The
inclusion of plugin-based main content (not supplementary content) such as
Flash has seriously damaged device-independent interchange and rendering.

It's not a bad trend, really, because chances are it won't continue too far
into the future in its present shoddy condition. It's just immature and
creates improper expectations for the amateur page author (which covers the
majority of page authors), and even problems for those of us who will
shortly celebrate 10 years of hand-editing HTML and would *love* to migrate
to a decent GUI tool for page design. (The only tool that comes close is
Dreamweaver, but that's out of my budget, and it prefers table layout to
stylesheets.)

Web pages aren't WYSIWYG, and never were intended to be. But many of these
products treat website creation as if it were making a brochure. From Page
Mill to Front Page, we've seen a string of products with great design tools
and terrible HTML output.

This is another discussion, of course. :)  Web 'pages' aren't pages at all,
but rather a manifestation of the content. If you don't see, you can use
Braille output. Or, like me, you can use speech output -- not that I can't
see, but I sometimes prefer to be working on something else while my pages
are read to me. Others expect the same pages to display on their Palm
Pilots or be heard (or seen, now) on their cell phones.

As for hand-editing the pages, I do that in a clean, Notepad-style editor
called "Webber", whose last build was (alas) in 1997. Webber has some help
and validation, but what it has that distinguishes it nicely from Notepad
is that tags are displayed in color (one color for start tags and another
for end tags), it has the ability to turn line wrap on and off, you can't
backspace or delete over a facing angle bracket, and it has tag matching. I
can edit quickly, so long as the page hasn't been previously clotted up
with stuff by some pseudo-WYSIWYG editor that adds spaces and carriage
returns.

My Kalvos & Damian site (http://kalvos.org/) is one of nearly 30 domains
that I do by hand. This one is going over the edge as far as maintenance,
though, because it is some 1,500 HTML documents now (the other 4,500 are
media -- graphics, audio, video). The pages are stylesheet-based, which
means I can easily change how they look by editing one document. And
there's lots of common content, so I can search/replace edit that part. But
it's still a bear, and could use a nice database for the 7,500 playlist
entries. :O

But I can't do XML by hand, don't know databases, and those are the next
steps for my sites. HTML will be fading like manual typewriters (or all
typewriters!), and that means it will be time for a serious GUI editor.

>Apparently there are still some things that these tools can do that GUI 
>based ones can not.

A qualified yes to that. Musical scoring is a very good example of a
difficult GUI product to build, because it has several purposes that need
to be met by a modern package:
1. Composition
2. Notation
3. Engraving
4. Parts
5. Printing
6. Audio

The TeX-style packages are very good at accomplishing #3 and #5, but it's
necessary to learn the language to do it. The best part of the
text-descriptive languages is the arbitrary nature of what they can do, and
this applies to creating newer scores. Because TeX (and related) packages
are not really *scoring* programs, but just one variant on making
text/images of any kind, it is possible to include arbitrary symbols and
graphics that are not part of any font.

On the other hand, there's not much good to a music scoring program that
doesn't actually do any music or much scoring. I expect a scoring program
to do all the items on the list (and probably more I didn't think of on the
spur of the moment).

==Composition (entering musical information by alphanumeric keyboard, by
scanning, by tablet, by musical keyboard, etc.) and being able to change
one's mind on the fly. An effective composition front end must have the
editing of every item as desired, and a hundred or more levels of undo,
plus undo history. In other words, a 3D word processor.
==Notation by conversion from these other entry methods and its proper
spacing, respelling (if necessary), error checking, and default conditions
(key, meter, transposition...), microtones, non-European notations, modern
notations, and the use of all 600 standard musical symbols, along with the
ability to include any of the other 2,000-plus notational symbols from the
Middle Ages to the present, and the separation of horizontal and vertical
musical elements by the major divisions of beats, bars, voices, layers,
parts, staves, and systems. Lyrics are required, as are related musical
elements such as frets, tablature, figured bass, and instructions to
performers. Vertical systems like Klaverscribo and skeletal systems like
Schenkerian notation are welcome. Basic notation like this is the biggest
aspect of the program, because it also must include arbitrary graphics and
the import of images and visual output from other sources.
==Engraving, i.e., the proper respacing of all elements, stacking order,
hiding redundant elements and providing courtesy information (accidentals,
key signatures, time signatures, alterations...), rules of presentation
based on historical and present-day sources, and legibility. This is the
"back end" of notation, where it goes from content to presentation.
==Parts preparation by extraction or derivation, where all elements in a
part found in the score are *automatically* rendered separately into a
playable form with transposition, page turns, block rests, and other
symbols included an correctly placed, and linked to the original document
for changes.
==Printing not only the pages on different papers and with different
margins, but of booklets (signatures, too) and bound scores, including
compensation for creep for folding and saddle stapling.
==Ability to play back what is on the page, with correct instrumentation,
ranges, and transpositions, in a stereo or multitrack demo with human
playing emulation if desired.

That's a modern scoring program. None meet all these conditions. Right now,
Finale is the closest. Its significant failures are that it is
measure-based and so requires workarounds for staggering barlines or
beaming over barlines and systems; that its understanding of horizontal
parts within the score is inadequate, and as a consequence, it cannot
produce individual players' parts that are linked to changes made in the
score; its inability to do not-horizontal and curved staff methods; and
that it has tried to maintain command compatibility across its 15 years of
production as well as with both Windows and Mac platforms. In some areas,
it certainly shows its age. (On the other hand, no other notation program
can do linked player parts, except Graphire, which fails in #1 and #6.)

As far as the arbitrary shapes that TeX-based systems can do, for 12 years
Finale has included a PostScript-engine shape design tool, whereby
arbitrary shapes (including smart ones that can be reshaped as needed
within a score) can be designed, copied, and reused in one score and
exported in a library to another score. It can import EPS as well as TIFF.
If I need curved staff lines, though, I'll have to find me a TeX user and
get some EPS output to use in Finale. :)

LilyPond users (as I wrote yesterday) dismiss GUI programs as not producing
proper output. First of all, that's not been true since the introduction of
Graphire Music Press in the 1980s, which was programmed by someone who had
a keen eye from engraving and imported all the visuals from standard
19th-century engraving practices into his fonts and metrics, and led the
way in giving GUI scoring programs a professional look (he did the notation
software for the Synclavier). Professional users of Score (another
line-editor program) pretty much migrated en masse to Graphire, despite its
hefty $1,800 price at the time. But even a program like Finale -- which got
a bad reputation from all the amateur musicians producing charts with it --
has been able use the metrics from major publishers as a template since at
least the mid-1990s. I use Henle metrics in some of my recent scores to
give them that stodgy Euro look. ;)

There are those that scoff at the audio demo as unnecessary for a notation
program. That was certainly the opinion of the Finale list ... until, that
is, Finale included a "humanized playback" feature, where playback errors
were parametricized and introduced into the mechanical Midi playback.
Suddenly scores came much more alive and provided a good demo of contents
for composer as well as for proofreaders. These users have discovered that
a scoring program is more than an engraving engine.

And so now, the era of stricly notation programs is coming to a close. The
notation module, engraving module, playback module, etc., are all part of a
music scoring (composition, notation, presentation, and publishing) system.

Dennis