8 May
2007
8 May
'07
9:53 p.m.
The current iteration of the LV2 specification seems to have settled
down, and there are a significant number of implementations now, so,
assuming that there's no problems found with the current spec I
propose to rename it as 1.0 in a few weeks time.
Background - http://lv2plug.in/
LV2 is an upcoming standard for plugins and matching host
applications. It's mainly targeted at audio processing and generation.
LV2 is a successor to LADSPA, created to address the limitations of
LADSPA which many hosts have outgrown. LV2 is not backwards
compatible, but migration tools will be released once the
specification is finalized.
Implementations
SLV2 - a library by Dave Robillard that makes it easy to add LV2
support to existing hosts, includes example code and documentation.
tarball: http://download.drobilla.net/ , docs: http://drobilla.net/
doc/slv2/modules.html and sample code: http://drobilla.net/doc/slv2/
lv2_simple_jack_host.c
LL plugins - lots of native LV2 plugins, an extension and a host that
implements the extension, all written by Lars Luthman. http://ll-
plugins.nongnu.org/
Zynjacku - a host for LV2 instruments by Nedko Arnaudov. http://
home.gna.org/zynjacku/
Ingen - a modular synth host that uses LV2, DSSI and LADSPA plugins
as its modules. Written by Dave Robillard. http://wiki.drobilla.net/
Ingen
SWH plugins - a port of my LADSPA plugins to LV2. http://
plugin.org.uk/lv2/
- Steve
9 May
9 May
6:15 a.m.
On Wed, May 09, 2007 at 02:53:33AM +0100, Steve Harris wrote:
The current iteration of the LV2 specification seems
to have settled
down, and there are a significant number of implementations now, so,
assuming that there's no problems found with the current spec I
propose to rename it as 1.0 in a few weeks time.
Background - http://lv2plug.in/
Some comments / potential problems.
1, Only integer sample rates. This should be at least a fraction
of two integers.
2. Plugins are expected to have a fixed set of ports. There are
cases where a plugin can only decide wich ports it will need
after being instantiated.
3. Plugins may want to delegate some of the processing to threads
running just below the audio thread priority, so this priority
is an essential initialisation parameter.
4. There are 'audio rate' and 'control rate' ports, but no 'init
time' ports. How are plugins supposed to discover initialisation
parameters ?
5. If a plugin is instantiated multiple times to operate on
multi-channel data it may want to share control ports within
such a group, if only to optimise the (possibly complex and CPU
intensive) code that maps external control values to internal
data. I see no way to form such groups.
6. The only way for plugins to discover if a control port value
has changed is to keep a copy and compare all values during
each run(). See also (7).
7. There is no fixed audio period. Host may call run() for any
number of samples. This is probably meant as a way to allow
hosts to change control values at arbitrary points, but this
defeats the purpose of having control rate in the first place.
It's a typical 'let's be lazy' solution that does not solve
the original problem except in some simple cases.
Some algorithms can't be written to run efficiently - or at
all - in such circumstances. Plugins should be run() with
fixed block size.
If plugins are to know that certain things need to happen at
particular offsets into a processing period then they should
be passed this info as a list of events (timestamed relative
to the start of the period), and be allowed to deal with that
in the most appropriate way, which may well be very different
to slicing up the audio period.
Some algorithms may even require that such events are presented
some number of samples ahead of their due time. This of course
forces the plugin to queue them internally, but in some cases
that's the only way to do it.
What is needed here is a generic way to pass a list of time-
stamped event to a plugin via a control rate port, and then
let the plugin deal with them as it sees fit.
--
FA
Follie! Follie! Delirio vano è questo !
6:38 a.m.
On Wed, 2007-05-09 at 12:21 +0200, Fons Adriaensen wrote:
On Wed, May 09, 2007 at 02:53:33AM +0100, Steve Harris
wrote:
Given that JACK only supports integer sample rates I don't think that
this is a big deal. On the other hand I can't really see any
disadvantages with having it as a float or double, so if there are any
compelling reasons for doing that I think I agree.
The current iteration of the LV2 specification
seems to have settled
down, and there are a significant number of implementations now, so,
assuming that there's no problems found with the current spec I
propose to rename it as 1.0 in a few weeks time.
Background - http://lv2plug.in/
Some comments / potential problems.
1, Only integer sample rates. This should be at least a fraction
of two integers. 2. Plugins are expected to have a fixed set of ports.
There are
cases where a plugin can only decide wich ports it will need
after being instantiated.
This can be done using an extension. I think Nedko Arnaudov has already
specified one for dynamically appearing and disappearing ports.
3. Plugins may want to delegate some of the processing
to threads
running just below the audio thread priority, so this priority
is an essential initialisation parameter.
Can be done as a HostFeature.
4. There are 'audio rate' and 'control
rate' ports, but no 'init
time' ports. How are plugins supposed to discover initialisation
parameters ?
Can be done as a HostFeature.
5. If a plugin is instantiated multiple times to
operate on
multi-channel data it may want to share control ports within
such a group, if only to optimise the (possibly complex and CPU
intensive) code that maps external control values to internal
data. I see no way to form such groups.
Can be done as a HostFeature.
6. The only way for plugins to discover if a control
port value
has changed is to keep a copy and compare all values during
each run(). See also (7).
This isn't all that expensive, but if a plugin really really needed a
new callback to be executed by the host when a control port value
changed it could be done as a HostFeature.
7. There is no fixed audio period. Host may call run()
for any
number of samples. This is probably meant as a way to allow
hosts to change control values at arbitrary points, but this
defeats the purpose of having control rate in the first place.
It's a typical 'let's be lazy' solution that does not solve
the original problem except in some simple cases.
Some algorithms can't be written to run efficiently - or at
all - in such circumstances. Plugins should be run() with
fixed block size.
Can be done as a HostFeature. In fact, there are two such extensions
already - see http://tapas.affenbande.org/wordpress/?page_id=53
If plugins are to know that certain things need to
happen at
particular offsets into a processing period then they should
be passed this info as a list of events (timestamed relative
to the start of the period), and be allowed to deal with that
in the most appropriate way, which may well be very different
to slicing up the audio period.
Some algorithms may even require that such events are presented
some number of samples ahead of their due time. This of course
forces the plugin to queue them internally, but in some cases
that's the only way to do it.
What is needed here is a generic way to pass a list of time-
stamped event to a plugin via a control rate port, and then
let the plugin deal with them as it sees fit.
Can be done as a port class. In fact, this is pretty much how the MIDI
extension works - see http://ll-plugins.nongnu.org/lv2/ext/MidiPort
The core LV2 spec doesn't support much more than the LADSPA spec, but
that wasn't the intention. The point is that it's easy to extend.
--ll
8:13 a.m.
2. Plugins are
expected to have a fixed set of ports. There are
cases where a plugin can only decide wich ports it will need
after being instantiated.
This can be done using an extension. I think Nedko Arnaudov has already
specified one for dynamically appearing and disappearing ports. > 6. The only way for plugins to discover if a
control port value
> has changed is to keep a copy and compare all values during
> each run(). See also (7).
dynparam is callback based, so plugin receives callback, in realtime
context when value has been changed by host (either automation or from
plugin UI)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
9:01 a.m.
On Wed, 2007-05-09 at 15:14 +0300, Nedko Arnaudov wrote:
Yes but unfortunately it works only for control/parameter "ports". And
dynparam extension does not use real lv2 ports. And parameter "ports"
are not "control rate" in lv2dynparam.
Anyway, it can be done using an extension.
--ll
2. Plugins are expected to have a fixed set of ports.
There are
cases where a plugin can only decide wich ports it will need
after being instantiated.
This can be done using an extension. I think Nedko Arnaudov has already
specified one for dynamically appearing and disappearing ports.
9:39 a.m.
On Wed, May 09, 2007 at 12:36:34PM +0200, Lars Luthman wrote:
See his comments in this.
So a plugin writer can't count on it.
Again, of no use it you can't count on it being present.
Same remark as the two above, and I wonder how it can be done at all.
Part of the solution would be to have a period or frame counter as parameter
to each run(). It would at least allow a plugin to discover wich run() calls
to its instances belong to the same period, and which is the first one for a
period. Trivial to implement and there is no good reason why it shouldn't be
there by default. But it's only part of what is required, it doesn't define
which instances form a group in the first place. A single unique group ID
would do. Again very simple to implement as standard.
Again you can't count on it being implemented. And a callback for each
parameter change doesn't solve the problem - in many cases you want to
handle all changes together because they modify the same internal data
and you don't want to redo the possibly complex calculations each time.
What's so difficult about setting a flag when a parameter is modified ?
But the best solution is to do away with static control values and present
all control changes as timestamped events.
Again, if you can't count on it, it's not very useful.
And that is the problem. It is much too easy both on hosts and plugins.
I really see no reason for not supplying an essential parameter such as
period size in the initialisation call. It's as fundamental as sample
rate. OK, some algos don't need it, but there are many that don't need
the sample rate either. Same for process priority and group ID.
All of this is trivial to ignore if you don't need it, but essential
in some cases.
*** These things should not be optional. ***
And why not present *all* control data as timestamped events from the
start ? In most cases there will be just one value for the start of the
period. Is this soooo difficult for a plugin writer to deal with ?
A plugin always has the simple option to ignore timestamps and just use
the last updates for the entire current period. You could even write a
simple wrapper library to present it with conventional control values
if it wants just those.
On Wed, 2007-05-09 at 12:21 +0200, Fons Adriaensen
wrote:
There is no reason to assume that plugins will always be used in
a Jack client. Fractional rates are required because resample
ratios often can't be expressed as a float or double. It's a
problem with the libsamplerate API as well.
1, Only integer sample rates. This should be at
least a fraction
of two integers.
Given that JACK only supports integer sample rates I don't think that
this is a big deal. On the other hand I can't really see any
disadvantages with having it as a float or double, so if there are any
compelling reasons for doing that I think I agree. 2. Plugins are expected to have a fixed set of
ports. There are
cases where a plugin can only decide wich ports it will need
after being instantiated.
This can be done using an extension. I think Nedko Arnaudov has already
specified one for dynamically appearing and disappearing ports. 3. Plugins may
want to delegate some of the processing to threads
running just below the audio thread priority, so this priority
is an essential initialisation parameter.
Can be done as a HostFeature. 4. There are
'audio rate' and 'control rate' ports, but no 'init
time' ports. How are plugins supposed to discover initialisation
parameters ?
Can be done as a HostFeature. 5. If a plugin
is instantiated multiple times to operate on
multi-channel data it may want to share control ports within
such a group, if only to optimise the (possibly complex and CPU
intensive) code that maps external control values to internal
data. I see no way to form such groups.
Can be done as a HostFeature. 6. The only
way for plugins to discover if a control port value
has changed is to keep a copy and compare all values during
each run(). See also (7).
This isn't all that expensive, but if a plugin really really needed a
new callback to be executed by the host when a control port value
changed it could be done as a HostFeature. 7. There is no
fixed audio period. Host may call run() for any
number of samples. This is probably meant as a way to allow
hosts to change control values at arbitrary points, but this
defeats the purpose of having control rate in the first place.
It's a typical 'let's be lazy' solution that does not solve
the original problem except in some simple cases.
Some algorithms can't be written to run efficiently - or at
all - in such circumstances. Plugins should be run() with
fixed block size.
Can be done as a HostFeature. In fact, there are two such extensions
already - see http://tapas.affenbande.org/wordpress/?page_id=53 If plugins
are to know that certain things need to happen at
particular offsets into a processing period then they should
be passed this info as a list of events (timestamed relative
to the start of the period), and be allowed to deal with that
in the most appropriate way, which may well be very different
to slicing up the audio period.
Some algorithms may even require that such events are presented
some number of samples ahead of their due time. This of course
forces the plugin to queue them internally, but in some cases
that's the only way to do it.
What is needed here is a generic way to pass a list of time-
stamped event to a plugin via a control rate port, and then
let the plugin deal with them as it sees fit.
Can be done as a port class. In fact, this is pretty much how the MIDI
extension works - see http://ll-plugins.nongnu.org/lv2/ext/MidiPort
The core LV2 spec doesn't support much more than the LADSPA spec, but that wasn't the intention. The point is that
it's easy to extend.
Optional support for fundament things is not a solution.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
--
FA
Follie! Follie! Delirio vano è questo !
10:08 a.m.
On Wed, 2007-05-09 at 15:41 +0200, Fons Adriaensen wrote:
See his comments in this.
Right, his extension didn't do what I thought it did. You can still
write another extension that does.
So a plugin writer can't count on it.
A plugin writer can count on the host supporting that feature if it uses
the lv2:requiredHostFeature predicate. The host will then not attempt to
load the plugin unless it supports that feature.
Again, of no use it you can't count on it being present.
See above.
Same remark as the two above, and I wonder how it can be done at all.
Part of the solution would be to have a period or frame counter as parameter
to each run(). It would at least allow a plugin to discover wich run() calls
to its instances belong to the same period, and which is the first one for a
period. Trivial to implement and there is no good reason why it shouldn't be
there by default. But it's only part of what is required, it doesn't define
which instances form a group in the first place. A single unique group ID
would do. Again very simple to implement as standard.
A basic way to do it would be to write an extension that adds a plugin
callback identical to DSSI's run_multiple(). If you need it for your
plugin to work you list it as a requiredHostFeature, if it works without
it but still supports it you list it as an optionalHostFeature.
Again you can't count on it being implemented. And a callback for each
parameter change doesn't solve the problem - in many cases you want to
handle all changes together because they modify the same internal data
and you don't want to redo the possibly complex calculations each time.
What's so difficult about setting a flag when a parameter is modified ?
But the best solution is to do away with static control values and present
all control changes as timestamped events.
I was just giving an example - it would be just as easy to do a callback
that was called with a list of ports that has changed.
Again, if you can't count on it, it's not very useful.
See above.
And that is the problem. It is much too easy both on hosts and plugins.
I really see no reason for not supplying an essential parameter such as
period size in the initialisation call. It's as fundamental as sample
rate. OK, some algos don't need it, but there are many that don't need
the sample rate either. Same for process priority and group ID.
All of this is trivial to ignore if you don't need it, but essential
in some cases.
*** These things should not be optional. ***
And why not present *all* control data as timestamped events from the
start ? In most cases there will be just one value for the start of the
period. Is this soooo difficult for a plugin writer to deal with ?
A plugin always has the simple option to ignore timestamps and just use
the last updates for the entire current period. You could even write a
simple wrapper library to present it with conventional control values
if it wants just those.
I think it is, if it is possible to implement the "fundamental" things
later when they are needed. Some of the things you've mentioned above
may be generally useful enough to go into the core spec, but on the
other hand LADSPA plugins have worked reasonably well without them, and
should a host that only wants LADSPA-type plugins have to implement lots
of functions that it doesn't really need? Isn't it better to have a
small core specification that all hosts and plugins use, and let hosts
and plugins that need more advanced features implement them as
extensions? Sure, all plugins will not work in all hosts, but there will
be clear mechanisms for a host to see which plugins it can use and which
it can't. DSSI plugins don't work in normal LADSPA hosts either.
--ll
On Wed, May 09, 2007 at 12:36:34PM +0200, Lars Luthman
wrote:
OK, then I agree. I see no reason to keep it a single integer.
On Wed, 2007-05-09 at 12:21 +0200, Fons
Adriaensen wrote:
There is no reason to assume that plugins will always be used in
a Jack client. Fractional rates are required because resample
ratios often can't be expressed as a float or double. It's a
problem with the libsamplerate API as well. 1, Only integer sample rates. This should be at
least a fraction
of two integers.
Given that JACK only supports integer sample rates I don't think that
this is a big deal. On the other hand I can't really see any
disadvantages with having it as a float or double, so if there are any
compelling reasons for doing that I think I agree. 2. Plugins are expected to have a fixed set of ports.
There are
cases where a plugin can only decide wich ports it will need
after being instantiated.
This can be done using an extension. I think Nedko Arnaudov has already
specified one for dynamically appearing and disappearing ports. 3. Plugins may want to delegate some of the processing
to threads
running just below the audio thread priority, so this priority
is an essential initialisation parameter.
Can be done as a HostFeature. 4. There are 'audio rate' and 'control
rate' ports, but no 'init
time' ports. How are plugins supposed to discover initialisation
parameters ?
Can be done as a HostFeature. 5. If a plugin is instantiated multiple times to
operate on
multi-channel data it may want to share control ports within
such a group, if only to optimise the (possibly complex and CPU
intensive) code that maps external control values to internal
data. I see no way to form such groups.
Can be done as a HostFeature. 6. The only way for plugins to discover if a control
port value
has changed is to keep a copy and compare all values during
each run(). See also (7).
This isn't all that expensive, but if a plugin really really needed a
new callback to be executed by the host when a control port value
changed it could be done as a HostFeature. 7. There is no fixed audio period. Host may call run()
for any
number of samples. This is probably meant as a way to allow
hosts to change control values at arbitrary points, but this
defeats the purpose of having control rate in the first place.
It's a typical 'let's be lazy' solution that does not solve
the original problem except in some simple cases.
Some algorithms can't be written to run efficiently - or at
all - in such circumstances. Plugins should be run() with
fixed block size.
Can be done as a HostFeature. In fact, there are two such extensions
already - see http://tapas.affenbande.org/wordpress/?page_id=53 If plugins are to know that certain things need to
happen at
particular offsets into a processing period then they should
be passed this info as a list of events (timestamed relative
to the start of the period), and be allowed to deal with that
in the most appropriate way, which may well be very different
to slicing up the audio period.
Some algorithms may even require that such events are presented
some number of samples ahead of their due time. This of course
forces the plugin to queue them internally, but in some cases
that's the only way to do it.
What is needed here is a generic way to pass a list of time-
stamped event to a plugin via a control rate port, and then
let the plugin deal with them as it sees fit.
Can be done as a port class. In fact, this is pretty much how the MIDI
extension works - see http://ll-plugins.nongnu.org/lv2/ext/MidiPort
The core LV2 spec doesn't support much more than the LADSPA spec, but that wasn't the intention. The point is
that it's easy to extend.
Optional support for fundament things is not a solution. 
12:19 p.m.
On Wed, 2007-05-09 at 15:41 +0200, Fons Adriaensen wrote:
So a plugin writer can't count on it.
Again, of no use it you can't count on it being present.
Same remark as the two above
This is intentional. LV2 is not intended to include every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is why
LV2 actually exists in a useful state and, say, GMPI does not...)
If something you require is not present, the plugin simply won't work in
that host. You (the plugin) can also make things optional so the
functionality will only be used if supported by the host.
This is a Good Thing(TM), not a bad thing. Bloating the spec requires a
real reason why a thing /must/ be in the core specification, i.e. why it
will not work at all as an extension. Plugins can "count on" anything
they want, if it's not provided things will simply fail gracefully (a
lot of thought has been put into being sure of this).
The simple reason for this is that we cannot be building every single
thing into the spec, because the spec would never exist. We'd be having
the same old LADSPA GUI rant fest on l-a-d all day, and nothing would
get finished. The line needs to be drawn somewhere, so it was drawn as
"equivalent to ladspa, with whatever additions necessary to be fully
extensible".
That said, I like most of your ideas, particularly control ports - I
hate them, lots. Hopefully someone comes up with a better solution and
they disappear entirely one day. Being a modular guy, I want CVs, but
others want timestamped events. It would be nice if we could have some
kind of polymorphic control port that supports all these uses, though
personally I think timestamped controls might as well just be more fully
featured messages.
3. Plugins may want to delegate some of the processing
to threads
running just below the audio thread priority, so this priority
is an essential initialisation parameter.
Can be done as a HostFeature. 4. There
are 'audio rate' and 'control rate' ports, but no 'init
time' ports. How are plugins supposed to discover initialisation
parameters ?
Can be done as a HostFeature. 5. If a
plugin is instantiated multiple times to operate on
multi-channel data it may want to share control ports within
such a group, if only to optimise the (possibly complex and CPU
intensive) code that maps external control values to internal
data. I see no way to form such groups.
Can be done as a HostFeature. Optional support for fundament things is not a
solution.
None of the things you have mentioned have any /actual/ reason to go in
LV2 itself, except the sample rate issue which does need to be figured
out. I'm for making it a rational number or double; locking it as an
int for no reason when there's any reason for something better at all is
short-sighted.
I do think I vaguely remember some reason why floating point sample
rates aren't good though.... ?
-DR-
12:34 p.m.
This is intentional. LV2 is not intended to include every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is why
LV2 actually exists in a useful state and, say, GMPI does not...)
While this makes perfect since in flexibility from a programmer
perspective, I wonder how it will affect things from an end-user
perspective, especially if LV2 becomes popular(Which many hope it would)...
The end user will have some plugins that are 'LV2' that will work in
some 'LV2' hosts but not others. How are they to know? Will they have
to have 'LV2 and supports these features' that they will have to check
off every time to see if it should be working or not?
Or 'Profiles' that fit a certain set of features?
Don't get me wrong, I love how flexible LV2 is intended to be. However
without some baseline for it, there are some definite concerns when
writing plugins in as far as compatibility for an end-user that may not
know to check every last little additional function.
Perhaps LV2 should by default include extensions that encompass the
points brought up here instead of dismissing them as capable of being
done, as if they can be done in one host, not nesseccarily in all, then
you have one giant mass of confusion in as far as what plugins can be
sued here, there or whatever, and instead of a standard plugin format,
we have a giant clusterf**k.
I apologize to anyone offended by the last statement in advance, but I
could not come up with a better way to describe it.
Seablade
12:42 p.m.
On 9 May 2007, at 17:19, Dave Robillard wrote:
Probably, but sometimes you just have to be realistic. I'm happy to
go with double sample rates if no one screams. I've had a quick look
at my code and it should be an easy transition - the most common
thing I do with the sample rate is cast it to a float or double and
store it somewhere anyway.
- Steve
Optional support for fundament things is not a
solution.
None of the things you have mentioned have any /actual/ reason to
go in
LV2 itself, except the sample rate issue which does need to be figured
out. I'm for making it a rational number or double; locking it as an
int for no reason when there's any reason for something better at
all is
short-sighted.
I do think I vaguely remember some reason why floating point sample
rates aren't good though.... ?
12:48 p.m.
On Wed, 2007-05-09 at 12:44 -0400, Thomas Vecchione wrote:
The end user will have some plugins that are
'LV2' that will work in
some 'LV2' hosts but not others. How are they to know? Will they have
to have 'LV2 and supports these features' that they will have to check
off every time to see if it should be working or not?
Or 'Profiles' that fit a certain set of features?
You could have meta-extensions that were simply a collection of other
extensions. "To support this extension, a host must support extensions
A, B, and C". Or something like that.
Perhaps LV2 should by default include extensions that
encompass the
points brought up here instead of dismissing them as capable of being
done, as if they can be done in one host, not nesseccarily in all, then
you have one giant mass of confusion in as far as what plugins can be
sued here, there or whatever, and instead of a standard plugin format,
we have a giant clusterf**k.
I don't think there is any huge danger of that happening. People will
probably mostly use a few popular hosts, plugin writers will make sure
that their plugins work in those hosts (if feasible) and host writers
will try to support as many plugins as possible. I guess it depends on
how creative (or how disciplined) LV2 programmers are.
There is a good argument against having a large core specification; the
larger it is, the harder it is to write hosts, and the fewer hosts will
be written.
--ll
12:51 p.m.
On Wed, May 09, 2007 at 12:44:22PM -0400, Thomas Vecchione wrote:
While this makes perfect since in flexibility from a programmer
perspective, I wonder how it will affect things from an end-user
perspective, especially if LV2 becomes popular(Which many hope it would)...
The end user will have some plugins that are 'LV2' that will work in
some 'LV2' hosts but not others. How are they to know? Will they have
to have 'LV2 and supports these features' that they will have to check
off every time to see if it should be working or not?
Or 'Profiles' that fit a certain set of features?
Hosts will be able to not ever list plugins they can't use, afaik.
I think it's likely that something one could call profiles will
crystallize, as plugins are made for more or less specific uses.
Many effect plugins make sense both in a DAW and a synth, but
sound generators like oscillators tend to not make sense in a DAW.
Synth plugins need hosts that deal with MIDI (well, perhaps OSC).
I mean there will be sets of needs that apply to plugins and hosts.
In the worst case we will need a table of what works where :)
--
Thorsten Wilms
Thorwil's Design for Free Software:
http://thorwil.wordpress.com
12:52 p.m.
On 9 May 2007, at 17:44, Thomas Vecchione wrote:
I expect the majority of plugins will only use the core spec. The
hosts can tell which plugins they don't have support for, and why so
they could do something intelligent in the UI (greying out and
tooltips or whatever).
There's also a lot of support to allow plugins to gracefully degrade,
or provide alternative implementations when a feature that they'd
like is not present.
This is
intentional. LV2 is not intended to include every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is
why
LV2 actually exists in a useful state and, say, GMPI does not...)
While this makes perfect since in flexibility from a programmer
perspective, I wonder how it will affect things from an end-user
perspective, especially if LV2 becomes popular(Which many hope it
would)...
The end user will have some plugins that are 'LV2' that will work
in some 'LV2' hosts but not others. How are they to know? Will
they have to have 'LV2 and supports these features' that they will
have to check off every time to see if it should be working or not? Or 'Profiles' that fit a certain set of
features?
Sure, why not? It's just a social contract.
Don't get me wrong, I love how flexible LV2 is
intended to be.
However without some baseline for it, there are some definite
concerns when writing plugins in as far as compatibility for an end-
user that may not know to check every last little additional function.
They wont have to. The point that they might not understand why for
eg. Ardour can't load one of Nedko's plugins is reasonable though.
Perhaps LV2 should by default include extensions that
encompass the
points brought up here instead of dismissing them as capable of
being done, as if they can be done in one host, not nesseccarily in
all, then you have one giant mass of confusion in as far as what
plugins can be sued here, there or whatever, and instead of a
standard plugin format, we have a giant clusterf**k.
That's a possibility for the future, I would expect any LV2 1.1 to be
the core spec + a set of commonly used extensions.
Discussing spec issues in an open forum like this though is a futile
effort, and it's simply not true that you can't get a lot done with
the core spec. LV2 is more capable than LADSPA, and there are some
hundred LADSPA plugins, which work to some degree :)
- Steve
1:04 p.m.
On Wed, 2007-05-09 at 12:44 -0400, Thomas Vecchione wrote:
This is intentional. LV2 is not intended to include every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is why
LV2 actually exists in a useful state and, say, GMPI does not...)
While this makes perfect since in flexibility from a programmer
perspective, I wonder how it will affect things from an end-user
perspective, especially if LV2 becomes popular(Which many hope it would)...
The end user will have some plugins that are 'LV2' that will work in
some 'LV2' hosts but not others. How are they to know? Will they have
to have 'LV2 and supports these features' that they will have to check
off every time to see if it should be working or not? From an end user perspective, hosts that can not run a
given plugin
should choose to simply not display it at all. The burden to check
(or
even know directly about) host features is certainly not on the end user
in any case.
As I pointed out, a lot of thought has been put into this. The
information is always there to know if, and why, a plugin is or is not
usable. So graceful failure from an end user perspective (or,
preferably, just hiding the plugin entirely and avoiding confusion and
clitter) is possible.
Think of it as extra plugins that would not exist /at all/ if the spec
wasn't extensible in this way. Nothing lost, right?
-DR-
1:18 p.m.
Gonna answer several posts with this I think in the interest of
simplicity as I tihnk I was misunderstood somewhat....
Lars:
That's a possibility for the future, I would expect any LV2 1.1 to be the core spec +
a set of commonly used extensions.
And while my opinion only matters a limited extent, I would suggest that
things like that get addressed earlier rather than later myself.
You could have meta-extensions that were simply a
collection of other
extensions. "To support this extension, a host must support extensions
A, B, and C". Or something like that.
Definitely a possibility, that is exactly what I was referring to with
'Profiles'. For example an Audio-Instrument profile might support XYZ
while a Video Profile might support others, as if I recall correctly
part of the point of LV2 was to support not just audio but possibly
other things as well? A GUI profile might be another one(Not saying it
is a good idea, just providing possible examples)?
Whatever the case of how that is handled, simplicity for the user as
well as the programmer needs to be considered. Even the profiles
mentioned above would add complexity in for the end user though.
I don't think there is any huge danger of that
happening. People will
probably mostly use a few popular hosts, plugin writers will make sure
that their plugins work in those hosts (if feasible) and host writers
will try to support as many plugins as possible. I guess it depends on
how creative (or how disciplined) LV2 programmers are.
I think that is being either very optimistic or pessimistic, or both at
the same time(If that is possible). Writing plugins for a few specific
hosts is a good idea, of course then you are limiting the capabilities
of others also developed with LV2 as they might not be able to support
all extensions out of the box quickly enough to become popular. As much
as I love Ardour, I would hate for it to be the only option out there,
then we are back to Pro-Tools all over again.
Also depending on LV2 programmers to always be completely disciplined is
being kinda optomistic IMO. Nothing against any current programmers,
but if we want to encourage people to develop plugins, some of those
people may just be getting started in programming. Some guidelines are
not a bad thing in that regard, and may even encourage folks to stay
logical and disciplined.
There is a good argument against having a large core
specification; the
larger it is, the harder it is to write hosts, and the fewer hosts will
be written.
I am not arguing that at all actually. I think Firefox's greatest
strength early on that it is starting to lose was the fact they aimed
for very lightweight and allowed extensions. However now they are
building more into the browser and less via extensions, instead of
shipping it with those functionalities as extensions that can be
disabled if desired.
Thorsten:
Hosts will be able to not ever list plugins they
can't use, afaik.
Unfortunatly that has nothing to do with my concern though. The problem
isn't that hosts won't list the plugin, it is that a plguin that works
here in program X, and I like the plugin but maybe not the program,
doesn't work here because a host y has not done that particular extension.
It could be looked at as the job of the programmer to support the
extension, but then you are adding complexity into the programmer's
lives as well by making them follow every custom extension to support
all these great plugins.
In the worst case we will need a table of what works
where :)
Yes but that should be ABSOLUTE worst case. I have enough problems
explaining audio on linux half the time to others, that if I was to be
asked every five minutes, well I have a plugin that works in RoseGarden
but wont work in Muse, but they both support LV2, trying to explain the
concept of extensions individually I think would be a problem.
Again I come back to profiles only because I couldn't think of a better
solution at the time(So people start suggesting;), but if I have to
point newcomers to a chart every time they want to knokw if their plugin
works, and maybe it hasn't been tested... Might as well be back to
VST/fst on linux debates there.
Steve:
I expect the majority of plugins will only use the core spec. The hosts can tell which
plugins they don't have support for, and why so they could do something intelligent in
the UI (greying out and tooltips or whatever).
I completely agree, but things like this I think need to be addressed in
a way that is simple for non-programmers to understand from the get-go.
There's also a lot of support to allow plugins to gracefully degrade, or provide
alternative implementations when a feature that they'd like is not present.
And I think that is also a good idea.
Sure, why not? It's just a social contract.
The catch is keeping it as simple as possible so we don't have an audio1
audio2 and audio 3.4 profile all at once IMO.
They wont have to. The point that they might not understand why for eg. Ardour can't
load one of Nedko's plugins is reasonable though.
And the latter portion was of course my primary point/concern.
Discussing spec issues in an open forum like this though is a futile effort, and it's
simply not true that you can't get a lot done with the core spec. LV2 is more capable
than LADSPA, and there are some hundred LADSPA plugins, which work to some degree :)
I didn't mean to suggest the core spec was not capable. I am just
trying to avoid where I see confusion possibly arriving in the future.
Dave:
As I pointed out, a lot of thought has been put into
this. The
information is always there to know if, and why, a plugin is or is not
usable. So graceful failure from an end user perspective (or,
preferably, just hiding the plugin entirely and avoiding confusion and
clitter) is possible.
And your average non-programmer end-user will understand the plugin is
LV2, and wonder why the heck it is not working in this program.
Think of it as extra plugins that would not exist /at
all/ if the spec
wasn't extensible in this way. Nothing lost, right?
And lots of complexity gained. That complexity is Linux's strength, but
also its weakness as it rarely gets addressed in a way that provides the
simplicity needed for an average user. I am not saying everything
should be addressed in such a way, but I am saying something like this
that is aimed to be used by the average end-user musician/producer/sound
designer/etc should be.
Once again my intent is not to belittle the extensivenesses of it. In
fact I might almost prefer LV2 be the base framework for ports that can
carry ANY sort of data for example, and then have the profiles define
what that data is, instead of anything being built into it, and ship 1.0
with a basic profile or three that people can implement based off what
their program is.
I admit I should have suggested that much earlier in the process, if I
actually expected it to be thought about, I had only lightly been
following it, sorry. But just to give an idea of where I stand that
hopefully will clarify my position of it. I am not saying that the
extensibility is a bad thing, I am saying that in the end the plugin
format needs to be given to the end user in a way that will seem
extremely simple to them.
Seablade
1:52 p.m.
On Wed, 2007-05-09 at 13:28 -0400, Thomas Vecchione wrote:
I don't think that is going to be a big problem. Though it's certainly
possible to write a proprietary LV2 host, I think it's safe to say that
most of them, in the foreseeable future, will be free software. So once
one host has implemented an extension, there will be actual code for
that implementation available to everyone else. Sure, different hosts
may have very different codebases, but it's still just a matter of
adaptation, not writing from scratch.
I think the best thing is to only define the core spec for now, see what
extensions pop up, which of them are useful or popular, which of them
make sense to use together etc, and then define some additional
structure or profiles or something else if needed.
--ll
I don't
think there is any huge danger of that happening. People will
probably mostly use a few popular hosts, plugin writers will make sure
that their plugins work in those hosts (if feasible) and host writers
will try to support as many plugins as possible. I guess it depends on
how creative (or how disciplined) LV2 programmers are.
I think that is being either very optimistic or pessimistic, or both at
the same time(If that is possible). Writing plugins for a few specific
hosts is a good idea, of course then you are limiting the capabilities
of others also developed with LV2 as they might not be able to support
all extensions out of the box quickly enough to become popular. As much
as I love Ardour, I would hate for it to be the only option out there,
then we are back to Pro-Tools all over again.
3:46 p.m.
On Wed, May 09, 2007 at 12:19:39PM -0400, Dave Robillard wrote:
This is intentional. LV2 is not intended to include
every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is why
LV2 actually exists in a useful state and, say, GMPI does not...)
I don't buy this. This is not about complicated or esoteric 'features'
but _basic infrastructure_. I didn't have to torture my mind to dream
up the simple things I mentioned - they were plain obvious after
reading the LV2 specs for about 15 minutes. That is several orders of
magnitude less than the GMPI discussion.
Do you really think that run(nframes, framecount) is so horribly
complicated compared to run(nframes) that the average plugin writer
would run (pun intended) away screaming ?
Do you really think that init(samplerate, periodsize, priority, groupid)
instead of init(samplerate) would complicate a host to the extent that
nobody would dare write one ?
Any objection you may have to 'periodsize' or any of the other arguments
in that list would apply equally to 'samplerate' - many plugins don't
need it. And it can be provided by an extension. Everything can be
provided by an extension. We need nothing at all.
None of these parameters are 'features' in the sense that they add
user-level functionality. They are just basic low-level technical
infrastructure required to make some things work, and cost almost
nothing. This is not the sort of thing that should be negociated
between a host and a plugin via a high-level protocol. A host that
does not provide such basic information is IMHO just broken.
I don't have any problems with the way LV2 provides for future
extensions - it's well done. But requiring such a mechanism to
obtain basic low-level information is as silly as offering the
gas tank on a car as an option (I assume you would include the
wheels as standard).
--
FA
Follie! Follie! Delirio vano è questo !
4:18 p.m.
On Wed, 2007-05-09 at 13:28 -0400, Thomas Vecchione wrote:
Gonna answer several posts with this I think in the
interest of
simplicity as I tihnk I was misunderstood somewhat....
Lars:
I don't really see the point of these "profiles" at all, to be honest.
Seems like just defining things for the sake of defining things.
You could have meta-extensions that were simply a
collection of other
extensions. "To support this extension, a host must support extensions
A, B, and C". Or something like that.
Definitely a possibility, that is exactly what I was referring to with
'Profiles'. For example an Audio-Instrument profile might support XYZ
while a Video Profile might support others, as if I recall correctly
part of the point of LV2 was to support not just audio but possibly
other things as well? A GUI profile might be another one(Not saying it
is a good idea, just providing possible examples)?
Whatever the case of how that is handled, simplicity for the user as
well as the programmer needs to be considered. Even the profiles
mentioned above would add complexity in for the end user though. Unfortunatly that has nothing to do with my concern
though. The problem
isn't that hosts won't list the plugin, it is that a plguin that works
here in program X, and I like the plugin but maybe not the program,
doesn't work here because a host y has not done that particular extension.
It could be looked at as the job of the programmer to support the
extension, but then you are adding complexity into the programmer's
lives as well by making them follow every custom extension to support
all these great plugins.
The perspective of this argument is getting a bit hand wavey. It's
really quite simple: there are "extra" features you can use/create/etc.
Either a plugin author supports these features, or not.
Either a host author supports these features, or not.
Either way, everything just works (or not) as it should.
I understand the idea of "plugin A doesn't work in host B" is maybe
unnerving at first glance, but you're looking at it from a strange
perspective and trying to come up with solutions to a problem that
simply doesn't exist.
To pick an obvious example, consider GUIs:
Host H is a command line app, and doesn't support GUIs.
Plugin P is a plugin with an optional GUI.
Plugin G is a plugin with a mandatory GUI (silly example, yes).
P works in H, P's GUI doesn't.
G doesn't work in H.
Of course GUIs don't work in H - it doesn't support GUIs! There is no
problem here...
-DR-
4:24 p.m.
Am Mittwoch, 9. Mai 2007 schrieb Fons Adriaensen:
I don't have any problems with the way LV2
provides for future
extensions - it's well done. But requiring such a mechanism to
obtain basic low-level information is as silly as offering the
gas tank on a car as an option (I assume you would include the
wheels as standard).
Haha, nice analogy! Surely you realize that most cars are sold with only the
basic standard-wheels? Sad but it seems that this also the case for lv2. If
you want to have sport-wheels or a bigger gas tank or a speedometer it seems
you have to rely on extensions to the basic version...
BTW: I wouldn't think bad about the extension-thing. If only it was optional
and most plugins would run with the basic features and only allow for more
with extensions available. But if I need to have hosts supporting certain
features to use the nice plugins this would have me stick with ladspa...
Another thing: I don't think Linux should ever try to get into the field where
certain interchangeable parts like plugins only work in some rare conditions.
That is what windows already provides, I wanted to get rid of that and
switched to linux...
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
4:52 p.m.
On Wed, 2007-05-09 at 22:01 +0200, Arnold Krille wrote:
BTW: I wouldn't think bad about the
extension-thing. If only it was optional
and most plugins would run with the basic features and only allow for more
with extensions available. But if I need to have hosts supporting certain
features to use the nice plugins this would have me stick with ladspa...
That would be rather silly, since you can do everything with LV2 plugins
without extensions that you can do with LADSPA. Extensions are for
things that you can _not_ do with LADSPA.
Another thing: I don't think Linux should ever try
to get into the field where
certain interchangeable parts like plugins only work in some rare conditions.
That is what windows already provides, I wanted to get rid of that and
switched to linux...
There is no reason that interchangeable plugins will not work in the
same hosts. But a MIDI synth is not interchangeable with a lowpass
filter or an OSC sequencer. If plugins will require different
extensions, it will be because they do different things. If hosts are
not interested in doing those things or don't even have the
infrastructure for them they will of course not implement those
extensions.
--ll
5:17 p.m.
On Wed, 2007-05-09 at 21:51 +0200, Fons Adriaensen wrote:
On Wed, May 09, 2007 at 12:19:39PM -0400, Dave
Robillard wrote:
Basic infrastucture is exactly what is there. If there is a problem you
see with the basic infrastructure, that is what we need to solve right
now.
Complaining that /your/ specifically needed features /must/ be in what
we call "the core LV2 specification" is pointless.
This is intentional. LV2 is not intended to
include every single
feature that everyone might want. It is intended for it to
be /possible/ to implement any feature someone might want (this is why
LV2 actually exists in a useful state and, say, GMPI does not...)
I don't buy this. This is not about complicated or esoteric 'features'
but _basic infrastructure_. I didn't have to torture my mind to dream
up the simple things I mentioned - they were plain obvious after
reading the LV2 specs for about 15 minutes. That is several orders of
magnitude less than the GMPI discussion.
Do you really think that run(nframes, framecount) is so horribly
complicated compared to run(nframes) that the average plugin writer
would run (pun intended) away screaming ?
Do you really think that run (nframes, framecount) is the single
parameter list for run that anyone might ever, at any point in the
indefinite future, for any purpose, wish to pass to run? Of course not.
framecount isn't even a good way of expressing a fixed block size
anyway, you can just pass a different thing every time.
If you want to discuss fixed block sizes, etc, discuss the existing work
done in that area by tapas (who has longed for that feature for ages
now, and I assume from the lack of objections from him that things are
fine on that front). There is already a solution to this, if you have a
problem with the solution, let it be known.
Perhaps we /do/ need to have a facility for additional parameters passed
to run. I'm open to this possibility with justification. What is
definitely not going to happen is tacking on a few arbitrary fixed
parameters with no foresight into future compatibility issues, such as
this framecount suggestion.
This is an extensible spec, and problems with it must be addresssed in
an extensible way.
Additional run parameters in a HostFeatures kind of way isn't
appropriate because of performance issues though. I think the current
way is probably fine, since plugins can provide additional run methods.
In other words, nothing at all is stopping you from providing your
run(nframes, framecount) method, and therefore it's absense from lv2.h
is not a problem.
Do you really think that init(samplerate, periodsize,
priority, groupid)
instead of init(samplerate) would complicate a host to the extent that
nobody would dare write one ?
?
We already have a mechanism for passing whatever parameters you want to
initialize a plugin. Unlike your (completely arbitrary and
non-extensible) idea here, it doesn't break binary compatibility with
every host/plugin implementation in existence every time someone comes
up with a need for another parameter.
LV2 as a specification requires significantly more foresight than the
examples you are providing here.... we can't be breaking everything
every time someone needs a new parameter for this or that.
Any objection you may have to 'periodsize' or
any of the other arguments
in that list would apply equally to 'samplerate' - many plugins don't
need it. And it can be provided by an extension. Everything can be
provided by an extension. We need nothing at all.
Sample rate is required by basically any plugin, is included in LADSPA,
and is included in LV2. Therefore sample rate is important to get
right, because it's there.
You are right it doesn't strictly /need/ to be there. It's there
because it's there in LADSPA - this rule exists solely to draw a line in
the sand to prevent everybody and his brother fighting over what baroque
junk to cram in the spec, like you are attempting at the moment. ;)
None of these parameters are 'features' in the
sense that they add
user-level functionality. They are just basic low-level technical
infrastructure required to make some things work, and cost almost
nothing. This is not the sort of thing that should be negociated
between a host and a plugin via a high-level protocol. A host that
does not provide such basic information is IMHO just broken.
No, what they are is Fons Adriaensen's pet features. Other people have
different pet features. We can't ram everyone's pet features into the
spec - not mine, not Steve's, and not yours. What we can do is make
sure that everyone's pet features as possible, which is what this beta
is for.
Things will not be added to lv2.h that are not /required/. Period. The
rationale for this is obvious, but I can elaborate if it's really
necessary.
What's important right now is any possible example you can think of why
something is _not possible_ with the current specification. Help in
this area is very much appreciated, arguing for unnecessary inclusions
is a waste of time.
-DR-
5:26 p.m.
On Wed, 2007-05-09 at 22:01 +0200, Arnold Krille wrote:
Am Mittwoch, 9. Mai 2007 schrieb Fons Adriaensen:
The car that is LADSPA has been working just fine in it's (admittedly
limited) domain. We have chosen that as our base set of features
accordingly.
It comes with a gas tank, and tires, but not a radio. There's a big
shelf of radios right at the dealership you can insert in 5 seconds with
no tools. Arguing for radios to be in the "standard" feature set is
stupid because:
a) One mandated radio that is permanently welded to the dash vs. a
selction of the best radios clever radio hackers come up with, fully
open and modular to replace radios at will. No brainer.
b) The "standard" feature set is completely irrelevant since you can
stick whatever you want in your car
c) Some people don't want radios!
-DR-
I don't have any problems with the way LV2
provides for future
extensions - it's well done. But requiring such a mechanism to
obtain basic low-level information is as silly as offering the
gas tank on a car as an option (I assume you would include the
wheels as standard).
Haha, nice analogy! Surely you realize that most cars are sold with only the
basic standard-wheels? Sad but it seems that this also the case for lv2. If
you want to have sport-wheels or a bigger gas tank or a speedometer it seems
you have to rely on extensions to the basic version...
6 p.m.
On Wed, May 09, 2007 at 05:17:50PM -0400, Dave Robillard wrote:
arguing for unnecessary inclusions is a waste of time.
Indeed it is. I'll argue for removals then. Neither run()
nor init() need the current parameters as they can be
provided by extensions.
(it's out of context, but my .sig fits nicely here)
--
FA
Follie! Follie! Delirio vano è questo !
7:03 p.m.
I don't really see the point of these
"profiles" at all, to be honest.
Seems like just defining things for the sake of defining things.
All it does is maintain an easier way of telling if a plugin will work
for the end user.
Keep in mind I am NOT talking about the programmer here, I am referring
strictly for the end user. And these 'profiles' actually are nothing
that isn't already in the spec, just put together in a different way
that is simpler for an end user to understand.
Either a plugin author supports these features, or
not.
Either a host author supports these features, or not.
And that is great, for the programmers.
Either way, everything just works (or not) as it
should.
Not to someone not familiar with the internals of how LV2 works. As an
example(I hate to bring up) how many people do you think could tell you
how the ineternals of a VST program work. Heck how many do you think
have an even basic idea of computer programming, much less tell you the
above.
I understand the idea of "plugin A doesn't
work in host B" is maybe
unnerving at first glance, but you're looking at it from a strange
perspective and trying to come up with solutions to a problem that
simply doesn't exist.
Actually this is just it, I understand it perfectly well. I am the one
stuck helping many people looking to use linux for audio that it would
make no sense whatsoever to.
"Why can't my plugin that is LV2, that is the same thing as a AU or VST
plugin, work in this program that is LV2 compliant?"
Again for a programmer and specifically someone familiar with how LV2
works, that is fine. For someone that has no concept of programming,
and just want something that works when(To them) it is supposed to, this
is a huge screwup that can be fixed relatively easily to be honest.
Host H is a command line app, and doesn't support
GUIs.
Plugin P is a plugin with an optional GUI.
Plugin G is a plugin with a mandatory GUI (silly example, yes).
P works in H, P's GUI doesn't.
G doesn't work in H.
Of course GUIs don't work in H - it doesn't support GUIs! There is no
problem here...
Until you get someone that has no clue in programming say...
Hey this had a GUI in this application, why doesn't it here?
And you try to explain that it is because this implementation doesn't
support GUIs, and they take that to mean the programming is broken
because it doesn't work for them.
Once again, this is not about me I am mentioning this. This is for the
half dozen people(As of right now, obviously not counting those that I
have gotten used to linux and how things work that might start again)
that still come to me wondering why something doesn't 'just work'.
Seablade
7:52 p.m.
On Thu, 2007-05-10 at 00:06 +0200, Fons Adriaensen wrote:
On Wed, May 09, 2007 at 05:17:50PM -0400, Dave
Robillard wrote:
init does not ever need to be replaced by any extension, since, again,
it already has a mechanism for providing whatever parameters you please,
and init in it's current form is required to allow these extensions to
work at all. Your init() "proposal" is nonsense, frankly.
run is obviously needed to.... duh, run the plugin. It's in LADSPA,
QED. Despite your childish attitude on the issue, a more fully featured
run method which supports fixed block sizes etc. is a fine idea, and is
possible with the current spec, so there is no problem here either.
Again, if you are interested in this problem see the existing solution.
Regarding the one sensible thing you /have/ said: is sample rate as a
double sufficient, or is there a good reason for numerator/denominator
(that outweighs the PITA for the plugin author)?
-DR-
arguing for unnecessary inclusions is a waste of
time.
Indeed it is. I'll argue for removals then. Neither run()
nor init() need the current parameters as they can be
provided by extensions.
(it's out of context, but my .sig fits nicely here) 
8:52 p.m.
On 5/9/07, Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
Regarding the one sensible thing you /have/ said: is
sample rate as a
double sufficient, or is there a good reason for numerator/denominator
(that outweighs the PITA for the plugin author)?
I'll play "dumb user" on this one...
Are there useful sample rates that can be expressed more accurately
with a pair of 32-bit integers than by a double?
If so, programmers who don't care about the extra accuracy could
presumably convert the ratio to a double in one line of code (at the
cost of a single division operation). That does not seem excessive,
assuming there are real-world examples where the extra accuracy
would help. Are there any?
--
joq
9:47 p.m.
On Wed, 2007-05-09 at 19:51 -0500, Jack O'Quin wrote:
On 5/9/07, Dave Robillard
<drobilla(a)connect.carleton.ca> wrote:
The only thing I can think of is if a plugin is doing resampley things
and works with wav files. If your sample rate is 48000/44100 and your
wav file is 44100.. well, you know /something/ you wouldn't know if it
was a double I guess. I can't think of any case where that 'something'
would actually be useful though, it's always going to get converted to a
double anyway.
Fons?
-DR-
Regarding the one sensible thing you /have/ said:
is sample rate as a
double sufficient, or is there a good reason for numerator/denominator
(that outweighs the PITA for the plugin author)?
I'll play "dumb user" on this one...
Are there useful sample rates that can be expressed more accurately
with a pair of 32-bit integers than by a double?
If so, programmers who don't care about the extra accuracy could
presumably convert the ratio to a double in one line of code (at the
cost of a single division operation). That does not seem excessive,
assuming there are real-world examples where the extra accuracy
would help. Are there any? 
10 May
10 May
3:36 a.m.
2007/5/10, Dave Robillard <drobilla(a)connect.carleton.ca>ca>:
Regarding the one sensible thing you /have/ said: is
sample rate as a
double sufficient, or is there a good reason for numerator/denominator
using a double as samplerate is highly undesirable, because for
example someone might want to test for specific samplerates, like
if ( samplerate == 44100) { ... }
And this cannot be done with a float value with the necessary "exactness". ;-)
I do support the proposal to use two integer values.
Cheers
-Richard
--
Are you teaching the What and the How but without the Why and the When?
3:42 a.m.
On Wed, May 09, 2007 at 07:14:05PM -0400, Thomas Vecchione wrote:
What has understanding internals to do with this?
All that will need to be understood is that is-an-LV2 is not
enough to describe a plugin or host.
Either way,
everything just works (or not) as it should.
Not to someone not familiar with the internals of how LV2 works. As an
example(I hate to bring up) how many people do you think could tell you
how the ineternals of a VST program work. Heck how many do you think
have an even basic idea of computer programming, much less tell you the
above. Again for a programmer and specifically someone
familiar with how LV2
works, that is fine. For someone that has no concept of programming,
and just want something that works when(To them) it is supposed to, this
is a huge screwup that can be fixed relatively easily to be honest.
Fixed relatively easy how?
Once again, this is not about me I am mentioning this.
This is for the
half dozen people(As of right now, obviously not counting those that I
have gotten used to linux and how things work that might start again)
that still come to me wondering why something doesn't 'just work'.
Do you propose to not have a plugin standard that can be extended for
various current and possible future needs to avoid some possible user
confusion?
Shall all hosts be forced to support all extensions available so
that a sample editor would have to "support" MIDI plugins?
--
Thorsten Wilms
Thorwil's Design for Free Software:
http://thorwil.wordpress.com
5:04 a.m.
Lets stick to the analogy a bit more.
I am not taking sides (I don't know enough off lv2 or ladspa to do so) but for
me it sounds as if fons isn't arguing about extras but of basic features...
Am Mittwoch, 9. Mai 2007 schrieb Dave Robillard:
On Wed, 2007-05-09 at 22:01 +0200, Arnold Krille
wrote:
But to extend the picture. Assume a car does have a radio it will not be
allowed to drive on all streets?
A plugin needing some special feature wouldn't not work on hosts not
implementing that feature. You gave the example of the gui yourself...
Explain to a user why his car is not allowed on certain streets because it
has a radio!
And I don't think fons talks about extras like radio but things like smoother
automation (controlling velocity in a smoother way)...
He didn't even mention guis (which I concur is a bonus and a host not
implementing graphics should still give access to the parameters via text).
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
Am Mittwoch, 9. Mai 2007 schrieb Fons
Adriaensen:
The car that is LADSPA has been working just fine in it's
(admittedly
limited) domain. We have chosen that as our base set of features
accordingly.
It comes with a gas tank, and tires, but not a radio. There's a big
shelf of radios right at the dealership you can insert in 5 seconds with
no tools. Arguing for radios to be in the "standard" feature set is
stupid because: I don't have any problems with the way LV2
provides for future
extensions - it's well done. But requiring such a mechanism to
obtain basic low-level information is as silly as offering the
gas tank on a car as an option (I assume you would include the
wheels as standard).
Haha, nice analogy! Surely you realize that most cars are
sold with only
the basic standard-wheels? Sad but it seems that this also the case for
lv2. If you want to have sport-wheels or a bigger gas tank or a
speedometer it seems you have to rely on extensions to the basic
version...
5:19 a.m.
On Wed, May 09, 2007 at 07:51:53PM -0500, Jack O'Quin wrote:
I'll play "dumb user" on this one...
Are there useful sample rates that can be expressed more accurately
with a pair of 32-bit integers than by a double?
If so, programmers who don't care about the extra accuracy could
presumably convert the ratio to a double in one line of code (at the
cost of a single division operation). That does not seem excessive,
assuming there are real-world examples where the extra accuracy
would help. Are there any?
This is not a user level thing, but a technical and implementation one.
It's also not about absolute accuracy (most soundcards are up to 0.1%
off anaway), but relative. In all multirate processing I know of it's
the _ratios_ that have to be exact or things don't work at all. The only
way to ensure they are is to express all sample frequencies as ratios.
For normal use it doesn't matter, just set the denominator to one.
--
FA
Follie! Follie! Delirio vano è questo !
5:41 a.m.
On Thu, May 10, 2007 at 11:03:56AM +0200, Arnold Krille wrote:
And I don't think fons talks about extras like
radio but things like smoother
automation (controlling velocity in a smoother way)...
He didn't even mention guis (which I concur is a bonus and a host not
implementing graphics should still give access to the parameters via text).
Nothing of what I said has anything to do with user level features.
I imagine a plugin as a component in a general audio DSP network (provided
by the host), and think about what would be required to support all the
types of processing (multi-channel, multi-rate, block-oriented, ...) that
are common in general audio DSP work. These algorithms are used in musical
plugins as well. But the user couldn't care less - he/she just wants the
result.
You can probably explain to a non-technical user that some hosts do support
e.g. MIDI or OSC and others don't - these are things he knows. You can not
IMHO explain to the average user that his favourite host does not accept
his favourite reverb plugin because it does not support a particular type
of algorithm - it's a different world that he doesn't care about. The basic
infrastructure to support all types of processing should be present in all
hosts, and it doesn't take much. You just have to know they exist and think
a bit.
--
FA
Follie! Follie! Delirio vano è questo !
5:43 a.m.
Dave Robillard wrote:
>> arguing for unnecessary inclusions is a waste
of time.
> Indeed it is. I'll argue for removals then. Neither run()
> nor init() need the current parameters as they can be
> provided by extensions.
[...]
run is obviously needed to.... duh, run the plugin. It's in LADSPA,
fons hasn't said anything about removing run();
he just proposed to remove the argument(s) from run(), so no need for
getting extra sarcastic
mfga.dsr
IOhannes
6:45 a.m.
On Thu, May 10, 2007 at 09:41:49AM +0200, Thorsten Wilms wrote:
On Wed, May 09, 2007 at 07:14:05PM -0400, Thomas
Vecchione wrote:
What has understanding internals to do with this?
All that will need to be understood is that is-an-LV2 is not
enough to describe a plugin or host.
the problem will be rather: why has this plugin a GUI in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Either
way, everything just works (or not) as it should.
Not to someone not familiar with the internals of how LV2 works. As an
example(I hate to bring up) how many people do you think could tell you
how the ineternals of a VST program work. Heck how many do you think
have an even basic idea of computer programming, much less tell you the
above. Again for a programmer and specifically someone
familiar with how LV2
works, that is fine. For someone that has no concept of programming,
and just want something that works when(To them) it is supposed to, this
is a huge screwup that can be fixed relatively easily to be honest.
Fixed relatively easy how?
Once again, this is not about me I am mentioning
this. This is for the
half dozen people(As of right now, obviously not counting those that I
have gotten used to linux and how things work that might start again)
that still come to me wondering why something doesn't 'just work'.
Do you propose to not have a plugin standard that can be extended for
various current and possible future needs to avoid some possible user
confusion?
Shall all hosts be forced to support all extensions available so
that a sample editor would have to "support" MIDI plugins?
8:41 a.m.
the problem will be rather: why has this plugin a GUI
in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
That is an exact example of one case that is certainly possible.
What has understanding internals to do with this?
All that will need to be understood is that is-an-LV2 is not
enough to describe a plugin or host.
And how is it doing to be described is my point. At the moment it is
being described as a function of what internal extensions are there in
the case of something that does beyond the spec. If this was one or two
extensions it wouldn't be bad at all, but since we are aiming for
expandability BEYOND what we can thing of right now I think it is a
large mistake to not plan for what would happen if there are 50
different extensions.
Do you propose to not have a plugin standard that can
be extended for
various current and possible future needs to avoid some possible user
confusion?
Absolutely not, and nowhere did I say that.
What I am attempting to propose is a good, end-user-friendly, be found
other than just describing individual extensions that gives end-users a
strong idea of what will and will not work. That is it.
Shall all hosts be forced to support all extensions
available so
that a sample editor would have to "support" MIDI plugins?
Again no. A host could still choose whatever they support. However,
for example, an audio host might support the audio extensions, a video
host might support the video extensions, and a host that is midi capable
the midi extensions. If you are dealing with 20 or 30 extensions there
for whatever reason, are you honestly going to have an end-user go
through and say, ok this extension is present, this one is present, this
one is not, crap my plugin won't work or will be missing a gui.
Do not get me wrong, as I have said repeatedly thus far, LV2 is nice and
highly expandable, and I certainly don't want to change that, but that
by itself will not make it usable for the end user. Power and
flexibility do not necessarily equate ease of use, and personally I do
not see a reason why this could not have all three, it is close as it is
and the only thing holding it back are clear definitions of what will
and won't work where for an end user that doesn't require 20 minutes
worth of work for each plugin to see if it SHOULD work. This has much
less to do with the technical requirements of the spec, and much more to
do with looking down the road and realizing that if this spec IS fully
taken advantage of, things might very well get messy.
Seablade
9:44 a.m.
On Thu, May 10, 2007 at 08:51:22AM -0400, Thomas Vecchione wrote:
And how is it doing to be described is my point. At the moment it is
being described as a function of what internal extensions are there in
the case of something that does beyond the spec. If this was one or two
extensions it wouldn't be bad at all, but since we are aiming for
expandability BEYOND what we can thing of right now I think it is a
large mistake to not plan for what would happen if there are 50
different extensions.
How about waiting a bit what extensions appear at all?
Can't make meaningful plans for profiles or whatever beforehand,
anyway.
Again no. A host could still choose whatever they
support. However,
for example, an audio host might support the audio extensions, a video
host might support the video extensions, and a host that is midi capable
the midi extensions. If you are dealing with 20 or 30 extensions there
for whatever reason, are you honestly going to have an end-user go
through and say, ok this extension is present, this one is present, this
one is not, crap my plugin won't work or will be missing a gui.
For the common user, hosts and plugin collections should be part
of the distribution he uses. Ideally host packages would recommend
plugin collections, but I only know that feature from Debian.
Anyway, the issue of the user having to check what works where
doesn't has to appear in this case.
It might be far easier to list the supporting hosts for each plugin,
once the number of extensions outgrows the number of hosts. It's not
difficult to read a plain list.
Do not get me wrong, as I have said repeatedly thus
far, LV2 is nice and
highly expandable, and I certainly don't want to change that, but that
by itself will not make it usable for the end user. Power and
flexibility do not necessarily equate ease of use, and personally I do
not see a reason why this could not have all three, it is close as it is
and the only thing holding it back are clear definitions of what will
and won't work where for an end user that doesn't require 20 minutes
worth of work for each plugin to see if it SHOULD work. This has much
less to do with the technical requirements of the spec, and much more to
do with looking down the road and realizing that if this spec IS fully
taken advantage of, things might very well get messy.
Please recognise that a new standard needs a phase of experimentation.
You simply can't decide on every possible what-if and nail everything
down, as then nothing is ever pushed out the door.
--
Thorsten Wilms
Thorwil's Design for Free Software:
http://thorwil.wordpress.com
9:51 a.m.
On Thu, May 10, 2007 at 12:53:44PM +0200, torbenh(a)gmx.de wrote:
the problem will be rather: why has this plugin a GUI in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
So how can the toolkit issue be adressed?
Could there be something like GUI hosts to assist plugin hosts
by running plugin GUIs that use another toolkit?
What does DSSI do?
--
Thorsten Wilms
Thorwil's Design for Free Software:
http://thorwil.wordpress.com
10:01 a.m.
For the common user, hosts and plugin collections
should be part
of the distribution he uses.
Oh I sincerely hope we are not going to tie people in like this, that
would be a VERY bad thing IMO.
It might be far easier to list the supporting hosts for each plugin,
once the number of extensions outgrows the number of hosts. It's not
difficult to read a plain list.
But it is more work, and if that list grows at all then it is a lot of
extra work. Not only that, but we are dealing with open source, is
someone going to go around to each individual project that exists,
whether or not they know about it, and test each individual plugin that
exists, whether or not we know about it? Again this is VST support in
linux as it currently stands all over again. Someone asks me if a
certain VST plugin is supported all I can answer is maybe. And a list
does exist for it, just usually doesn't have half the plugins people
look for as it depends on others trying it and reporting it, and their
exact configurations.
Please recognise that a new standard needs a phase of
experimentation.
You simply can't decide on every possible what-if and nail everything
down, as then nothing is ever pushed out the door.
I am fully aware of that, but the entire point of LV2 being so flexible
is specifically so that the 'what-if' I am proposing CAN happen. I
(Personally) think it is foolish to build the spec specifically so that
it can happen, and then ignore what will happen when it does.
What happens when arbitrary extensions are made by a handful of people,
for a handful of plugins on a year by year basis. In a couple of years
you have significantly more than a handful of extensions.
Will it happen? Who knows. But, my understanding is that LV2 was
written specifically so that the above COULD happen if it needed, and it
is extremely easy to define new extensions.
If we want it to remain a 'standard' plugin format, we should plan for
it being used to its capabilities and make sure some level of
interoperability remains, and that that level is clear for the end-user
to understand.
As I mentioned before I am tossing out my two cents in full
understanding that it can be chosen to be extensively ignored, with
every right, on the part of any or all of the developers. I don't mean
to offend any of them here, and I certainly don't take offense at folks
disagreeing with me, just so that it is clear.
It is just my two cents based off my experience with helping people
understand linux audio thus far and a major pitfall I see with building
something extremely flexible and powerful but without any organization
so those less technical saavy folks can understand it.
Seablade
10:25 a.m.
On Thu, May 10, 2007 at 10:11:19AM -0400, Thomas Vecchione wrote:
Tie in?
For the common
user, hosts and plugin collections should be part
of the distribution he uses.
Oh I sincerely hope we are not going to tie people in like this, that
would be a VERY bad thing IMO. What happens when arbitrary extensions are made by a
handful of people,
for a handful of plugins on a year by year basis. In a couple of years
you have significantly more than a handful of extensions.
This is FLOSS, right? Nobody gets to tell people what to do or not
in the end. So if anyone wants to create 'arbitrary' extensions,
he will. No profiles, no nothing change that.
It's a wild software jungle out there anyway and I really do think we
have to rely on distributors to make it more handable for the average
user, where average user refers to everyone who is for whatever reason
not able or inclined to go out there to explore, test and learn.
--
Thorsten Wilms
Thorwil's Design for Free Software:
http://thorwil.wordpress.com
10:58 a.m.
On 10 May 2007, at 08:35, Richard Spindler wrote:
2007/5/10, Dave Robillard
<drobilla(a)connect.carleton.ca>ca>:
I don't support it unless someone has a representation issue. You're
not like to see if (fs == 44100) anyway, and if you did you'd want to
hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if
(fs_num / fs_denom == 44100) then things are bit dodgy anyway.
Whew, a lot of ifs.
- Steve
Regarding the one sensible thing you /have/ said:
is sample rate
as a
double sufficient, or is there a good reason for numerator/
denominator
using a double as samplerate is highly undesirable, because for
example someone might want to test for specific samplerates, like
if ( samplerate == 44100) { ... }
And this cannot be done with a float value with the necessary
"exactness". ;-)
I do support the proposal to use two integer values.
11:04 a.m.
On 10 May 2007, at 14:51, Thorsten Wilms wrote:
On Thu, May 10, 2007 at 12:53:44PM +0200,
torbenh(a)gmx.de wrote:
DSSI runs the plugin UI in a separate process with its own X
connection. It's not ideal, but it works OK. The biggest problem is
that it makes it trickier for the host to re-parent the UI - I don't
know if anyone's made that work.
However it's important not to let the perfect be the enemy of the
good. Having UIs at all is more important than subtle features that
some host would like to make things prettier / more convienient.
- Steve
the problem will be rather: why has this plugin a GUI in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
So how can the toolkit issue be adressed?
Could there be something like GUI hosts to assist plugin hosts
by running plugin GUIs that use another toolkit?
What does DSSI do?
11:12 a.m.
On Thu, 2007-05-10 at 16:05 +0100, Steve Harris wrote:
On 10 May 2007, at 14:51, Thorsten Wilms wrote:
Re-parenting can be done using the XEMBED protocol, implemented in e.g.
GTK as the Socket and Plug widgets. You need to give the Socket the
window ID of the Plug or vice versa, so to do it in DSSI would require a
(trivial) extension of the host <-> GUI communication protocol. I did
some simple experiments with it earlier and it seems to work fine.
--ll
On Thu, May 10, 2007 at 12:53:44PM +0200,
torbenh(a)gmx.de wrote:
DSSI runs the plugin UI in a separate process with its own X
connection. It's not ideal, but it works OK. The biggest problem is
that it makes it trickier for the host to re-parent the UI - I don't
know if anyone's made that work.
the problem will be rather: why has this plugin a GUI in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
So how can the toolkit issue be adressed?
Could there be something like GUI hosts to assist plugin hosts
by running plugin GUIs that use another toolkit?
What does DSSI do?
11:20 a.m.
On 10 May 2007, at 16:10, Lars Luthman wrote:
On Thu, 2007-05-10 at 16:05 +0100, Steve Harris
wrote:
OK, well that's cool then.
It would still suck on windows because processes are very expensive
there, but that doesn't concern me too much; X servers are not that
common on windows anyway, so hypothetical DSSI/LV windows UIs could
use a different mechanism.
- Steve
On 10 May 2007, at 14:51, Thorsten Wilms wrote:
Re-parenting can be done using the XEMBED protocol, implemented in
e.g.
GTK as the Socket and Plug widgets. You need to give the Socket the
window ID of the Plug or vice versa, so to do it in DSSI would
require a
(trivial) extension of the host <-> GUI communication protocol. I did
some simple experiments with it earlier and it seems to work fine. On Thu, May 10, 2007 at 12:53:44PM +0200,
torbenh(a)gmx.de wrote:
DSSI runs the plugin UI in a separate process with its own X
connection. It's not ideal, but it works OK. The biggest problem is
that it makes it trickier for the host to re-parent the UI - I don't
know if anyone's made that work.
the problem will be rather: why has this plugin a GUI in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
So how can the toolkit issue be adressed?
Could there be something like GUI hosts to assist plugin hosts
by running plugin GUIs that use another toolkit?
What does DSSI do?
11:50 a.m.
On Thu, 2007-05-10 at 16:21 +0100, Steve Harris wrote:
On 10 May 2007, at 16:10, Lars Luthman wrote:
Lars' GUI extension is directly embeddable without a separate process or
xembed hacks or anything.
'course it's also GTK only..
-DR-
On Thu, 2007-05-10 at 16:05 +0100, Steve Harris
wrote:
Re-parenting can be done using the XEMBED protocol, implemented in
e.g.
GTK as the Socket and Plug widgets. You need to give the Socket the
window ID of the Plug or vice versa, so to do it in DSSI would
require a
(trivial) extension of the host <-> GUI communication protocol. I did
some simple experiments with it earlier and it seems to work fine.
OK, well that's cool then.
It would still suck on windows because processes are very expensive
there, but that doesn't concern me too much; X servers are not that
common on windows anyway, so hypothetical DSSI/LV windows UIs could
use a different mechanism.
12:18 p.m.
On Thu, 2007-05-10 at 11:03 +0200, Arnold Krille wrote:
And I don't think fons talks about extras like
radio but things like smoother
automation (controlling velocity in a smoother way)...
He didn't even mention guis (which I concur is a bonus and a host not
implementing graphics should still give access to the parameters via text).
As I said before, I'm personally a big fan of better control ports.
However the ones that are there are LADSPA equivalent, and porting both
hosts and plugins would be much more annoying if they were removed.
I look forward to having better control ports, but that is not something
that needs to go into LV2 itself; ports of any new type can be added.
Currently MIDI (which is hardly a niche feature for plugins in general)
is implemented as an extension as well - there's no downside to this.
Extensions are not "second class" in any way. We can designate popular
extensions as "official" extensions in the future, but this basically
just documentation and means nothing.
So yes, better controls will be nice, but it does not need to be in the
LV2 spec itself. This sort of incremental improvement by the community
is exactly what LV2 has been designed to support. We don't all /need/
to fight on the mailing list about these ports, because someone who
cares can just get on with doing it, and the problem can be
discussed/solved independently.
Right now we just need to make sure all these things are
possible, /then/ we can get on with making them happen.
-DR-
1:39 p.m.
Tie in?
Tie someone into a specific distribution because that is the first one
they tried and had something they liked.
This is FLOSS, right? Nobody gets to tell people what
to do or not
in the end. So if anyone wants to create 'arbitrary' extensions,
he will. No profiles, no nothing change that.
EXACTLY my point. When do they cease being arbitrary extensions and
instead be something a bit more structural for those programming the
host to have a basic idea of what they should do to support the majority
of plugins.
It's a wild software jungle out there anyway and I
really do think we
have to rely on distributors to make it more handable for the average
user, where average user refers to everyone who is for whatever reason
not able or inclined to go out there to explore, test and learn.
I would completely disagree, that seems like a very lazy way of doing
things(No offense intended to you personally Thorsten). Oh this seems
to difficult, let someone else do it.
Seablade
2:19 p.m.
On Thu, 2007-05-10 at 13:49 -0400, Thomas Vecchione wrote:
Seems there's a bit of confusion here.
"Extensions" usually include, if anything at all, a single header file
and maybe a bit of data in a .ttl file (though usually you only care
about what's in the plugins data file anyway). Extensions of the simple
"function with more parameters" kind don't require any additional code
at all (you just dlsym your symbol and use it as specified).
For a host to support an extension, it can include everything it needs
in the host itself. Since this is a specification (and not a specific
library interface), this is the best way of doing things.
Translation: no "tie in" here.
There is the possibililty of helper libraries to make dealing with
extensions (or plugins, or anything), but that's par for the course.
Apps depending on libraries is business as usual, and app authors can
handle the situation however they please.
I still fail to see what this "profile" idea actually entails, in
concrete terms... I suspect it doesn't mean anything at all ;) As Lars
points out, trying to tell everyone what to do isn't worth the effort,
and is contrary to the whole point here anyway. I'm not sure why anyone
would want to bother trying to come up with arbitrary definitions of
feature set combinations and slapping a "profile" name on it. What's
the point? Support the features you can/want to support..
That said, this is purely a documentation issue. A nice central
location for finding what's out there in LV2 land would be useful. A
wiki is probably the only thing that's feasible, unless someone wants to
maintain something more custom.
-DR-
Tie in?
Tie someone into a specific distribution because that is the first one
they tried and had something they liked.
This is FLOSS, right? Nobody gets to tell people
what to do or not
in the end. So if anyone wants to create 'arbitrary' extensions,
he will. No profiles, no nothing change that.
EXACTLY my point. When do they cease being arbitrary extensions and
instead be something a bit more structural for those programming the
host to have a basic idea of what they should do to support the majority
of plugins.
2:46 p.m.
Translation: no "tie in" here.
My "Tie In" comment was directly related to this specific sentence by
Thorsten...
For the common user, hosts and plugin collections
should be part
of the distribution he uses.
I despise the thought of being "tied in" to a distribution as a user,
especially since very rarely does a distribution match my needs exactly.
That is my own personal preference there, I should have made it more
specific.
I still fail to see what this "profile" idea
actually entails, in
concrete terms... I suspect it doesn't mean anything at all ;) As Lars
points out, trying to tell everyone what to do isn't worth the effort,
and is contrary to the whole point here anyway. I'm not sure why anyone
would want to bother trying to come up with arbitrary definitions of
feature set combinations and slapping a "profile" name on it. What's
the point? Support the features you can/want to support..
The point is to allow people not familiar with the technicalities of it
to know when their plug-in will or won't work. As I have said in the
past, I only use the 'profile' because I couldn't come up with a simpler
way of doing it(And asked for other suggestions). All the profile would
be is a defined set of extensions that are included in its support to
allow some form of consistency across the board.
That said, this is purely a documentation issue. A
nice central
location for finding what's out there in LV2 land would be useful. A
wiki is probably the only thing that's feasible, unless someone wants to
maintain something more custom.
I mentioned it was not a technical issue some time ago. It is all in
how it is presented, and that some forethought needs to be given to this
in the event that the flexibility IS taken advantage of in LV2.
Seablade
4:07 p.m.
On Wednesday 09 May 2007, Dave Robillard wrote:
If you want to discuss fixed block sizes, etc, discuss
the existing work
done in that area by tapas (who has longed for that feature for ages
now, and I assume from the lack of objections from him that things are
fine on that front). There is already a solution to this, if you have a
problem with the solution, let it be known.
Yep, no objections :) As these extensions (fixed-buffersize and
power-of-two-buffersize) are rather easy to implement, especially for jack
apps where the API guarantees a fixed power of two buffersize in between
buffer-size callbacks [aha - this should be an extension, too ;)], i hope all
LV2 hosts which are useful [for me] at all will support it :) So i considered
this problem solved.
Have fun,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
5:39 p.m.
On Thu, May 10, 2007 at 03:58:25PM +0100, Steve Harris wrote:
I don't support it unless someone has a
representation issue. You're
not like to see if (fs == 44100) anyway, and if you did you'd want to
hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if
(fs_num / fs_denom == 44100) then things are bit dodgy anyway.
Let me state once and for all, even it will not gain me any popularity:
Anyone who thinks that writing a range check on a fraction A/B is too
difficult is very probably completely incompetent and should not waste
his/her time trying to write audio DSP code for a plugin.
This is not a reflection on Steve's competences which are beyond doubt.
But if the word of Linux Audio wants to accommodate amateurism and
ignorance at the expense of professionalism and experience, I will
not hesitate a second to say goodbey. I'll feel sad for a few days
but not much longer.
--
FA
Follie! Follie! Delirio vano è questo !
6:08 p.m.
On 10 May 2007, at 22:44, Fons Adriaensen wrote:
On Thu, May 10, 2007 at 03:58:25PM +0100, Steve Harris
wrote:
I wasn't suggesting it was hard, just that doing the value check on
an integer is no easier than doing it on a double, so that's not an
argument in either direction.
I don't support it unless someone has a
representation issue. You're
not like to see if (fs == 44100) anyway, and if you did you'd want to
hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if
(fs_num / fs_denom == 44100) then things are bit dodgy anyway.
Let me state once and for all, even it will not gain me any
popularity:
Anyone who thinks that writing a range check on a fraction A/B is
too
difficult is very probably completely incompetent and should not
waste
his/her time trying to write audio DSP code for a plugin. But if the word of Linux Audio wants to accommodate
amateurism and
ignorance at the expense of professionalism and experience, I will
not hesitate a second to say goodbey. I'll feel sad for a few days
but not much longer.
I'm not sure that it's reasonable to to describe representing sample
rates as a floating point number as amateurish. Switching to a
numerator/denominator pair is a bit of a departure, and will
significantly increase the effort of porting LADSPA plugins to LV2,
so I'm not keen until I understand the benefit in concrete terms.
I dislike boilerplate code that appears everywhere, and certainly all
my plugins would grow
double fs = (double)fs_denom / (double)fs_num; which seems a bit
pointless on the face of it.
I could probably run sed script to switch to num/denom format, but
it's almost zero effort to switch to a double, and none of my plugins
will derive any benefit whatsoever from the dum/denom pair. Do you
have an example of where knowing both factors is useful?
- Steve
9:13 p.m.
On Thu, 2007-05-10 at 23:44 +0200, Fons Adriaensen wrote:
On Thu, May 10, 2007 at 03:58:25PM +0100, Steve Harris
wrote:
I don't think it's all that reasonable to go attacking others for not
accepting an idea before even justifying the idea...
The fraction method is just a nuisance, it has nothing to do with
competence. If there's a sufficiently compelling reason for the
rational number approach, we should go with that, if not, we should
stick with the double. Obviously.
-DR-
I don't support it unless someone has a
representation issue. You're
not like to see if (fs == 44100) anyway, and if you did you'd want to
hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if
(fs_num / fs_denom == 44100) then things are bit dodgy anyway.
Let me state once and for all, even it will not gain me any popularity:
Anyone who thinks that writing a range check on a fraction A/B is too
difficult is very probably completely incompetent and should not waste
his/her time trying to write audio DSP code for a plugin.
This is not a reflection on Steve's competences which are beyond doubt.
But if the word of Linux Audio wants to accommodate amateurism and
ignorance at the expense of professionalism and experience, I will
not hesitate a second to say goodbey. I'll feel sad for a few days
but not much longer.
9:37 p.m.
On Thu, May 10, 2007 at 11:44:54PM +0200, Fons Adriaensen wrote:
On Thu, May 10, 2007 at 03:58:25PM +0100, Steve Harris
wrote:
Anyone who refuses to write LV2 extensions has a bad taste.
this is about aesthetics.
we all love the sound, but look:
void Ladspa_Moogvcf2::runproc (unsigned long len, bool add)
{
int k;
float *p0, *p1, *p2, *p3, *p4;
float c1, c2, c3, c4, c5;
float g0, g1, r, dr, w, dw, x, t;
p0 = _port [0];
p1 = _port [1];
p2 = _port [2] - 1;
p3 = _port [3] - 1;
p4 = _port [4] - 1;
g0 = exp2ap (0.1661 * _port [5][0]) / 2;
g1 = exp2ap (0.1661 * _port [10][0]) * 2;
if (add) g1 *= _gain;
c1 = _c1 + 1e-6;
c2 = _c2;
c3 = _c3;
c4 = _c4;
c5 = _c5;
w = _w;
r = _r;
do
{
k = (len > 24) ? 16 : len;
p2 += k;
p3 += k;
p4 += k;
len -= k;
t = exp2ap (_port [7][0] * *p3 + _port [6][0] + *p2 + 10.71) / _fsam;
if (t < 0.8) t *= 1 - 0.4 * t - 0.125 * t * t;
else
{
t *= 0.6;
if (t > 0.92) t = 0.92;
}
dw = (t - w) / k;
t = _port [9][0] * *p4 + _port [8][0];
if (t > 1) t = 1;
if (t < 0) t = 0;
dr = (t - r) / k;
while (k--)
{
w += dw;
r += dr;
x = -4.5 * r * c5 + *p0++ * g0 + 1e-10;
// x = tanh (x);
x /= sqrt (1 + x * x);
c1 += w * (x - c1) / (1 + c1 * c1);
c2 += w * (c1 - c2) / (1 + c2 * c2);
c3 += w * (c2 - c3) / (1 + c3 * c3);
c4 += w * (c3 - c4) / (1 + c4 * c4);
if (add) *p1++ += g1 * (c4);
else *p1++ = g1 * (c4);
c5 += 0.5 * (c4 - c5);
}
}
while (len);
_c1 = c1;
_c2 = c2;
_c3 = c3;
_c4 = c4;
_c5 = c5;
_w = w;
_r = r;
}
you are IMO disqualified from aestetics discussions :)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
I don't support it unless someone has a
representation issue. You're
not like to see if (fs == 44100) anyway, and if you did you'd want to
hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if
(fs_num / fs_denom == 44100) then things are bit dodgy anyway.
Let me state once and for all, even it will not gain me any popularity:
Anyone who thinks that writing a range check on a fraction A/B is too
difficult is very probably completely incompetent and should not waste
his/her time trying to write audio DSP code for a plugin.
10:30 p.m.
On Fri, 2007-05-11 at 03:45 +0200, torbenh(a)gmx.de wrote:
On Thu, May 10, 2007 at 11:44:54PM +0200, Fons
Adriaensen wrote:
[snip]
On Thu, May 10, 2007 at 03:58:25PM +0100, Steve
Harris wrote:
Anyone who refuses to write LV2 extensions has a bad taste.
this is about aesthetics.
we all love the sound, but look:
void Ladspa_Moogvcf2::runproc (unsigned long len, bool add)
{ I don't support it unless someone has a
representation issue. You're
not like to see if (fs == 44100) anyway, and if you did you'd want to
hedge a bit: if (fs > 44090 && fs < 44110). If you have to write if
(fs_num / fs_denom == 44100) then things are bit dodgy anyway.
Let me state once and for all, even it will not gain me any popularity:
Anyone who thinks that writing a range check on a fraction A/B is too
difficult is very probably completely incompetent and should not waste
his/her time trying to write audio DSP code for a plugin. you are IMO disqualified from aestetics discussions :)
.... uh oh.
Can we figure out this sample rate thing before this gets really
ugly? :)
-DR-
10:37 p.m.
On Wed, 2007-05-09 at 02:53 +0100, Steve Harris wrote:
The current iteration of the LV2 specification seems
to have settled
down, and there are a significant number of implementations now, so,
assuming that there's no problems found with the current spec I
propose to rename it as 1.0 in a few weeks time.
[snip]
Implementations
SLV2 - a library by Dave Robillard that makes it easy to add LV2
support to existing hosts, includes example code and documentation.
tarball: http://download.drobilla.net/ , docs: http://drobilla.net/
doc/slv2/modules.html and sample code: http://drobilla.net/doc/slv2/
lv2_simple_jack_host.c
I forgot to mention; I'd appreciate it if anyone (especially host
authors or anyone with C library experience and an eye for binary
compatibility) could give the SLV2 API a quick overview/critique (the
dox linked above or the headers in /slv2 in the tarball)
It has evolved mostly to suit Nedko and my own needs, but a few more
eyes would be beneficial. I'd like to get it nailed down solid, future
proof, released, and in distributions ASAP.
Also, anyone who knows about that whole "packaging" thing and has a bit
of free time on their hands.... :)
Thanks,
-DR-
11 May
11 May
5:51 a.m.
New subject: power-of-two buffer size. (was: Re: [ANN] LV2 beta3)
Florian Schmidt wrote:
On Wednesday 09 May 2007, Dave Robillard wrote:
I don't think the power-of-two buffersize is guaranteed by
the jack API.
It is true that the ALSA backend wants the buffers to be a power of two.
But AFAIK it is not an API guarantee.
If I'm wrong, I'll have to fix the freebob backend because it doesn't
enforce this.
Pieter
If you want to discuss fixed block sizes, etc,
discuss the existing work
done in that area by tapas (who has longed for that feature for ages
now, and I assume from the lack of objections from him that things are
fine on that front). There is already a solution to this, if you have a
problem with the solution, let it be known.
Yep, no objections :) As these extensions (fixed-buffersize and
power-of-two-buffersize) are rather easy to implement, especially for jack
apps where the API guarantees a fixed power of two buffersize in between
buffer-size callbacks [aha - this should be an extension, too ;)], i hope all
LV2 hosts which are useful [for me] at all will support it :) So i considered
this problem solved.
5:57 a.m.
On Fri, May 11, 2007 at 03:45:36AM +0200, torbenh(a)gmx.de wrote:
Anyone who refuses to write LV2 extensions has a bad
taste.
this is about aesthetics.
I don't refuse to use extensions. My point is that they should
be used for adding user-level functionality such as MIDI or OSC
support, but not to get the basic low-level stuff right.
My critique on the basic LV2 spec is not that it doesn't support
certain types of application (these can be added by extensions),
but that it provides very poor or broken support for certain types
of algorithms. Probably because the people who defined it have
never written those kind of things and are not aware of what is
required.
To re-use a previous example, it's like a car that does work,
it has wheels, and engine, a gas tank, etc. But it doesn't
have lights, a hand break, or windscreen wipers. Most of the
time you don't need any of these. But if you drive at night
you need lights, it it rains you need windscreen wipers and
in the hills you need a handbrake. All three are mandatory
in most countries.
we all love the sound, but look:
Ah, my very first Linux code !!! (tears of emotion :-).
There a a few things I would do differently today (as I
did in more recent plugins):
- use enum'ed port names,
- use 'z1, z2, z3...' as the variables representing filter
state (corresponding to z^{-1} in the maths).
For the rest, I suspect you're falling over the terse style
and short variable names. All this is essentially mathematical
code. People use short names like a,b,c (variables), i,j,k
(indices), or x,y,z (unknowns or coordinates) in maths.
If you know the subject matter they are as good as any other.
If not, there is no point in reading this sort of code, it's
not meant to be tutorial.
Suppose you write code to solve a quadratic equation.
Everybody will understand:
d = sqrt (b * b - 4 * a * c)
because that is what is in the textbooks, and what you have
learned at school. Writing this as:
discriminant=sqrt(square(firstOrderCoefficient)-4*secondOrderCoefficient*constantTerm)
will not contribute anything useful.
--
FA
Follie! Follie! Delirio vano è questo !
6:38 a.m.
On Fri, May 11, 2007 at 03:45:36AM +0200, torbenh(a)gmx.de wrote:
this is about aesthetics.
...
you are IMO disqualified from aestetics discussions :)
As I'm writing this I'm listening to a very nice piece of
music, written by composer who is well known and highly
regarded in this community. Yet I'm sure most of you would
disqualify it on 'aesthetic' grounds, or what you may think
are aestethic grounds.
Except under fascist regimes, or those controlled by
religious zealots, aesthetics are subjective.
Also note:
aesthetics != hype_of_the_day
aesthetics != political correctness
BTW, I did notice the :)
--
FA
Follie! Follie! Delirio vano è questo !
8:59 a.m.
Dave Robillard wrote:
Can we figure out this sample rate thing before this gets really
ugly? :)
Please use rational values. Hardly anyone ever resamples to an
irrational number and it's also needed to do proper A/V sync.
While it's true that most real-life applications will be happy with a
(double) - it can not guarantee exactness and most (double)-precision
bugs are hard to trace/detect in the source.
ffmpeg provides a simple API - see their `rational.h`
static inline double av_q2d(AVRational a){
return a.num / (double) a.den;
}
2c,
robin
9:37 a.m.
On Fri, 2007-05-11 at 14:55 +0200, Robin Gareus wrote:
Dave Robillard wrote:
That sounds like a good argument for two ints to me. Although you'd have
to do a lot better than double if you wanted to represent irrational
numbers in binary form. =)
(NaN and Inf doesn't count)
--ll
Can we figure out this sample rate thing before this gets really
ugly? :)
Please use rational values. Hardly anyone ever resamples to an
irrational number and it's also needed to do proper A/V sync.
11:12 a.m.
On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
That sounds like a good argument for two ints to me.
Although you'd have
to do a lot better than double if you wanted to represent irrational
numbers in binary form. =)
Two 32-bit ints can represent (the non-integer part of) most (not all)
irrational values to better precision than a double. The algo to find
them is a bit mysterious but very simple. Simple example: 355/113 is
equal to pi with a relative error of less than 1e-7, not bad for two
3-digit numbers. It's not difficult to find two 32-bit ints that would
be better than a double.
--
FA
Follie! Follie! Delirio vano è questo !
11:12 a.m.
New subject: power-of-two buffer size. (was: Re: [ANN] LV2 beta3)
On Friday 11 May 2007, Pieter Palmers wrote:
Florian Schmidt wrote:
I remember i looked this up before. Right now i only found this:
http://jackaudio.org/files/docs/html/jack_8h.html#a14
"nframes new buffer size. Must be a power of two"
This is the jack_set_buffer_size docs. I think i remember having read this in
a different context, too. But it seems the docs have changed or i have
dreamed..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On Wednesday 09 May 2007, Dave Robillard wrote:
I don't think the power-of-two buffersize is guaranteed by the jack API.
It is true that the ALSA backend wants the buffers to be a power of two.
But AFAIK it is not an API guarantee.
If I'm wrong, I'll have to fix the freebob backend because it doesn't
enforce this. If you want to discuss fixed block sizes, etc,
discuss the existing work
done in that area by tapas (who has longed for that feature for ages
now, and I assume from the lack of objections from him that things are
fine on that front). There is already a solution to this, if you have a
problem with the solution, let it be known.
Yep, no objections :) As these extensions (fixed-buffersize and
power-of-two-buffersize) are rather easy to implement, especially for
jack apps where the API guarantees a fixed power of two buffersize in
between buffer-size callbacks [aha - this should be an extension, too
;)], i hope all LV2 hosts which are useful [for me] at all will support
it :) So i considered this problem solved.
11:22 a.m.
On Friday 11 May 2007, Fons Adriaensen wrote:
On Fri, May 11, 2007 at 03:45:36AM +0200,
torbenh(a)gmx.de wrote:
Since there is a way to add all this functionality as extension, the question
is:
Why would you _not_ want these as extensions, but as part of the core api?
I can think of several reasons:
- If it were implemented as extension you would put extra load on the
developers of plugins/hosts. Namely that they have to grok the extension
mechanism.. Luckily the extension mechanism is very simple, thus only a tiny
bit of extra work is required.. I don't think this extra work is in any way
significant, especially for people writing more than one plugin (the overhead
of using this functionality as part of an extensions as compared to a direct
implementation in the core is very very small, the only overhead left is the
initial learning of the extension mechanism itself)
- A more important point is fragmentation. Some hosts will support only these
features, different hosts only others etc.. This will decrease end user
experience if it interferes with really basic functionality (e.g. there is
more than one extension for something like fixed buffersizes, etc..). I am
pretty sure though that pretty soon a fixed set of extensions will evolve
which all hosts will implement. LV2 is basically the _ideal_ playground for
such an evolution to take place.
The current discussion clearly shows that there are differing opinions about
what is essential and what not.. Let evolution take over :) It will probably
take a while. But that's the beauty of LV2: Even if the core devs don't agree
with you, not all is lost :) But time will show that you were right... And
once this issue has been settled by having an essential set of extensions
they might go into the next core spec.
I do agree with you that there is such an essential set of features that
really should be in the core spec, but as it will sort itself out anyways by
means of evolution, i also consider this problem fixed ;)
Have fun,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Anyone who refuses to write LV2 extensions has a
bad taste.
this is about aesthetics.
I don't refuse to use extensions. My point is that they should
be used for adding user-level functionality such as MIDI or OSC
support, but not to get the basic low-level stuff right.
My critique on the basic LV2 spec is not that it doesn't support
certain types of application (these can be added by extensions),
but that it provides very poor or broken support for certain types
of algorithms. Probably because the people who defined it have
never written those kind of things and are not aware of what is
required.
12:20 p.m.
On Fri, May 11, 2007 at 05:13:17PM +0200, Florian Schmidt wrote:
On Friday 11 May 2007, Fons Adriaensen wrote:
Since there is a way to add all this functionality as extension, the question
is:
Why would you _not_ want these as extensions, but as part of the core api?
I can think of several reasons:
...
- A more important point is fragmentation. Some hosts will support only these
features, different hosts only others etc.. This will decrease end user
experience if it interferes with really basic functionality (e.g. there is
more than one extension for something like fixed buffersizes, etc..). I am
pretty sure though that pretty soon a fixed set of extensions will evolve
which all hosts will implement. LV2 is basically the _ideal_ playground for
such an evolution to take place.
This comes close. Allow me quote myself:
You can probably explain to a non-technical user that some hosts do support
e.g. MIDI or OSC and others don't - these are things he knows. You can not
IMHO explain to the average user that his favourite host does not accept
his favourite reverb plugin because it does not support a particular type
of algorithm - it's a different world that he doesn't care about. The basic
infrastructure to support all types of processing should be present in all
hosts, and it doesn't take much. You just have to know they exist and think
a bit.
A second reason would be that using different init() and run() functions,
not in function of user-level functionality but just to support some types
of algorithm complicates a host for no good reason. OTOH the extra data
required to support multi-channel, multi-rate and block-oriented algos
is minimal, it doesn't complicate a host or get in the way of anything,
and can be simply be ignored if you don't need it.
Thirdly, since it seems already impossible to explain this to the core
designers, I won't hold my breath until some host developers understand
why some simple things are necessary, and implement them. It will not
happen. Which means that I can't write the plugins I'd want to write
because no host will support them. And if I have to write both the host
and the plugins, I could as well use any other API that does the job.
I'm fully behind the ideas at the basis of LV2 as regards high-level
functionality. But the rules - and the aesthetics - in the low-level
underworld of DSP are different to those of IT engineering in general.
Things have to be as simple and efficient as possible, even if this
goes at the expense of beautiful abstractions.
--
FA
Follie! Follie! Delirio vano è questo !
12:58 p.m.
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman
wrote:
So, that's true, but I've still not seen an example of where an
synchronous audio plugin needs to know the numerator and denominator
individually to better do it's processing.
A double can represent pi with an error of 2e-16, and I can't believe
that the billionth of a cent detune error is in any way significant.
I am probably being dense here, but please give an example. In the
meantime I'm going to write some code to measure the accumulated
error, incase its just a trivial piece of arithmetic that's escaped
me. Floating point maths is sometimes non-intuative.
- Steve
That sounds like a good argument for two ints to
me. Although
you'd have
to do a lot better than double if you wanted to represent irrational
numbers in binary form. =)
Two 32-bit ints can represent (the non-integer part of) most (not all)
irrational values to better precision than a double. The algo to find
them is a bit mysterious but very simple. Simple example: 355/113 is
equal to pi with a relative error of less than 1e-7, not bad for two
3-digit numbers. It's not difficult to find two 32-bit ints that would
be better than a double.
2:17 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman
wrote:
OK, so I ran some test code (http://plugin.org.uk/misc/num-denom-vs-
double.c) and there is indeed a measurable drift when using double
accumulators - if you have numerators and denominators that are float
unfriendly - which is not /that/ unlikely. But, it's equivalent to a
worst-case detune of less than 1/10000th of a cent as far as I can
tell - not audible, but possibly measurable under extreme
circumstances, as long as no analogue hardware is involved (which
rules out listening to it for eg.).
So, this makes me marginally more sympathetic to the idea that it is
useful, but I'm still not quite convinced that:
a) many people will bother to do their accumulators in integer space
without rounding, and
b) hosts will have the sample rate available to them in that form.
If there's a plugin developer that will use integer pair accumulators
(I guess Fons will?) and a host that will generate denominators other
than a power of ten or two I'm happy to go with the int pair. It
could also be that my maths is wrong.
My preference is still to go for a double, as the difference is too
minimal to be audible, under any circumstances, and it makes plugin
developers lives harder. LV2 is intended to be an audio plugin
format, not for scientific uses. Of course if the host gets its
sample rate as a double, it's a PITA, and generally lossy to convert
that into num/denom.
- Steve
That sounds like a good argument for two ints to
me. Although
you'd have
to do a lot better than double if you wanted to represent irrational
numbers in binary form. =)
Two 32-bit ints can represent (the non-integer part of) most (not all)
irrational values to better precision than a double. The algo to find
them is a bit mysterious but very simple. Simple example: 355/113 is
equal to pi with a relative error of less than 1e-7, not bad for two
3-digit numbers. It's not difficult to find two 32-bit ints that would
be better than a double.
2:51 p.m.
On 11 May 2007, at 16:13, Florian Schmidt wrote:
I do agree with you that there is such an essential set of features
that
really should be in the core spec, but as it will sort itself out
anyways by
means of evolution, i also consider this problem fixed ;)
I also agree. I agree with Fons that there are "essential" features
missing from LV2, but I don't agree about which ones. However, in the
interests of Just Getting On With It I want the extensions to evolve.
Designing specifications without pretty extensive implementation
experience is fraught (look at LADSPA), this is an unfortunate
catch-22. The IETF and W3C will only standardise things that are
already common practice. I know LAD is not really in that world - no-
one will loose millions of dollars if we mess up - but I'm sure we
all value our time highly.
- Steve
3:29 p.m.
On 11 May 2007, at 16:56, Fons Adriaensen wrote:
A second reason would be that using different init() and run()
functions,
not in function of user-level functionality but just to support
some types
of algorithm complicates a host for no good reason. OTOH the extra
data
required to support multi-channel, multi-rate and block-oriented algos
is minimal, it doesn't complicate a host or get in the way of
anything,
and can be simply be ignored if you don't need it.
I don't support the idea of adding multirate (in the resampling
sense) support to LV2, I think it can be handled better by other APIs.
Multi-channel is non issue as far as I can see.
Block oriented needs some thought and experimentation, but the
existing extension seems fine to me, as a first cut. Experience will
show whether its sufficient and appropriate to the problem. I'll note
that there already several block-based LADSPA plugins, where LADSPA
has zero support for these features, you have to suffer compromises,
its ugly, and they don't work in the general case, just common case,
but it is possible.
Thirdly, since it seems already impossible to explain
this to the core
designers, I won't hold my breath until some host developers
understand
why some simple things are necessary, and implement them. It will not
happen. Which means that I can't write the plugins I'd want to write
because no host will support them. And if I have to write both the
host
and the plugins, I could as well use any other API that does the job.
There's necessary in order to not make things any worse than the
status quo, and there's necessary to implement some hypothetical
plugins that don't yet exist.
Entering into a "jam tomorrow" discussion of everyone's pet features
is at best fraught and at worst fatal to the process. You might think
that there are only 3 things missing, but so does everyone else, and
they wont be the same 3 things. After a while you have GMPI over-
specification hell.
LV2 offers several useful features out of the box that LADSPA
doesn't*, and it's long overdue, so I think any suggestion that it
would be a bad thing to standardise it asis, is nonsense. When we
have experience of, and consensus on things such as block-based
processing we can produce a 1.1 spec that mandates them.
* fixing the nasty UID issue, port symbols and port connected-ness
spring to mind.
- Steve
3:42 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Fri, May 11, 2007 at 06:24:38PM +0100, Steve Harris wrote:
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
>Two 32-bit ints can represent (the non-integer
part of) most (not all)
>irrational values to better precision than a double. The algo to find
>them is a bit mysterious but very simple. Simple example: 355/113 is
>equal to pi with a relative error of less than 1e-7, not bad for two
>3-digit numbers. It's not difficult to find two 32-bit ints that would
>be better than a double.
First, if you read the paragraph above in its context, it should be
clear that this is *not* the rationale for having sample rates as
a ratio of two integers. It's just a side note.
(Sigh) I have already written (some nights ago) that this has nothing
to do with _absolute_ precision. Most sound cards are way off their
nominal sample rate anyway, and very few people complain.
This is about _relative_ precision in multirate processing. It only
works if the ratios are exact. It does not work at all if they are
not. I can easily imagine processing networks where not all plugins
run at the same rate, but at rates related by simple integer ratios.
Maybe improbable for music production. But certainly possible for
audio DSP work in general.
b) hosts will have the sample rate available to them
in that form.
??? In the current spec the sample rate is an integer. JACK and ALSA
will give you an integer. Just set the denominator to 1 if your host
runs all plugins at the normal sample rate, as most will do.
** That's really all there is to it. **
We may even require that if the sample rate is integer the denominator
must be set to 1. Simple plugins that can't do division and expect a
single integer can then refuse to instantiate if the denominator is
not 1.
:-)
--
FA
Follie! Follie! Delirio vano è questo !
4:48 p.m.
On Fri, May 11, 2007 at 08:26:50PM +0100, Steve Harris wrote:
I don't support the idea of adding multirate (in
the resampling
sense) support to LV2, I think it can be handled better by other APIs.
??? It has nothing to do with resampling.
Multi-channel is non issue as far as I can see.
It's most certainly not.
...
...
I've had enough of this, and will just forget about LV2.
As you said, things will be better handled by other APIs.
--
FA
Follie! Follie! Delirio vano è questo !
7:11 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 11 May 2007, at 20:37, Fons Adriaensen wrote:
No all hosts run in JACK or ALSA, there are gstreamer LADSPA hosts
and Core Audio LADSPA hosts offline LADSPA hosts, and so on.
- Steve
On Fri, May 11, 2007 at 06:24:38PM +0100, Steve Harris
wrote:
I see. So that's the point that I missed. Here, I think the
difference of opinion is that I don't think LADSPA-style APIs are at
all appropriate for multirate audio - the LADSPA API was built very
much with input sample rate = output sample rate in mind. I think
that any move away from that will complicate the API, when a better
solution would be to use a different API altogether.
In audio production, IME the main need for multirate processing in
music production is resampling, and while there are a wide variety of
resampling algorithms, I'm not sure it justifies a plugin URI, or any
kind of substantial addendum to one. IMHO it certainly should not be
a major feature of a predominantly synchronous API, due to the level
of complexity it brings with it. You can argue that you can ignore
the multirate features if you're writing synchronous plugins, but the
multirate parameters will always be there, confusing newbies and
making the spec document longer.
LADSPA, for all its faults was very easy to start programming. I
would never have bothered learning if it was a complex as AudioUnits,
for example.
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> Two 32-bit ints can represent (the
non-integer part of) most (not
> all)
> irrational values to better precision than a double. The algo to
> find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that
> would
> be better than a double.
First, if you read the paragraph above in its context, it should be
clear that this is *not* the rationale for having sample rates as
a ratio of two integers. It's just a side note.
(Sigh) I have already written (some nights ago) that this has nothing
to do with _absolute_ precision. Most sound cards are way off their
nominal sample rate anyway, and very few people complain.
This is about _relative_ precision in multirate processing. It only
works if the ratios are exact. It does not work at all if they are
not. I can easily imagine processing networks where not all plugins
run at the same rate, but at rates related by simple integer ratios.
Maybe improbable for music production. But certainly possible for
audio DSP work in general. b) hosts will
have the sample rate available to them in that form.
??? In the current spec the sample rate is an integer. JACK and ALSA
will give you an integer. Just set the denominator to 1 if your host
runs all plugins at the normal sample rate, as most will do.
12 May
12 May
12:16 a.m.
On Fri, 2007-05-11 at 17:56 +0200, Fons Adriaensen wrote:
I'm fully behind the ideas at the basis of LV2 as
regards high-level
functionality. But the rules - and the aesthetics - in the low-level
underworld of DSP are different to those of IT engineering in general.
Things have to be as simple and efficient as possible, even if this
goes at the expense of beautiful abstractions.
Being an "extension" doesn't introduce any additional complexity or
inefficiency.
-DR-
12:18 a.m.
On Fri, 2007-05-11 at 17:23 +0100, Steve Harris wrote:
On 11 May 2007, at 16:13, Florian Schmidt wrote:
++
-DR-
I do agree with you that there is such an essential set of features
that
really should be in the core spec, but as it will sort itself out
anyways by
means of evolution, i also consider this problem fixed ;)
I also agree. I agree with Fons that there are "essential" features
missing from LV2, but I don't agree about which ones. However, in the
interests of Just Getting On With It I want the extensions to evolve.
12:20 a.m.
On Fri, 2007-05-11 at 17:56 +0200, Fons Adriaensen wrote:
On Fri, May 11, 2007 at 05:13:17PM +0200, Florian
Schmidt wrote:
> On Friday 11 May 2007, Fons Adriaensen wrote:
>
> Since there is a way to add all this functionality as extension, the question
> is:
>
> Why would you _not_ want these as extensions, but as part of the core api?
>
[snip]
A second reason would be that using different init()
and run() functions
For at least the third time.. additional init() functions does not make
sense. The existing init function already has an arbitrarily extensible
parameter mechanism.
-DR-
12:37 a.m.
On Fri, 2007-05-11 at 22:24 +0200, Fons Adriaensen wrote:
On Fri, May 11, 2007 at 08:26:50PM +0100, Steve Harris
wrote:
Multichannel in LV2 is straightforward and will almost certainly be
used.
I don't support the idea of adding multirate
(in the resampling
sense) support to LV2, I think it can be handled better by other APIs.
??? It has nothing to do with resampling.
Multi-channel is non issue as far as I can see.
It's most certainly not. I've had enough of this, and will just forget
about LV2.
As you said, things will be better handled by other APIs.
Considering the FACT that something doesn't need to be in lv2.h for you
to be able to use it, all save one of your objections are not actually
problems.
The valid one you did bring up (which is appreciated), sample rate, is
currently being discussed and figured out so everyone is happy.
I fail to see the problem here.
-DR-
12:43 a.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Fri, 2007-05-11 at 22:36 +0100, Steve Harris wrote:
On 11 May 2007, at 20:37, Fons Adriaensen wrote:
I'm not so sure I agree with that; you /could/ do multirate with LV2.
Yes, it's more complicated, but no more complicated than multirate audio
via any other API (other than the slight un-prettyness of having a
single hardcoded sample rate parameter).
Anyway, there's no doubt that the basic plugin API shouldn't be made
more complicated by this esoteric need, so agreed there. As with
everything else, that bridge can be crossed when someone gets there...
-DR-
On Fri, May 11, 2007 at 06:24:38PM +0100, Steve
Harris wrote:
I see. So that's the point that I missed. Here, I think the
difference of opinion is that I don't think LADSPA-style APIs are at
all appropriate for multirate audio - the LADSPA API was built very
much with input sample rate = output sample rate in mind. I think
that any move away from that will complicate the API, when a better
solution would be to use a different API altogether. On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> Two 32-bit ints can represent (the
non-integer part of) most (not
> all)
> irrational values to better precision than a double. The algo to
> find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that
> would
> be better than a double.
First, if you read the paragraph above in its context, it should be
clear that this is *not* the rationale for having sample rates as
a ratio of two integers. It's just a side note.
(Sigh) I have already written (some nights ago) that this has nothing
to do with _absolute_ precision. Most sound cards are way off their
nominal sample rate anyway, and very few people complain.
This is about _relative_ precision in multirate processing. It only
works if the ratios are exact. It does not work at all if they are
not. I can easily imagine processing networks where not all plugins
run at the same rate, but at rates related by simple integer ratios.
Maybe improbable for music production. But certainly possible for
audio DSP work in general.
12:52 a.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Fri, 2007-05-11 at 18:24 +0100, Steve Harris wrote:
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
>
>> That sounds like a good argument for two ints to me. Although
>> you'd have
>> to do a lot better than double if you wanted to represent irrational
>> numbers in binary form. =)
>
> Two 32-bit ints can represent (the non-integer part of) most (not all)
> irrational values to better precision than a double. The algo to find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that would
> be better than a double.
[snip]
My preference is still to go for a double, as the
difference is too
minimal to be audible, under any circumstances, and it makes plugin
developers lives harder.
The annoyance on the plugin developer is small enough that I don't think
it sways the decision very much.
I'm all for LV2 being minimal, since extensions can take care of
additional functionality and everything will just work out all nice and
open sourcey; but deliberately putting things in the spec that's known
to be less able than a (not that much more complicated) alternative
really doesn't sit right with me.
A single division doesn't justify crippling the spec if there's any even
remotely feasible application of the numerator/demoninator method, IMO.
LV2 is intended to be an audio plugin
format, not for scientific uses. Of course if the host gets its
sample rate as a double, it's a PITA, and generally lossy to convert
that into num/denom.
This, OTOH, would sway the decision more than the division, if it were
actually a problem (though being a host and not plugin nuisance weakens
the relevance quite a bit). It's not a problem on any of the (typical
'round these parts) audio APIs I know.. is it a problem anywhere LV2 is
ever likely to see the light of day?
-DR-
3:39 a.m.
New subject: power-of-two buffer size. (was: Re: [ANN] LV2 beta3)
On Fri, 2007-05-11 at 11:50 +0200, Pieter Palmers wrote:
I don't think the power-of-two buffersize is
guaranteed by the jack API.
It is true that the ALSA backend wants the buffers to be a power of two.
But AFAIK it is not an API guarantee.
If I'm wrong, I'll have to fix the freebob backend because it doesn't
enforce this.
A power of two is fine for PCI boards, but is it also optimal for say
USB audio?
IIRC, USB happens once every millisecond so I for one would have thought
that numbers like 48, 96 or 44 and 45 would pop up naturally
4:02 a.m.
New subject: power-of-two buffer size. (was: Re: [ANN] LV2 beta3)
On Sat, May 12, 2007 at 09:39:44AM +0200, Jens M Andreasen wrote:
A power of two is fine for PCI boards, but is it also
optimal for say
USB audio?
IIRC, USB happens once every millisecond so I for one would have thought
that numbers like 48, 96 or 44 and 45 would pop up naturally
The driver layer is supposed to handle that. Unfortunately ALSA
seems to have problems with this. The simple solution is to use
a three-period buffer size (-n 3), at least at 48 kHz.
At 44.1 kHz the number of samples transferred each millisecond is
not a constant. So either that turns into a non-constant period size
or the driver layer has to handle the repackaging.
--
FA
Follie! Follie! Delirio vano è questo !
5:52 a.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Fri, 2007-05-11 at 21:37 +0200, Fons Adriaensen wrote:
??? In the current spec the sample rate is an integer.
JACK and ALSA
will give you an integer. Just set the denominator to 1 if your host
runs all plugins at the normal sample rate, as most will do.
Given the function f(a,b), where most people would only need to bother
about f(a), we could do:
#define f(a) f2(a,1)
So there you have it. In this case it really is possible to both eat
your cake and keep it.
The friendly one-page skeleton pass-thru demo will not mention the
second parameter, but it will be documented in the man page.
** That's really all there is to it. **
3:34 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 12 May 2007, at 05:52, Dave Robillard wrote:
On Fri, 2007-05-11 at 18:24 +0100, Steve Harris
wrote:
You might feel differently if you had 100 run methods to change, but
yes.
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
>
>> That sounds like a good argument for two ints to me. Although
>> you'd have
>> to do a lot better than double if you wanted to represent
>> irrational
>> numbers in binary form. =)
>
> Two 32-bit ints can represent (the non-integer part of) most (not
> all)
> irrational values to better precision than a double. The algo to
> find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that
> would
> be better than a double.
[snip]
My preference is still to go for a double, as the
difference is too
minimal to be audible, under any circumstances, and it makes plugin
developers lives harder.
The annoyance on the plugin developer is small enough that I don't
think
it sways the decision very much. I'm all for LV2 being minimal, since extensions
can take care of
additional functionality and everything will just work out all nice
and
open sourcey; but deliberately putting things in the spec that's known
to be less able than a (not that much more complicated) alternative
really doesn't sit right with me.
Sure.
A single division doesn't justify crippling the
spec if there's any
even
remotely feasible application of the numerator/demoninator method,
IMO.
No idea.
- Steve
LV2 is intended to be an audio plugin
format, not for scientific uses. Of course if the host gets its
sample rate as a double, it's a PITA, and generally lossy to convert
that into num/denom.
This, OTOH, would sway the decision more than the division, if it were
actually a problem (though being a host and not plugin nuisance
weakens
the relevance quite a bit). It's not a problem on any of the (typical
'round these parts) audio APIs I know.. is it a problem anywhere
LV2 is
ever likely to see the light of day?
3:35 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 12 May 2007, at 10:52, Jens M Andreasen wrote:
On Fri, 2007-05-11 at 21:37 +0200, Fons Adriaensen
wrote:
Ugh. I really don't like that. If the API mandates a num/denom, make
sure its propertly documented and people use it, otherwise it's a
waste of everyone's time, and it will never be possible to use it in
practice.
I can only assume that Fons was joking when he said that, as he's so
concerned about compatibility.
Also,
if (denom != 1) return 1;
double fs = (double)num;
is more complex than
double fs = (double)num/(double)denom;
- Steve
??? In the current spec the sample rate is an
integer. JACK and ALSA
will give you an integer. Just set the denominator to 1 if your host
runs all plugins at the normal sample rate, as most will do.
Given the function f(a,b), where most people would only need to bother
about f(a), we could do:
#define f(a) f2(a,1)
So there you have it. In this case it really is possible to both eat
your cake and keep it.
The friendly one-page skeleton pass-thru demo will not mention the
second parameter, but it will be documented in the man page.
5:58 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Sat, 2007-05-12 at 20:35 +0100, Steve Harris wrote:
On 12 May 2007, at 10:52, Jens M Andreasen wrote:
> Given the function f(a,b), where most people
would only need to bother
> about f(a), we could do:
>
Ugh. I really don't like that. If the API mandates
a num/denom, make
sure its propertly documented and people use it, otherwise it's a
waste of everyone's time, and it will never be possible to use it in
practice.
Ehrm, I think I said it should be documented in the man page, but
perhaps not in the skeleton demo aimed at people with a bright idea
they'd like to try out
I can only assume that Fons was joking when he said
that, as he's so
concerned about compatibility.
You don't have to like it, actually most people (except for Fons?) can
just ignore it and move on with whatever it was that they were doing ...
The cost of pushing one or a few extra more/less redundant parameters on
the stack is /nada/ compared to the pointer arithmetics involved in
figuring out where the in and out buffers are located, and then start
shuffling data around and then, while we are at it, perhaps do something
with the data as well?
And no, I can't follow Fons here either, and this discussion has no
relevance to my own line of thought (which is very stubborn integerish
BTW) but, if this is important to a minority, then why not? The overhead
is next to nil and the added complexity can be hidden from those who
don't know how to make it tick.
Mmmmm ....
Or perhaps Fons needs to clearify his case to make it obvious for
everyone that this is the way to go
6:27 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 12 May 2007, at 22:58, Jens M Andreasen wrote:
they can't /ignore/ it, they have to use it. I agree that it doesn't
have to be very taxing.
On Sat, 2007-05-12 at 20:35 +0100, Steve Harris
wrote:
People will copy the skeleton demo, so if it doesn't use the
denominator you may as well not have it.
On 12 May 2007, at 10:52, Jens M Andreasen wrote:
> Given the function f(a,b), where most people
would only need to
> bother
> about f(a), we could do:
>
Ugh. I really don't like that. If the API
mandates a num/denom, make
sure its propertly documented and people use it, otherwise it's a
waste of everyone's time, and it will never be possible to use it in
practice.
Ehrm, I think I said it should be documented in the man page, but
perhaps not in the skeleton demo aimed at people with a bright idea
they'd like to try out I can only
assume that Fons was joking when he said that, as he's so
concerned about compatibility.
You don't have to like it, actually most people (except for Fons?) can
just ignore it and move on with whatever it was that they were
doing ... The cost of pushing one or a few extra more/less
redundant
parameters on
the stack is /nada/ compared to the pointer arithmetics involved in
figuring out where the in and out buffers are located, and then start
shuffling data around and then, while we are at it, perhaps do
something
with the data as well?
The computational cost is vanishingly small.
- Steve
26 May
26 May
1:05 p.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Fri, 2007-05-11 at 18:24 +0100, Steve Harris wrote:
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
>
>> That sounds like a good argument for two ints to me. Although
>> you'd have
>> to do a lot better than double if you wanted to represent irrational
>> numbers in binary form. =)
>
> Two 32-bit ints can represent (the non-integer part of) most (not all)
> irrational values to better precision than a double. The algo to find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that would
> be better than a double.
So, what's the verdict on this?
Don't want to fall into the perpetual beta with known issue trap, I'd
like to fix the sample rate issue and crank out another beta ASAP..
I'm skeptical we'd ever actually see a plugin that would use rational
sample rate, so I vote double unless:
- rational is required for perfect video sync over long time frames
- someone can provide a concrete example of a realistic plugin that
would require/benefit from rational
-DR-
30 May
30 May
5:30 a.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 26 May 2007, at 18:05, Dave Robillard wrote:
On Fri, 2007-05-11 at 18:24 +0100, Steve Harris
wrote:
Agreed. And no-one has to my knowledge.
Multirate processing would require an extension, so that extension
may as well add the num/denom format for the sample rates as and when
it's needed.
- Steve
On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
>
>> That sounds like a good argument for two ints to me. Although
>> you'd have
>> to do a lot better than double if you wanted to represent
>> irrational
>> numbers in binary form. =)
>
> Two 32-bit ints can represent (the non-integer part of) most (not
> all)
> irrational values to better precision than a double. The algo to
> find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that
> would
> be better than a double.
So, what's the verdict on this?
Don't want to fall into the perpetual beta with known issue trap, I'd
like to fix the sample rate issue and crank out another beta ASAP..
I'm skeptical we'd ever actually see a plugin that would use rational
sample rate, so I vote double unless:
- rational is required for perfect video sync over long time frames
- someone can provide a concrete example of a realistic plugin that
would require/benefit from rational
5:43 a.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On Wed, 2007-05-30 at 10:30 +0100, Steve Harris wrote:
On 26 May 2007, at 18:05, Dave Robillard wrote:
Unless you count internal filter banks with lower samplerate for each
band (to save memory and CPU, since they have lower bandwidth than the
total signal). But I don't know enough about multi-rate processing to
suggest an actual example.
--ll
On Fri, 2007-05-11 at 18:24 +0100, Steve Harris
wrote:
Agreed. And no-one has to my knowledge.
Multirate processing would require an extension, so that extension
may as well add the num/denom format for the sample rates as and when
it's needed. On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
>
>> That sounds like a good argument for two ints to me. Although
>> you'd have
>> to do a lot better than double if you wanted to represent
>> irrational
>> numbers in binary form. =)
>
> Two 32-bit ints can represent (the non-integer part of) most (not
> all)
> irrational values to better precision than a double. The algo to
> find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that
> would
> be better than a double.
So, what's the verdict on this?
Don't want to fall into the perpetual beta with known issue trap, I'd
like to fix the sample rate issue and crank out another beta ASAP..
I'm skeptical we'd ever actually see a plugin that would use rational
sample rate, so I vote double unless:
- rational is required for perfect video sync over long time frames
- someone can provide a concrete example of a realistic plugin that
would require/benefit from rational 
9:29 a.m.
New subject: num/denom v's double (was: Re: [ANN] LV2 beta3)
On 5/30/07, Lars Luthman <lars.luthman(a)gmail.com> wrote:
On Wed, 2007-05-30 at 10:30 +0100, Steve Harris
wrote:
mmm. This isn't really an example for the num/denom format but I used
to run my physical synthesis ladspa plugins with low sample rates as
you could control sample rate as a way of controlling wave speed. It
also made the processor load a lot lower. Using these in jack
environment where your actually doing anything else would possibly be
an example but you can do the multirate code in the plugin instead of
the host though just as easily. I can't think of another use but i
don't know anything about video stuff.
Loki
On 26 May 2007, at 18:05, Dave Robillard wrote:
Unless you count internal filter banks with lower samplerate for each
band (to save memory and CPU, since they have lower bandwidth than the
total signal). But I don't know enough about multi-rate processing to
suggest an actual example.
--ll
On Fri, 2007-05-11 at 18:24 +0100, Steve Harris
wrote:
Agreed. And no-one has to my knowledge.
Multirate processing would require an extension, so that extension
may as well add the num/denom format for the sample rates as and when
it's needed. On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
>
>> That sounds like a good argument for two ints to me. Although
>> you'd have
>> to do a lot better than double if you wanted to represent
>> irrational
>> numbers in binary form. =)
>
> Two 32-bit ints can represent (the non-integer part of) most (not
> all)
> irrational values to better precision than a double. The algo to
> find
> them is a bit mysterious but very simple. Simple example: 355/113 is
> equal to pi with a relative error of less than 1e-7, not bad for two
> 3-digit numbers. It's not difficult to find two 32-bit ints that
> would
> be better than a double.
So, what's the verdict on this?
Don't want to fall into the perpetual beta with known issue trap, I'd
like to fix the sample rate issue and crank out another beta ASAP..
I'm skeptical we'd ever actually see a plugin that would use rational
sample rate, so I vote double unless:
- rational is required for perfect video sync over long time frames
- someone can provide a concrete example of a realistic plugin that
would require/benefit from rational
6181
days inactive
6203
days old
linux-audio-dev@lists.linuxaudio.org
87 comments
17 participants
participants (17)
-
Arnold Krille -
Dave Robillard -
Florian Schmidt -
Fons Adriaensen -
IOhannes m zmoelnig -
Jack O'Quin -
Jens M Andreasen -
Lars Luthman -
Loki Davison -
Nedko Arnaudov -
Pieter Palmers -
Richard Spindler -
Robin Gareus -
Steve Harris -
Thomas Vecchione -
Thorsten Wilms -
torbenh＠gmx.de