On Sun, 2012-08-19 at 22:25 -0700, Sean Bolton wrote: > Hi Dave, > > On Mon, 20 Aug 2012 00:27:12 -0400 David Robillard <d...@drobilla.net> > wrote: > > I am porting to LV2 some AMS-influenced plugins (mainly those by Fons) > > which have odd 1/Oct frequency ports. I understand why it is > > sometimes convenient to use octaves rather than the more typical Hz > > for frequency, but after some digging to figure out how to precisely > > describe this unit, I discovered the central frequency is middle C, > > i.e. C4, i.e. around 262Hz. > > I know that most of the 1/octave ports in these plugins describe > *intervals* rather than *frequencies*, that is, they describe frequency > ratios relative to bases usually specified by other ports. > > Are you saying that there are some 1/octave ports which > are actually used to describe absolute frequencies, independently > of other input? If so, that is odd, as you said.
Sure. They are used for /all/ frequencies. Some are only relative, but not all, notably oscillator frequencies and filter cutoff. > But to address your > question, any "standard" for 0.0 = X Hz is going to be arbitrary, > whether it is ~261.625Hz or 440Hz or even 415Hz for the baroque > folks. Sure. Only 0 Hz could really be argued as not arbitrary, but that doesn't work. However, tuning being based on A4=440Hz (or perhaps a different A4, but 440 as standard) is certainly the most standard 'tuning note' if you have to pick. > If you're proposing something that asks plugin authors to > "fix" their plugins to the standard, why not just ask them to be clear > about whether a port specifies an interval or an absolute frequency, and > if it's an absolute frequency, use the more typical Hz port type? I agree, Hz ports are indeed generally less hassle in everything except AMS, and used pretty much everywhere else. Nobody ever got fired for using the SI unit. However these plugins use 1/Oct, and converting them would be non-trivial and change their interface considerably. I am only putting them in a more well-defined package, and do not plan to fragment the guts. Limitations of LADSPA and funny ill-defined units aside, they are excellent sounding plugins designed to work in concert and I am merely doing a conservative port faithful to the originals. It may be a good idea to specify absolute or relative explicitly, though I'm not sure if unit is the best way to encode this. That concept could apply to any unit, so probably not. While maybe theoretically useful information, no immediate use in hosts comes to mind, so I'll just ignore that idea until there's a concrete reason to do otherwise. I am, as usual, not really interested in trying to mandate what developers may do, only that it is done sensibly and plugin interfaces are actually well-defined and usable. IIRC this has come up before and some feel quite strongly that this unit is best in modular environments. Fine. However, many of these ports *do* express an absolute frequency (regardless of mod/offset/tune parameters), and therefore this unit needs to define a center frequency in order for the interface to these plugins to be well-defined. While problematic in LADSPA, I don't really have a problem with this unit in LV2 since we can describe it properly and a clever host can automatically do the right thing (in conjunction with CV being actually distinguishable from true audio, this should make the filters usable in more non-modular hosts, e.g. automating moog filters in a DAW) Thanks, -dr
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev