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

[Tim Goetze]

[Fons Adriaensen]

>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.

ok, then you've probably already connected LFOs to TOGGLED and INTEGER
ports. i haven't heard you complain about their 'typedness' yet.

>> 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.

it may be trivial, but your model forces its duplication over and over
again in every plugin implementing the functionality, for no good
reason.

besides, nobody ever planned on stopping you from using any signal as
a trigger. the behaviour is pretty shaky with TOGGLED and INTEGER
already (requires knowledge of the internals of either host or plugins
or both), so i don't understand your concern about TRIGGER or
MOMENTARY in this regard.

>> 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.

always? just a few paragraphs before, you said you connect anything to
anything in ams, disregarding value interpretation by the plugins. how
come they will always agree? and if the host wants to inject signals
into the plugin network? or is this out of the question? do you expect
signals to always come from a ladspa plugin? do you expect all hosts
to work like ams? do you expect all users to be as knowledgeable as
you about the internals of ams and ladspa?

and what about the need for a 'low' signal between two triggers? you
haven't given us a good way to handle this yet with the generic model.

>> 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.

there may be many professionals on this list, but it may also have
occurred to you that a different work ethic is prevalent.

you're using linux, no? well, linus came up with that thing without
requesting a detailed specification first. by now, it is made of
thousands of patches that no-one ever specified in detail first.

you're using ladspa too, no? if Richard hadn't come up with an
implementation mostly of his own, we'd probably still be sitting in
the trees, singing 'oh how nice if we had a plugin API, i have this
great idea for one here'.

particularly here, things don't move forward if nobody ever pushes
into implementation. for another great example, Paul came up with Jack
without first asking around for specifications.

you will surely know that one major reason for the distinction between
specification and implementation in the professional world is that it
*saves you a lot of work changing your implementation over and over
again*. don't break your head over the work i do. i'm just fine,
thanks.

lastly, so far the least concern about the patches has been the
implementation itself, and it hasn't mixed into the discussion
of the concepts afaict.

>> 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.

HAS_VERSION is utterly necessary at some point to allow for API
versioning to be done cleanly, and better sooner than later. i'm
surprised to hear you, a professional, criticize so essential an
idea.

>> 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.

granted. i have some doubts that you will be able to convincingly
advertise your proposal's merits without providing code however.

>> 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.

so what's against supplying one solution to two problems?

amicalement,

tim