Specifications:
Federation: This is the name of the federation you wish to connect to. For our purposes, it should probably be 'flo'.
Orchestra: This is the name of the Orchestra you want to connect to. This is dependent on your location (ex. CMU, LSU).
Name: This is the performer name. It should be something unique.
IP: Your IP Address. Should be sensed and provided automatically by Java.
Server URL Base: The prefix address of the server URL. Defaults to http://www.music.cs.cmu.edu/cgi-bin/
Be the orchestra's supernode?: Toggle if you are registering as the supernode (One per orchestra).
Be a performer?: Radio button for being a Performer.
Be a conductor?: Radio button for being the Conductor (one per federation).
Supernode that's not performer or conductor?: Chat-only option for specific case.
Debug options:
Buffer size: Some performers can have issues with clicking - this can be solved by adjusting the buffer size. It should be made just big enough to avoid clicking, trial and error may be necessary for this. (6-8 were found to be reasonable values in initial tests)
Fast Start: For debug purposes - fast start will only load one sample, for faster testing.
The first time the user runs the program, some settings will be filled in with defaults. The user's settings are saved to a .jar file, which, each subsequent time the user runs the program, will automatically fill in the GUI with the previously saved settings.
To build and use FloCtrl, one needs to export jar file and put resources directories at the same directory:
./FloCtrl.jar
./sound/...
./Lang/...(language images, please look at attachment.
If you have a mac, it is convenient to use a app bundle (also in the attachment). To use this bundle, you need to manually copy sound directory into FloCtrl.app/Contents/Resources/ since the attachment space is not large enough for a full app file on this page. If you updated your jar file, you can replace the jar file under FloCtrl.app/Contents/Resources/Java/.
The max heap size is already set to 512 MB in the bundle setting. If you use windows, you need to manually set the heap size using -Xmx512 command in your console.
Our GUI is complete and working, and has a specification written for it on the floctrl wiki. It saves and loads settings correctly. It's been relabelled for ease of use and understanding by users, rather than debugging purposes.
We are initializing everything correctly (as far as we know based on what other groups have told us), and have made possible errors during initialization more explicit.
We were still working on getting a good runnable .jar file. However, zeyu has given us some help, and we are going to create a more detailed and simpler set of instructions.
In the early phases: Work with all the groups to design class Main. This means finding out all the classes that need to be created and calling the right initialization methods in the right order.
As people start developing code, you should try to compile the code into a single program, looking for missing components, name conflicts, bugs, places where callers do not properly call APIs, etc.
The danger of this assignment is that you will do more debugging and testing than coding, so you may not end up with much code to show for your efforts. Therefore, you should keep some notes on your work and interactions with other groups. You should be able to say that you identified and helped fix quite a few defects.
When this is the first time the project is run, we ask for all fields relevant to the system (ie role, ip address, server name, federation name, your name).
The GUI, as well as the rest of the project, runs on the GUI thread. When the user finishes the initial login process, the form will vanish and the user GUI will be shown.
Initialization is controlled by FloCtrlMain.main(), where execution starts.
The project is structured as a collection of sub-projects such as Clock and Chat. There should be one instance of the main class of each sub-project. Sub-projects call upon other sub-projects by invoking methods of these instances, so obviously, each sub-project instance must have a way to reach other sub-project instances.
This could be handled by adding static (class) variables to FloCtrlMain and setting them to the instances of sub-projects. Unfortunately, this does not work because it creates mutual dependencies between (sub)projects and cycles are not allowed in the Eclipse build system.
Instead, there is a static variable in each sub-project's main class, e.g. Clock.clock and Chat.chat. These variables are set by FloCtrlMain during the initialization phase.
Since we only want one instance of each subsystem (at most), each subsystem will count instances and raise an error if someone tries to make a second instance (just to be safe).
This is something like the Singleton pattern, but rather than allowing anyone to make the first instance, we enforce that main() and only main() will make all instances. This gives us a well-defined and readable order of instantiation. The basic order is:
We will create a simple form GUI with a button to setup the program. Setup initializes all objects stated above. When setup is complete, the form will be hidden, and the GUI corresponding to the role of the user will be shown.
Also, preferences will be saved to a Java Preferences object.