Re: [LAD] Lv2 port replication [was Re: the role of lv2 extensions]
On 14 Aug 2009, at 00:37, David Robillard wrote: >> I thought that the proposal for that the number of channels in each >> port would be 1 or N. > > Well, it could be, but that seems sure to be limiting in the > future. It > also seems to be not really feasible, short of being a joke useful for > only the most trivial of plugins: 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On 14 Aug 2009, at 00:48, David Robillard wrote: >> Several channels on a mixer should be doable with the 1/N channels >> restriction. > > 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
On Friday, August 14, 2009, Paul Davis wrote: > On Thu, Aug 13, 2009 at 5:06 PM, Luis > Garrido wrote: > > Bear in mind that Qt is C++ and signal/slot based, so you'll have the > > usual problem of integrating GStreamer callbacks using static methods > > and the user payload at the calls. > > gtkmm is signal/slot based too, but because of its closer integration > with C++ idioms, this particular issue doesn't arise too much. you > don't need a pre-processor to use libsigc++ Of course you need a pre-processor to use libsigc++. The pre-processor is a standard part of the C++ (or plain C) compilation chain, for instance the "cpp" program for the GCC compiler. It takes care of expanding macros, compile directives and conditional compilation. Maybe you are thinking about the Qt's "moc" code generator tool. It reads a C++ header file, and if it finds one or more class declarations that contain the Q_OBJECT macro, it produces a C++ source file containing the meta-object code for those classes. This code implements the calls and callbacks for Qt's native signals and slots, among other things. MOC is not a pre-processor because it doesn't replace any text in the original header file before the next compilation step. It is only a code generator. The original header is a standard C++ header that can be used as-is by a C++ compiler. > and if you are working in > C++ for any reason, you should be aware of sigc++. its the greatest > thing for C++ since boost (and thankfully, boost includes something > closely modelled on it these days). > > what toolkit you choose, so I'd favour GTK because of its easy > > integration with GStreamer and to keep the whole application under the > > callback paradigm. > > signals & slots are a callback mechanism too. they just hide it from > the programmer with a different kind of abstraction (when this signal > is "emitted", call the following "slot"). its all just syntactic > sugar. The main (functional) difference between the two systems is that Qt's signals and slots can be manipulated at runtime, while you can't do the same with libsigc++, that freezes the connections at compile time. Manipulate means that you can connect and disconnect signals and slots at runtime, store and retrieve those connections from a text or XML file, and so on. This also makes Qt's signal/slots a little more expensive in processing time over libsigc++. Here is a comparision between them: http://libsigc.sourceforge.net/benchmark.shtml Why Doesn't Qt Use Templates for Signals and Slots? http://doc.trolltech.com/templates.html Qt's native signal/slot mechanism isn't mandatory to developt Qt-based applications. It is possible to use Boost, libsigc++ or something else. See: http://doc.trolltech.com/signalsandslots.html#using-qt-with-3rd-party-signals-and-slots Regards, Pedro ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
How about Juce? =p http://www.rawmaterialsoftware.com/juce/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
On Fri, Aug 14, 2009 at 2:36 PM, Ray Rashif wrote: > How about Juce? =p http://www.rawmaterialsoftware.com/juce/ Or NUI: http://www.libnui.net/ ... I've never tried this, would be interested in impressions from anyone who has. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On Fri, 2009-08-14 at 10:13 +0100, Steve Harris wrote: > On 14 Aug 2009, at 00:48, David Robillard wrote: > >> Several channels on a mixer should be doable with the 1/N channels > >> restriction. > > > > 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. > > 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 Hm, 2? Why 2? > bus out X 8 Hm, 8? Why 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 inputs 2 * N outputs 2 * N Why 2? Why do they all have to be 2? Perhaps a simpler example: an n->m panner. Are you really going to argue that an n->m panner is not a useful plugin!? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [was Re: the role of lv2 extensions]
On Fri, 2009-08-14 at 10:06 +0100, Steve Harris wrote: > On 14 Aug 2009, at 00:37, David Robillard wrote: > >> I thought that the proposal for that the number of channels in each > >> port would be 1 or N. > > > > Well, it could be, but that seems sure to be limiting in the > > future. It > > also seems to be not really feasible, short of being a joke useful for > > only the most trivial of plugins: > > 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? Read: I'm not interested in anything beyond current plugins in swh-plugins. > 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. I gave several examples of where this is useful, and it's pretty telling that the only other plugin API that can do this does it this way. That API (AU) is a dull pragmatic commercial thing, it's not like they did it that way for fun. It is more or less necessary to do it this way if you want multiple channels to actually make any semantic sense anyway, "4 channels" is meaningless. If this conversation has devolved into an argument over whether we need straightforward functionality that I know for a fact I need in the near future, then it has outlived its usefulness. Unless anyone else is planning on actually implementing this any time soon, it doesn't matter anyway. Don't mind me, I'll be over here doing it right. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
On Fri, 2009-08-14 at 12:50 +0200, Pedro Lopez-Cabanillas wrote: > The main (functional) difference between the two systems is that Qt's signals > and slots can be manipulated at runtime, while you can't do the same with > libsigc++, that freezes the connections at compile time. Uh no -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On 14 Aug 2009, at 15:56, David Robillard wrote: > On Fri, 2009-08-14 at 10:13 +0100, Steve Harris wrote: >> On 14 Aug 2009, at 00:48, David Robillard wrote: Several channels on a mixer should be doable with the 1/N channels restriction. >>> >>> 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. >> >> 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 > > Hm, 2? Why 2? 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. >> bus out X 8 > > Hm, 8? Why 8? Because of the sends. Unless you're planning to have N * M way controls as well? >> 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 > > inputs 2 * N > outputs 2 * N > > Why 2? Why do they all have to be 2? Because of the pan control. > Perhaps a simpler example: an n->m panner. Are you really going to > argue that an n->m panner is not a useful plugin!? That's a more compelling example, but it can be done with M * N-way panners and a mixer. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
On Thu, Aug 13, 2009 at 8:29 PM, David Robillard wrote: > Gtkmm is quite nice for the more C++ minded. Much nicer standard C++ > style than the cracked out preprocessed pseudo-C++ insanity that is Qt, > at any rate. As Pedro says, Qt just contains a code generator; you still end up with C++. I don't think the differences between Qt and libsigc++ signal/slot mechanisms are all that much to be worried about -- libsigc++ gets you "purer" C++ but Qt involves less typing, particularly of those pesky angle brackets. They both work. Good material for endless pub arguments, but not worth getting in a froth about when you're actually coding. (I generally use Qt, and I would say that Qt4 is a very fine library in general. Not much wrong with GTKmm either though.) Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
Hey all, I've just downloaded and built NUI, it seems ok, a little "plastic"-"shiny" looking, and the sliders run kinda slowly on this laptop. (Havent tried anywhere else.) GTK(mm) sliders work no prob here on the other hand but I develop with GTK, so my view is biased ;-) Their screenshots look nice though.. and there's pretty nifty docu with it by the looks! -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] GTK+ vs QT for new Open Source Project.
On Fri, 14 Aug 2009, Pedro Lopez-Cabanillas wrote: >> gtkmm is signal/slot based too, but because of its closer integration >> with C++ idioms, this particular issue doesn't arise too much. you >> don't need a pre-processor to use libsigc++ > > Of course you need a pre-processor to use libsigc++. The pre-processor is a > standard part of the C++ (or plain C) compilation chain, for instance > the "cpp" program for the GCC compiler. It takes care of expanding macros, > compile directives and conditional compilation. > > Maybe you are thinking about the Qt's "moc" code generator tool. It reads a [snip] > MOC is not a pre-processor because it doesn't replace any text in the original [snip] moc is processing source code by scanning it and then generating code that will be fed to the compiler. This is a preprocessor. I love Qt, really... but having to use moc is annoying. I'm not alone in this. Plus, syntax highlighters sometimes choke on Qt's syntax. >> signals & slots are a callback mechanism too. they just hide it from >> the programmer with a different kind of abstraction (when this signal >> is "emitted", call the following "slot"). its all just syntactic >> sugar. > > The main (functional) difference between the two systems is that Qt's signals > and slots can be manipulated at runtime, while you can't do the same with > libsigc++, that freezes the connections at compile time. Manipulate means Not exactly. You can manipulate run-time connections with either library. libsigc++ requires that the types of the connections being made at runtime are already known at compile time. Qt allows you to make connections between signals and slots whose types are not known until runtime. This difference is generally not significant to an application designer. The only place I know that this ability is being utilized is in KDE where the UI's are being created at run-time from an XML file specification. And with a little planning, you could probably do something similar with sigc++. HTH, Gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On Fri, 2009-08-14 at 17:09 +0100, Steve Harris wrote: > On 14 Aug 2009, at 15:56, David Robillard wrote: > > Perhaps a simpler example: an n->m panner. Are you really going to > > argue that an n->m panner is not a useful plugin!? > > That's a more compelling example, but it can be done with M * N-way > panners and a mixer. Tell the user that... :) It can be done with a sufficiently large collection of product plugins too. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] Multi-Channel channel order
Is there any existing 'standard' for the order of channels for higher-than-stereo multi-channel streams? I'd assume this would be defined for interleaving or something, though that's not what it's needed for: I think the port groups extension should specify an order for all the channels of the various types of group. Though this isn't necessary useful in the normal case (ports are separate ala LADSPA), with this replication stuff and presumably other things the host and plugin are going to have to deal with sets of buffers, and having a predefined standard order for them seems like it would make life a lot simpler and faster (and not having one seems to have no benefit). For example, for discrete non-interleaved 5.1 (using a full channel for the .1) we have 6 channels: left, center, right, rear left, rear right, LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup) What order should these be passed in? Any existing practices? Thanks, -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, Aug 14, 2009 at 12:36:36PM -0400, David Robillard wrote: > Is there any existing 'standard' for the order of channels for > higher-than-stereo multi-channel streams? > > ... > > For example, for discrete non-interleaved 5.1 (using a full channel for > the .1) we have 6 channels: left, center, right, rear left, rear right, > LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup) > > What order should these be passed in? Any existing practices? For 5.1 there are several orders in use. Same for AMB, in particular higher order. But: either it doesn't matter (e.g. for EQ), and where it does matter a 'general' multichannel plugin (i.e. an essentially mono one that knows about the multichannel port extension and can replicate its internals) probably can't do the job anyway, and you need a dedicated plugin. That would be the case for e.g. an AMB compressor that would apply the same gain to all channels, but derive it only from one of them (W). What is important is that a dedicated 5.1 plugin should be compatible to a 'general' one that has 'anonymous' or just numbered channels, and configured for 6 channels. Also, e.g. an EQ that can be set to six channels should work as well *any* 6-ch format. Which means that in that case channel names are not a property of the plugin, but of the host. For a dedicated 5.1 or AMB plugin that would be different. This suggest that there would some form of trying to match a port defined by the host to that provided by the plugin. If they are identical, all is OK, but that would not be the only case, some other combinations have to work as well. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
David, > What order should these be passed in? Any existing practices? If you use some sort of syntactic port naming, like [foo.L, foo.R, foo.RL, foo.RR, foo.C, foo.LFE] the order doesn't matter - the application that does the connection should be aware of this, of course. Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, 2009-08-14 at 19:29 +0200, Fons Adriaensen wrote: > On Fri, Aug 14, 2009 at 12:36:36PM -0400, David Robillard wrote: > > > Is there any existing 'standard' for the order of channels for > > higher-than-stereo multi-channel streams? > > > > ... > > > > For example, for discrete non-interleaved 5.1 (using a full channel for > > the .1) we have 6 channels: left, center, right, rear left, rear right, > > LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup) > > > > What order should these be passed in? Any existing practices? > > For 5.1 there are several orders in use. Same for AMB, in > particular higher order. Oh well. I'll just come up with one that seems reasonable and has the most overlap I guess, and maybe ship a header file with them all #defined just for convenience's sake (this is all just for convenience, see below) > But: either it doesn't matter (e.g. for EQ), and where it does > matter a 'general' multichannel plugin (i.e. an essentially mono > one that knows about the multichannel port extension and can > replicate its internals) probably can't do the job anyway, and > you need a dedicated plugin. It doesn't matter in most cases (and all currently existing cases), but there's easy things to come up with where it would be useful so it's best to define. Useful data never hurts. > What is important is that a dedicated 5.1 plugin should be > compatible to a 'general' one that has 'anonymous' or just > numbered channels, and configured for 6 channels. Generally the idea with the groups extension is that all grouped ports are labeled with their 'roles' (this is largely the point). They're still compatible with plugins that don't have this data in the LADSPA sense, you can hook it up manually or with messy heuristics etc. Note all this port groups stuff is purely RDF data. Anything else that needs to refer to multi-channel would naturally just use these definitions though, so defining anything that would be useful (like channel order) is wise, so e.g. things don't end up using a bunch of different orderings. Lack of this data just means the host is pretty much screwed when it comes to doing nice higher level connecting of multi-channel streams. It's not really feasible to do so, except: > Also, e.g. an EQ that can be set to six channels should > work as well *any* 6-ch format. Which means that in that > case channel names are not a property of the plugin, but > of the host. Good point. I guess nothing really needs to be done here though, the plugin can just label a bunch of ports as part of a group without a role. > For a dedicated 5.1 or AMB plugin that would be different. > > This suggest that there would some form of trying to match > a port defined by the host to that provided by the plugin. > If they are identical, all is OK, but that would not be > the only case, some other combinations have to work as well. I generally think of this problem in terms of "plugin telling the host precisely what it's I/O is". Hosts can be as clever as they like :) Ideally (IMO), hosts would look at all the plugins they have to find converters. For example, if you have stereo, and need to convert it into 5.1, check all your plugins for something with a stereo in corresponding to a 5.1 out. Hardcoded logic in hosts for this kind of thing is unfortunate, especially for e.g. ambisonics where it's far from trivial behaviour. Thanks, -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, 2009-08-14 at 19:34 +0200, Florian Faber wrote: > David, > > > What order should these be passed in? Any existing practices? > > If you use some sort of syntactic port naming, like [foo.L, foo.R, > foo.RL, foo.RR, foo.C, foo.LFE] the order doesn't matter - the > application that does the connection should be aware of this, of course. Yes, this information is not necessary in the usual context of port groups. In particular, the port index order isn't related. Just useful data that will be needed for other things. Cheers, -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On 14 Aug 2009, at 17:30, David Robillard wrote: > On Fri, 2009-08-14 at 17:09 +0100, Steve Harris wrote: >> On 14 Aug 2009, at 15:56, David Robillard wrote: >>> Perhaps a simpler example: an n->m panner. Are you really going to >>> argue that an n->m panner is not a useful plugin!? >> >> That's a more compelling example, but it can be done with M * N-way >> panners and a mixer. > > Tell the user that... :) > > It can be done with a sufficiently large collection of product plugins > too. The host can do it automatically, obviously. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [somewhat OT] Dataquay -- a C++ wrapper for the Redland RDF data store using Qt4
This is rather off-topic for this list, but I know that some developers here have a warped interest in this sort of thing. Dataquay is a free open source library that provides a friendly C++ API for the popular Redland RDF data store using Qt4 classes and containers. http://breakfastquay.com/dataquay/ Dataquay is intended to be simple to use and easy to integrate. It is principally intended for use in Qt-based applications that would like to use an RDF datastore as backing for in-memory project data -- that is, data being edited by the user, such as points and their properties in a graphical editor -- to avoid having to provide application data-specific file I/O and to make it easy to augment the data with descriptive metadata pulled in from external sources. Dataquay is also intended to be useful for applications whose primary purpose is not related to RDF but that have ad-hoc RDF needs for metadata management. Dataquay is similar in concept to the Soprano library (http://soprano.sourceforge.net/), but smaller, less sophisticated, and with BSD rather than LGPL licensing. Please see the website for more information, downloads, and caveats. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, Aug 14, 2009 at 01:52:38PM -0400, David Robillard wrote: > I generally think of this problem in terms of "plugin telling the host > precisely what it's I/O is". Hosts can be as clever as they like :) Or a plugin telling a host what its I/O *can* be - i.e. offering several options and letting the host or user decide which one makes sense. For example a plugin could offer to do the right thing for either general multichannel (all equal) or for some AMB format. Then it depends on the host or user to select the right mode. It's this sort of thing I had in mind when writing that maybe you can't just rely on port properties alone. > Ideally (IMO), hosts would look at all the plugins they have to find > converters. For example, if you have stereo, and need to convert it > into 5.1, check all your plugins for something with a stereo in > corresponding to a 5.1 out. Hardcoded logic in hosts for this kind of > thing is unfortunate, especially for e.g. ambisonics where it's far from > trivial behaviour. True... But take into account that such conversions would be the exception rather than the rule. You could have a 5.1 mixdown session that at the end is converted to stereo for a CD release, but you would normally never have anything that converts between different formats more than once. So it's perfectly acceptable to require a user decision in case such a conversion is needed. But I do agree 100% that there should be no hardcoded logic for such things - it would get it wrong most of the time, no matter how hard you try. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On Fri, 2009-08-14 at 20:01 +0100, Steve Harris wrote: > On 14 Aug 2009, at 17:30, David Robillard wrote: > > > On Fri, 2009-08-14 at 17:09 +0100, Steve Harris wrote: > >> On 14 Aug 2009, at 15:56, David Robillard wrote: > >>> Perhaps a simpler example: an n->m panner. Are you really going to > >>> argue that an n->m panner is not a useful plugin!? > >> > >> That's a more compelling example, but it can be done with M * N-way > >> panners and a mixer. > > > > Tell the user that... :) > > > > It can be done with a sufficiently large collection of product plugins > > too. > > The host can do it automatically, obviously. The host can do it automatically with the C multiplication operator as well, obviously. Surround panning is not trivial, and not a small amount of code. It is exactly the sort of thing you'd want a plugin for. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
David Robillard wrote: > Is there any existing 'standard' for the order of channels for > higher-than-stereo multi-channel streams? > > I'd assume this would be defined for interleaving or something, though > that's not what it's needed for: I think the port groups extension > should specify an order for all the channels of the various types of > group. Though this isn't necessary useful in the normal case (ports are > separate ala LADSPA), with this replication stuff and presumably other > things the host and plugin are going to have to deal with sets of > buffers, and having a predefined standard order for them seems like it > would make life a lot simpler and faster (and not having one seems to > have no benefit). > > For example, for discrete non-interleaved 5.1 (using a full channel for > the .1) we have 6 channels: left, center, right, rear left, rear right, > LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup) > > What order should these be passed in? Any existing practices? don't know about x.1, but for ambisonics, the emerging standard seems to be the "ambisonic channel number" scheme as defined here: http://ambisonics.ch/standards/channels/ most favoured normalization scheme is sn3d, i.e. plugins will have to deal with inputs greater than 1.0f. of course, most applications up to now use the furse-malham standard of w xyz rstuv klmopq, each being normalized to 0..1, with the exception of W, which is additionally divided by sqrt(2). but for political reasons, new plugins should use acn rather than fuma, so that's what should be defined as a standard first. if there is sufficient pressure and people are volunteering, another fuma scheme can always be added. regards, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, 2009-08-14 at 22:31 +0200, Fons Adriaensen wrote: > On Fri, Aug 14, 2009 at 01:52:38PM -0400, David Robillard wrote: > > > I generally think of this problem in terms of "plugin telling the host > > precisely what it's I/O is". Hosts can be as clever as they like :) > > Or a plugin telling a host what its I/O *can* be - i.e. offering > several options and letting the host or user decide which one > makes sense. For example a plugin could offer to do the right thing > for either general multichannel (all equal) or for some AMB format. > Then it depends on the host or user to select the right mode. It's > this sort of thing I had in mind when writing that maybe you can't > just rely on port properties alone. You can pretty much literally describe anything with port properties (or similar), since RDF is a fully powerful data model. Something like this will involve some binary things as well, yes. As usual that is kept to a minimum because data is more flexible. I agree both things you mention here (listing the specific formats a group can support, or 'general multi-channel) are needed. This isn't too bad, it could e.g. support 5.1 or WXY or whatever, or any number of channels from 1 through 16. The only thing I can think of that would make it hairier is if, say, the plugin could only support multiples of some number of channels. Is this necessary where the upper limit is infinity? Are there any more complex requirements that are reasonable? I can't think of any, this seems way beyond reasonable to me. > > Ideally (IMO), hosts would look at all the plugins they have to find > > converters. For example, if you have stereo, and need to convert it > > into 5.1, check all your plugins for something with a stereo in > > corresponding to a 5.1 out. Hardcoded logic in hosts for this kind of > > thing is unfortunate, especially for e.g. ambisonics where it's far from > > trivial behaviour. > > True... But take into account that such conversions would be the > exception rather than the rule. You could have a 5.1 mixdown session > that at the end is converted to stereo for a CD release, but you would > normally never have anything that converts between different formats > more than once. So it's perfectly acceptable to require a user decision > in case such a conversion is needed. But I do agree 100% that there > should be no hardcoded logic for such things - it would get it wrong > most of the time, no matter how hard you try. Sure. Just a host/UI issue. Even using plugins to do it you'd probably have to defer to the user to ask which one to use anyway. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On Fri, Aug 14, 2009 at 04:47:22PM -0400, David Robillard wrote: > Surround panning is not trivial, and not a small amount of code. It is > exactly the sort of thing you'd want a plugin for. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, Aug 14, 2009 at 04:54:57PM -0400, David Robillard wrote: > The only thing I can think of that would make it hairier is if, say, the > plugin could only support multiples of some number of channels. Is this > necessary where the upper limit is infinity? Are there any more complex > requirements that are reasonable? I can't think of any, this seems way > beyond reasonable to me. I don't see ATM any reason to put restrictions on N (apart from some reasonable maximum). One thing I can imagine is that the internal processing would be in groups of 4 channels to exploit SSE. But even in that case the interface could be 1,2, or 3 less. On the other hand, this makes a case for using an interleaved format, and for rounding up the number of _physical_ channels if the number of _logical_ channels is not a multiple of four. In other words the host would just provide some dummy channels allowing the plugin to use groups of four without having to copy on input an output. Just a silly idea, but I'm considering exactly that for the internal organisation of an app I'm working on. But then there are also the graphical CPUs today, again changing the picture. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier wrote: > David Robillard wrote: > > Is there any existing 'standard' for the order of channels for > > higher-than-stereo multi-channel streams? > > > > I'd assume this would be defined for interleaving or something, though > > that's not what it's needed for: I think the port groups extension > > should specify an order for all the channels of the various types of > > group. Though this isn't necessary useful in the normal case (ports are > > separate ala LADSPA), with this replication stuff and presumably other > > things the host and plugin are going to have to deal with sets of > > buffers, and having a predefined standard order for them seems like it > > would make life a lot simpler and faster (and not having one seems to > > have no benefit). > > > > For example, for discrete non-interleaved 5.1 (using a full channel for > > the .1) we have 6 channels: left, center, right, rear left, rear right, > > LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup) > > > > What order should these be passed in? Any existing practices? > > don't know about x.1, but for ambisonics, the emerging standard seems to > be the "ambisonic channel number" scheme as defined here: > http://ambisonics.ch/standards/channels/ Excellent, thanks! > most favoured normalization scheme is sn3d, i.e. plugins will have to > deal with inputs greater than 1.0f. Hm. I never considered normalization... the reasoning and details behind this seem to be pretty deep. I will maybe just say SN3D is the normalization that should be used, and that's that? This is similar to what we've done with LADSPA and LV2 and Jack anyway. Audio is -1.0 .. 1.0 float, not clipped, period. Picking the/a best and just saying that's what we use seems to have worked out very well vs the the "support every little different encoding possible" method that causes a huge complicated mess... > of course, most applications up to now use the furse-malham standard of > w xyz rstuv klmopq, each being normalized to 0..1, with the exception of > W, which is additionally divided by sqrt(2). That the letters aren't in any really sensible order in ACN does seem pretty weird. > but for political reasons, new plugins should use acn rather than fuma, > so that's what should be defined as a standard first. if there is > sufficient pressure and people are volunteering, another fuma scheme can > always be added. Sounds good to me. (Fons, what is the situation WRT this stuff with your ambisonics plugins? AFAIK they are the only ones that exist in LAD land) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, 2009-08-14 at 23:14 +0200, Fons Adriaensen wrote: > On Fri, Aug 14, 2009 at 04:54:57PM -0400, David Robillard wrote: > > > The only thing I can think of that would make it hairier is if, say, the > > plugin could only support multiples of some number of channels. Is this > > necessary where the upper limit is infinity? Are there any more complex > > requirements that are reasonable? I can't think of any, this seems way > > beyond reasonable to me. > > I don't see ATM any reason to put restrictions on N (apart from some > reasonable maximum). One thing I can imagine is that the internal > processing would be in groups of 4 channels to exploit SSE. But even > in that case the interface could be 1,2, or 3 less. Sounds reasonable. I think it should be straightforward to model it in such a way that new kinds of advanced restrictions can be added later if it's necessary anyway, so if there's no need for this kind of stuff now, no sense trying to define it. > On the other hand, this makes a case for using an interleaved format, > and for rounding up the number of _physical_ channels if the number > of _logical_ channels is not a multiple of four. In other words the > host would just provide some dummy channels allowing the plugin to > use groups of four without having to copy on input an output. Hm. True. Well, if it works out that this stuff can be spec'd such that more complex restrictions like this can be added, we can ignore this for now. So, we'll see. Tempting case though, if the plugin did know there's multiple of 4 buffers always, it could use a literal 4 in the loop, and recent GCC would probably successfully vectorize it... I guess interleaving coming up eventually was inevitable :/ One major disadvantage to using interleaving anywhere in the plugin interface is that it makes redistributing the data to/from LADSPA (and LADSPA style LV2) plugins significantly more expensive, difficult, and impossible to do in place. Ditto for JACK buffers. Given that, I think avoiding interleaving at the plugin API level is probably very desirable unless there's a really compelling reason to do otherwise. (GStreamer uses interleaved internally, if that's worth anything) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
David Robillard wrote: > On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier wrote: >> most favoured normalization scheme is sn3d, i.e. plugins will have to >> deal with inputs greater than 1.0f. > > Hm. I never considered normalization... the reasoning and details > behind this seem to be pretty deep. I will maybe just say SN3D is the > normalization that should be used, and that's that? fine. it's just that plugins *will* have to deal with signals greater than 1.0 in some channels, because that's how BOB wants them to be. > This is similar to what we've done with LADSPA and LV2 and Jack anyway. > Audio is -1.0 .. 1.0 float, not clipped, period. Picking the/a best and extra emphasis on "not clipped", no mention of -1.0 .. 1.0 :-D >> of course, most applications up to now use the furse-malham standard of >> w xyz rstuv klmopq, each being normalized to 0..1, with the exception of >> W, which is additionally divided by sqrt(2). > > That the letters aren't in any really sensible order in ACN does seem > pretty weird. the weird thing is the order of the WXYZ... scheme. when you look at the spherical harmonics components, WXYZ... is a pile of historic junk that is totally unintuitive. consider for instance the components which are invariant under z axis rotation: W: first (and only) of the 0th order components Z: last of the 1st order components R: first of the 2nd order components. so it's time to do away with backward compatibility in this case and create a better world for our grandchildren, even if our generation has to suffer in this world. >> but for political reasons, new plugins should use acn rather than fuma, >> so that's what should be defined as a standard first. if there is >> sufficient pressure and people are volunteering, another fuma scheme can >> always be added. > > Sounds good to me. > > (Fons, what is the situation WRT this stuff with your ambisonics > plugins? AFAIK they are the only ones that exist in LAD land) there is also the CMT toolset by richard furse. both furse and malham have expressed no regrets at doing away with FuMa at this year's ambisonics symposium... i know fons hates fuma and has publicly stated he wants to get rid of it, even though the current AMB set still uses it for historical reasons. there will probably be adaptor plugins for a transitional period - i recently used a quick hack to interface FuMa plugins with the graz cube, who can only deal with ACN and their own in-house scheme (which is being phased out in favour of ACN). best, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On 14 Aug 2009, at 21:47, David Robillard wrote: >> >> The host can do it automatically, obviously. > > The host can do it automatically with the C multiplication operator as > well, obviously. True, but irrelevant. If you have N channels feeding a panner with 5.1 outs v's N channels feeding 2.1 outs, I very much doubt that you want that to be a single plugin. Ambisonics may well be different, but my understanding is that there's a selection of different formats, and you don't go between them by just adding or removing channels. > Surround panning is not trivial, and not a small amount of code. It > is > exactly the sort of thing you'd want a plugin for. Agreed. I still don't know how you'd make it work though. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Fri, Aug 14, 2009 at 05:44:21PM -0400, David Robillard wrote: > > http://ambisonics.ch/standards/channels/ > > Excellent, thanks! That is also the one I'd support, together with either n3d or n3d normalisation, but I wish I could share Joern's optimism about it being accepted... The matter came up in last year's AMB meeting in Graz. That was followed by some very hot and mostly useless discussion on the surround sound list and at various other shady ad-hoc places. It was scheduled to be discussed again at this year's meeting in Graz where both Joern and I were present along with the complete beau monde of Ambisonics, But no conclusion was arrived at, first because we didn't have enouth time and second because for many of the participants it was something they were not prepared for - the necessary introductory talk took almost all the time we had. > > most favoured normalization scheme is sn3d, i.e. plugins will have to > > deal with inputs greater than 1.0f. Not really - for n3d some of the _panning gains_ can be > 1 iff you set W = 1. Absolute levels are not the same thing as relative gains. For sn3d the panning gains are <= 1. > > but for political reasons, new plugins should use acn rather than fuma, > > so that's what should be defined as a standard first. if there is > > sufficient pressure and people are volunteering, another fuma scheme can > > always be added. > > Sounds good to me. Again I would 100% support that, but it is not current practice. Any application that uses this scheme will be the brave one that starts a revolution. > (Fons, what is the situation WRT this stuff with your ambisonics > plugins? AFAIK they are the only ones that exist in LAD land) The plugin set (did you get the latest and greatest ?) uses FuMa and also it assumes that positive azimuth is to the right which is plain wrong. The only reason for that is that most hosts can't create a widget that has negative values to the right and positive ones to the left (and LADSPA can't tell them they should do it). The plugins will remain what they are, but my support for FuMa ends there. All new stuff will be n3d or sn3d and use either the 'computer graphics' (= ACN) or 'Gerzon' order. If the new stuff is more than a plugin it could *maybe* offer FuMA as an option at the external interfaces, as e.g. AmbDec does. Internally everything will be n3d. Anyway, if ports are labeled in 'machine readable' way the order doesn't matter - a host will be able to sort things out. It does matter e.g. in a file format that doesn't have metadata to describe the order. Dave, don't worry about the weird order of the single character names shown on the web page about ACN, They are mentioned only to show how the order relates to the FuMa one. ACN doesn't use these names, it only uses the numbers. Another outcome of the Graz meetings is that the port groups that are currently named H#V# should really be named H#P#. The H#V# ones do also exist, but are different. I'll have to rename all existing AmbDec presets for the same reason. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Sat, 2009-08-15 at 00:38 +0200, Jörn Nettingsmeier wrote: > David Robillard wrote: > > On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier wrote: > > >> most favoured normalization scheme is sn3d, i.e. plugins will have to > >> deal with inputs greater than 1.0f. > > > > Hm. I never considered normalization... the reasoning and details > > behind this seem to be pretty deep. I will maybe just say SN3D is the > > normalization that should be used, and that's that? > > fine. it's just that plugins *will* have to deal with signals greater > than 1.0 in some channels, because that's how BOB wants them to be. > > > This is similar to what we've done with LADSPA and LV2 and Jack anyway. > > Audio is -1.0 .. 1.0 float, not clipped, period. Picking the/a best and > > extra emphasis on "not clipped", no mention of -1.0 .. 1.0 :-D I just meant this is what normal audio is in LADSPA/etc, i.e. historically we've just picked one and said that's it, and it's worked fine, so there's little reason to try and accomodate a bunch of different ways to encode ambisonic streams and make everyone have to deal with that nuisance. > >> of course, most applications up to now use the furse-malham standard of > >> w xyz rstuv klmopq, each being normalized to 0..1, with the exception of > >> W, which is additionally divided by sqrt(2). > > > > That the letters aren't in any really sensible order in ACN does seem > > pretty weird. > > the weird thing is the order of the WXYZ... scheme. when you look at the > spherical harmonics components, WXYZ... is a pile of historic junk that > is totally unintuitive. consider for instance the components which are > invariant under z axis rotation: > W: first (and only) of the 0th order components > Z: last of the 1st order components > R: first of the 2nd order components. > > so it's time to do away with backward compatibility in this case and > create a better world for our grandchildren, even if our generation has > to suffer in this world. Should have changed the letters too in the process? :) I agree historic junk should be cast away in general, and /definitely/ in this case. Shiny new specs = opportunity to fix past mistakes... > >> but for political reasons, new plugins should use acn rather than fuma, > >> so that's what should be defined as a standard first. if there is > >> sufficient pressure and people are volunteering, another fuma scheme can > >> always be added. > > > > Sounds good to me. > > > > (Fons, what is the situation WRT this stuff with your ambisonics > > plugins? AFAIK they are the only ones that exist in LAD land) > > there is also the CMT toolset by richard furse. > both furse and malham have expressed no regrets at doing away with FuMa > at this year's ambisonics symposium... If ever there was a plugin collection that needs some love, that's the one; the nemesis of valgrind loving LADers everywhere :) > i know fons hates fuma and has publicly stated he wants to get rid of > it, even though the current AMB set still uses it for historical > reasons. there will probably be adaptor plugins for a transitional > period - i recently used a quick hack to interface FuMa plugins with the > graz cube, who can only deal with ACN and their own in-house scheme > (which is being phased out in favour of ACN). Hm. Unfortunate. No straight port then :/ Though if there's two (open) plugin collections that do ambisonics, and the authors of both hate fuma, the LADSPA stuff can just move to ACN along with ports anyway. What is the result if you connect a fuma stream to a ACN stream, getting the channels matched correctly but just not the normalisation? Is it just clipping, or is the interpretation completely different? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Lv2 port replication [for dummies]
On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote: > On 14 Aug 2009, at 21:47, David Robillard wrote: > >> > >> The host can do it automatically, obviously. > > > > The host can do it automatically with the C multiplication operator as > > well, obviously. > > True, but irrelevant. > > If you have N channels feeding a panner with 5.1 outs v's N channels > feeding 2.1 outs, I very much doubt that you want that to be a single > plugin. It has to be, because the N channels may be a specific type of N channels. 7.1, say, or ambisonic. > Ambisonics may well be different, but my understanding is that there's > a selection of different formats, and you don't go between them by > just adding or removing channels. 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. > > Surround panning is not trivial, and not a small amount of code. It > > is > > exactly the sort of thing you'd want a plugin for. > > Agreed. I still don't know how you'd make it work though. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Multi-Channel channel order
On Sat, 2009-08-15 at 01:04 +0200, Fons Adriaensen wrote: > On Fri, Aug 14, 2009 at 05:44:21PM -0400, David Robillard wrote: > > Jörn Nettingsmeier wrote: > > > most favoured normalization scheme is sn3d, i.e. plugins will have to > > > deal with inputs greater than 1.0f. > > Not really - for n3d some of the _panning gains_ can be > 1 iff you > set W = 1. Absolute levels are not the same thing as relative gains. > For sn3d the panning gains are <= 1. I'm glad this stuff is actually defined elsewhere. :) > > > but for political reasons, new plugins should use acn rather than fuma, > > > so that's what should be defined as a standard first. if there is > > > sufficient pressure and people are volunteering, another fuma scheme can > > > always be added. > > > > Sounds good to me. > > Again I would 100% support that, but it is not current practice. > Any application that uses this scheme will be the brave one that > starts a revolution. As far as LV2 goes, there's basically zero precedent whatsoever, so brave new world it is. Whichever is most reasonable if you could start anew and pick a single standard is the one to choose. If other stuff all bogged down with legacy is different, whatever. Not everything uses -1..1 float audio either. Conversion isn't the end of the world. Even if the real world has a billion different formats, we can at least make this world nicer. It's the Jack way :) > > (Fons, what is the situation WRT this stuff with your ambisonics > > plugins? AFAIK they are the only ones that exist in LAD land) > > The plugin set (did you get the latest and greatest ?) uses FuMa > and also it assumes that positive azimuth is to the right which is > plain wrong. The only reason for that is that most hosts can't > create a widget that has negative values to the right and positive > ones to the left (and LADSPA can't tell them they should do it). > > The plugins will remain what they are, but my support for FuMa ends > there. All new stuff will be n3d or sn3d and use either the 'computer > graphics' (= ACN) or 'Gerzon' order. If the new stuff is more than a > plugin it could *maybe* offer FuMA as an option at the external > interfaces, as e.g. AmbDec does. Internally everything will be n3d. I was just thinking a direct port to LV2 would be nice, but whatever. Sounds like a level of abstraction is/will be in there somewhere that can deal with it anyway. (You could use the same ontology for lrdf on LADSPA plugins, but the chances of that actually being used are probably slim. I am not personally interested in it, anyway, but the ontology is deliberately simple and 'flat' to make it possible to use in basic things) > Anyway, if ports are labeled in 'machine readable' way the order > doesn't matter - a host will be able to sort things out. It does > matter e.g. in a file format that doesn't have metadata to describe > the order. For normal plugins that just use the metadata, it's all based on the semantic "role" and order is irrelevant. Dynamic stuff probably needs the order though. Plugin code doesn't want to have to deal with this crap when the spec can easily make the host have to pass it in a certain order (when there's a choice, complexity goes in the host). > Dave, don't worry about the weird order of the single character > names shown on the web page about ACN, They are mentioned only > to show how the order relates to the FuMa one. ACN doesn't use > these names, it only uses the numbers. Hrm. I wonder if the names should be changed then... currently they are wChannel, xChannel, etc. I'll have to think about how to work both in there without it being a PITA to query. > Another outcome of the Graz meetings is that the port groups > that are currently named H#V# should really be named H#P#. > The H#V# ones do also exist, but are different. I'll have to > rename all existing AmbDec presets for the same reason. OK, thanks -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
