Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
From: Fons Adriaensen (fons.adriaensen_AT_skynet.be)
Date: Tue Mar 09 2004 - 00:23:20 EET
On Mon, Mar 08, 2004 at 10:06:25PM +0100, Tim Goetze wrote:
> [Fons Adriaensen]
> >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.
You can, and you're responsable for the result. I wouldn't want a
host stopping me from doing this, and in fact do similar things all
the time in AMS.
> not to mention you cannot connect an audio output to control input
> without at least some conversion.
That distinction is already made very clear in LADSPA.
> >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.
The required logic is trivial. And it allows you to use any signal as
a trigger.
> 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?
Unless the trigger is coming from a push button provided by the host,
the host doesn't need to know anything at all. The two modules that
are connected need to agree, and that will always the case.
> 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.
You could combine trigger and velocity in the simple MIDI case. But that
is *not* the general case. I can easily imagine a plugin that would sample
and latch not only velocity but also some other parameters when triggered.
On a keyboard, you have velocity together with the trigger, and maybe key
pressure afterwards. But there are other controllers, even within the
limited world of Midi.
> >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'.
Still it's the wrong way round. Describing an idea by its implementation forces
people to focus on two things at a time, and invites confusion. They may for
example agree with the idea but not with the implementation. It can make a
debate considerably more complex, tiring and complex than it need be. If, in
my professional sphere, I would present code at a design review, I'd be removed
from the project.
> >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. :)
Things *are* moving. And to make them settle in the right place, they should
not be pushed too hard :-)
> >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 do believe this. But then the HAS_VERSION thing is not necessary.
> 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.
I beg to disagree here.
> while we're at it, i'd also like to know why limiting the value->label
> mapping to integers is beneficial.
It's two different problems that happen to map to similar data structures.
See my reply to Steve's post.
-- Fons
This archive was generated by hypermail 2b28 : Tue Mar 09 2004 - 00:21:25 EET