8 Mar
2004
8 Mar
'04
7:57 p.m.
[Fons Adriaensen]
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.
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.
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.
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.
granted. i have some doubts that you will be able to convincingly
advertise your proposal's merits without providing code however.
so what's against supplying one solution to two problems?
amicalement,
tim
On Mon, Mar 08, 2004 at 10:06:25PM +0100, Tim Goetze
wrote:
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.
[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. 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. 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. 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.