On Mon, 2012-08-20 at 16:06 +0000, Fons Adriaensen wrote: > On Mon, Aug 20, 2012 at 11:24:17AM -0400, David Robillard wrote: > > 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. > > If have som difficulty in imagining what that would mean in practice... > Could you give an example ? > > As I see it, all (frequency) ports are relative. +1 means 'add an > octave to whatever you have'. If they are all zero (which means they > don't have any effect) you get the internal reference frequency. > What difference could there be between two ports, both 'octaves', > both zero, but having a different reference ?
Well, the oscillators for example have a frequency input port. One expects to be able to plug a frequency from the 'note module' (e.g. driven by keyboard) into this port and get the desired result. > > 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 you couild give a list of the ones you're working on, I could give you > the magic numbers. So far I have done all of MCP and all of VCO. http://svn.drobilla.net/lad/trunk/plugins/fomp.lv2/ I have put them all in the same collection. On that, if you feel like incorporating/maintaining these upstream, I can easily make it so they can co-exist and build alongside the LADSPA versions. The changes to the core code is only typedeffing a few types for frame counts and so on. Otherwise it's just the addition of new interface binding code (very small) and one data file per plugin. If not, that's fine too. > Note that these plugins really were designed for AMS. Some controls (those > that map to GUI sliders etc) are 'control rate', the others are audio rate. > The latter ones are never used as such, they are subsampled and interpolated, > with the interpolation being done on the internal variables rather than the > inputs. That's fine. LV2 has a distinct type for CV ports so they don't get confused with actual audio ports. I do not particularly like the idea of plugins designed for one particular host, but the oscillators and filters at least are obviously intended for a modular environment. I am mainly interested in them for Ingen, where they are used much like in AMS. (Ingen itself can run as a plugin, so the bigger idea here is to allow users to patch up their own instruments and load them in any host without writing any code) > Alsa note that the VCO ones are really out of date. I have much better > replacements, but they'll have to wait. Oh well. I am just porting what is. Better oscillators sure would be really nice though :) I havn't done any ear testing in a long time, but IIRC these are among the best that are currently out there as free software. > > I realize in reality I am probably stuck with this (IMO ill-considered) > > convention... oh well. Seemed worth mentioning anyway. > > The thing that matters is consistency. For example if you have something > that converts MIDI note numbers to a 'voltage', that should use the same > reference point as the plugins. I probably followed the convention used > by AMS' midi controller modules. Yep. Mine used Hz, but I added such a port to make using these plugins possible without the nuisance of having to use a converter. Doing this, and wanting to document it properly, is what led me to question the reference note. -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
