Printing Music Scores

Stephen Travis Pope stp at limbo.create.ucsb.edu
Fri Mar 6 09:12:42 UTC 1998


Hello all,

Based on this discussion, I thought I should say/write a few words about
Siren's GUI framework. It is based on the one used in the MODE, and
documented in detail in an article in Computer Music Journal (CMJ) 16:3 (Fall
1992). (This document is included as ASCII in the Siren release's "Siren Doc"
archive; a compressed PostScript version [with figures] is to be found in http://www.create.ucsb.edu/~stp/PostScript/IDP.cmj.ps.Z.)

MODE/Siren GUI Tools

Siren is designed specifically for the easy construction of graphical tools
for manipulating sound and music (as well as other complex structured data).
There is a sophisticated (IMHO) framework for automatic layout of scores and
other event lists. There is a wide array of musical glyphs (including most of
the symbols found in standard music fonts). The figures in the CMJ article
give examples of the graphical applications I wrote in the MODE.

The earlier versions of the tools ("DoubleTalk" and the "HyperScore
ToolKit") used "old" MVC. These were ported in the MODE to VisualWorks,
meaning that windowSpec methods were used for view creation. Now that the
"core" of the package (magnitudes, events, event lists, schedulers, I/O
ports, etc.), has been ported to Squeak, I'm getting around to re-writing the
GUI framework for Squeak/Morphic. (The basic display list framework works
quite well in Squeak already, but runs under old MVC rather than Morphic.)

"Navigator" MVC

The basic premise of the Siren GUI framework (taken from the "Navigator"
application developed at Xerox PARC by David Leibs, Adele Goldberg,  and
myself based on our eariler systems "DoubleTalk" and "The Delusion of Maya"),
is that all applications are simply glorified drawing tools with some smarts
about the objects that the user is manipulating. The run-time relationships
are somewhat like the following (for a drawing of this, see figure 6 on p. 17
of the CMJ paper):

A view has model that's an an event list editor (or other editor).
A view has a display list that it displays.
(The view's controller uses the display list for hit detection.)
An event list editor has a model that's an an event list (or other complex object).
An event list editor has a layout manager that it uses to generate the
view's display list on demand.
A layout manager uses a structure accessor to navigate around the event list.

Building a new notation means refining one of the built-in layout manager
classes. This might, for example, generate a simple "piano roll" notation
using a note's pitch and time to generate its x/y position, and its duration
to determine its width (PitchTimeLayoutManager does this). Fancier layout
managers can have all sorts of layout rules involving generating graphical
symbols for non-playing events (e.g., bar lines) or generating multi-glyph
sub-display-lists for each event (e.g., including an accidental).

>From the CMJ article: "Much of the work of building a new tool within the
MODE often goes into customizing the interaction and manipulation mechanisms,
rather than just the layout of standard pluggable view components. Building a
new notation by customizing a layout manager class and (optionally) a view
and controller, is relatively easy. Adding new structure accessors to present
new perspectives of structures based on properties or link types can be used
to extend the range of applications and to construct new hypermedia link
navigators. This architecture means that views and controllers are extremely
generic (applications are modeled as structured graphics editors, or "MacDraw
with structures behind it"), and that the bulk of many applications' special
functionality resides in a small number of changes to existing accessor and
layout manager classes."

Status

Release 1.31 of Siren includes all the "core" classes ported to Squeak. The
Navigator framework works as well (up to the level of display list editors
and simple layout managers). The higher-level tools have not yet been ported
because I plan to re-think them in the process of moving over to Morphic. (I
am chanting the famous Ungar/Smith mantra of "only objects on the screen" and
trying to take a less tool-oriented approach, but am having a hard time at it.) 

I'd love collaborators, and can set up a mechanism for more frequent updates
as soon as the next minor release settles. (I've been re-designing MIDI in
the past few weeks, and believe I've been able to greatly improve it.)

If there's interest, I can set up a special Siren mailing list, or we can
keep this discussion on the Squeak list for the time being...

stp

_ Stephen Travis Pope
_ Center for Research in Electronic Art Technology (CREATE)
_ Dept. of Music, Univ. of California, Santa Barbara (UCSB)
_ stp at create.ucsb.edu,  http://www.create.ucsb.edu/~stp/





More information about the Squeak-dev mailing list