On Thu, Apr 27, 2006 at 05:13:24 -0400, Dave Robillard wrote: Yeah, but given that it doesn't work, I think its reasonable to remove it. We replace it with something that does work the moment after "LADSPA2" is finalised. - Steve

On Thu, 2006-04-27 at 13:14 +0200, Luis Garrido wrote: I disagree - XML is a nightmare to read (and has plenty of weird characters too). TTL looks much nicer. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

On Fri, 2006-04-28 at 09:02 +0100, Steve Harris wrote: But RDF can be written in XML, so it must have the features, mustn't it? I just find it very hard to believe that audio plugins are that special. Everyone else seems to manage fine with XML. Damon

On Fri, 2006-04-28 at 11:12 +0100, Damon Chaplin wrote: Google around the 'net for some examples of the same data in RDF/XML versus Turtle. You'll change your mind real quick. ;) -DR-

On Apr 27, 2006, at 3:12 AM, Steve Harris wrote: Okay, Steve, I trust you have something ready to go that you feel will replace it, but I'm still worried. The discussion you and Paul had on this list sounded to me like you were both conflating the need for scaling a linear range (widget or MIDI CC) to an exponential one (e.g. frequency port), with the need to provide unit labels for port values (e.g. "dBFS"). The two are independent, and I agree with Dave that the log scaling hint is essential. It does work when bounds are sensibly specified (i.e. don't include zero), and needs to be extended -- not dropped -- to handle the other common cases people try to (ab)use it for. If we're going to replace it "the moment after 'LADSPA2' is finalised", then we'd better be sure the replacement is ready to go. Can you tell us more, please? -Sean

On Apr 28, 2006, at 1:30 AM, Steve Harris wrote: <snip> Yikes, now I'm sure this is headed the wrong direction! Say you specify that a port is representing frequency -- is it a pitch multiplier, where the 'knob' should be scaled by pitch (i.e. log(frequency)), or does it refer to an FFT bin, so that it should be scaled linearly? How about a delay time whose unit is 'seconds'? Log or linear scaling? Or a distortion drive control whose unit is technically 'radians'? How's a host supposed to figure out how to scale that? What should it do with a 'magnification' port that is unitless? It's not possible for a host to know how to scale a port from just the unit labeling. Unit labeling and input value scaling are independent, in fact are completely orthogonal except in certain conventional cases like IEC for some (not all!) dB ranges. I'm okay waiting until the base LADSPA2 spec is done to figure this part out, to keep the confusion down, so long as we all realize that until we do, LADSPA2 hosts will be even more clumsy in this regard than LADSPA 1 hosts currently are. And Steve -- setting my knit-picking here aside ;-) -- thank you very much for all your work on this! -Sean

++. there definitely needs to be a 'logarithmic' hint. maybe even log(10) vs log(2). im sure this RDF/JSON/YAML thing can make a case for it

possibly not. but, i'm not a mathematician :) i just know that toggling sliders between log and linear in PD, Bidule, Audiomulch etc can be useful, and some kind of hint from the plug which should be the default could be useful.. when its 0-1, yes. what about 20-22050? i guess i wasnt clear on why you are convinced log hint is a bad idea. but given the above goblygook i gues i will never understand :)

On Sat, 2006-04-29 at 10:50 +0100, Steve Harris wrote: It's information with which you can do something a LOT more useful than without... -DR-

On Tue, 2006-05-02 at 17:57 +0200, Alfons Adriaensen wrote: saying that the port range is exponential doesn't pin it down very much. it still requires the host to make decisions about precisely what kind of exponential curve to use for the range, and it may get it wrong. i suggested dropping it because it doesn't appear to me to provide adequate information to use it correctly. i fully support having a way to indicate that a port range is exponential if it includes *all* the required information. care to suggest a simpler approach?

On Tue, May 02, 2006 at 05:21:44PM +0100, Steve Harris wrote: That's a contradiction. -- FA Follie! Follie! Delirio vano e' questo!

