The presence of both MOMENTARY and TRIGGER seems redundent. TRIGGER means that it's reset to 0 after one call to run() or run_adding()? That'll happen so fast, the user won't even notice the UI change. If TRIGGER is for scale values, how will it scale if it's set to 0 after every call? The distinction between them is overlapping and confusing. Taybin -----Original Message----- From: Tim Goetze <tim(a)quitte.de> Sent: Mar 7, 2004 7:39 PM To: linux-audio-dev(a)music.columbia.edu Subject: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff) attached you'll please find three files: * a patch moving ladspa.h 1.1 to 2.0 * a program showing how a host evaluates 2.0 extensions * a thoroughly documented example plugin making use of the extensions changes to the patch with respect to the last version include consolidation of the extended port info into a dedicated structure. also included is a warning note concerning the deprecation of the 1.1 default value hints and some minor clarifications. the patch defines HINT_MOMENTARY as asked by Taybin and Steve. it also credits Taybin now (Steve already being credited). - the example plugin is written with the intention to show, in all its sometimes gory detail, how ladspa works 'from the plugin side'. the plugin is fully operational in hosts implementing either version of the standard. (it doesn't even sound so bad at all :) there are a number of more elegant ways to accomplish what the plugin source does, but these have all been ignored for the sake of showing exactly how things are coming together in ladspa. - if you expect the extension to make a plugin author's life harder by a significant amount, i would like to ask you to go over the source code of the example plugin and see for yourself. all the places where the plugin refers to the 2.0 incarnation have been marked as such. i'm confident you'll agree that words like 'invasive', 'incomprehensible', 'bloated' or 'complicating' are not doing the extension justice. i would also like you to consider that it is up to you, either plugin or host author, to altogether ignore the extension and still come up with something perfectly useful. you can always extend your work to make use of the extension at a later date. all this takes is added code, with no changes to what you already have. - my apologies offered for the obnoxious use of the '2.0' version tag for this proposal. for sheer lack of fantasy, typing laziness and a number of other bad habits, i couldn't come up with something better. amicalement, tim ps: it is hoped that the example plugin source will be helpful to aspiring plugin authors, no matter the fate of the extension proposal.