UC Irvine - ICS 125

Project in Software System Design

FQ 2004 Project Opportunities

Index

1. Working Sphere

2. Integrating Palantír with Subversion and Eclipse

3. Creating and Updating Palantír Views

4. Robustifying Palantír

5. Integration of xlinkit with ArchStudio 3

6. xArchScript: Scripting for xADL 2.0 documents in ArchStudio 3

7. unexceptional.net: PHASE II

8. File-sharing - moving towards "what you see is what you get"

9. GXL Validator Plug-In

10. GXL Visualization Plug-in

11. New Computer-based Choral Musical Score Display

12. Blah Blah Blah: A Content Creation Infrastructure In Support Of Speech-Based Location-Aware Mobile Phone Gaming

13. New True 3-D Digital Display System

14. Java-based Genome Browser for Mitochondrial DNA

Last modified: September 27, 2004 12:15 PM


Working Sphere

I'd like the students to design a system whereby people could connect together their separate "events" in their daily working lives that are related by being part of a common project (what we call a working sphere). This means that people would identify their projects at the outset (e.g. NSF ITR project, 135 course, JPL project, etc.). Then as people create Word docs, Excel spreadsheets, send/receive emails, write notepads for phone messages, etc. they would assign these to their separate working spheres. Thus, each working sphere would contain a set of information related to it. In this way, people would access their data according to their working spheres.

But wait--it gets more complicated. I don't think a simple traditional file hierarchy is the way to go. I'd like to see similarity indexes used to relate the documents within each working sphere in terms of "closeness". This "closeness" measure could be determined e.g. as the time that the artifact was created, by specifying the key person (or people) involved in it, by its importance, or even some other measure. This means in effect that people could have different visualizations of their information dependiing on what dimension they would like to use to view their information. i envision the interface as a visualization of the information within a working sphere.

The motivation for this system comes from real life data that shows that people switch projects about every 12 minutes (and lower order events about every 3 minutes). The goal is that this system can help people maintain continuity in their working spheres.

Back to Index


Integrating Palantír with Subversion and Eclipse

Palantír is a workspace awareness tool that informs developers about the ongoing activities of other developers. Specifically, it informs them of potential conflicts as they develop. Such conflicts may be direct (one developer, working in their cubicle, starts editing a file that another developer, working in their cubicle on the other side of the building, just started editing as well) or indirect (one developer edits a file and makes significant changes to the interface of the class defined in that file, while another developer is reworking the program to make increased use of the -- now old -- interface). Palantír is a tool that we have developed that helps in these situations. It operates by sending out events regarding the changes that a developer makes, thereby informing the other developers of these changes and allowing them to contact each other if they notice their work overlaps.

To date, Palantír has operated in a stand-alone fashion. Recently, we completed an integration of Palantír and CVS and Eclipse; now we would like to create an integration between Palantír, Subversion (another CM system) and Eclipse. This project will involve understanding how Eclipse's plug-in architecture works, intimate familiarity with a leading configuration management system, and using a distributed, event-based infrastructure.

Features:

* Build a wrapper around Subversion / Subclipse (the Subversion Eclipse
plug-in) that emits events to the Palantír event server.

* Calculate the severity (size) of changes in this wrapper.

* Support easy configurability from Eclipse.

* (Special requirement): use Palantír + CVS + Eclipse in the development
of this tool, on a separate branch in our repository, and report on
any issues with Palantír and suggest improvements along the way (you
will not have to implement those, however)

For more information:

* www.ics.uci.edu/~asarma/Palantir

Back to Index


Creating and Updating Palantír Views

Palantír is a workspace awareness tool that informs developers about the
ongoing activities of other developers. Specifically, it informs them of
potential conflicts as they develop. Such conflicts may be direct (one
developer, working in their cubicle, starts editing a file that another
developer, working in their cubicle on the other side of the building, just
started editing as well) or indirect (one developer edits a file and makes
significant changes to the interface of the class defined in that file,
while another developer is reworking the program to make increased use of
the -- now old -- interface). Palantír is a tool that we have developed
that helps in these situations. It operates by sending out events regarding
the changes that a developer makes, thereby informing the other developers
of these changes and allowing them to contact each other if they notice
their work overlaps.

