On Wed, 3 Mar 2004, Tom Szilagyi wrote: This plugin looks very interesting. I am considering to modify the LADSPA host module of AlsaModularSynth so that the presets would appear in a combobox selector. However it's even more complicated than I thougt: If I print out the parameter name, I get: <LADSPA parameter name> Presets AfterBurn (Short) :0 1: AfterBurn (Long) Drum Chamber :2 3: Garage Garage (Bright) :4 5: Gymnasium Gymnasium (Bright) :6 7: Gymnasium (Bright) - HD Hall (Small) :8 9: Hall (Medium) Hall (Large) :10 11: Hall (Large) - HD Plate (Small) :12 13: Plate (Medium) Plate (Large) :14 15: Plate (Large) - HD Pulse Chamber :16 17: Pulse Chamber (Reverse) Resonator (96 ms) :18 19: Resonator (152 ms) Resonator (208 ms) :20 21: Room (Small) Room (Medium) :22 23: Room (Large) Room (Large) - HD :24 25: Slap Chamber Slap Chamber - HD :26 27: Slap Chamber (Bright) Slap Chamber (Bright) - HD :28 29: Smooth Hall (Small) Smooth Hall (Medium) :30 31: Smooth Hall (Large) Smooth Hall (Large) - HD :32 33: Vocal Plate Vocal Plate - HD :34 35: Warble Chamber Warehouse :36 37: Warehouse - HD </LADSPA parameter name> If the format would be such that each preset would follow a number of the form "n:", it would be much simpler that the alternating form where for even numbers the number follows the preset name. I would like to implement an algorithm for LADSPA plugins that would look if a) The parameter name is INTEGER b) Looks if it contains ("0:" and "1:") or ("0=" and "1=") Given a) and b) it would split the name string, counting a variable "count" and searching subsequently for substrings ("%d:", count). A combobox will then replace the integer slider for those parameters. Matthias -- Dr. Matthias Nagorni SuSE Linux AG Maxfeldstr. 5 phone: +49 911 74053375 D - 90409 Nuernberg fax : +49 911 74053483

Hello, Matthias Nagorni wrote: isn't the right thing to do to use the RDF metatadata? Uwe -- voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from germany

On Thu, Mar 04, 2004 at 03:57:32 +0100, Dr. Matthias Nagorni wrote: RDF is very simple - RDF syntax and RDF Schema may be complex, but RDF is not. In any case all of this is wrapped by the lrdf library. I can understand the objection to another library though :) - Steve

On Thu, Mar 04, 2004 at 04:59:31 +0100, Alfons Adriaensen wrote: It is not a problem if you use a library. That was partly my fault, and its not good, but the latency value can depend on input port values, so I couldn't think of an alternative. I'm begining to think that it should have been a fixed value (in RDF of course ;) and plugins with varying latnecy shouldn't be corrected for). Mostly default values. RDF defaults for LADSPA predate ladspa.h default hints, which are a hack. It would be, but its hard to keep binary compatibility and wouldnt it be better to just have one extensible metadata format that you can use for ports descriptions, scales, defaults, and presets? - Steve

On Thu, 2004-03-04 at 12:28, Tim Goetze wrote: Then we'd be solving the problem of relying on a complex external library by just moving all that complexity into LADSPA. I'm not so sure that's a good idea. Using lrdf is, after all, completely optional. -Dave

