4. Writing LADSPA Hosts

This section contains a number of considerations, and some advice, for LADSPA hosts.

Of course, LADSPA hosts vary a lot more than the plugins, so we cannot specify a cookbook recipe.

4.1 General Considerations

Before trying to host LADSPA plugins, figure you what the limits of your host's support should be. Hopefully these guidelines will be of some value:

• Hosts should be able to inspect any plugin library and determine its suitability. For example, for many applications an output port is mandatory, but the format doesn't mandate that. Be clear in your error handling.
• Hosts should generally provide an interface to the control ports.
• Hosts may wish to cope with multi-channel sound. Some LADSPA plugins directly deal with stereo as two separate ports; others will require that you instantiate two handles.

4.2 Finding which plugins are available.

Hosts should obey the LADSPA_PATH environment variable, and may actively seek out plugins there.

4.3 Loading and using a plugin

Here is how the host should use a plugin:

• It should obtain the LADSPA_Descriptor* from the ladspa_descriptor function.
• Create and destroy plugin handles:
  • call instantiate to make each instance you want.
  • call activate to prepare/clear the instance for use and call connect_port for each port (the host may run these in any order it wants).
  • call run or run_adding as many times as you want. It may also run connect_port more times to change the buffer locations.
  • call deactivate if it is not NULL. Then the plugin may be destroyed or re-activated.
  • call cleanup on the plugin handle (returned from instantiate).
• Unload the plugin when you are down with all plugin instances that reference it.