Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO)

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@email-addr-hidden>
> 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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev