╔═══════════════════════════════════════════╗
║ ║
║ W E L C O M E T O D M U S E ║
║ ═════════════════════════════════════ ║
╚═══════════════════════════════════════════╝
┌────────────────────────────────────────┐
│ <shft> F1 = Toggle to regular window │
└────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────┐
│ │
│ If you are reading this document for the first time and │
│ are unfamiliar with the commands for scrolling the text, you │
│ should be aware that <ctrl> ▲ (hold down the <ctrl> key and │
│ push the cursor UP key) will scroll the text UP and <ctrl> ▼ │
│ will scroll the text DOWN. You can also use the PageUp and │
│ PageDown keys to scroll quickly through the document. │
│ │
└──────────────────────────────────────────────────────────────────┘
1.1 Dmuse is a multi-tiered program. At the most basic level,
it is a program designed to display and print musical scores and
parts. You may use it for this purpose without knowing about or
using any of its other features. But Dmuse can also function as
a multi-window, multi-tasking research environment. It includes
a resident file manager, a fully integrated screen editor with
30 overlapped windows and a powerful programming language called
Zbex. Each of the 30 windows can act like a computer terminal
and run a Zbex program. At the same time, these windows
continue to respond to screen editor commands.
1.2 We have attempted to organize the documentation for Dmuse
in a way that reflects its multi-tiered character. At the
simplist level, the operation of the program is designed to be
self evident -- hence the menu bar at the top, with its five
pull-down menus. Using these menus, you can perform the basic
operations necessary to display and print music. The help
subjects Displaying Music and Printing Music (included in the
help menu), will give you the information you need to perform
these functions.
1.3 The next level of complexity is learning to use the screen
editor. This knowledge will be useful if you decide you want
to edit the music files. Also, learning to use the editor is
a prerequisite to using any of the advanced features of Dmuse.
The help subject, Using the Screen Editor gives a complete
description of how the editor functions. You may also learn
about the editor keystrokes through The Editor Keystrokes
utility included in the help menu.
1.4 If you want to edit or change the music, you will need to
understand the format of the Music Page Files (.MPG files)
and the Compressed Format Files (.CFT files). You will find
documentation for these subjects in the help selections
MPG file format and CFT file format.
1.5 You will find the resident file manager to be an extremely
useful utility. A detailed description of this utility can be
found in the help selection Resident File Manager.
1.6 The advance applications fall into three categories:
(1) using wordwrap with the editor, (2) the Zbex programming
language, and (3) the use of dictionaries. Dmuse is installed
with these applications disabled. The idea is that Dmuse
should appear initially as a simple and easy-to-use program
for those people who only want to display and print music.
If you are interested in one or more of the advanced
applications, the help selection Advanced Topics contains
the documentation you need, including instructions on how
to activate these features.
1.7 This completes the introduction to Dmuse. For those
users who are curious about the origin and evolution of the
Dmuse program, what follows is a history of how this program
came to be written and what future purposes it might serve.
──────────────────────────────────────────────────────────────────
2.1 The story begins in the mid 1970's before the advent of
personal computers. At that time, the smallest computer a user
could buy was called a MINI computer. In terms of today's PC
hardware and software, the MINI computer was a technological
infant. Memory size and disk space were measured in kilobytes
instead of megabytes; and computer speed was measured in
thousands of Hertz instead of billions.
2.2 The software required to run the MINI computer was arcane
a user pretty much needed a background in computer science to
use one. Nevertheless, there were visionaries at that time
who understood the potential the computer held for changing
the way we work. One of these was David Woodley Packard, a
professor of Classics at UCLA. Packard was interested in
using the MINI computer for research and teaching in ancient
languages, principally ancient Greek. Using knowledge he had
gained from working with the computer system at UCLA, Packard
designed a specialized time sharing system called Ibycus,
which ran on Hewlett Packard hardware and displayed ancient
Greek on computer terminals, something that had not been done
before. To assist the development of applications on this
system, Packard developed a specialized programming language
called Ibex.
2.3 I first became interested in computer applications in music
in 1982. At that time, commercial software applications for
the Humanities were practically non existant. Most of the work
being done in this area was confined to university research
projects using large, centralized computing facilites. I did
not have access to these kinds of resources, but fortunately I
was familiar with the progress that David Packard had made in
creating a scaled down, affordable system for humanities
research. I therefore arranged to acquire an Ibycus system for
my own research. The Ibycus system turned out to be ideal for
this purpose, and its availability was one of the primary factors
in my decision in 1985 to formally establish the non-profit
Center for Computer Assisted Research in the Humanities (CCARH).
2.4 We continued to use the Ibycus system at CCARH until 1989,
at which time we decided the system needed upgrading. David
Packard had already made the decision to abandon the outdated
MINI computer hardware and to implement his next version of
Ibycus on a dedicated personal computer which he designed and
built himself and which he called the Baby Ibycus. Moving in
a slightly different direction, I decided to implemented a
stripped down version of the Ibycus system first on a UNIX
workstation using X-Windows and later on the PC. I called my
program "the Monster," because it ran all of my Ibex software
and served as a complete working environment. I added some
features to the Ibex programming language but dropped others.
In particular, the system lost its capability to display
ancient Greek but gained the capability to display musical
notation. I have named this Ibex variant Zbex.
2.5 We have been using the Monster at CCARH since 1992. We use
it for all of our data entry, data storage, music typesetting
and publishing, and music research applications. We also use
it for running the Center. All of the financial operations of
the Center -- check writing, book keeping, payroll and payroll
taxes are done with Ibex programs running on the Monster. All
software development is done using the Monster's editor. All
research software is written in Zbex.
2.6 When it came time to write a user program for displaying
and printing music, what I needed was a user interface. I
already had versions of these programs written in Zbex and
running on the Monster. My two choices were (1) to write a
new, dedicated interface for this purpose, or (2) to graft
the music display and printing applications onto the existing
Monster program. I chose the second option for two reasons:
(1) I determined that it would take less time to get the job
done if I used the interface I had already developed, and (2)
I saw good reasons for making the Monster available to other
people. This inproved version of the Monster was completed
in 1995 and was given the name Dmuse.
2.7 From 1995 until 2006, the Dmuse environment stayed
basically the same and became quite stable over these years
of use. But the world of computing changed radically during
this same time period. The DOS operating system, upon which
Dmuse was built, virtually became extinct. Computer speed
and memory increased more than 100 fold, and graphical interfaces
were completely redesigned. These changes -- especially the
death of DOS -- threatened to choke off Dmuse as a viable user
interface. It was clear that Dmuse needed to be moved to a
new platform. My choice was Linux.
2.8 In the fall of 2006, I began a process of revising Dmuse
to run in a X-Window on Linux. Fortunately, I had the experience
in 1989 of writing to X, and also the necessary documentation.
I say "fortunately," because in today's world (2007) most
interface programmers never deal with X-Windows directly;
instead, they write using higher level "Widgets." The problem
with Widgets is that they presuppose certain interface
conventions such as popup windows, buttons, slide bars, etc.,
all of which are made easy. But other interface conventions
such as the blackboard metaphone used by Dmuse become extremely
difficult if not impossible to implement with Widget style
programming. The transfer of the Dmuse environment to Linux
was competed in the fall of 2007.
──────────────────────────────────────────────────────────────────
3.1 I believe that Dmuse could become a valuable asset to anyone
wishing to use the computer for research in many branches of the
Humanities, including but not limited to music. As people in the
field of Classics are aware, David Woodley Packard's Ibycus
system was highly successful for both teaching and research
purposes and was instrumental in the development of the great
databases of classical literature, the TLG at UC Irvine and the
TLL at the Packard Humanities Institute and Yale University. I
believe other such opportunites also exist. The fact is that
scholars have just barely scratched the surface of what computers
can do in aiding research in their disciplines. Each of today's
PCs is 1000 times more powerful than the big, multi-million
dollar mainframes of the 1960's that used to sit behind glass
walls at major universities. Yet in terms of reseach applications
in the humanities, in most cases (Classics is an exception) we
have not progressed very far from those days.
3.2 This brings me to the final help selection, namely, New
Directions. Here I discuss possible new directions that
Dmuse could take, including both musical and non-musical
applications. We cannot move forward in all directions at
once. The decision about what we do next depends in large
part on what you, the users of this program, would like to
have. We recognize that there are a lot of software
alternatives available to today's user and that a program
like Dmuse will be useful only if it occupies a niche that
is both useful and unique. We welcome your feedback.
Walter B. Hewlett
Stanford, CA
December, 2007