To date, we have built a number of different visualizations for Palantir.
Most of these have been experimental, but since people are starting to use
Palantir in a number of different settings, we need to (a) reexamine these
views, (b) reimplement them properly so they are scalable and resistant
against errors, and (c) investigate other ways of visualizing the
information. This is not a mere reimplementation effort; we want to
critically look at the visualizations with the team, decide upon features,
and build the visualizations from scratch. In addition, the MS Windows
Explorer view is brand-new. This project involves working with a state of
the art configuration management approach, designing and implementing a MS
Windows extension, working with Eclipse, and state-of-the-art visualizations
to be designed.

Features:

* Create a new Eclipse perspective that informs developers of minimal,
average, and maximum severity of changes.

* Redesign and reimplement the grid view to properly scale and work.

* Build a MS Windows Explorer view that is similar to the Palantír
explorer view, but is actually an extension to the real Windows
Explorer program.

* Update the Internet Palantír explorer view.

* (Special requirement): use Palantír + CVS + Eclipse in the development
of this tool, on a separate branch in our repository, and report on
any issues with Palantír and suggest improvements along the way (you
will not have to implement those, however)

For more information:

* www.ics.uci.edu/~asarma/Palantir

Back to Index


Robustifying Palantír

Palantír is a workspace awareness tool that informs developers about the
ongoing activities of other developers. Specifically, it informs them of
potential conflicts as they develop. Such conflicts may be direct (one
developer, working in their cubicle, starts editing a file that another
developer, working in their cubicle on the other side of the building, just
started editing as well) or indirect (one developer edits a file and makes
significant changes to the interface of the class defined in that file,
while another developer is reworking the program to make increased use of
the -- now old -- interface). Palantír is a tool that we have developed
that helps in these situations. It operates by sending out events regarding
the changes that a developer makes, thereby informing the other developers
of these changes and allowing them to contact each other if they notice
their work overlaps.

To date, we have an experimental version of Palantír that we hav estarted to
use ourselves. A key aspect of the implementation of Palantír is a
centralized database to which the clients connect. The problem, currently,
with Palantír is that it does not allow (a) disconnected operation, and (b)
any issues with a connection "going down". We want to extend Palantír so
that someone can take a workspace on their laptop, disconnect from the net,
and resync up when they connect back to the network. We also want to
leverage this mechanism to "resynchronize" when a connection is accidently
lost due to the server disappearing for some reason. This project involves
dealing with advanced issues in distributed systems, a unique "research /
testing" slant, and an opportunity to design creative solutions.

Features:

* Support disconnection of Palantír client, with "saving" of events
to send later.

* Support reconnection of Palantír client, with resynchronization
of views, updating of the server, and getting informed of what
happened in the rest of the project met anderen.

* Investigate how Palantír may break down with network outages,
server crashes/kills, etc, and propose and implement solutions.

* (Special requirement): use Palantír + CVS + Eclipse in the development
of this tool, on a separate branch in our repository, and report on
any issues with Palantír and suggest improvements along the way (you
will not have to implement those, however)

For more information:

* www.ics.uci.edu/~asarma/Palantir

Back to Index


Integration of xlinkit with ArchStudio 3

ArchStudio 3 is a research environment for software architectures. It
is similar to code-based environments like Eclipse or Visual Studio in
that it integrates many software engineering tools in a single, unified
environment, but instead of focusing on the code as the primary
development artifact, it focuses on an architectural model, specified
in an XML-based language called xADL 2.0.

xlinkit is an off-the-shelf constraint analyzer for XML documents. It
allows users to specify complex constraints among XML elements using
a (relatively) simple constraint language, and then quickly checks XML
documents to see if those constraints are met or not. If they are not
met, then violations of those constraints are reported.

The goal for this project is to integrate xlinkit into ArchStudio 3
to allow ArchStudio developers to rapidly create analysis tools for
xADL 2.0 architectural descriptions. In its current form, xADL 2.0
has many implied constraints among elements that are too complex to
be checked by a regular XML syntax validator; however xlinkit should
be able to check many/most of these constraints. Ideally, the output
of this project would be a framework in which developers could write
a constraint in the constraint language of xlinkit, and then have
xlinkit check an open xADL 2.0 architecture for these constraints
and report violations in a user-friendly way.

