On Mon, 2012-08-20 at 10:18 +0000, Fons Adriaensen wrote: > On Mon, Aug 20, 2012 at 12:27:12AM -0400, David Robillard wrote: > > > tl;dr: I think the most reasonable standard for an absolute 1/oct > > frequency unit is 0.0 = 440Hz > > You're confusing two things: unit and reference point. The second > you have only on a log scale, for example if you use dB you need > to define what 0 dB means.
Good point, but a "unit" in general can include a reference point as part of its definition. When used relatively, as with dB for e.g. gain, it's usually obvious what the reference point is. When used absolutely, sure, you need a reference point, but multiple reference points is hell. Augmenting "octaves" is probably a bad idea though, I will probably make a new unit for "octaves centered around <whatever>". > The unit here is 'octaves'. The reference point is not a property > of any port AFAICS. It could be a property of the plugin: the > frequency it is set to when all control inputs are zero. That is a sensible way of looking at it, but a plugin /could/ have two ports in octaves with different reference points. Probably shouldn't, and certainly weird, but it makes sense. You can think about it either way, but port-centric is much simpler in practice. Precisely defining port "units"(+reference points) is straightforward, and fits in with what hosts actually do (check unit, "oh, it's ms and I have s", do the right thing to get the desired value in the port). Doing so for the plugin in metadata is a slippery slope to having to precisely define the entire internal operation of the plugin is so it's clear what that reference point means. If we really want to cling to the idea that this unit is strictly relative, better to use define the reference point dynamically with a control input (in Hz) as Sean suggested, though this would add a very tiny amount of overhead and might cause problems for plugins with precomputed things(?)... It is also tricky for things working with note numbers since the convertion to and from note numbers is very simply, but if you involve tuning in Hz, not so much. ... but anyway, this is all ontology astronautics. What is needed, in practice, is a way to have one particular numeric value convey one particular absolute frequency, as it does with Hz, or with AMS's convention. That means a standard reference point, regardless of how or where it's specified. I guess, since it's your code... how do you feel about using 440 instead (at least in LV2 versions), and how difficult would this be to adjust? It's not immediately obvious to me what magic number twiddling would have to happen. I realize in reality I am probably stuck with this (IMO ill-considered) convention... oh well. Seemed worth mentioning anyway. Cheers, -dr
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
