On Tue, 2009-08-11 at 15:15 +0100, james morris wrote: Something like that; the data side of things is relatively easy. The connect method takes a void* pointer, so this is fine. You can stick whatever kind of data you want in ports without needing a new connect method. The question here is probably: array of pointers to buffers, or one big multi-buffer? The former is probably more flexible. Backwards compatibility is one reason a big multi-buffer (the first part of which is a single normal buffer) might be good. Though there can just be a rule something like "if the host doesn't support multi-buffers, the plugin must expect a single buffer", which seems fine. That's essentially the problem to solve :) Well, pretty much everything is via extension_data, and/or features. The usual pattern is to have it return a struct of function pointers. In other words, you can add whatever functions to the LV2 API you want. So here, we need something like a function the host calls to tell the plugin to increase its replication factor. Then rules for when this function can be called and its semantics etc. etc. Port names/symbols (symbols) must not be interpreted in ways like this, ever. Reading the .ttl and instantiating the plugin binary are different times. How the host behaves will depend on things it figured out from the .ttl though, yes. Cheers, -dr

On Tue, 2009-08-11 at 19:01 +0100, Steve Harris wrote: Sold. Probably not (it would actually be void* anyway), but the header can provide a nice inline function for this. Good point... this also sets things up to be compatible with plugin-allocated dynamic output buffers in the future without needing any hokey mechanism just to say how many are there, which can't hurt. Maybe we should go a teeny bit further and make the struct extensible, putting the data pointer first. Slight overhead in that the number of channels may be shared between many ports, though. I think the port would probably have to be of the MultiPort type, then either 1) also of another data type, or 2) have a :contentType predicate to point to that other type. We certainly don't want a combinatorial explosion of multi-types. Probably 2) is needed for backwards compatibility, but I forget the details of the spec here... Well, you'd end up checking the number of channels stored in the plugin's data anyway, having a case where it's just a plain old buffer doesn't seem to be that much of an additional nuisance (and the win is massive). -dr P.S. extension and LV2 in general discussions are much more active here than lv2-dev. I wonder about the benefit of it existing at all...

On Tue, 2009-08-11 at 20:54 +0100, Steve Harris wrote: Agreed. It's probably best to allow it to vary. I suspect that different groups of ports varying separately will be needed by larger plugins. Some have synthesis sections and effects sections, or multiple 'mixer strips' and the like, for example. Meh, I'm thoroughly sick of multiple versions of the same plugin. Control vs audio is next against the wall :) It's probably straightforward to make it so that plugin authors can do it however they want, anyway. I see a great deal of existing plugins that would make sense to replicate, so I would say yes. True. Just a thought. -dr

On Wed, Aug 12, 2009 at 09:46:58PM +0100, james morris wrote: That is the essential difference between a plugin being used in a multichannel stream and one being used for polyphonic synthesis, where the cutoff frequency could be a per-voice envelope. Provided the plugin can do both, it is the *host* that has to make clear what's required. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On 12/8/2009, "David Robillard" <dave(a)drobilla.net> wrote: Or ganging the control ports?

On 12 Aug 2009, at 22:20, David Robillard wrote: Yes, most importantly it lets you handle the cases that the host can't eg. multichannel compression. I guess reverb would be another example, but I don't know how multichannel reverb works. In that situation, offering per-channel controls makes no sense. - Steve

On Wed, 2009-08-12 at 23:29 +0200, Fons Adriaensen wrote: (Aside: this reminds me a bit of a number thing that comes up often in design stuff: a "special" 0 is fine, a "special" 1 is fine, but a "special" 2 or anything else is very likely bad (because it should be a generic "many")) Here we have 1 (no replication) or many (replicate to n, or maybe a multiple of m if we need that). The problem being, sometimes we want group A (audio) to replicate and C (controls) to not, and sometimes we want them both to. They can't be truly independent though, because they need to match if they're both replicated. Regardless we need replication to happen on a "group of ports" level (rather than a whole plugin level), so given that, how about: Allow one group of ports to have either no replication, or the same replication count as another group of ports. Obvious example being, controls tend to stick to 1, audio tends to get replicated, but we may want to replicate the controls to match audio. So, a single plugin could do all of the above cases in a single instance, if the author wants to do it that way. Deals with all the possible cases (?) but really simple: basically one property to say "if I'm replicated, I must match this other group's count". The lazy host can just not replicate them at all without any negative consequences Cheers, -dr

