Song Manager: The Song Manager is the interface between the Network Manager, the GUI, the Song, and the Mixer. The Song Manager is notified via callbacks of changes to the song made by the GUI or by the Network Manager in response to a remote user's actions.
Mixer: The mixer takes data from the Song and then looks up the appropriate samples from the Sample Collection. It composites together the samples for the currently playing segment and stores the result in the Audio Stream (a buffer). This component would also apply effects such as speeding up or slowing down samples. The Mixer updates the Audio Stream buffer when the Song Manager tells it to (when the segment has changed).
Song: The Song is the internal representation of a song. It contains several tracks which store references to the actual samples that they correspond to from the Sample Collection.
Network Manager: The Network Manager is responsible for sending and receiving changes to the song over the network. It uses callbacks from the GUI to initiate new network connections. LoopBack uses a client/server model for networking, with one user as the "host" and the other users as clients.
Server/Client Socket: TCP sockets are used for network communication, because we would rather have the reliability of TCP than the slightly lower latency of UDP. We make this choice because changes to the song do not need to appear to other users immediately (since the current segment constantly loops, it's okay if we wait an extra loop for our changes to propagate).
GUI: The GUI is both where users edit songs and where they initaite network connections and change permissions for remote users. The GUI communicates with both the Song Manager and Network Manager via callbacks. The Song Manager is responsible for keeping the display of the song in sync with any changes that are made, by calling into the GUI. It will probably be written using Qt, but will need to have a lot of custom widgets.
Sample Collection: The Sample Collection stores all of the samples. Depending on the number of samples it could be a database or a less complicated data structure. It keeps track of where the corresponding files are on disk for all of the samples, and is responsible for bringing them into memory when needed.
Audio Stream: The Audio Stream is a buffer of the audio data for the current segment. It is written by the Mixer and read by the JACK Thread.
JACK Thread: The JACK Thread is driven by callbacks from the JACK server, and is responsible for copying data to the server when needed (JACK uses a "pull" model).
JACK: JACK is a low-latency audio server for Linux. It is used to ensure that audio is played back without gaps or stutters.
JACK: Used for relaible audio playback. Might be able to take over some of the functionality of the Mixer as far as playing multiple tracks concurrently.
Other libraries such as libsndfile might also be used for reading and writing audio to and from files.
The Team Lead will make sure that everything stays on schedule and will help coordiante the members of the group. Also, she will help any person or people that fall behind schedule with coding if need be.
The coders will be responsible for coding their respective components according to the system design
The Documentation Master will work closely with the coders and architects to produce high-quality documentation of both internal APIs and end-user features. In addition, he will be responsible for creating a course webpage and taking notes at meetings and posting them to the webpage. He will be in charge of the final README document when the software is released.
The Architects will be responsible for having a good understanding of how the overall system is designed and how the pieces fit together. Questions and conflicts about the interfaces of the various components will be resolved by the architects. They will also play a support role during integration.
The Tools Tzar will be responsible for making sure that tools like SVN are set up, and will answer questions that other group members have about the tools.
The testers will be responsible for running unit and system tests, and possibly will deploy an automated testing system. Also, they will be responsible for finding users to do user-testing.
The system model in my specifications document was very vague, and was not detailed enough to show what was going on. I had to redesign things when I did the top level design in order to make everything actually workable.
Also, I didn't mention that external libraries would probably be necessary to handle some of the audio-related tasks in my specifications document.