Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
From: Fons Adriaensen (fons.adriaensen_AT_skynet.be)
Date: Tue Mar 09 2004 - 04:10:54 EET
On Tue, Mar 09, 2004 at 12:46:09AM +0100, Tim Goetze wrote:
> [Fons Adriaensen]
> >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.
I have not yet seen an AUDIO and (TOGGLED or INTEGER) port. Anything non-
AUDIO in AMS is (by default) mapped to a GUI widget, not a port. So most
probably I have not done this.
> >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.
Most plugins that require this will probably want to do this their own
way for their own good reasons. And it is *really* trivial in most cases.
BTW, if your pushbutton emits the trigger signal *while* it is pressed,
as you stated before, then you still need edge detection logic in the plugin,
unless you want to repeat the triggered action for every sample (or at least
every process period) while the button remains pressed.
> >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?
They will not always agree. I also said I was responsable for the result.
As I would be if I a plugged a line output into a mic input.
> 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?
I never said I was against the TRIGGER or MOMENTARY bit. I only said you
only need one of these.
> 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?
No, No.
> 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.
I do not understand what you mean by this.
> there may be many professionals on this list, but it may also have
> occurred to you that a different work ethic is prevalent.
This has nothing to do with ethics.
> 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.
When Linus started this, he was alone. And I'm pretty sure he had a
spec at least in his mind before the first kernel was ever written.
The more people are involved, the more you need it.
> 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*.
That is not the main function of a spec. It provides a framework for
analysis and discussion before any code is written. It also covers
things that are not directly visible in the code. Take for example
the 'when' or 'while' question we discussed before. Where is that
defined in your code ?
> don't break your head over the work i do. i'm just fine, thanks.
I'm not breaking my head :-). But you could have saved yourself a
lot of work.
> 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.
If your proposals are indeed backwards compatible, as I believe they
are, there is no need for this now.
> >It's two different problems that happen to map to similar data structures.
>
> so what's against supplying one solution to two problems?
They are different, and require different solutions.
Functionality : one is essential, the other mostly decorative.
Implementation: one is simple, the other will become more complex as you
go a bit deeper into it.
- Is a host required to provide exactly the value you specify at a scale
point on a slider, or is it allowed to supply the value corresponding to
the pixel position of the scale point ?
- For the integer 'switch', it's not so difficult to design a widget that
will handle all reasonable string lengths. For a slider with tick marks
this is already less evident.
- Maybe you want to specify the physical position of the scale points as
well, either to solve the above problem, or to have something more subtle
than the LIN / LOG choice we have now.
-- FA
This archive was generated by hypermail 2b28 : Tue Mar 09 2004 - 04:06:39 EET