Extending the Software |
---|
EXPLANATION OF THIS SECTION
This section of the manual provides hints on how programmers can extend jProductionCritic's functionality.
In order to extend jProductionCritic developers can download its source code and Javadocs from the jMIR web page.
ADDING NEW ERROR CHECKING ALGORITHMS
The principle way in which researchers will likely want to extend jProductionCritic is to add new error checking algorithms. As noted in the section of the manual on jProductionCritic's class structure, each error checking algorithm is implemented as a separate class in the jproductioncritic.errorcheckers Java package, and each such separate class extends the ErrorChecker abstract class. This architecture makes it easy to add new error checking algorithms essentially as plug-ins.
Each ErrorChecker subclass must, of course, implement ErrorChecker's abstract methods. Of particular importance, the checkForErrors method is where the core error checking processing must be implemented. jProductionCritic will call this method (with the audio to analyze provided as an argument), and this method must return a list of ErrorReport objects detailing any problems found.
The other abstract methods which must be implemented (getDefaultConfigurationSettings and validateConfigurationSettings) are simply related to specifying the valid configuration settings that the new error checker needs. The new ErrorChecker subclass can specify whatever new configuration settings it needs, and jProductionCritic will automatically add these new configuration settings to new configuration files that it generates (jProductionCritic can be forced to generate a new configuration file simply by deleting the old file).
New ErrorChecker subclasses must also implement a constructor that sets all fields (inherited and not) to default values and that has a single argument consisting of a ConfigurationSettings object. If this ConfigurationSettings argument is non-null, then some or all defaults are replaced by the specified values.
Developers are encouraged to look at the code for any of the existing ErrorChecker subclasses (e.g. DigitalClipping), as they can serve as helpful models.
Once the new ErrorChecker class is complete, all that a developer must do to have jProductionCritic begin checking for it is to add one line to the JProductionCritic.getAllErrorCheckers method that adds an object of the new class to the list of implemented ErrorChecker objects. Everything else is then automatically taken care of, including providing the new error checking algorithm with audio, formatting its error reports, parsing its configuration settings and more.
ADDING NEW GLOBAL SETTINGS TO THE CONFIGURATION FILE
As noted in the section of the manual on configuration settings, certain settings are specific to individual error checkers, and others can be applied to multiple error checkers. If developers wish to add new global configuration settings, they can do so by adding an appropriate line to the ConfigurationSettings.setConfigurationsToDefaults method. Developers can observe how this is done with the error_report_merge_proximity_maximum setting, for example.
EXTENDING THE GUI
Those who wish to extend the GUI may do so by modifying the jproductioncritic.gui package. It should be noted that the GUI classes do not provide any real processing functionality, as all they do in essence is to formulate the actions of the user in ways that can be fed into the JProductionCritic.performAllProcessingBasedOnCommandLineArguements method, just as command line arguments would be.