On Wed, 2009-08-12 at 23:24 +0100, Steve Harris wrote: That, and letting it change while the plugin rolls without dropouts... What immediately comes to mind is (simplified to ignore groups etc, all functions on the plugin): An instantiation class function: void* prepare_replication(uint32_t count) Which returns some opaque data structure. Non-realtime things like allocation can be done here. An audio class(*) function: void apply_replication(uint32_t count, void* data) Where the host must pass whatever the plugin passed it in prepare_replication. This way the plugin can allocate whatever auxiliary data structures or compute tables or whatever non-realtime stuff needs to be done, then apply it in realtime, without having to bother the plugin with a bunch of threading junk that should be the host's problem anyway. (Apply NULL to taste for plugins that need no data etc) On backwards compatibility, something like "if apply_replication has never been called, the port buffer is a single, normal buffer of the given data type" seems to be all that would work. Not too bad, I think. If this is a problem for some reason it can always be made a mandatory feature for the plugin. -dr (* We should change this to "process class")

On Thu, 2009-08-13 at 11:03 +0100, Steve Harris wrote: You can't allocate things and precompute tables and such in the process thread. It must be split like this if the replication is to change while the plugin rolls. (Actually it's tempting to go a tiny bit further and replace count with features and just have a generic mechanism for this. It crops up all over the place. That's getting ahead of ourselves though) -dr

On Wed, 2009-08-12 at 23:39 +0100, james morris wrote: ... I don't think "or ganging the control ports" really quite conveys the idea entirely ;) -dr

On Thu, 2009-08-13 at 00:05 +0100, james morris wrote: So the guy claiming he described the solution already is still working on grasping the problem? :P </daft> Other plugins are /way/ outside of scope. What is "the number of channels"? Just some abstract parameter, we're designing a plugin API here, not a modular synth's internals. As described in the above quoted email, the problem is sometimes you want the audio ports on plugin P replicated and the control ports on plugin P singular, but other times you want the control ports on plugin P replicated to match the audio ports. Anything to do with other plugins is well within "host's problem" territory. In a word, no. Same problem, and it seems a very simple solution can handle the complex cases anyway. Cheers, -dr

On 12/8/2009, "David Robillard" &lt;dave(a)drobilla.net&gt; wrote: I said previously I was fairly sure port replication should be a property of a port. The LP filter example had one cutoff port for two channels, and asked what if we want two cutoff ports. This implies that the cutoff port can have no replication or the same replication as the number of channels processed. It's so obvious that different ports within the same plugin MUST have the same replication count or no replication I never thought to spell it out. I was trying to point to the question of: Why base the replication of a control port on the replication of the audio ports? The audio port replication is based on the number of channels, so base the replication of the control port (if it is to be replicated) on that also. The plugin will be informed of the number of channels by the host anyway. So we have two new port properties: one to say this port should always be replicated - audio ports would use this - and another to say that this port can be replicated but does not have to be. The matching of counts is implied because there's no sane reason why port replication counts would not match. James.

