9 Sep
2015
9 Sep
'15
8:57 p.m.
hi richard, paul, stefan and fellow LADders,
the Debian folks currently are a bit at a loss of the proper
interpretation of the LADSPA_PROPERTY_REALTIME property.
ladspa.h says:
/* Property LADSPA_PROPERTY_REALTIME indicates that
the plugin has a
real-time dependency (e.g. listens to a MIDI device) and so its
output must not be cached or subject to significant latency. */
the discussion started about a year ago (see [760758]), and it seems
that there are two opposing interpretations of that property:
#1 setting the property indicates to the host, that the plugin must not
be used in a non-realtime environment.
this means that a plugin that has this property set, must not be used
for batch processing, e.g. because it uses wall-clocked input (like
MIDI-devices) that simply won't deliver proper input when running at a
speed that is decoupled from wall clock.
OR
#2 setting the property indicates to the host, that the plugin can be
run at a lower (timing) priority; so the host can deliberately add
latency without compromising the usefulness of the full processing
chain. that would be mostly for plugins that do not do any input ->
output processing, but only take input (e.g. metering, recording).
that's just a quick summary. there's more arguments in the bugreport
[760758].
personally i lean towards #1 (as i don't see much use cases for the
second interpretation), but given that someone as deeply involved into
linux audio as fons favours #2, i would like to ask the creators of
LADSPA for their canonical view.
thanks for your insights,
gfmadsr
IOhannes
[760758] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760758
9 Sep
9 Sep
9:07 p.m.
My interpretation is that LV2 means LADSPA Version 2 and thus should
be preferred at all times to LADSPA.
On Wed, Sep 9, 2015 at 4:56 PM, IOhannes m zmölnig <zmoelnig(a)iem.at> wrote:
hi richard, paul, stefan and fellow LADders,
the Debian folks currently are a bit at a loss of the proper
interpretation of the LADSPA_PROPERTY_REALTIME property.
ladspa.h says:
/* Property LADSPA_PROPERTY_REALTIME indicates
that the plugin has a
real-time dependency (e.g. listens to a MIDI device) and so its
output must not be cached or subject to significant latency. */
the discussion started about a year ago (see [760758]), and it seems
that there are two opposing interpretations of that property:
#1 setting the property indicates to the host, that the plugin must not
be used in a non-realtime environment.
this means that a plugin that has this property set, must not be used
for batch processing, e.g. because it uses wall-clocked input (like
MIDI-devices) that simply won't deliver proper input when running at a
speed that is decoupled from wall clock.
OR
#2 setting the property indicates to the host, that the plugin can be
run at a lower (timing) priority; so the host can deliberately add
latency without compromising the usefulness of the full processing
chain. that would be mostly for plugins that do not do any input ->
output processing, but only take input (e.g. metering, recording).
that's just a quick summary. there's more arguments in the bugreport
[760758].
personally i lean towards #1 (as i don't see much use cases for the
second interpretation), but given that someone as deeply involved into
linux audio as fons favours #2, i would like to ask the creators of
LADSPA for their canonical view.
thanks for your insights,
gfmadsr
IOhannes
[760758] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760758
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9:16 p.m.
On 09/09/2015 11:07 PM, Paul Davis wrote:
My interpretation is that LV2 means LADSPA Version 2
and thus should
be preferred at all times to LADSPA.
thanks for you input.
i totally agree with your sentiment when it comes to new development.
however, the problem we are trying to solve is bugfixing legacy plugin
code (numerous LADSPA version 1 plugins distributed in major distros
based on Debian won't go away simply because there is now a better
framework).
gfmdstr
IOhannes
9:25 p.m.
Am 09.09.2015 23:15, schrieb IOhannes m zmölnig:
On 09/09/2015 11:07 PM, Paul Davis wrote:
As a host developer I don't care about this extension, because it say's
nothing. I first try to, but, nope, . .
My interpretation is that LV2 means LADSPA
Version 2 and thus should
be preferred at all times to LADSPA.
thanks for you input.
i totally agree with your sentiment when it comes to new development.
however, the problem we are trying to solve is bugfixing legacy plugin
code (numerous LADSPA version 1 plugins distributed in major distros
based on Debian won't go away simply because there is now a better
framework).
gfmdstr
IOhannes
13 Sep
13 Sep
3:07 a.m.
On Wed, 2015-09-09 at 22:56 +0200, IOhannes m zmölnig wrote:
hi richard, paul, stefan and fellow LADders,
the Debian folks currently are a bit at a loss of the proper
interpretation of the LADSPA_PROPERTY_REALTIME property.
ladspa.h says:
We changed the name of this to "isLive" in LV2 to avoid confusion with
the heavily overloaded term "realtime".
I believe #1 is the intent. The hint serves to distinguish plugins that
have some dependency on real time, from those that do not (only
processing their input). The latter can be used in a more functional
way, being called to process a block whenever, where the actual time run
is called is irrelevant. The hint being set essentially means "if the
plugin is activated, run() must be called regularly at a rate roughly
corresponding to the passage of real time"
Th comment says "plugin has a real-time dependency (e.g. listens to a
MIDI device)" which seems pretty clear. Explanation #2, while perhaps a
useful thing in some circumstances, really does not follow from the
hint's definition.
--
dr
/* Property LADSPA_PROPERTY_REALTIME indicates
that the plugin has a
real-time dependency (e.g. listens to a MIDI device) and so its
output must not be cached or subject to significant latency. */
the discussion started about a year ago (see [760758]), and it seems
that there are two opposing interpretations of that property:
#1 setting the property indicates to the host, that the plugin must not
be used in a non-realtime environment.
this means that a plugin that has this property set, must not be used
for batch processing, e.g. because it uses wall-clocked input (like
MIDI-devices) that simply won't deliver proper input when running at a
speed that is decoupled from wall clock.
OR
#2 setting the property indicates to the host, that the plugin can be
run at a lower (timing) priority; so the host can deliberately add
latency without compromising the usefulness of the full processing
chain. that would be mostly for plugins that do not do any input ->
output processing, but only take input (e.g. metering, recording). 
8:29 a.m.
[David Robillard]
I believe #1 is the intent. The hint serves to
distinguish plugins that
have some dependency on real time, from those that do not (only
processing their input). The latter can be used in a more functional
way, being called to process a block whenever, where the actual time run
is called is irrelevant. The hint being set essentially means "if the
plugin is activated, run() must be called regularly at a rate roughly
corresponding to the passage of real time"
Th[e] comment says "plugin has a real-time dependency (e.g. listens to a
MIDI device)" which seems pretty clear. Explanation #2, while perhaps a
useful thing in some circumstances, really does not follow from the
hint's definition.
"This", as it is so succinctly put nowadays.
(I seem to remember Steve Harris telling me he'd asked for the
inclusion of this flag but would later find it ill-conceived and of no
practical use. Could be wrong though, mists of time and all that. In
any event, ignoring the flag altogether seems to be the most pragmatic
solution.)
Cheers, Tim
16 Sep
16 Sep
12:27 a.m.
On Sun, 2015-09-13 at 10:28 +0200, Tim Goetze wrote:
[David Robillard]
I can see its use in theory, though not much in practice seems to have
any need for it.
It makes me think of a "purely functional" flag, which would be more
useful (you only need one instance to run on whatever), but that's much
stronger and forbids any state whatsoever, not just time...
--
dr
I believe #1 is the intent. The hint serves to
distinguish plugins that
have some dependency on real time, from those that do not (only
processing their input). The latter can be used in a more functional
way, being called to process a block whenever, where the actual time run
is called is irrelevant. The hint being set essentially means "if the
plugin is activated, run() must be called regularly at a rate roughly
corresponding to the passage of real time"
Th[e] comment says "plugin has a real-time dependency (e.g. listens to a
MIDI device)" which seems pretty clear. Explanation #2, while perhaps a
useful thing in some circumstances, really does not follow from the
hint's definition.
"This", as it is so succinctly put nowadays.
(I seem to remember Steve Harris telling me he'd asked for the
inclusion of this flag but would later find it ill-conceived and of no
practical use. Could be wrong though, mists of time and all that. In
any event, ignoring the flag altogether seems to be the most pragmatic
solution.)
3176
days inactive
3183
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
David Robillard -
hermann meyer -
IOhannes m zmölnig -
Paul Davis -
Tim Goetze