Hi all, It was very interesting to read all your opinions. Here are mine. :) [Steve Harris] Shouldn't be functionality have a priority over simplicity or ease of use? As an engineer a chill comes over my back if i think about the possibility of breaking something that works now (eg. changing latency when the user adjusts some setting) in favour of being able to achieve a simpler plugin description. (And in fact, my pitch shifter actually makes use of this possibility; it would be impossible to maintain sample-precise output position without this.) [Steve Harris] Agreed. I basically believe that the ladSpa spec. is almost completely OK. However, one thing i would change is that i can't specify an arbitrary default for a control but only fixed ones eg. 0, 1, 100, 440. It would be nice to have another hint where i could specify an arbitrary default value, probably in a very similar fashion as the port_range_hints[].LowerBound and port_range_hints[].UpperBound fields work. But i do think fancy things such as these damned reverb preset names should be in a separate metafile, since not every host wants to use them and i feel this is a cleaner design than embedding everything in the core source file. [Tim Goetze] This last sentence is particularly true, and this is exactly why it would be very painful to actually do it. As a plugin author/maintainer, you don't want to update your core code every now and then when someone else discovers she needs just one more possibility to add. And you don't want to see your plugins rendered useless in a number of hosts, just because their authors didn't catch up with implementing the latest and greatest achievements of ladSpa possibilities. If a host doesn't make use of metadata, that should be OK -- gui may be crappy, but after all, the plugin should *work*. Any plugin, in any host. That's the point. Yes, particular plugins like my reverb or other fairly complex ones could use some extra possibilities, but that can be satisfied by an external and *optional* set of metadata, and i don't see why RDF won't be good for this purpose. The metadata should be (and currently, it *is*) completely optional both to provide and to use. (oh, RDF is bloated... yes, it is. May this be the biggest trouble in our lives :))) [Tim Goetze] Yes, i support that particular possibility. What i wouldn't like to see is the emerge of multiple versions with multiple possibilities, varying host support of these features etc (as i've stated my opinion above). [Matthias Nagorni] We agree it's not a simple solution. But it's a solution anyway :) To me, the idea of a solid, stable core api (LADSPA) extended by an optionally provided/used metadata layer mainly concerned with gui appearance and default issues (RDF) is very pleasing. Tom

On Fri, Mar 05, 2004 at 12:12:23 +0100, Tim Goetze wrote: Absolutly - that doesnt mean it cant be improved in some small areas - without adding complexity to the core of LADSPA. I do not think these things are critical to the functioning of all hosts or plugins, and so should be external. Units are a good case in point. You could just have a char * representation, or you could (hypothetically) have some structured repesentation say that ms was a Time unit with a long name of "milliseconds" and it has ratio of 0.001 with the SI base unit, which is the second, which has... If you code that in the spec you either need a complex data structure (and so a library to read it ideally) or you encode the knowledge in every host, whereas is you encode it in RDF, you just express the units once in the schema and all hosts can access it, plus if a plugin needs to declare new units (or even a new class of units), it can, and they will be understood by all hosts, even if they've never seen that unit before. Hosts that just want to render the units after slider can just ask "whats the label for port 3's units", whereas hosts that want to do tempo -> time mapping for eg. can ask what they are and what thier relation to seconds is. Heh, yeah, I choke on "human readable" too, but I've worked with a /lot/ of metadata languages and RDF is about the only one that isn't distilled evil :) - Steve

On Fri, Mar 05, 2004 at 02:10:30AM +0100, Tim Goetze wrote: I couldn't agree more. The functionality provided by the port descriptors is basically OK, what *is* missing are the enumerated values - you need these to have sensible labels on an n-way switch for example. And that's a very common thing on a synth module, or on audio equipment in general, and not a luxury or an option. The same mechanism could of course be used for presets. And I'll repeat my request to have a hint bit saying that port pointers can be NULL to indicate that the port is not connected. This is quite a 'general' feauture, and it will not break anything, so why the resistance and the delay ? Do you actually speak Dutch ? :-) -- FA

On Fri, Mar 05, 2004 at 02:10:30 +0100, Tim Goetze wrote: Nor would I. I also wouldn't want to push the job of understanding units onto them. I think defaults are neccesary and it was a bug that they were missing form the orginal spec, hence the hint addition. Technically speaking everything which is not a port value or an identifier is metadata. I'd prefer to decide what goes into ladspa.h on a case by case basis. I've been backing HINT_MOMENTARY and _RANDOMISABLE for about 6 months. I think those belong in ladspa.h - scale values and units do not. - Steve

Agreed. Leave LADSPA be. I'm pretty sure this is the 9000th time I've said this, but the S in ladspa is the most important letter. Some hosts simply don't care about metadata, and they shouldn't have to. I don't see a problem with the current rdf-using solution. And as far as XML... well, like it or hate it, it's 'the' format for structured text storage. Having things in XML is just more flexible than anything else. ie. if you wanted to make online user documentation for your plugins, it's a trivial task. XML to HTML? Done in minutes. Heck, someone could make an database of all currently known LADSPA plugins, with port information, descriptions, etc. etc. and it really wouldn't be that hard at all. ... I'm sure there's a point buried somewhere in here. :) -Dave