On 13/8/2009, "David Robillard" &lt;dave(a)drobilla.net&gt; wrote: I'm assuming the only ports to be replicated are those which have say a multiPort property. I don't see why replication would not be the same in a plugin instance, across all ports with that property. .... I was imagining the "number of channels" value as being accessible by something like this: typedef struct { /** Opaque pointer to host data. * The plugin MUST pass this to any call to functions in this struct. * Otherwise, it must not be interpreted in any way. */ LV2_Multi_Ports_Callback_Data callback_data; /** Access the number of channels the plugin should process. */ uint32_t (*get_channel_count)(LV2_Multi_Ports_Callback_Data callback_data); } LV2_Multi_Ports_Feature; Where the host defines the callback data struct and the callback to access it (and thus provide the dreaded channel count of the particular stream the plugin is inserted in). The plugin calls the callback when needed. It might store the channel count (or count of outputs it's inputs should connect to). I doubt it, but have to ask: are you saying the plugin will not know how much replication it should do until its connect method is called with multiple outputs? Cheers, James.

On 13 Aug 2009, at 20:01, David Robillard wrote: That, IMHO, is a different problem space. Several channels on a mixer should be doable with the 1/N channels restriction. - Steve

On 13/8/2009, "Fons Adriaensen" &lt;fons(a)kokkinizita.net&gt; wrote: That's the problem I've limited myself to. ... All the port type (property) would do is say this port is replicated. How the plugin handles that is down to the author. For the limiter example you might want a boolean value (a gui check box) which the plugin acts upon to determine this. There would still be the same number of inputs/outputs replicated in both cases (I think)... James.

On Fri, 2009-08-14 at 01:26 +0200, Fons Adriaensen wrote: You're cutting the problem apart in the wrong direction, these "cases" don't make much sense. We just need a way to replicate ports... Polyphony does differ in that there's the additional issue of 'active' vs 'inactive' voices, but I think that is orthogonal to actually replicating ports. It seems a few cases have popped up where we need this and that little bit of binary information associated with port contents - maybe there should be a mechanism for this? In this case, of course, that thing would be a boolean for whether this voice is active. We don't want to have to create a new port type for "audio plus bool active", that'll just end up in combinatorial type explosion. In a word: yes. The basic LV2 spec - which is small, and simple - is capable of this, so why not? I certainly need it anyway. If you don't, then don't bother with such things. LV2 itself does not bloat because of stuff like this. The extension mechanism you think you don't like is what solves this problem. I see no problem with this whatsoever. Why the heck would you want 4 APIs instead of 1, when 1 will do? These are all things that are very similar in scope and appropriate for LV2. Inputs, process, outputs. Sure, not everything in the entire world is - what VAMP plugins do, for example, is not a good match for LV2 at all - but this stuff certainly is. Things as complicated as Zyn do require some more complicated extensions. You are perfectly free to ignore them and act as if they do not exist at all. Again, the extension idea is the reason for this. There is no problem with the scope mentioned at all, and there is no problem with a much wider scope than that either. If it's not to your liking, simply ignore it. People can implement all sorts of retarded things within LV2, much like in any programming language. This doesn't affect anyone else. You always have LADSPA+metadata if that's all you really want. The scope of LV2 itself is tiny, and I think it should be kept as tiny as possible... but you have actually been arguing that the scope of LV2 should be dramatically increased! Wide scope would indeed be bad if everything was mashed in some big messy kitchen sink specification - just one of many reasons this is a bad thing, and it's not done this way. LV2 itself is very small and simple, and yet all the above fancy things are possible. That is good design. LV2 designed in the way you seem to think would be better would be MUCH larger and MUCH more complicated and MUCH less capable. That is bad design. The tale of the tape tells it all, so to speak. (I guess I have to bite at the whole FUD thing, so here it is:) If you do not like the design issues involved with this kind of thing, then just ignore them. Frankly, Fons, and I don't mean this as an insult in any way; you're an excellent math and DSP guy (probably the most useful person around here for that sort of thing) - but you're not very good at design(*). If the problem is not to your liking, that doesn't mean the problem itself is stupid. Making a good extensible plugin API with this scope is not at all stupid, it's clearly just not your thing. Similarly, I havn't the slightest clue how to go about writing a filter - but I'm glad others do, because I know good filters are useful ;) If you have useful input, which as a plugin/app author you often do, then fire away, but this FUD crap (and it is FUD because it is not based on facts) really just gets in the way of things. Nothing useful can possibly come from it. WHY are extensions bad? WHY is using LV2 for Zyn and arithmetic operations bad? WHY the heck would you want a different API for a synth and a panner? WHY? The why part is usually left out because there isn't one... Actual concrete criticism is useful, and welcome, but constant vague hand-wavey "LV2 is the devil just because" kind of arguments are not. You have a lot of great plugins, many of which suffer a great deal from the limitations of LADSPA (more so than most, actually, e.g. CV) - your input on LV2 things is therefore probably useful, and getting your plugins ported to LV2 would definitely benefit everyone. However, In order for input to be useful, and for your concerns (if you have any tangible ones) to be addressed, there has to be actual factual points in there. That the LV2 sky is falling is not very useful... Again, I apologize for taking this personal in a sense, but it seemed the only way to make the point. You point out genuine, concrete problems with LV2, or related things, and I hereby personally promise to do my best to resolve them (eventually), and thank you for your input; but there is really very little I or anyone else can do with variations on "LV2 is crap". -dr (* and I will be the first to admit that I suck at DSP. Mathey types who are good at design (and vice versa) are very, very few and far between. Different modes of thinking entirely.)

On Thu, 2009-08-13 at 21:27 +0100, Steve Harris wrote: Replicating ports is a different problem space than replication ports? If we end up with a bunch of different little half-assed extensions for the same thing, then the extension FUD is right. If there are real, actual, concrete reasons why doing something is very complex and probably not useful, that's another story, but I don't think that's the case here. A mixer usually has several 'strips', each of which may have different counts. Like the ardour mixer, for example. This is a simple, realistic, and useful case where simply having a single global value doesn't cut it. The same goes for virtually anything with several signal paths. -dr

On 14 Aug 2009, at 00:48, David Robillard wrote: I don't see a) how having multiple channel counts makes any difference b) how the hell the host would deal with it. Lets see, in a typical mixer setup, we have Audio: in X N out X N master out X 2 bus out X 8 Control: master gain X 1 channel gain X N low shelf X N high shelf X N trim X N pan X N bus sends 8 X N all looks fine to me. - Steve

On 14 Aug 2009, at 15:56, David Robillard wrote: Well, it was supposed to be a stereo mixer. So the output will have a stereo role, making it an n-ary out is just not that simple, you'd need to do something truly odd with the pan control. Because of the sends. Unless you're planning to have N * M way controls as well? Because of the pan control. That's a more compelling example, but it can be done with M * N-way panners and a mixer. - Steve

On 14 Aug 2009, at 17:30, David Robillard wrote: The host can do it automatically, obviously. - Steve

On Fri, Aug 14, 2009 at 04:47:22PM -0400, David Robillard wrote: Very true. More generally, one reason for wanting plugins in any audio processing system is to allow for non-standard things. Which more or less means that a plugin API should never be based on assumptions about the most 'common' case - its very reason to exist is to go beyond that. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote: It has to be, because the N channels may be a specific type of N channels. 7.1, say, or ambisonic. Exactly. You can't use N 1->M panners to do an N->M panning job. This is true of *.1 as well as ambisonics. In general, this is just the ugly head of a huge shortcoming LAD stuff has always had, the LADSPA and JACK assumption that just having a "bunch of channels" is not good enough. If you think about it, it's actually pretty true to say that the LAD/Jack/LADSPA stack doesn't even correctly support stereo! We get by with undocumented assumptions about port order and such. I'd have a hard time saying anything beyond stereo is reasonably supported at all. Sure, you can carefully wire up everything manually, but the shortcomings there are obvious. Time to fix that oops. I don't think it's really that bad, or much worse. Instead of the API allowing the host to say "plugin, you have N channels", the API allows the host to say "plugin, this group has N channels". On the data side of things, all we really need is the before discussed predicates to say this group's count matches that group's count, and a predicate to list supported 'stream types'. I could be missing something? It doesn't seem that much more complicated. It /could/ be quite a bit more complicated if, say, the host set the input counts and the plugin could dynamically say pretty much anything about the output counts, but I agree /that/ would probably be going too far. I don't think that is really needed, being able to say this group and that group are equivalent seems to take care of anything even remotely feasible in the short to medium term. Equivalence is pretty easy to deal with, and the simple plugins (that are the arguments for a global count) would only have 1 input and 1 output group that would match anyway. The simple plugin case is pretty much as easy to deal with as it is if the spec only supported a single count. Common host logic would be something like: - I have a stereo stream here for this plugin - Does this plugin support stereo input? - If yes, then set the plugin inputs to stereo, and check what outputs are matched (trivial), and set those to stereo too - If no, this plugin doesn't work here (defer to user or just reject) There are annoying cases that could crop up, such as the outputs already being connected to something non-stereo, but these would have to be dealt with either way. It seems to be having the count at the group level doesn't really complicate anything much. Cheers, -dr

On 15 Aug 2009, at 19:25, Steve Harris wrote: I was going to shut up, but I'll just add that I am open to having my mind changed. It seems like a decent idea in theory. If you can walk me through some realworld cases (not hypothetical, I have this requirement coming up stuff), and it doesn't seem like a horrible burden on the user, or host author. I know it's pretty reasonable from the plugin authors p.o.v. I'll note that AU is not a great example to follow though, it's distinctly horrible to work with. Though not just for this reason. I'll give it some more thought when I get back, if you've not lost interest :) - Steve

On 13 Aug 2009, at 18:10, David Robillard wrote: Ah. I see. I thought that the proposal for that the number of channels in each port would be 1 or N. In that case, I object to the proposal on the basis of over complexity, and trying to solve a problem we don't actually have. - Steve

On 14 Aug 2009, at 00:37, David Robillard wrote: I'm not interested in hypothetical future plugins. 1/N gives us support for multi channel compressors, limiters etc, multichannel reverbs, what else is there that cares about the difference between a quad channel plugin and two stereo ones? A proposal where each group of ports can have it's own number of channels just brings lots of modelling problems, like what does it mean if you have 14 channels and 2 sidechains? It's just not useful, and your argument that it's no harder is not convincing. - Steve

On 11/8/2009, "David Robillard" &lt;dave(a)drobilla.net&gt; wrote: I've been trying to figure out if a port should have a property applied to it to indicate to the host it is a multichannel port or if a new sub class of port should be created. The latter implies further subclasses to match the existing port subclasses so I'm almost sure it would be more sensible for multichannel ports to be specified via a property. It's slowly sinking in... Slowly. Ok, that's good. BTW, I'm trying to figure this out for my own experience rather than making an pretense toward creating a multichannel LV2 extension (just in case anyone thinks otherwise). cheers, James.