8 Mar
2004
8 Mar
'04
10:10 p.m.
On Tue, Mar 09, 2004 at 12:46:09AM +0100, Tim Goetze wrote:
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.
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.
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.
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
[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. 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. 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?
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?