The challenges for this project include obtaining a copy of xlinkit
for development (it's currently under commercial license but the
original developers are friends of the software group here, and
it should be possible to get a developer's license or use an older,
open-source release), integrating xlinkit into the ArchStudio 3
environment as a component (or set of components, or meta-component),
writing constraints to check xADL 2.0 documents, and translating
the results of the constraint check into data that is in the
format used by ArchStudio 3.

This project is worth doing because it has the potential to improve
the constraint analysis capabilities for software architecture models
significantly. I believe that a properly done xlinkit-ArchStudio
integration will make writing analysis tools for xADL 2.0 descriptions
a full order of magnitude simpler than it is now, and likely more
efficient as well. In the longer-term, I believe the xlinkit-ArchStudio
integration will be critical to managing relationships among different
views in a multi-viewed software architecture model.

> Features: (a short bullet list of one-line descriptions of features or
> requirements)

- xlinkit integrated into ArchStudio 3 as a component (or set of
components, or meta-component)
- Such that errors found when checking xADL 2.0 documents are
displayed to the user in a friendly way
- Such that errors found when checking xADL 2.0 documents are
related back to individual elements in the document in a
format that other ArchStudio 3 tools (e.g. editors like
ArchEdit and Archipelago) can understand so they can help
the user focus on and fix the errors.
- A set of example constraint analyzers for the current version
of xADL 2.0.
- Includes some part/tool/well-defined-method that allows
developers to easily create future xlinkit constraints for
future xADL 2.0 features
- Double Bonus: Obtaining/using an xlinkit license that allows
us to redistribute the results of this work as a part of
the ArchStudio 3 toolset.

Back to Index


xArchScript: Scripting for xADL 2.0 documents in ArchStudio 3.

ArchStudio 3 is a research environment for software architectures. It
is similar to code-based environments like Eclipse or Visual Studio in
that it integrates many software engineering tools in a single, unified
environment, but instead of focusing on the code as the primary
development artifact, it focuses on an architectural model, specified
in an XML-based language called xADL 2.0.

Currently, ArchStudio 3 provides a reasonable Java API for reading
and writing xADL 2.0 documents element-by-element, but writing new
components and classes that take advantage of this API for simple
xADL maintenance tasks can be cumbersome. To augment this API, we
would like to integrate a scripting framework into ArchStudio that
allows users to write and execute scripts that can perform maintenance
tasks on xADL 2.0 documents. For example:

- Find all elements in the document that do not have an ID (but
should), and generate a random, unique ID for each one.
- Replace all links in the architecture with two links and
an instrumenting connector.
- Create a component type for each component in an architecture
that doesn't have one, based on the information in the component's
description.

Because xADL 2.0 is a complex (and extensible) language, the scripting
language should support simple functions, recursion, variables, string
maniuplation and all the other trappings of a 'real' scripting language.
As such, we recommend that an off-the-shelf scripting framework for Java
be used--this should simplify your life greatly. Candidates include Jython
(a Python implementation for Java) and Rhino (a Javascript implementation
for Java). The outcome of this project should include at least one
ArchStudio 3 component accessible via API that can execute scripts; bonus
for including a separate script editor/debugger component.

This project is challenging because it involves integrating an
off-the-shelf software tool (a scripting engine) with an existing
environment. It will probably also entail the use of Java reflection
to provide a full suite of capabilities. The reward is that the
environment will be significantly enhanced for users that need to create
and maintain real architecture descriptions, simplifying some maintenance
tasks by up to an order of magnitude.

> Features: (a short bullet list of one-line descriptions of features or
> requirements)

- Integrate an off-the-shelf Java scripting engine into ArchStudio 3
as a component exposing an API callable by other components
- Allow users to write scripts that can traverse arbitrary xADL
2.0 documents, read them, and make changes.
- Demonstrate the effectiveness of the tool by writing scripts
to:
- Find all elements in the document that do not have an ID (but
should), and generate a random, unique ID for each one.
- Replace all links in the architecture with two links and
an instrumenting connector.
- Create a component type for each component in an architecture
that doesn't have one, based on the information in the component's
description.
- Bonus: Create a separate script editing/debugging component.

Back to Index


unexceptional.net: PHASE II

unexceptional.net is a multimodal, pervasive, location-aware 'net-centric'
game.