On Fri, Mar 05, 2004 at 02:02:10 +0100, Fons Adriaensen wrote: Because they weren't thought of at design time. There is allready enumerated value support in RDF. Very simple hosts do not need it. Thats what Taybin was working on last night. IMNSHO that was not the best way to implement preset selection - just storing the presets as RDF on disk and letting the hosts (that can / want to) pick them up is a better idea. You cant describe enumerations as a critical core feature, because we've got along without them for 4 years. I'd agree that its not optimal, but I also dont think they should bloat the port structure and break binary compatiblity, or the plugin structure and mess up a perfectly good binary format. - Steve

On Fri, Mar 05, 2004 at 12:21:42 +0100, Dr. Matthias Nagorni wrote: That is not complete, you also need strings, push-to-make (momentary) controls and probably opaque blobs. The problem for enumerations is where to put the list of strings and values. Unfortunatly a simple hint will not do it. I agree that combo boxes are very useful, and LADSPA should have access to them, but AMS is /not/ a simple host, why should it not use RDF? Just the ability to do plugin categorisation is a huge bonus, bordering on essential if you have a lot of plugins installed. There are hosts that wouldn't use enumerations, eg. Pd, applyplugin and ecasound. A tiny hint and changing one of the structs - thats quite a big deal. On the other hand, RDF has had LADSPA enumerations for something like 12 months. They work, thier easy to support and they dont break compatibility with anything. I honestly dont understand the problem. Your saying that you dont like fact that the TAP reverb has a big port label and no machine readable enumeration (and that's fair enough), and I'm saying "go to http://plugin.org.uk/lrdf/ and get a library that will give you enumerations for it", what is the problem, really? You allredy have the metadata installed, and probably the library too, just no way to read it from AMS. - Steve

On Fri, Mar 05, 2004 at 03:57:39 +0100, Dr. Matthias Nagorni wrote: HINT_MOMENTARY, yes, I've been asking for it for months. They cannot be aproximated by toggles (think of tap tempo or sync reset controls), and are at least as important as enumerations, which can in most cases can be aproximated by notes in the port label. I still dont think that listing some hardcoded presets in an integer control port is a good way to have presets. It screws up automation for one thing. Which allready uses lrdf (at least the devel version does). And anyway - enumerations are not a good way to solve that problem. Could, but its far from neccesary. Its not that LADSPA is missing combo slections, its just that thier not labelled - users have to look in the docs. Momentary switches are just not there at all. All of the features missing from LADSPA seem neccesary to someone - but if we add them all in the nwe will have a crappy and still incomplete plugin format, just like VST or DirectX. - Steve

On Fri, Mar 05, 2004 at 04:48:35PM +0100, Alfons Adriaensen wrote: The disaterous case for the current (annotation in the label) pure ladspa.h hack is the TAP Reverb preset, as it has so many annotated values. I think it would be much better if the plugin came with preset files(s) describing the presets so that host could present them as choices, doesnt need a wierdly semanticly overridden port, and automation can still work. I think that only big, complex UI driven hosts need scales and enumerations, and they can just use RDF. Any app that links against GTK or Qt is not even going to notice liblrdf. A nice and incomplete plugin standard. I believe that it will always be incomplete but it doesnt have to be messy or complex. People complain DirectX is missing features, and its /huge/. The key feature that made me start coding for LADSPA was how easy it was to create plugins - I dont want that to be taken away and potentailly discourage new developers. - Steve

[Richard Spindler] there is one: it seems consensus that making RDF mandatory for hosts should be avoided. amicalement, tim

