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

[Tim Goetze]

[Fons Adriaensen]

>On Tue, Mar 09, 2004 at 12:46:09AM +0100, Tim Goetze wrote:
>> 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.

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.


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

that is MOMENTARY, and such signals indeed require edge detection in
an event-unaware system as is ladspa.

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

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.


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

they are backwards compatible through the use of this bit.

>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