The game is quest-based, and revolves around a central character - Guy.
Guy is a frustrated comic artist, game designer, hacker who's recently
found out that his long-time partner is having an affair. This discovery
launches him upon a series of quests, that you participate in, in effort
to gain insight into the nature of his partner's relationship. In the
process, due to his cheating partner's interests and influence, his
experience is infused with an eastern philosophy and spirituality that
dictates the nature of the quests, and the ultimate goal, Guy's search for
"enlightenmnet."

PHASE I: Background

Phase I (begun in Redmiles' 125 class, and continued over the Summer)
involved design and implementation of a server infrasturcture for storing
and delivering game-sttte via both GPS enabled cell phone, and the Web.

On the Web side, a Blog (administered by the game's central character,
Guy) is used as a vehicle for providing the player information about
current game state, player locations, and quest progress. The Blog is also
used as an administrative framework enabling the game designers to
dynamically and flexibly customize the game and have it immediately
reflected in the various interfaces - at this point Web and GPS cellphone.
I refer to this as the 'World-Building Toolkit' component. The
world-building is done through a series of user-friendly Web pages
allowing customization of a wide-range of game-state data such as
inventory, statistics, the main character, npc characters, and a number of
location related services allowing specification of how things like
region, terrain, and structure will be defined and treated during
gameplay. All of this work was done using PHP, MySQL, HTML, DHTML, and
Javascripting.

On the phone side we used Nextel's Motorola i730 GPS cellphones for
prototyping. The phone client is written in J2ME using the MIDP 2.0
specification. We also wrote a servlet that handles direct socket
connections to the game server, and does the authentication and data
uploading and downloading. The phone game is a 2D isometric style game
where the main character Guy runs around the world on a series of
location-based quests madly looking for his cheating partner and her
lover. On startup of the phone game a number of things happen: 1)
authentication; 2) notification and storage of the player's lat/lon
location to the server; 3) pulling down the player's active quest
information from the server to the phone; and 4) pulling down all relevant
inventory, statistics, region, terrain, and structure data from the server
to the phone. The phone has two modes of representing the player; 1) the
'astral body' which is associated with the character representation that
is controlled via key commands and can interface it with the gameworld
(pick up items, bomb structures, interact with characters, etc); and 2)
the 'physical body' which is controlled via the player's actual movement
in physical space, updated via the GPS feed. As game play ensues,
game-state is continually updated to the server. After quitting, when the
player logs back in to the game via the Web interface, the impact of game
play via the phone will be reflected in the Blog.

All this brings us to what I would love to get students from your class
involved with as...

PHASE II: Next Steps

One of the core R&D projects in the Game Culture and Technology Lab is a
'Game-Grid' infrastructure we have implemented in relationship with our
partners, the San Diego Supercomputer Center, Sun Microsystems, and a
third-party technology middleware provider, Butterfly.net. Among other
things, the grid will enable massively multiuser game environments on a
scale far greater than anything currently available. We have hooked
several 3D game engines into the grid - Crystalspace, NDL and Torque. One
of the goals is to enable a character that is instanciated in one
environment to seamlessly move into a completely foreign environment
running in another engine.

This brings me back to unexceptional.net. Phase II prototyping will
involve specifying and implementing a real-time 3D massively multiuser
interface (MMOG) to Guy's world that runs on the grid. Torque will be used
as the primary engine. The goal will be to make the MMOG function
analagous to the phone. In other words, to build in at the infrastructure
and content creation level a far greater degree of modularity and
flexibility than is common. For instance, the Torque client will need to
communicate with the game server database to access stats, inventory, and
location information, as well as update that information to the database
during gameplay.

This team would be primarily responsible for helping to design and
implement the Torque client in relation to what already exists on the Net
and GPS phone side. Useful skills would include familiarity with 3D games
and game engines, graphics programming, SQL database programming, PHP
scripting, Torque's internal scripting language (similar to C++), and
networking.

Back to Index


File-sharing - moving towards "what you see is what you get"

Description:
File-sharing applications such as Napster, Gnutella, Limewire etc. were all really cool, but they suffered from a very significant problem. There was no way to ensure that the resources (such as files) you were downloading were actually the resources you thought you were downloading. Moreover, you could in fact have downloaded viruses and spyware that could have harmed your computer. What if there could be a way to ensure "what you see is what you get!!"