On Fri, 5 Mar 2004, Steve Harris wrote: Just as my personal conclusion of that thread: We do not lose anything if we accept either the proposal by Tim or Fons or something in between. Both proposals are binary compatible with the current standard. Plugin-writers and host-developers would still have the choice to use the extension or to ignore it and use e.g. the RDF extension instead. And I doubt that new plugin writer get scared by some slightly extended ladspa.h, at least as long as it keeps to be as well-documented as it is now. I will now shut up and hope that an extension will be agreed upon. Once Tom (and hopefully others) follow the new standard, I will update AMS. And keep in mind: Extending LADSPA does not mean that all plugins need to be modified. It's only that cases like e.g. the reverb presets can be fixed in a clean way. Matthias -- Dr. Matthias Nagorni SuSE Linux AG Maxfeldstr. 5 phone: +49 911 74053375 D - 90409 Nuernberg fax : +49 911 74053483

[Steve Harris] like others, i'm not quite sure discussing this any further is going to be particularly fruitful, but here goes anyway. 1) we got on for four years because in essence, we could never seem to agree on how to extend ladspa. 2) we disagree on the meaning of 'meta'. that's nothing to worry about seeing that this has happened and is happening to great philosophers past and present, too. - i would like to carry your definition to the extreme in a fiendish and unfair manner, as is my custom (and please let me prefix this with an expression of my utter regret of being so rude, and with an assertion of my deepest respect for all your fine efforts in the field so far): what do we have in ladspa that is *not* 'meta'? * we have a plugin. * the plugin has n ports. * it also offers certain methods to carry out operations for us. following your line of thought, we arrive at the interesting conclusion that *everything transcending these concepts* is 'meta'. some consequences: * presets are 'meta'. * value ranges are as much 'meta' as are value labels. * default values are as much 'meta' as are any hints. * any textual information about the plugin is 'meta': - port names are 'meta' since the port is already identified by its numerical index. - Maker, Label, Name, Copyright surely are 'meta'. - Properties are 'meta'. without doing too big a leap of thought, one may even conclude that UniqueID is 'meta': it can be stripped from the descriptor because 'file.so' and the index passed to ladspa_descriptor() already contain enough information to uniquely identify the plugin. - i would like to contrast this with a different definition of 'meta': all information vitally needed for machine *and* man to treat and use the plugin as intended, without querying other sources than the plugin itself, is *not* 'meta'. it is 'direct' or 'inherent' knowledge. some consequences: * everything labeled 'meta' in the above thought experiment becomes 'not meta', except for the presets. * knowing that 0.5 = half a second is 'not meta'. * knowing that 0 = sin, 1 = tri, 2 = saw is vital, thus 'not meta'. * knowing that the plugin causes 64 frames delay is 'not meta'. - my apologies offered for this long-winded and impudent argumentation. yet to top it off, i would like to question your point of 'keeping this out of ladspa is making coding simpler'. what do you think is simpler to do for somebody new to all this: * learning the API, or * learning the API *and* RDF? amicalement, tim

[Steve Harris] your definition of meta data seems much to the point. however it also seems we still are in disagreement, this time over the limits of the 'data' that is described by the 'meta'. but pursuing this distinction any further is, as you point out so rightly, probably beyond the scope of this thread. i'm not sure a studio professional will agree with your estimation of the vitality of these information bits, in part or in toto. ok, the 'simple' argument. three things against that: * ladspa isn't that simple anymore, take a step back and look at the default value mechanism in place now if in doubt. i would think it's not sensible to protect the virginity of a princess already raped. compared to that, the patch is downright fool-proof. add to this that in the long run, the patch will even rub out this sore spot. * the 'simple' in ladspa also means: all you need, in a compact frame. a frame that RDF bursts, and one that the patch keeps intact. (and we do agree we need more than ladspa 1.1 offers.) * from the very beginning, ladspa has included meta data (by your strict definition of meta and data), and for good reasons. departing from that now may look good from an academical point of view, but in fact it's a rougher breakage than keeping with the spirit. as is the use of 2.0's extensions: optional, you can write your plugin or host entirely disregarding them. i've just now compiled swh-plugins-0.4.3 against 2.0, without any compilation issues or problems using the compiled plugins. no need to change a single line of code. afaics, RDF and the extensions mix well. if you would like to see that, we can amend the patch stating that data about the plugin that is queried from RDF sources overrides the corresponding ladspa members. i even think this is very sensible, it's a very convenient way to customize after all. i'd also like to point out (as the test program posted with the first patch shows) that querying the additional information from the plugin isn't even nearly as hard as deriving default values is right now. add to this that the use of the value->label enum is optional, and that 2.0 makes it possible to specify default values directly: one must conclude that writing plugins with 2.0 is even easier than it is with ladspa 1.1. we'll all work with it a lot if everyone agrees on it for storing metadata, and i do. :) i'm even looking forward to it fwiw. sure, it's good fun to discuss this. but i agree we should keep it out of this discussion for the time being. vriendelijk, tim