On Tue, 2006-05-02 at 17:21 +0100, Steve Harris wrote: The problem here is that most people who want the log hint just want it as, well.. a logarithmic hint. Not a precise definition of a mathmatical mapping from parameter value to port value (which would also be nice, but is a seperate thing really). As an example, I map MIDI controllers to negative parameter ranges ALL the time, and using an exponential curve more often than not. Obviously in a strict mathmatical sense this doesn't work out at all (can't have a negative log), but it's a useful (necessary for me) feature. (as mentioned I calculate the curve on [1, n] and shift it down to wherever I need it). I would like ladspa:logarithmic to remain as the fuzzy not-very-well-defined hint that it is right now, because it solves the UI/MIDI/etc problems. You can't even provide a usable frequency slider to a user without it! A future extension that precisely defines ranges, units, scales, etc. wouldn't conflict with this simple hint. That said, I'm not going to lose any sleep over it not being in there. The end effect will just be that the extension which fixes it will become a de facto standard. Battles over what metadata to include in the spec is best left until after we have the C side of things absolutely pinned down to everyone's satisfaction, IMO. -DR- -DR-

On Tue, 2006-05-02 at 19:19 +0200, fons adriaensen wrote: note: the hint didn't say "exponential". it said "logarithmic".

On Tue, May 02, 2006 at 09:07:47 +0200, fons adriaensen wrote: Yes, I've always though HINT_EXPONENTIAL would be clearer, but whatever. - Steve

On Thu, 2006-04-27 at 05:13 -0400, Dave Robillard wrote: its however really causing headaches on the host side. the default host lib should provide some means to convert linear/logarithmic properly. -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org

I haven't posted to this thread yet, for a couple of reasons besides the usual lack of time. One reason is that on a technical level I don't have any argument with most of what Steve says. Removing descriptive data from the plugin I think is a good principle. I'm not fond of this Turtle format, it is complicated and I don't find it easily "visually parseable" but it's still better than XML RDF, and so long as you can easily hack someone else's .ttl file to make your own, it probably isn't much of an issue. Technically it all looks pretty much OK. But the other reason is that I don't find much to make me care about the outcome at this stage. This may be a technically better way to design a LADSPA-like plugin API, but until it offers something significantly more useful than LADSPA, that's rather irrelevant to anyone outside this thread. A LADSPA 2 that is the same as LADSPA 1, "technically superior" but incompatible will probably fail. Authors of existing hosts won't want the trouble; plugin authors will put up with the potential extra work of doing LADSPA 1 to get better host coverage. So the aim is to do more interesting things with it afterwards. But what? We want to avoid ending up with LADSPA, DSSI, and "LADSPA2", with the latter two being incompatible overlapping extensions of the first. That would be very impractical for authors of plugins that might want features from both of the extended APIs. I think we want to avoid having LADSPA, DSSI, "LADSPA2" and "DSSI2" as well; the menu is complicated enough already, for anyone reading it for the first time. This format is really going to have to aim to grow into something that can replace DSSI as well. And while that could be great, it's a much more snaggly business -- DSSI has turned out pretty complicated, for some very sound reasons, and that has already helped it to be less popular than we'd hoped. If it was obvious that we could simplify it a lot the "LADSPA2" way, that would be great, but I don't see at first glance that it is. So, I wouldn't mind hearing some thoughts on what this rewrite might ultimately be for. Chris

On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: OSC message. That's a tougher one. OSC message. Silly useless function. Toss it on the trash heap with run_adding. -DR-

On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote: Not really - plugins only get to write to the control ports in the run() callback (or select_program() for DSSIs), and it's entirely possible and plausible that a program would want to list the available programs for a plugin before it starts running it's audio callback. Would it be possible to change the instantiation function from LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, unsigned long SampleRate, const char* BundlePath, const char** HostFeatures); to something like this: LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, unsigned long SampleRate, const char* BundlePath, const char** HostFeatures, void** HostFeatureData); where HostFeatureData is a NULL-terminated array of the same size as HostFeatures, containing feature-specific data that the plugin can read and/or write. Then, if HostFeatures[3] is "PROGRAM_LIST_CALLBACK", HostFeatureData[3] can point to a 'const DSSI_Program_Descriptor *(*)(LADSPA_Handle, unsigned long)', i.e. a DSSI program list callback pointer, and the plugin can set it to point to its program list callback. Or you could define a "DSSI" host feature and a struct similar to the current DSSI_Descriptor with configure(), get_programs(), get_midi_controller_for_port() etc and pass a pointer to that instead. I don't see any other obvious way to let future extensions add their own callbacks (except for specifying a function name in the RDF file and then dlsym()ing that symbol name in the host). -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