XREP is one solution to this problem. It uses a reputation-based approach that helps peers choose reliable resources in decentralized P2P applications. In addition, the PACE architectural style provides guidance on how and where to integrate trust and reputation models in the application architecture. PACE, combined with XREP, can provide a promising approach to tackle the problem of choosing reliable resources in file-sharing applications. PACE implementations for other domains, such as auction and collaboration, have already demonstrated its feasibility.

The goal of the project will be to incorporate the XREP approach into PACE for the document-sharing domain. In particular, each peer will be built using the PACE architectural style and will utilize the XREP reputation model to determine the trustworthiness and reliability of a resource and the provider before it is actually downloaded.

This project offers several benefits:
1. An introduction to component-based software architectures and styles.
2. An introduction to the effects of decentralization and P2P.
3. An introduction to trust and reputation management.
4. Study of a P2P resource-sharing application.

Features:
The document-sharing application should
- Conform to the PACE architectural style
- Utilize the PACE and C2 frameworks, and the ArchStudio environment
- Incorporate the XREP reputation approach with PACE
- Provide a proper user-interface for both the document-sharing application and XREP.

- Help draw conclusions about
(a) the feasibility of using PACE in a resource-sharing domain, and
(b) the ease of incorporating the XREP reputation model into PACE.

Back to Index


GXL Validator Plug-In

This project will deliver an <http://www.eclipse.org/>Eclipse plug-in that is capable of validating a <http://www.gupro.de/GXL/>GXL document to ensure correct GXL syntax, and of assisting the user in reparing the incorrect syntax.The validation and repair will be done according to the standard GXL version 1.0.

Background

A number of software re-engineering tools have been created for aiding programmer in gaining high-level knowledge of software systems from source code. These tools are usually designed for a specific purpose, and will work the best in different cases. Consequently, using a combination of tools can provide a better result than using a single tool because tools can offset weaknesses among each other. Therefore, an ability to share data between tools is desired in order to reduce duplicate work, or to allow comparison of results. However, data interoperability among these tools is a challenge, as the tools normally have their own local format for results which is incompatible with the other tools.

In order to solve this issue, <http://www.gupro.de/GXL/>Graph eXchange Language (GXL) was created as a standard exchange format between software tools. GXL is an XML-based language that supports data interoperability among tools by providing a standard notation to represent data and its meaning (schema). A number of GXL converters are created by for converting a result file in a tool's proprietary format to GXL format and vice versa, e.g. rsf2gxl, gxl2svg. In summer of 2004, the MRS.G project developed a set of <http://www.eclipse.org/>Eclipse plug-ins to facilitate working with GXL files and converters. The plug-ins include a GXL editor, Converter Integration Framework, and a series of converter plug-ins. Results from this project show that some converters do not produce a result file that conform to the GXL standard. Also, the resulting files can not be used as an input to another converters or other tools. Also, a errors can creep in when a user modifies a GXL file in an editor. In order to solve this problem, a plug-in that is able to detect errors and assist a user in reparing the errors is needed.

Project Description

The GXL Validator Plug-in will build on the existing MRS. G plug-ins and source code. It should be able to interoperate with an existing GXL editor. The new plug-in should capable of validating an existing GXL file, or a file generated by the converter plug-ins in order to check whether it conform to the GXL standard. The plug-in should also assist a user in repairing the errors. For example, the editor should be extended to inform users about the location of errors, and provide some suggestion about correction that can be made. Where the solution for the error is obvious, it should be able to repair the file automatically or interactively.

Features

The plug-in shall be able to validate GXL syntax
It should be able to detect simple XML syntax errors such as unclosed quotes
It should be able to detect specific GXL syntax errors such as missing required attribute, or the use of unspecified keywords
The GXL editor should be able to inform the user about errors
Underline or otherwise highlight the error item in the active page
Providing a mark at the beginning of the line, or in the file icon on eclipse views to show the location of the error (like the way Eclipse show errors in a Java file)
Providing help in correcting the errors
Provide hints for an error that has multiple solutions
Provide automatic correction for a simple and obvious mistake such as unclosed quotes
Some patterns of errors are common such as ones that created by a converter. For a known error pattern, it should provide the user a choice of auto correction of the entire file.
Allow the user to choose whether to validate or repair the file for a specific convertor. Some files may not have syntax errors, but are not suitable to be used as input for a specific converter. For example, a file without the name of nodes specified will be useless to use as an input for a gxl2svg converter as the result will show only blank boxes. For these known issues, provide correction hints or auto correction for those GXL files.