prologue: this mail is not intended to be a smooth read. if you have any kids around, tell them to play somewhere else please. i am an impatient, flawed kind of character quick to give in to a sudden temper. [Steve Harris] to me, this sounds like: we're engineers, sc*ew the rest. it also has a faint taste of that famous '640k will always do' quote. to repeat: nobody is disputing the usefulness of RDF for what you intend it to do for us, on the contrary. and i may remind you that the particular convenience it offers is mostly for people who can't be bothered with the technical details. the 'ugly' argument is simply misplaced. 1) this is a pure engineering effort, designed to interface software with software. 'beautiful' or 'ugly' is not what this is about, as it relies on a highly subjective mode of judgement. 'functional or not' is a much better choice of distinction, and i'm more than willing to discuss the merits of the patch in this regard. 2) expanding an API to do things it didn't do before while being compatible is always 'ugly', to use your choice of terminology. as witness i call the default hints in ladspa, and proceed to 3) removing the default value hack, and be it with a vector of values, will make ladspa less 'ugly'. 4) even ladspa 1.0 was 'ugly'. there are much 'nicer' designs of APIs around, if you ask me. 5) has it occurred to you that many people object to RDF as being 'ugly'? which is why we have to bite the bullet. agreed. i'm sorry for having to meet your stubbornness with repetition myself: THE EXTENDED FEATURES IN THE PATCH ARE OPTIONAL AS MUCH AS IS RDF, SO PLEASE REFRAIN FROM REPEATING THIS POINTLESS ARGUMENT IN THE FUTURE. it has been shown in code that access to the extended features from the host side is just as simple as is liblrdf (and one may want to argue: even simpler because of a removed level of indirection). further down your post, you admit to this yourself. what does really break the spirit: excluding what you call metadata or including it, recalling that your interpretation of metadata doesn't even fit the data included in ladspa 1.0? the port/default vector schizophrenia is something we'll have to live with anyway. in this context, i would like to point out that port names are a separate vector as well, and have been ever since ladspa 1.0, so it must be concluded we don't even introduce a new concept. that you have made more than clear by now. :) amicalement, tim

On Fri, Mar 05, 2004 at 01:11:29PM +0100, Alfons Adriaensen wrote: I dont think thats very clean myself, and how do you represent the numbers that go with the labels? eg. gate(1410) has -1.0 -> "key listen", 0.0 -> "gate", 1.0 -> "bypass" and you might reasonably want non integer values for enumerations. - Steve

On Fri, Mar 05, 2004 at 02:40:08 +0100, Alfons Adriaensen wrote: OK, thats a reasonable definition for enumerations, but its missing the non-ionteger eqivalent, "scale points" or whatever you want to callthem, eg in ringmod_2i1o(1188) "Modulation depth (0=none, 1=AM, 2=RM)" input, control, 0 to 2, default 0. its not an integer control, its a continuous valued control with specific meanings at specific points. Another example is an oscilator control knob in LFO modules with contiunous varition through sine, tri, saw, square. I'l grant you that this case is less common, but its still one of the "neccesary" control types. Right, in the integer hint case I dont see why you would. I dont think what you're prosoing is an unacceptably bad hack (though I dont think its a good one either), but I do think the RDF solution is much cleaner. - Steve

