On Mon, Mar 08, 2004 at 05:20:42PM +0100, Matthias Nagorni wrote: Why should a host care about knowing this ? It could only important if the trigger is connected to a GUI element that would be set into some state by the trigger and remain there until reset by the user. Unless we start 'typing' all ports, and expect to host to police all connections, TRIGGER / MOMENTARY is required only for display purposes. The two ends of a trigger connection are not symmetrical. I fail to see what this means. Either something sends out both rising and falling edges, OR it can send at most one edge during its entire lifetime. -- FA

[Alfons Adriaensen] we're already requiring hosts to police connections for value conversions. seeing that connecting a TRIGGER or MOMENTARY port to a 'continuous' data source or destination implies unintended effects ranging to perceived malfunction, i think it is only sensible to 'type' the distinction. aren't they? can you expand on this, please? i'll try to explain in terms of UI controls: MOMENTARY: a push button, sending 'yes' when pressed and 'no' when released. TRIGGER: a push button, sending 'yes' only at press *or* release, and 'no' at any other point in time. amicalement, tim

On Mon, 2004-03-08 at 14:23, Fons Adriaensen wrote: Agreed, FWIW. -Dave

[Fons Adriaensen] 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. not to mention you cannot connect an audio output to control input without at least some conversion. 'while'. sorry for being vague. 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. 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? ok, suppose we say only MOMENTARY, and one-shot triggering is always rising edge. now we have another problem: Taybin is pretty adamant in requiring MOMENTARY to imply TOGGLED. this means we'll always need another port to transmit the velocity value for note-on and similar events. fine, no problem? apart from this meaning a waste of resources, how do we transmit two such impulses in successive run() calls? simply split the run() call in two? at what a waste of resources do we arrive then, for the doubtful pleasure of having a 'simple' model. beats the intention of simplicity if you ask me. 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'. the discussion revolves around a lot of concepts because a lot of things in ladspa need clarification or improving. so far, i find this discussion a lot more fruitful than any we've had before. i agree about the sitting down part. however, i *am* saying movement is necessary. :) so far, everything proposed by us both can be safely ignored by 1.1 hosts. 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 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. while we're at it, i'd also like to know why limiting the value->label mapping to integers is beneficial. - my apologies for a far too long post. i agree that verbosity is not always a virtue. vriendelijk, tim

[Jesse Chappell] the patch states that the 'low' value is always zero, and that zero needs not be inside the value range. fwiw, i prefer ladspa units if at all possible for less overhead and greater control. i'm sure others prefer a jack client with a snappy UI. :) 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. That distinction is already made very clear in LADSPA. The required logic is trivial. And it allows you to use any signal as a trigger. 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. You could combine trigger and velocity in the simple MIDI case. But that is *not* the general case. I can easily imagine a plugin that would sample and latch not only velocity but also some other parameters when triggered. On a keyboard, you have velocity together with the trigger, and maybe key pressure afterwards. But there are other controllers, even within the limited world of Midi. 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. Things *are* moving. And to make them settle in the right place, they should not be pushed too hard :-) I do believe this. But then the HAS_VERSION thing is not necessary. I beg to disagree here. It's two different problems that happen to map to similar data structures. See my reply to Steve's post. -- Fons

[Fons Adriaensen] ok, then you've probably already connected LFOs to TOGGLED and INTEGER ports. i haven't heard you complain about their 'typedness' yet. 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

[Fons Adriaensen] 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. that is MOMENTARY, and such signals indeed require edge detection in an event-unaware system as is ladspa. 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. 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. 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. thanks, even if it should have been for nothing, i won't regret. they are backwards compatible through the use of this bit. 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. 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 :)" that surely belongs into RDF, doesn't it? vriendelijk, tim

On Tue, Mar 09, 2004 at 04:29:55AM +0100, Tim Goetze wrote: LADSPA does already clearly indicate if a port is CONTROL or AUDIO. Another aspect of this is that the period size set by the audio interface or JACK need not necessarily correspond to a soft synth's internal control rate. CSound is one example of this. The new AMS I'm currently thinking about will be another. In this case the designer has the choice of either - calling plugins at the real control rate, and allow the use of LADSPA control ports to carry LF signals (LF0, ENV, ...) - or call the plugins at a much lower rate, map LADPSA control ports to widgets only, and not allow them to be routed. The LADSPA spec does not clearly define which of the two is intended. OK, not having TRIGGER halfs the control bandwidth. But if your event frequency is approaching the control rate or even half of it, you will run into trouble anyway, as the events will be quantised in time in a way you'd probably not expect. It just means the k-rate is too low for the application at hand. -- FA

[Alfons Adriaensen] for good reasons, i think. vriendelijk, tim

On Tue, Mar 09, 2004 at 03:10:54 +0100, Fons Adriaensen wrote: I can see that scale points might be more complex, but they are just as vital. A reasonable implementation might be for a <whatever enumerated ui> + a slider, picking from the enumerated control jumps the slider, moving the slider could clear the enumeration control or set it to the nearest value. Hmm... yes, these are related issues (both are annotations of specific control values), but they can be seperated. - Steve

[Steve Harris] true. however, the behaviour connecting a TOGGLED or INTEGER port to a continuous signal source is undefined and relies on the host and/or plugin rounding convention, and whether one is in place. amicalement, tim

[Steve Harris] true. though it must be reckoned that some hosts may opt to force value adjustment, or do any kind of value arithmetic for that matter, at the port level. under some circumstances it is a sensible thing to do, and the spec is a recommendation, not a requirement in this case. amicalement, tim