Constraints

The validator should be written in Java and should use an existing data binding component created in MRS. G project. The source code for the component and GXL editor will be made available.

Notes

The user interface of the validation should be like the similar to the Eclipse JDT with syntax checking of Java file

Resources

<http://www.gupro.de/GXL/>GXL website
<http://www.eclipse.org/>Eclipse Website
<http://eclipse-wiki.info/PDE>Information on the Eclipse Plug-in Development Environment (PDE)
<http://www.cs.umanitoba.ca/~eclipse/>Eclipse tutorial website
<http://calla.ics.uci.edu>Galen Lab Home Page
<http://mrsg.tigris.org>MRS.G Development Site on tigris.org

Back to Index


GXL Visualization Plug-in

This project will deliver an <http://www.eclipse.org/>Eclipse plug-in that is capable of visualizing a <http://www.gupro.de/GXL/>GXL document that is currently open in MRS.G's GXL editor. The visualization shall depict the diagram as a graph, i.e. a collection of nodes and edges. The visualization should be editable and the changes made in the visualization should be reflect in the source GXL document.

Background

A number of software re-engineering tools have been created for aiding programmers in gaining high-level knowledge of software systems from source code. These tools are usually designed for a specific purpose, and will work the best in different cases. Consequently, using a combination of tools can provide a better result than using a single tool because tools can offset weaknesses among each other. Therefore, an ability to share data between tools is desired in order to reduce duplicate work, or to allow comparison of results. However, data interoperability among these tools is a challenge, as the tools normally have their own local format for results which is incompatible with the other tools.

In order to solve this issue, <http://www.gupro.de/GXL/>Graph eXchange Language (GXL) was created as a standard exchange format between software tools. GXL is an XML-based language that supports data interoperability among tools by providing a standard notation to represent data and its meaning (schema). A number of GXL converters are created by for converting a result file in a tool's proprietary format to GXL format and vice versa, e.g. rsf2gxl, gxl2svg. In summer of 2004, the MRS.G project developed a set of <http://www.eclipse.org/>Eclipse plug-ins to facilitate working with GXL files and converters. The plug-ins include a GXL editor, Converter Integration Framework, and a series of converter plug-ins. Results from this project show that some converters do not produce a result file that conform to the GXL standard. Also, the resulting files cannot be used as an input to another converters or other tools. Also, a errors can creep in when a user modifies a GXL file in an editor. In order to solve this problem, a plug-in that is able to detect errors and assist a user in reparing the errors is needed.

Project Description

The project will extend an existing MRS.G project, and should be able to interoperate with an existing GXL editor and XML Beans for handling GXL documents. The new plug-in should capable of creating a graph visualization for an active GXL document opened in the GXL editor. The visualization should be editable and changes should be reflected in the source docuemnt.

Features

The plug-in shall be able to visualize the graph represented by the GXL document
The visualization should be able to manage the layout of the graph in an understandable fashion
The user should be able to select to visualize a specific portion of the document (For example, a GXL file may be very large, so the user should be able to select to visualize only nodes and edges that have references to a selected node)
It should allow the user to zoom in, zoom out or resize the graph in case that the graph is too big or too small for the display
The visualization should be able to show selected properties of nodes and edges
The visualization should be editable
The user should be able to edit properties of nodes and edges through the visualization such as their names
The user should be able to delete unwanted nodes or edges
Changes in visualization should propergate to the souce document correctly, e.g. when a node is deleted the references and its elements should also be deleted

Constraints

The visualization should seamlessly integrated into Eclipse environment and the existing MRS.G component
The validator should be written in Java and should use an existing data binding component created in MRS. G project. The source code for the component and GXL editor will be made available.

Notes

