MAEstro is an attempt to decentralize the structure of multimedia authoring programs.

A perspective that MAEstro brings is the idea that multiple applications with differing purposes are all part of the system. These components are, possibly, distributed across multiple platforms. They identify four components:

1. Media editors

2. An authoring application

3. An inter-application messaging system

4. The Port Manager application

It uses inter-application messaging to allow the system to adapt to changing media formats and techniques. The paradigm is a NeXT like Speaker-Listener protocol. They stress that MAEstro communication protocol is a "remote control" protocal rather than a data transfer protocol. (this is in keeping with the idea of "transport" being a control protocol rather than a transfer protocol.

Another useful idea is to separate media manipulation and control. This is very important in that it provides a mechanism to separate soft and hard real-time operations.

Uses a timeline editor is used to manipulate and sync media on distributed platforms. The timeline is one of three possible methods to coordinate media in time. A timeline is very accurate visual way to sequence media that is intuitive and easy to manipulate. However, in complicated sequences, a cue list can be a bettor tool to simplify understanding of a sequence. In general its slightly easier to run a show with a cue list than a timeline, but the are both excellent tools. Any system should have both representations and be able to translate one to the other and back.

Media is defined as sources of information or by the applications written for them (their interfaces?). The applications are the media editors as well as where the "performance" occurs. It is unclear how the application stitches together everything for a cohesive presentation.

Real time and sync is outside the scope of maestro. Brings up the idea of having two types of media in the system: media that can be synchronized and media that will not be able to by synchronized due to physical limitations. (Here synchronized at a high detailed level).

Media Segment: part of a document managed by a media editor. Could be a passage of music or piece of text or a particular video clip.

Document, selection, and performance. is defined by applications but time is always measured in milliseconds.

Selection: start, end, duration. (duration here is an estimate for the time to completion).

Messages are for selection and performance:

selection- get current document name, and get selection

performance- open document, set selection, perform selection.

ME: why can't this be one message? i.e: "select and get selection with this document name" and "perform selection in document"? There idea around getting and performing and control is somewhat muddled.

In the system there is a central registry where media editor Applications register to advertise media services and capabilities. Two messages are provided: connect and disconnect. This is used so media authoring applications can know what media editor applications are available.

This paper describes an underling structure that helps an authoring tool deal with media. However, it doesn't look at working with media from the user perspective enough. The representation of the media is numerical rather than iconic.

The central idea of this paper is the networked organization, message passing, and separation of media from control.

Author notes that the idea of place is not transparent to the authoring system because not all nodes of the network have the same capabilities.

Future directions include protocol converters to other types of messaging systems. This would be like a language translator.

Also they want to include media writing/creating applications as well as performer/ selectors.

They talk about the need for pause and resume. Here, again, they are muddled in their concepts about control of media. Eventually they will have to implement full "control transport" of start, stop, still, speed, seek, and select. (hmm, a nice bunch of 's' words!)

They have not addressed the need for layout but talk about the need for messages to hide and show windows. Nothing is mentioned about positioning, resizing or transition.