There are essentially three ways to use a LADSPA plugin library in jMax Phoenix: let jMax to automatically load all the available LADSPA libraries, explictly load libraries from preferences or from packages description, or embed the ladspa package in a jMax package.
Independently on how you configurate jMax, if a Ladspa library is loaded, jMax Phoenix will define a jMax object for each plugin contained in the library, using the plugin label as the object name, and adding ”~” at the end to respect the jMax naming conventions.
The object will have an inlet for each plugin input port, either control or signal, and an output for each output ports, again, either control or signal.
Input control ports will take ints or floats. The first inlet take also a list, mapping each value to a control inlet. Control output ports can be fired by sending a bang to the first inlet.
The object take arguments, as many as control inlets, that are used as initial values for the plugin control ports; values that not specified are set to the plugin port default value.
If the library has been loaded using the automatic scanning option or the require tag (see below for explications), jMax Phoenix automatically extract all the available information and generate help texts for the object and its inlets and outlets (that you can see by mousing over the object or its inlets or outlets).
If the library has been loaded from a user defined package, jMax Phoenix will not extract the information automatically, because the pacakge should already include it (see below for details).
By default, jMax Phoenix load all the LADSPA libraries that are found on a specific path, and make them availables as jMax objects.
This behaviour can be configured in the preferences; the following XML snippet is an example of how ladpsa is configured.
<?xml version="1.0"?> <jmax> <preferences> <laspa scan="true"> <path url="/usr/local/lib/ladspa"/> <path url="jmax://home/.ladspa"/> </ladspa> </preferences> </jmax>
The above code enable auto scanning of ladspa directories, and define two directories where to look for the path.
You can add other directories either in your personal configuration file ~/.jmax.xml or
by changing your configuration file; if you want to remove the existing path, you need to
edit the platform specific configuration file.
You can disable scanning by adding the following line to your personal configuration file, inside the preference block.
.... <preferences> .... <ladspa scan="false"/> .... </preferences> ....
Under Linux, the searched directories are those in the above example; in Ubuntu Studio, for example, this give access to around 640 new jMax Phoenix objects.
Under MacOS and Windows, the values are not yet defined. Any suggestions ?
The require tag can be used in the preferences or in a package definition to load an explicitly named ladspa library.
If for some reason you do not want or do not need an automatic scan, you may configure jMax Phoenix to load a specific number of ladspa libraries by using the require tag in your personal preference file, like in the following XML fragment.
<?xml version="1.0"?> <jmax> <preferences> <require ladspa="ladspa-library-1"/> <require ladspa="ladspa-library-2"/> <require ladspa="ladspa-library-3"/> </preferences> </jmax>
You instruct jMax Phoenix to load the named plugin libraries. The library name can be a full jmax URL,
or just the library file name; in the latter case, the library is searched in the standard ladspa
directories, as given by the environment variable LADSPA_PATH.
As described above, meta data for the plugin objects is automatically generated and loaded in the user interface.
If a package depends on a set of ladspa plugins, you may use the require tag in the package description file to load the specified libraries, like in the following XML fragment.
<?xml version="1.0"?> <jmax> <package name="MyPackage"> <require ladspa="ladspa-library-1"/> <require ladspa="ladspa-library-2"/> <require ladspa="ladspa-library-3"/> ....... </package> </jmax>
jMax Phoenix will load the ladspa libraries just before the package. This method is fine if you deliver your package to well known environments, but if you want to be sure that the ladspa libraries exist in the target environment, you may package them within your jMax package; see next section
You can define a package that include a set of ladspa libraries.
The object can be explicitly defined as being object of ladspa type, using
a number of object xml element (See the package documentation
for details), and you can package the ladspa libraries within the jMax package jar.
You'll have to object metadata yourself, and you may add jMax help patches for the plugins. The jMax object name in this case may also be different from the LADSPA label.
A small program to extract most of the meta data information from a LADSPA library is provided in the jMax Phoenix distribution.
The advantage of this method is that you can provide the LADSPA libraries needed to your application within the package, so the installation and distribution is vastly simplified.
Details on how to create a package embedding one or more ladspa plugin libraries is given here .
jMax Phoenix does not require a special compilation for LADSPA plugins. But take care of the fact that a plugin compiled with a 64 Bit architecture will probably not works on a 32 bit environment.