There are a libraries that will perform graph layout available on the web. These packages should be considered before implementing graph layout algorithms from scratch.
The most difficult portion of this assignment is like maintaining consistency between the editor and the visualization. Ensuring that edits in the visualizer are reflected in the text document, and vice versa, is a challenging problem.
The cusomter will be able provide examples of good visualization tools to the team. These examples can serve as a source for ideas. It's possible, although not certain, that some of these can serve as a starting point for the GXL Visualization plug-in.

Resources

<http://www.gupro.de/GXL/>GXL website
<http://www.eclipse.org/>Eclipse Website
<http://eclipse-wiki.info/PDE>Information on the Eclipse Plug-in Development Environment (PDE)
<http://www.cs.umanitoba.ca/~eclipse/>Eclipse tutorial website
<http://calla.ics.uci.edu>Galen Lab Home Page
<http://mrsg.tigris.org>MRS.G Development Site on tigris.org

Back to Index


New Computer-based Choral Musical Score Display

Objective: Develop a desktop application and server to present choral musical scores in a completely new and vastly simplified method of displaying and communicating musical choral scores to a choir (and ultimately to different performers.)

Background

The method of presenting musical scores in the form of sheet music, with its attendant complex and abstract notation, has remained relatively unchanged for hundreds of years. Computers have mostly only been used to write music using a computer so that a finished musical score can be printed out looking the same way scores looked 150 years ago. No attempt has been made to use computers to change the appearance and hence the method of communicating the composer’s intent to the performer. The page of music displayed on the computer screen looks identical to the same page of music composed 150 years ago. To someone not schooled and trained in music theory as a musician the notations written on the page are very abstract; they are not intuitive; are incomprehensible to a non-musician and are literally medieval.

The purpose of this project is to revolutionize the way a musical score is communicated to the performer in an intuitive manner so that he or she will have a much faster learning curve on a new piece of music at the same time being able to significantly improve the quality of the performance.

Project Description

The project will produce a simplified feasibility demonstration of the computer-based scoring and display system. The demonstration system will simulate what the ultimate operational system will look like and how it will perform to convey the musical information to the performer(s). One or more choral pieces for at least 4 voices (Soprano, Alto, Tenor and Bass) will be displayed and “played” in real time with each voice on a separate LCD notebook display.
Time permitting, additional features will be added that will include the following:
1.      The computer will provide each voice with a quiet pitch tone to the respective singer’s ear one beat or one bar before the singer voices the note so that they will get the right pitch.
2.      The computer will play a louder note in real-time in synchronization with the part the signer is performing.
3.      A throat microphone on the singer’s neck will allow the singer to phonate the tone (almost silently with mouth closed) before coming in and during the singing so that a real-time “pitch meter” on the screen can display an indication to the singer whether they are under or over pitched.
4.      Instead of musical notes, as used in conventional scores, the notes will be displayed as lines that scroll across the screen much like an old fashioned scroll in a player piano. Each note to be sung will be on a horizontal line corresponding to one note on a piano keyboard (white or black.)
5.      The moving lines that represent the notes will vary in width according to the loudness with which they are to be sung.
6.      The tonal quality, whether bright or mellow, will be designated by whether the line has a fuzzy or a smooth edge. (Change of color of the line, e.g. red to blue could alternatively be used.)
7.      The words of the choral piece will accompany the moving lines as they scroll across the screen.
8.      The exact timing of the entry and exit of a note is designated by when the horizontally scrolling note line hit a stationary vertical time marker on the screen.
9.      The consonants in the words, which are important to making a sung word intelligible to the listener, will be designated in the score line by a narrow broadening of the line at the appropriate timing.
10.  A real-time TV image of the musical director (conductor) will appear as a desktop image behind the musical display so the singer’s eyes are constantly seeing the conductor while reading the computer score.

Constraints

Must use standard off-the-shelf hardware consisting of a PC server connecting to a number (at least 4) LCD displays or notebooks with displays that can be exactly synchronized with server.

Notes

Contact the customer for additional information

Alex Metherell
E-mail: Alex.Metherell@cox.net

Back to Index


Blah Blah Blah: A Content Creation Infrastructure In Support Of Speech-Based Location-Aware Mobile Phone Gaming

Clients:
Bill Tomlinson, Assistant Professor of Informatics and Drama
Robert Nideffer, Associate Professor of Studio Art and Informatics

