4 Mar
2011
4 Mar
'11
12:30 p.m.
Hi,
Just a quick question, where does validation of parameters belong?
Invalid params might crash the engine, so some validation should go there.
But if the job of validation is down to the UI, the engine can be more
efficient.
But if multiple UIs are possible, validation effort is duplicated.
How should I approach?
Cheers,
James.
--
_
: http://jwm-art.net/
-audio/image/text/code/
4 Mar
4 Mar
12:33 p.m.
On Fri, Mar 4, 2011 at 6:30 AM, James Morris <jwm.art.net(a)gmail.com> wrote:
But if multiple UIs are possible, validation effort is
duplicated.
duplication never hurt anyone, much. especially since each instance
might differ in the view of what the limits are.
12:53 p.m.
On 4 March 2011 11:33, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Fri, Mar 4, 2011 at 6:30 AM, James Morris
<jwm.art.net(a)gmail.com> wrote:
What about if the engine depends on the limits to be properly set in
order for it to function correctly?
I'm thinking in particular of a sampler and its play and loop ranges.
The loop range must reside within the play range, and the play range
must reside within the actual bounds of the sample.
If I were to add a release loop to this... Then at minimum the end
point of the second loop would need to be after (or equal to) the end
point of the first loop.
I suppose the obvious answer is to put this validation in the set and
get methods of the engine.
I just wondered if someone could define a case where it would be in
the set/get methods of engine, and another case where it should be in
the UI.
Regards,
James.
--
_
: http://jwm-art.net/
-audio/image/text/code/
But if multiple UIs are possible, validation
effort is duplicated.
duplication never hurt anyone, much. especially since each instance
might differ in the view of what the limits are.
8:17 p.m.
On Fri, 2011-03-04 at 11:53 +0000, James Morris wrote:
On 4 March 2011 11:33, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
Make your plugin robust. Plugins should not crash no matter what the
host throws at them.
In theory, yes, we could define a bunch of strict rules and such to
remove this burden from plugin authors, but in practise that road leads
to flaky software.
On Fri, Mar 4, 2011 at 6:30 AM, James Morris
<jwm.art.net(a)gmail.com> wrote:
What about if the engine depends on the limits to be properly set in
order for it to function correctly? But if multiple UIs are possible, validation
effort is duplicated.
duplication never hurt anyone, much. especially since each instance
might differ in the view of what the limits are.
I suppose the obvious answer is to put this validation
in the set and
get methods of the engine.
I just wondered if someone could define a case where it would be in
the set/get methods of engine, and another case where it should be in
the UI.
The reason to do it in the "UI" (actually host) is performance.
<insert famous quote about premature optimization here>
-dr
12:53 p.m.
On Friday 04 March 2011 12:30:13 James Morris wrote:
Just a quick question, where does validation of
parameters belong?
Invalid params might crash the engine, so some validation should go there.
But if the job of validation is down to the UI, the engine can be more
efficient.
The engine doesn't have to do the validation in the realtime-processing
thread. Just check for the limits where the values enter the engine. This can
easily done when using functions to set the values and thus hiding the
internal queues (to get the new values to the realtime-engine without blocking
either side).
But if multiple UIs are possible, validation effort is
duplicated.
Well, checking the limits once to many doesn't crash the engine. Not checking
the limits might...
Have fun,
Arnold
12:54 p.m.
2011/3/4 James Morris <jwm.art.net(a)gmail.com>om>:
But if the job of validation is down to the UI, the
engine can be more
efficient.
The current LV2 spec says that the plugin's "engine" should validate
its inputs anyway... IIRC, there is a draft/experimental extension
that allows the host to specify that it will take care of that, but I
haven't seen it used yet (and probably it should be that way until it
gets "serious enough").
However, I have no idea whether how much performance gain you would
obtain from that and/or if it allows to do stuff that you can't do
now.
In my (admittedly limited) experience in developing LV2 plugins, it
shouldn't be much of a problem.
Stefano
7:56 p.m.
On Fri, 2011-03-04 at 11:30 +0000, James Morris wrote:
Hi,
Just a quick question, where does validation of parameters belong?
Invalid params might crash the engine, so some validation should go there.
But if the job of validation is down to the UI, the engine can be more
efficient.
But if multiple UIs are possible, validation effort is duplicated.
How should I approach?
Plugins must gracefully handle out-of-range values, typically either by
clamping or ignoring. The ranges in LV2 are "soft".
There could be an extension for "hard" limits, as a micro-optimization,
but I don't know if one exists (or if the performance advantage of
avoiding an if or two is worth the hassle).
-dr
5073
days inactive
5073
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Arnold Krille -
David Robillard -
James Morris -
Paul Davis -
Stefano D'Angelo