8 Mar
2004
8 Mar
'04
11:40 p.m.
[Fons Adriaensen]
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.
that is MOMENTARY, and such signals indeed require edge detection in
an event-unaware system as is ladspa.
suppose you want to trigger twice, in two consecutive run() cycles.
you have to 'bring the line down' inbetween to accomplish this if you
only have MOMENTARY, not TRIGGER. how do you do it? you have to split
the first run() cycle into two to bring the line down before you can
bring it up again.
i'm sure you'll want to avoid all the extra code, wasted cycles and
headaches this means.
in addition, to correctly render these consecutive trigger signals,
you have to know future data (the next trigger). the alternative is to
delay the next trigger, either in similar fashion by breaking up the
second run() cycle, or by postponing it until the next cycle. if in
the latter case you have another trigger request waiting to be
signalled then, you're completely lost.
they are backwards compatible through the use of this bit.
On Tue, Mar 09, 2004 at 12:46:09AM +0100, Tim Goetze
wrote:
what makes you presume an LFO is always running at audio rate? running
a network at 64 or 32 frames blocksize is common, and good enough for
many k-rate (control) signals.
there also are a lot of other good k-rate sources besides LFOs.
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. I never said I was against the TRIGGER or MOMENTARY
bit. I only said you
only need one of these.
it's at least hugely convenient to have both, and doesn't change a bit
about your use of plugins. but read on for why it's even necessary.
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. 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 ?
quoting ladspa.h.diff:76: "A simple example for such a signal source
is a pushbutton: the port value is set to a non-zero value when the
button is pressed, and returns to zero when the button is released."
if this is not enough to the point, i am incapable of any form of
communication, and should write neither code nor endless posts in
quijotean style. just tell me. :)
you see, i agree with you about the benefits of a good specification.
but please consider that with many non-native speakers around, it
becomes increasingly difficult to communicate exact ideas. the only
thing that then remains to make your statement is the code.
I'm not breaking my head :-). But you could have
saved yourself a
lot of work.
thanks, even if it should have been for nothing, i won't regret.
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. 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 ?
any host author will try to represent it the best and most useful he
can. the spec says that a host may even choose to ignore the values.
how's that for precision? :) we can't make assumptions about the
host's display interface, not even about the existence of it in the
first place.
nonetheless, a useful idea is a 'magnetic' slider position, or
displaying the value label for a short time when the slider hits or
crosses the value.
- 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.
as above: use it, ignore it, it's up to the host. or, to quote Jesse:
"A very good question, but whichever host comes up with the best answer
wins :)"
- 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.
that surely belongs into RDF, doesn't it?
vriendelijk,
tim