In recent years mobile phones have become common in the US, and games for these phones have flourished. Currently, mobile gaming is focused almost exclusively around using the phone as a miniature computer, where buttons provide the primary input mechanism and a tiny screen displays the output. This paradigm is at odds with the core functionality of the telephone – voice input and output. We are convinced that there could be a whole new generation of games better utilizing voice technology.

The project involves prototyping an interactive adventure game using a voice-driven interface on location-aware mobile phones. The ICS 125 team would work to design back-end support for connecting a GPS-enabled mobile phone to both a speech recognition system (e.g., Sphinx, http://cmusphinx.sourceforge.net/) and a text-to-speech system (e.g., FreeTTS, http://freetts.sourceforge.net/). The processing between these two systems would be based on the GPS data from the phone.

A simple interaction might take the following form. A person calls a certain phone number to begin the game. She then walks around campus. When she passes a certain set of GPS coordinates (for example, the front of the Science Library), her phone says 'You see a large book with an Anteater on the cover.' She replies, 'Get book.' The phone then tells her, 'You pick up the book.' She then says 'Inventory,' and the phone responds 'You have a large book with an Anteater on the cover.'

While this interaction is very simple, a system that can perform in this way will allow for the creation of much more complex mobile games and other interactive experiences. Ideally the project will be designed to allow ease of content creation so additional game modules can be relatively quickly built and deployed.

Features:
Speech recognition
Speech synthesis
GPS data transfer from phone to base station
Database of locations/objects and game state tracking
System to generate the content that will be synthesized into speech

Back to Index


New True 3-D Digital Display System

Objective: Develop software for a digital display system for use in digital image displays (e.g. notebook screens, medical imaging displays, TVs, etc.) that will allow the user to view a true stereoscopic pair of images without wearing any devices on the viewers head.

Background

Most computer and medical imaging displays that purport to show 3-D images actually only show a 2-D projection of a 3-D object.  A good example of this is bar chart with 3 variable axes instead of 2 which is projected into the 2 dimensional plane of the display.

Human vision perceives three dimensional space by presenting the brain with a stereo-pair of images.  This is how depth perception is obtained.  To view on a notebook screen or TV plasma display, etc. one eye must be able to see one of the stereo-pair images and the other eye must see only the other stereo-pair images with no cross-over between them.  This has typically been done by alternately displaying each image on the screen while alternately shuttering a polarizing shutter over each eye of the viewer.

Project Description

This new approach that will not encumber the person viewing the screen with any devices on their person will use a very fine lenticular screen superimposed on the face of the display. The lenticular screen is made up of tiny cylindrical lenses positioned vertically side-by-side with a pitch equal to one lens every 2 pixels (or multiples thereof) horizontally such that the left eye will see only the even numbered pixels while the right eye sees only the odd numbered pixels (or visa versa.) The cylindrical lenses of the lenticular screen spreads the pixels out so that a complete but different image is seen by each eye.  When the person is positioned at the right distance from the screen and positioned correctly in a horizontal position a full stereo pair of images will be viewed with full depth perception.

The purpose of this project is to develop the software that controls the video display card of the display that will take the input of a stereo-pair of images and interdigitate them so that one of the images is on the horizontally odd-numbered pixels and the other image is on the even-numbered pixels.

Constraints: Must use standard off-the-shelf hardware consisting of a PC with an LCD or plasma display.

Notes: Contact the customer for additional information

Alex Metherell
E-mail: alexm@ics.uci.edu

Back to Index


Jave-based Genome Browser for Mitochondrial DNA.

MItochondria are semi-autonomous organelles existing within each one of our cells which are involved in energy production (the "power plants" of the cell). They have relatively short genomes consisting of 16,500 letters over the four-letter DNA alphabet. The genome contains 13 genes and several hundred positions that are variable across the human population. The goal of the project is to build a Jave-based browser of the mitochondrial genome that would allow one to zoom in and out of any region along the genome and view the corresponding annotations. Such a toold could be used by scientists in different fields from biology, to medicine, to anthropology, and even to forensic science. The project would be carried in close collaboration with the groups of Dr. Baldi (ICS) and Dr. Wallace (College of Medicine).

Back to Index


ICS125 FQ04
Richard N. Taylor
School of Information and Computer Sciences
University of California, Irvine CA 92697-3425