[linux-audio-dev] LADSPA Instruments

robbins jacob jacobrobbins_ at hotmail.com
Wed Apr 9 21:50:01 UTC 2003

While reading over the ladspa v1.1 header, i noticed that hint number 0x2C0 
is defined as follows:

   /* This default hint indicates that the Hz frequency of `concert A'
   should be used. This will be 440 unless the host uses an unusual
   tuning convention, in which case it may be within a few Hz. */
   #define LADSPA_HINT_DEFAULT_440     0x2C0

   These "LADSPA_HINT_DEFAULT_..." hints tell a host how to set the values 
for a port when the user doesn't supply any values.

   But then it hit me, "what kind of port could have a default defined as 
440 HZ, concert A?" Clearly, the only reasonable use for a port of this type 
is to control the pitch of an instrument-type object. Any ladpsa plugin that 
has a port with hint DEFAULT_440 set, be it a true synthesis-engine with no 
audio input ports, or some sort of tonal filter, can be used to generate 
coherent melodic output (ie tunes,songs,melodies,pitched-vocalizations...).

   This is important because it means that we can implement _right_now_ 
ladspa instruments that can be used without the user having to hook up 
control A to port B or generally know what the hell they're doing. In fact, 
the sine oscillator plugin, provided by Richard Furse as an example plugin 
for the ladspa sdk, is a reference example that host programmers can code 
off of _right_now_. Just remember that each ladspa plugin instance is a 
single voice, so polyphony must be implemented in the host. Fortunately, 
this is not that hard(*).

   The DEFAULT_440 hint took me by surprise because there aren't many ladspa 
virtual synths out there. With the use of this hint, coding a synth is about 
as simple as we would expect from ladspa: very. Many projects with 
integrated softsynths could put some of their core dsp routines into ladspa 
plugins and start seeing immediate benefits because the widespread use of 
the ladspa format facilitates sharing plugins between apps. Once again, this 
is all completely possible _right_now_ with the current version of ladspa.

   What's even better is that ladspa instruments will be automatically 
ported to the new XAP plugin format when it becomes available. This is 
because one of the first XAP plugins will be a plugin to "wrap" LADSPA 
plugins inside an XAP plugin. Plugin developers will then be able to choose 
whether to fully move to the new plugin architecture, continue using ladspa, 
or, (isn't linux great:) both.

   For the record, the XAP standard has settled on using linear pitch 
instead of pitch in HZ. linear pitch is defined as a floating point value, 
with 0 = 440 hz, and scale 1.0/octave. (example 440 hz = 0 lin pitch, 220 hz 
= -1 lin pitch, 110 hz = -2 lin pitch, 55 hz = -3 lin pitch). As you can 
see, the mapping between linear pitch and HZ is an isomorphism, so 
translation between the two is not much of an issue.

   Remember that each ladspa plugin instance is only ONE voice in a possibly 
polyphonous instrument. This means that plugin authors do not need to worry 
about the MIDI standard (voice_on, voice_off) at all if they don't want to. 
Translating from midi to ladspa is one of the host's burdens. I have placed 
a simple scheme for doing this at 


(*) to make a host use multiple ladspa plugin instances as a single 
polyphonous instrument do the following:
-make a linked list of all the plugin instances as you activate them
-make a linked list called active_instances and one called 
-add all plugin instances to the inactive_instances list
-have your realtime thread move instances from inactive_instances to 
active_instances when it activates them to handle a MIDI voice_on event, and 
back when a MIDI voice_off arrives saying that the note is finished. I have 
placed a simple scheme for handling input events at 

Protect your PC - get McAfee.com VirusScan Online  

More information about the Linux-audio-dev mailing list