On Mon, Mar 08, 2004 at 10:06:25PM +0100, Tim Goetze wrote: > [Fons Adriaensen]
> >Can you point me to some document that contains that requirement ? > > 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. 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. > not to mention you cannot connect an audio output to control input > without at least some conversion. That distinction is already made very clear in LADSPA. > >Why would you ever need both ? Unless the two events are one sample apart > >(unlikely if they come from a GUI), you can always use the first. > >And if something like "TRIGGER" is used, it should at least send different > >events for press and release. And in that case "MOMENTARY" is a subset and > >consequently not required. > > 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. The required logic is trivial. And it allows you to use any signal as a trigger. > 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? 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. > 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. 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. > >I'm more and more alarmed by the way this debate is going. I see lots of > >ideas but no clearly defined concepts nor any attention to completeness and > >consistency. I see implementation (diffs on ladspa.h) before specification. > > 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'. 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. > >If such as thing as a new LADSPA version (with feautures that can *not* be > >ignored by a host without impairing functionality of either the host or the > >plugin) is introduced, then we should at least sit down, think, and come > >out with something that is structured and consistent. I'm not saying such > >a move is necessary. > > i agree about the sitting down part. however, i *am* saying movement > is necessary. :) Things *are* moving. And to make them settle in the right place, they should not be pushed too hard :-) > >Note that the two changes I proposed > > > >- HINT_ENUMERATED, always together with HINT_INTEGER, and appending > > the labels to an existing array, > > > >- HINT_CAN_BE_NULL, to signal that a port pointer can be NULL > > when unconnected, > > > >can be safely ignored by any host. In the fist case, the GUI will show > >ints instead of labels. In the second, the plugin may waste some CPU > >cycles. > 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 do believe this. But then the HAS_VERSION thing is not necessary. > 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. I beg to disagree here. > while we're at it, i'd also like to know why limiting the value->label > mapping to integers is beneficial. It's two different problems that happen to map to similar data structures. See my reply to Steve's post. -- Fons