On Mon, 2006-05-01 at 02:13 +0200, Lars Luthman wrote: Eeeww. I like the hostfeatures idea, but don't do parallel arrays, make a struct: struct HostFeature { char* name; void* data; } Though I don't think this is the right way of going about this. We should leave HostFeatures as is and add instantiation parameters (as a few people have requested) with the above form. You could define a HostFeatures that guarantees a certain parameter will be there to get what you want. Something like: struct LADSPA_Parameter { char* name; char* data; } LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor, unsigned long sample_rate, const char* bundle_path, const char** host_features, const LADSPA_Parameter** parameters) Basically the same as Lars' proposal above, slightly remixed to make it more general and useful. This is needed, among other things, for eg. variable number of ports support (through a special port type), which is an extension I would REALLY like to be possible (one plugin, stereo/mono support). Things like FFT bin size, MIDI buffer size, etc. could also be parameters. There's heaps of possible uses.. Semantics: the parameters should be completely optional, and the plugin MUST NOT fail to instantiate based on the lack of a necessary parameter (unless that is specified as a HostFeatures). It could also be used to passs function pointers to the plugin as Lars suggested, which would be very nice, but given what happens if something gets messed up (SEGFAULT), I don't know if this is the best mechanism to provide that. (This isn't really a 'new feature' so much as HostFeatures done right IMO) Thoughts? -DR-

On Mon, 2006-05-01 at 21:24 +0100, Steve Harris wrote: mono/stereo isn't the best example. I'm thinking of things like an n->1 mixer plugin. Both true. I was reaching for examples other than the above one. :) Admittedly the variable ports thing is the only use case I can really think of at the moment. I think you're right though, instantiation parameters probably aren't the best way to achieve that, the number of ports could be provided as a field of the struct the same as MIDI buffer sizes. That's probably better and more consistent; though has the same problems with plugin providing the output and being able to allocate the ports (or dictate how many the host allocates) that MIDI output has. I guess the port things aren't a good justification for the creation parameters, you're right. The question, then, is what is the recommended way for the host to provide functions to the plugin? That's what Lars was originally seeking (and solves the above allocation problem as well) -DR-

On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote: Do you mean that the plugin should dlopen the host? Wouldn't that require some way to pass the path to the host program to the plugin (in which case you might as well pass a function pointer directly)? -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

On Mon, 2006-05-01 at 22:27 +0100, Steve Harris wrote: Can't that cause all sorts of memory protection errors on systems that do not support backlinking? On the other hand, if it works on Linux that is good enough for me. -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote: From what I glean from this you are talking about having the plugin .so access symbols that are defined in the host. I know this is possible, and you don't even have to link against any stub library. Check out the -E or --export-dynamic option to gnu ld. I don't know if this is a good idea, though. It feels kinda freaky.

On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote: this is not TRUE on windows. otherwise yes. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: one portable way is to pass a struct of function pointers filled by the host to the plugin initialization function, as done in the SuperCollider server plugin API. <sk>

On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote: It does if the struct looks like this: struct ExtensionFunctions { struct { const char* extension_uri; void* function_pointer; }* null_terminated_function_array; }; -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

On Wed, 2006-05-10 at 15:15 +0200, Lars Luthman wrote: I don't like the function pointer specific nature of it. Simpler: struct HostFeature { const char* feature_uri; void* data; }; This allows the host to pass anything to the plugin, function pointer, struct of some useful data, pointer to some shared resource, etc. etc. -DR-

