20 Aug
2012
20 Aug
'12
6:27 a.m.
Hi all,
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.
For hosts to be able to use such plugins effectively, I need to
precisely describe this unit (and then other plugins can implement to
spec and they will all get along). We already have an 'octaves' unit,
but no base frequency is defined. I can add one, but I am not sure
about this strange choice.
Nobody tunes anything based on middle C, with its odd frequency of
261.62556... writing this in a spec gives me pause. I suspect it
evolved from MIDI code in AMS where the 60 of middle C looks as
reasonable as anything else, but when you try to actually
define/document the unit it looks silly.
I think the natural central frequency to use is A440, at precisely a
nice round 440.0 Hz, so 0.0 is A4=440.0Hz, 1.0 is A5=880.0Hz, -1.0 is
A3=220Hz, and so on. Whenever a default or center or tuning frequency
is needed, you use A4/440Hz...
tl;dr: I think the most reasonable standard for an absolute 1/oct
frequency unit is 0.0 = 440Hz
Thoughts?
-dr
20 Aug
20 Aug
7:24 a.m.
Hi Dave,
On Mon, 20 Aug 2012 00:27:12 -0400 David Robillard <d(a)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. 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. 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?
-Sean
9:14 a.m.
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(a)drobilla.net>
wrote:
Sure. They are used for /all/ frequencies. Some are only relative, but
not all, notably oscillator frequencies and filter cutoff.
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. 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
12:18 p.m.
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.
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.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
5:24 p.m.
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:
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>".
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. 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
6:06 p.m.
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:
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 ?
On Mon, Aug 20, 2012 at 12:27:12AM -0400, David
Robillard wrote:
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>".
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. 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. 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.
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.
Alsa note that the VCO ones are really out of date. I have much better
replacements, but they'll have to wait.
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.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
6:34 p.m.
On Mon, 2012-08-20 at 16:06 +0000, Fons Adriaensen wrote:
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.
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
On Mon, Aug 20, 2012 at 11:24:17AM -0400, David
Robillard wrote:
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.
On Mon, 2012-08-20 at 10:18 +0000, Fons
Adriaensen wrote:
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 ? On Mon, Aug 20, 2012 at 12:27:12AM -0400, David
Robillard wrote:
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>".
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. 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. 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. 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.
9:26 p.m.
On Mon, Aug 20, 2012 at 12:34:38PM -0400, David Robillard wrote:
So far I have done all of MCP and all of VCO.
You'll find a call to exp2ap() with a complicated sum as
the argument. One of the terms of that sum, usually near
the end, is a constant. Adding 0.75f to that should
transpose verything from middle C to A (440) - 3/4 octave
up.
Also please check that all FP constants are single
precision as well as all math.h functions. I was
rather careless with that when I wrote those plugins.
It matters, in particular if you compile for 32-bit
SSE.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:54 p.m.
On Mon, 2012-08-20 at 19:26 +0000, Fons Adriaensen wrote:
On Mon, Aug 20, 2012 at 12:34:38PM -0400, David
Robillard wrote:
Makes sense. Great, thanks.
So far I have done all of MCP and all of VCO.
You'll find a call to exp2ap() with a complicated sum as
the argument. One of the terms of that sum, usually near
the end, is a constant. Adding 0.75f to that should
transpose verything from middle C to A (440) - 3/4 octave
up. Also please check that all FP constants are single
precision as well as all math.h functions. I was
rather careless with that when I wrote those plugins.
It matters, in particular if you compile for 32-bit
SSE.
There is a GCC flag that warns about this (dubious float promotions), I
will run them through that.
Concerns about fragmentation?
Cheers,
-dr
21 Aug
21 Aug
10:59 a.m.
On Mon, Aug 20, 2012 at 04:54:16PM -0400, David Robillard wrote:
Concerns about fragmentation?
Fragmentation ???
Caio,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
8:33 p.m.
On Tue, 2012-08-21 at 08:59 +0000, Fons Adriaensen wrote:
On Mon, Aug 20, 2012 at 04:54:16PM -0400, David
Robillard wrote:
i.e. these LV2 ports having different functionality than the LADSPA
originals.
Other than some trivial typedefs (SampleRate, SampleCount, PortIndex,
PortData), I have not touched the actual implementations at all. I can
send patches for that bit if you like.
-dr
Concerns about fragmentation?
Fragmentation ???
4909
days inactive
4910
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
3 participants
participants (3)
-
David Robillard -
Fons Adriaensen -
Sean Bolton