[linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

Tim Goetze tim at quitte.de
Mon Mar 8 21:06:25 UTC 2004


[Fons Adriaensen]
>On Mon, Mar 08, 2004 at 06:30:01PM +0100, Tim Goetze wrote:
>> we're already requiring hosts to police connections for value
>> conversions.
>
>Can you point me to some document that contains that requirement ?

not that i knew of any. simple reasoning tells us you cannot, for
example, connect a LFO (-1 .. 1) to, say, a phaser modulation depth
(0 .. 1) control.

not to mention you cannot connect an audio output to control input
without at least some conversion.

>> MOMENTARY: a push button, sending 'yes' when pressed and 'no' when
>> released.
>
>'when' or 'while' ?

'while'. sorry for being vague.

>> TRIGGER: a push button, sending 'yes' only at press *or* release, and
>> 'no' at any other point in time.
>
>Why would you ever need both ? Unless the two events are one sample apart
>(unlikely if they come from a GUI), you can always use the first.
>And if something like "TRIGGER" is used, it should at least send different
>events for press and release. And in that case "MOMENTARY" is a subset and
>consequently not required.

from a philosophical point of view, you are certainly right. from the
implementation pov, the generalization you are postulating forces
plugins only interested in 'when do i (re)start my wave cycle, sample
playback, ADSR envelope etc' to contain a lot of unnecessary logic
for edge detection (transition of state) of the generalized
trigger/momentary signal.

and how is a host supposed to translate, for example, a MIDI note-on
in this generic model? it needs to know whether the plugin is going to
act on rising or falling edge to start with. how? if the plugin is
acting on falling edge, the host needs to raise the value for at least
one run() call and drop it for the next. is this practical? does this
support accurate timing? how much code does it require we'd never need
with a dedicated one-shot trigger concept?

ok, suppose we say only MOMENTARY, and one-shot triggering is always
rising edge. now we have another problem: Taybin is pretty adamant in
requiring MOMENTARY to imply TOGGLED. this means we'll always need
another port to transmit the velocity value for note-on and similar
events. fine, no problem? apart from this meaning a waste of
resources, how do we transmit two such impulses in successive run()
calls? simply split the run() call in two? at what a waste of
resources do we arrive then, for the doubtful pleasure of having
a 'simple' model. beats the intention of simplicity if you ask me.

>I'm more and more alarmed by the way this debate is going. I see lots of
>ideas but no clearly defined concepts nor any attention to completeness and
>consistency. I see implementation (diffs on ladspa.h) before specification.

the point in providing diffs is to have a concrete base for
discussion, to show this is not fantasy but a working concept, and to
make clear that this is not 'how about this when we have the next blue
moon, and peace on earth' but 'now is the time to do something about
it, so speak up'.

the discussion revolves around a lot of concepts because a lot of
things in ladspa need clarification or improving. so far, i find this
discussion a lot more fruitful than any we've had before.

>If such as thing as a new LADSPA version (with feautures that can *not* be
>ignored by a host without impairing functionality of either the host or the
>plugin) is introduced, then we should at least sit down, think, and come
>out with something that is structured and consistent. I'm not saying such
>a move is necessary.

i agree about the sitting down part. however, i *am* saying movement
is necessary. :)

>Note that the two changes I proposed
>
>- HINT_ENUMERATED, always together with HINT_INTEGER, and appending
>  the labels to an existing array,
>
>- HINT_CAN_BE_NULL, to signal that a port pointer can be NULL
>  when unconnected,
>
>can be safely ignored by any host. In the fist case, the GUI will show
>ints instead of labels. In the second, the plugin may waste some CPU
>cycles.

so far, everything proposed by us both can be safely ignored by 1.1
hosts.

i'm slowly getting tired of repeating this over and over again. if you
do not believe me, compile any host or plugin [collection] of your
choice against a patched ladspa.h, and check for impaired
functionality. in this context, i'd like to point out that the
proposed solution of PortValueEnum does not cause older hosts to
display integers where labels should show up, but you may want to
see so for yourself.

i would also like to encourage you to post a patch for
HINT_ENUMERATED, and show how it's supposed to work for plugins and
hosts. it's so much easier to talk about it once it's coded up, and
proven to work as intended.

while we're at it, i'd also like to know why limiting the value->label
mapping to integers is beneficial.

-

my apologies for a far too long post. i agree that verbosity is not
always a virtue.

vriendelijk,

tim



More information about the Linux-audio-dev mailing list