On Saturday 29 Apr 2006 17:42, Dave Robillard wrote: And there you've introduced something I haven't seen in this thread yet: sending messages rather than just values to your plugin. How come there are dozens of posts here talking about the name of the API and bitching over whether this "extensible" plugin API should start out with a logarithmic port hint, when things like this are going unmentioned? Is the expectation that any plugin be able to define that a certain port accepts any given structure of data, defined entirely in the RDF? Or what? You see that's all terribly glib, but the things that make the non-GUI parts of DSSI complex are not so much about how data is passed to and from the plugin as when it is passed, what the dependencies between things are (e.g. when you change a configure value, the programs may change; when you change a program, the ports may change), what the threading requirements are and so on. An entirely generic anything-in anything-out plugin is unlikely to be much actual use, in practice. Hexter, Xsynth, WhySynth etc. run_multiple is DSSI's equivalent of MIDI channels. There is no channel information in the note messages passed to a plugin; instead the host creates as many instances as it needs, effectively one instance per channel, and run_multiple allows the plugin to share work between them if appropriate. If it has no work to share, it just doesn't bother providing this function. This can have advantages for the plugin (the simple case is simpler) and user (any plugin appears able to receive any number of channels of input, without the user's having to know what the plugin's actual configuration is). The main disadvantage is simply that it's different from how other MIDI-based APIs work. In my view it's better in isolation -- in a homogenous environment -- but can become awkward when mixed with actual MIDI devices. Chris

On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote: Dave, you complain about people talking down about modular synths, then yourself discount things that are only useful in non-modular designs? How about a little reciprocity here? run_multiple_synths() _is_ useless to any host (like Om), that wants to process an arbitrary connection graph one node at a time. run_multiple_synths() is very useful when a host can run multiple instances of a plugin at once. It provides easy, lock-free sharing of resources across the instances. It allows FluidSynth-DSSI and hexter to both provide a shared pool of voices used across several instances, with _sample-accurate_ voice stealing. It allows FluidSynth-DSSI to easily bolt onto libfluidsynth, and share soundfont data between multiple instances, without the need for a custom soundfont loader. In contrast, I purposely wrote WhySynth without using run_multiple_synths(), just to see how difficult the resource sharing would be. Nasty mess of mutexes and try_locks().... All of this is not to say that run_multiple_synths() doesn't have some real PITA issues. But that's a discussion better had over on dssi-devel. -Sean

On Sun, Apr 30, 2006 at 11:59:25 -0400, Dave Robillard wrote: On the contrary, some people have said "I need it" to the LOG hint, but it's still not the right thing ;) - Steve

On Sun, Apr 30, 2006 at 06:39:05 -0400, Dave Robillard wrote: There's a difference between needing the feature, and needing that part of the spec, which was the point I was trying to make. Logarithmic input values are very important, I couldn't agree more, but the LOG hint doesn't give you that. Sure. - Steve

On Sat, Apr 29, 2006 at 12:40:11PM -0400, Dave Robillard wrote: I think that's Chris's point though. LADSPA2 has a lot of potential, but why will the users care? However I know that at least one plugin developer will port all his plugins as soon as its finalised, and all the pent up addiditons to LADSPA people have been wanting for ages, but were just to painful to add can be applied. I think the promise of the new features (better auto-built UIs and control randomise are good examples) is enough to make users request support from host authors. These things take time, and I'm not expecting it to be an overnight success, but there are so many cool things that could be done with a more capable, but still fundamentally simple spec. As to DSSI, I regard it as a quiet sucess, theres a fair few pieces of software that wouldn't have existed without it, and it was a good learning experience. Plus we showed that its possible to have plugin UIs on linux without crazy X hacks :) As to wether LADSPA2 can replace DSSI, well, hopefully at some point (we never intended DSSI to be a permenant solution, D right), but its not so urgent. The problems with LADSPA dont affect DSSI so much because it has custom UIs and configure(), which cover a multitude of sins. - Steve

On Sunday 30 Apr 2006 00:01, Dave Robillard wrote: So what are those things, and how will LADSPA2 get us to them? I'm not looking for perfect foresight here, just some inspiring examples. Just because one API is easier to extend than another, doesn't mean that it will necessarily happen easily or in a useful way (i.e. with consistent enough coverage from hosts or plugins to be really useful). The logarithmic hint discussion here is an example of that -- it's just about the most trivial thing that can be imagined as an application of an extensible API, yet it's ended up in a lengthy discussion with no consensus so far. Chris

On Sun, 2006-04-30 at 12:38 +0100, Steve Harris wrote: Similarly, distinguishing 'audible' ports from 'CV' ports, allowing a lot more (eg filter) plugins to run in Ardour. -DR-