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 http://soundtank.sourceforge.net/input_maps ---jacob.................. (*) 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 inactive_instances -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 http://soundtank.sourceforge.net/input_maps _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963