On Fri, Mar 05, 2004 at 04:11:35 +0100, Dr. Matthias Nagorni wrote: They are the same problem - annotating certain values with labels. If you solve one and not the other something is very wrong. I see Tim has just posted a solution to both but I havent looked at it yet. Less common, thats different. The same as enumerations then? It doesnt need to, its metadata. All it requires is that the hosts that want those features parse the RDF - thats not all the hosts (though the majority allready do) and it doesnt require any changes to ladspa.h. - Steve

On Fri, Mar 05, 2004 at 04:11:35PM +0100, Matthias Nagorni wrote: Provided the scale points for a continuous control correspond to the integer values, then we could use HINT_ENUMERATED without HINT_INTEGER. There would be a string for each integer value in the port range. Some could be NULL if required. -- Fons

On Fri, Mar 05, 2004 at 05:19:58PM +0100, Tim Goetze wrote: Please show me a case where these scale points have to be non-integer. -- fons

[[me]] [Fons Adriaensen] Hey wait... regarding what you write about my "plugin breaking every host except Ardour": 1. It does *not* break all hosts: it works fine in (at least) JACK-Rack, GLAME (although i haven't pushed that very hard), and applyplugin (joking, don't count this). It was reported that it does break ecasound, but not after commenting out the #define at the top of tap_reverb.h (just check the docs). So i wouldn't say "my plugins break all hosts except Ardour". (Oh, and i didn't mention AMS -- Matthias Nagorni wrote a hack (thanks!) that makes the reverb look nicer, not that fixes its breakage.) 2. And as a last note about the port name string: you don't have to use it, see #define mentioned above. The newline characters are not forbidden in ladspa.h AFAIK. And i made it look good in Ardour because i *use* Ardour and not anything else for my audio engineering, and i wrote this plugin because i needed to have it. Ardour should use RDF, and i'm sure it *will* use it -- when it is time. But i needed to have a usable reverb before that. Anyway, the progress towards a new solution is very promising (yes, i really mean this list has a bunch of very cool minds on it), and i will be happy to adapt all my plugins as soon as a new standard is established. Tom

On Thu, Mar 04, 2004 at 01:42:06 -0500, Dave Robillard wrote: Yes, exactly. In reality you'd need a library to handle more complex LADSPA structures anyway - especially if you wanted cross-version compatibility. - Steve

On Thu, Mar 04, 2004 at 07:34:48 +0100, Fons Adriaensen wrote: Hmmm... bloat is relative - the description of all the TAP, CMT and SWH (> 100) plugins on my system + the schema takes up 200k on disk - which is only 12k if you gzip it (you can keep it gzipped on disk if you like), in lrdf's in-memory form thats something like 20k of ram. c.f. the difference between writing your software in C over C++ ;) I dont follow this point. OSC is not simpler than XML. Really. Also, it doesnt have the features you'd want for metadata representation, so you end up re-inventing much of RDF, but with a syntax and semnatics that no-one else could understand. In any case XML is not the only RDF syntax, the one lrdf uses for export (eg. if you save a preset out) is Ntriples, which is basicly: <a:foo> <a:bar> "some value" . ... Doesnt get much easier than that. - Steve

On Thu, Mar 04, 2004 at 01:38:32 -0500, Dave Robillard wrote: Its not obvious, but plugin libraries can invent thier own classes, eg. you could add a "TAP Plugins" class to the top level or below a "By Provider" or something. Plugin authors should agree some convention before doing it though - otherwise there might be a mess of classes :) - Steve

On Thu, 4 Mar 2004, Dave Robillard wrote: I agree. And this feature is something I could agree to use RDF for. It's nice but optional. OTOH an enumeration HINT to build combobox selectors is not optional. This information should be provided by the LADSPA plugin itself. It will not be on top of my (currently quite long) TODO list, but I'll think about it. A tabbed dialog would be best. Matthias -- Dr. Matthias Nagorni SuSE Linux AG Maxfeldstr. 5 phone: +49 911 74053375 D - 90409 Nuernberg fax : +49 911 74053483