9 Aug
2009
9 Aug
'09
1:23 p.m.
Hello all,
I have an ardour mixer strip with 4 input and 2 outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
9 Aug
9 Aug
3:52 p.m.
On Sun, Aug 9, 2009 at 11:22 AM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
Hello all,
wrong maiing list, really. but continuing on ...
I have an ardour mixer strip with 4 input and 2
outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
its certainly not documented, but not much is. it doesn't serve any
purpose other than being one of the several approaches one could take
with this somewhat unusual (but certainly not wrong) i/o
configuration. basically, ardour has the concept of "data streams"
within the signal processing route. imagine the situation *without*
the plugin for a moment: what happens to the "extra" data streams C &
D that don't obviously map to the outputs? executive decision: add
them to the outputs (and do it badly, by adding C *and* D to both
outputs, just for good measure). add the plugin to the situation ....
presumably ardour should know that there are now really just two data
streams post-plugin and that nothing needs to be done. but it appears
that it doesn't discover this, and this may be intentional but more
likely is just a bug.
5:05 p.m.
On Sun, 2009-08-09 at 13:52 -0400, Paul Davis wrote:
On Sun, Aug 9, 2009 at 11:22 AM, Fons
Adriaensen<fons(a)kokkinizita.net> wrote:
This behaviour will be manually configurable (and smarter by default) in
3.0, FWIW. Particularly with (LV2) plugins that give more useful
information about what ports represent.
Cheers,
-dr
Hello all,
wrong maiing list, really. but continuing on ...
I have an ardour mixer strip with 4 input and 2
outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
its certainly not documented, but not much is. it doesn't serve any
purpose other than being one of the several approaches one could take
with this somewhat unusual (but certainly not wrong) i/o
configuration. basically, ardour has the concept of "data streams"
within the signal processing route. imagine the situation *without*
the plugin for a moment: what happens to the "extra" data streams C &
D that don't obviously map to the outputs? executive decision: add
them to the outputs (and do it badly, by adding C *and* D to both
outputs, just for good measure). add the plugin to the situation ....
presumably ardour should know that there are now really just two data
streams post-plugin and that nothing needs to be done. but it appears
that it doesn't discover this, and this may be intentional but more
likely is just a bug.
5:53 p.m.
On Sun, Aug 09, 2009 at 03:05:16PM -0400, David Robillard wrote:
On Sun, 2009-08-09 at 13:52 -0400, Paul Davis wrote:
Any workarounds today ?
AFAICS, even LV2 would need an 'extensions' to say if it makes sense
or not to replicate a plugin (yes for EQ or delay, very probably no
in most other cases).
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
On Sun, Aug 9, 2009 at 11:22 AM, Fons
Adriaensen<fons(a)kokkinizita.net> wrote:
This behaviour will be manually configurable (and smarter by default) in
3.0, FWIW. Particularly with (LV2) plugins that give more useful
information about what ports represent. Hello all,
wrong maiing list, really. but continuing on ...
I have an ardour mixer strip with 4 input and 2
outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
its certainly not documented, but not much is. it doesn't serve any
purpose other than being one of the several approaches one could take
with this somewhat unusual (but certainly not wrong) i/o
configuration. basically, ardour has the concept of "data streams"
within the signal processing route. imagine the situation *without*
the plugin for a moment: what happens to the "extra" data streams C &
D that don't obviously map to the outputs? executive decision: add
them to the outputs (and do it badly, by adding C *and* D to both
outputs, just for good measure). add the plugin to the situation ....
presumably ardour should know that there are now really just two data
streams post-plugin and that nothing needs to be done. but it appears
that it doesn't discover this, and this may be intentional but more
likely is just a bug.
6:39 p.m.
On Sun, 2009-08-09 at 21:52 +0200, Fons Adriaensen wrote:
On Sun, Aug 09, 2009 at 03:05:16PM -0400, David
Robillard wrote:
You could maybe make a send or insert and wire something up in jack?
On Sun, 2009-08-09 at 13:52 -0400, Paul Davis
wrote:
Any workarounds today ? On Sun, Aug 9, 2009 at 11:22 AM, Fons
Adriaensen<fons(a)kokkinizita.net> wrote:
This behaviour will be manually configurable (and smarter by default) in
3.0, FWIW. Particularly with (LV2) plugins that give more useful
information about what ports represent. Hello all,
wrong maiing list, really. but continuing on ...
I have an ardour mixer strip with 4 input and 2
outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
its certainly not documented, but not much is. it doesn't serve any
purpose other than being one of the several approaches one could take
with this somewhat unusual (but certainly not wrong) i/o
configuration. basically, ardour has the concept of "data streams"
within the signal processing route. imagine the situation *without*
the plugin for a moment: what happens to the "extra" data streams C &
D that don't obviously map to the outputs? executive decision: add
them to the outputs (and do it badly, by adding C *and* D to both
outputs, just for good measure). add the plugin to the situation ....
presumably ardour should know that there are now really just two data
streams post-plugin and that nothing needs to be done. but it appears
that it doesn't discover this, and this may be intentional but more
likely is just a bug. AFAICS, even LV2 would need an 'extensions' to
say if it makes sense
or not to replicate a plugin (yes for EQ or delay, very probably no
in most other cases).
The port groups extension lets a plugin say things like "these two
outputs are a stereo pair associated with this particular mono input",
or "this port is a sidechain of this other port", etc. A big problem
with this stuff with LADSPA is that "3 audio outputs" is pretty much
impossible to make sense of (or even 2... the only reason anything
multi-channel works at all is apps make undocumented assumptions). What
ports are what, and what other ports they may correspond to, is all the
information you really need.
That said, yeah, replication for anything beyond 1 in 1 out is pretty
unlikely to make sense regardless; unless someone is using 4 outputs as
2 stereo pairs or something like that. Ideally we'll get to the point
where the user can specify they are doing so, so the automatic logic has
more to work with. It's a bit of a weird thing to do anyway, though...
I don't think it makes sense to say whether "replicating a plugin" makes
sense or not, in general. Not the plugin's problem, in any case, the
plugin should just describe what it's I/O is. How clever the host wants
to be given that information is the host's problem (and depends on quite
a bit of host specific stuff)
Cheers,
-dr
7:42 p.m.
On Sun, Aug 09, 2009 at 04:39:01PM -0400, David Robillard wrote:
The port groups extension lets a plugin say things
like "these two
outputs are a stereo pair associated with this particular mono input",
or "this port is a sidechain of this other port", etc. A big problem
with this stuff with LADSPA is that "3 audio outputs" is pretty much
impossible to make sense of (or even 2... the only reason anything
multi-channel works at all is apps make undocumented assumptions). What
ports are what, and what other ports they may correspond to, is all the
information you really need.
Not really, see below.
That said, yeah, replication for anything beyond 1 in
1 out is pretty
unlikely to make sense regardless; unless someone is using 4 outputs as
2 stereo pairs or something like that. Ideally we'll get to the point
where the user can specify they are doing so, so the automatic logic has
more to work with. It's a bit of a weird thing to do anyway, though...
Things like using 4 channels as 2 stereo pairs just shouldn't happen.
Given e.g. Ardour's flexibility in creating strips with any number
of channels there is no need to do such things. Just use 2 stereo
strips in that case, you can link the gains if that is essential (*).
I don't think it makes sense to say whether
"replicating a plugin" makes
sense or not, in general. Not the plugin's problem, in any case, the
plugin should just describe what it's I/O is. How clever the host wants
to be given that information is the host's problem (and depends on quite
a bit of host specific .
For a simple 'mono' plugin there are at least three different
cases to consider whem using it in a 'multichannel' situation;
1. A plugin that does e.g. EQ can be replicated without problem
for multichannel use - you expect the same processing on all
channels, the order doesn't matter, and the channels do not
interact.
2. The situation is already different for e.g. a compressor
or limiter. In that case you would expect the same gain profile
on all channels, probably determined (but not always) by the one
with the highest level. In other words the channels *do* interact.
3. Polyphonic synthesis is again different situation, the voices
would share some control inputs but not all, and many of the voices
could be 'inactive' most of the time - a case that invites some
optimisation.
Clearly at least (2) requires the plugin to be aware of the situation,
and to be designed to handle it. That in turn is possible only if the
plugin interface can represent this case. But also case (1) would
benefit from being aware of the multichannel use: in many cases the
bulk of the work is not the real signal processing but things like
limiting the rate of change of parameters, computing and interpolating
internal parameter values etc. and all of that can be shared if the
plugin standard is designed for it. It's not possible to 'retrofit'
this to existing mono plugins by an extension. And finally, a plugin
that would do the right thing in case (2) would fail if used in case
(3) - it again needs to be aware of being used in this role.
The fourth multichannel case would be things like Ambisonics,
where channels are not equivalent. This can be handled only by
plugins designed for these type of signals. They would probably
use special port types to indicate this. But at the same time a
simple mono EQ could be replicated safely to process even a 16-ch
AMB signal, so that should be possible even if the port types do
not match, and should not require special 'AMB equalisers'.
So the logic is not going to be as simple as just requiring the
same port types. Building this logic on top of a set of optional
extensions would seem to be a nightmare, and that is and always
has been my main objection to this approach.
(*) Ardour allows linking faders in groups, but it does not have
'VCA' faders - which is incredible since these are one of the
most useful feauters of almost all digital (and some analog)
mixers.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:10 p.m.
On 9/8/2009, "Fons Adriaensen" <fons(a)kokkinizita.net> wrote:
2. The situation is already different for e.g. a
compressor
or limiter. In that case you would expect the same gain profile
on all channels, probably determined (but not always) by the one
with the highest level. In other words the channels *do* interact.
...
Clearly at least (2) requires the plugin to be aware of
the situation,
and to be designed to handle it. That in turn is possible only if the
plugin interface can represent this case. But also case (1) would
benefit from being aware of the multichannel use: in many cases the
bulk of the work is not the real signal processing but things like
limiting the rate of change of parameters, computing and interpolating
internal parameter values etc. and all of that can be shared if the
plugin standard is designed for it. It's not possible to 'retrofit'
this to existing mono plugins by an extension. And finally, a plugin
that would do the right thing in case (2) would fail if used in case
(3) - it again needs to be aware of being used in this role.
some probably bad ideas:
rather than trying to get a number of instances of the same plugin
sharing data, is there any way for having a dynamic number of ports
created within one plugin depending on the context (noof channels) it is
placed in?
slightly different maybe if you've got 4 ins two outs some kind of
switchery for routing/mixing within the plugin [ and (i'm not sure this
is a good idea) the ability to handle connections (a port for a port)
to i/o s within a plugin (ie dropdown combo box etc to select the in to
use for this in or the out to use for that out in the plugin itself). ]
9:31 p.m.
On Sun, 2009-08-09 at 23:10 +0100, james morris wrote:
On 9/8/2009, "Fons Adriaensen"
<fons(a)kokkinizita.net> wrote:
That is almost certainly the way to go IMO. I see no advantage to
trying to make several separate instances of a single plugin work this
way, and it's quite a bit more complicated, and raises some ugly
realtime issues, and generally breaks the whole LADSPA/LV2 model when
you consider static/shared control ports and such. This way probably
has a ton of optimisation issues as well (bunch of process calls instead
of one, plugin code doesn't have direct access to all inputs/outputs,
etc. It's a mess)
Dynamic number of ports, though, is simpler, more efficient, fits well
with static/shared ports, and useful in cases other than this one (i.e.
we need it anyway). I can't think of any cons.
The way AU handles it is analogous to dynamic numbers of ports as well.
-dr
2. The situation is already different for e.g. a
compressor
or limiter. In that case you would expect the same gain profile
on all channels, probably determined (but not always) by the one
with the highest level. In other words the channels *do* interact.
...
Clearly at least (2) requires the plugin to be
aware of the situation,
and to be designed to handle it. That in turn is possible only if the
plugin interface can represent this case. But also case (1) would
benefit from being aware of the multichannel use: in many cases the
bulk of the work is not the real signal processing but things like
limiting the rate of change of parameters, computing and interpolating
internal parameter values etc. and all of that can be shared if the
plugin standard is designed for it. It's not possible to 'retrofit'
this to existing mono plugins by an extension. And finally, a plugin
that would do the right thing in case (2) would fail if used in case
(3) - it again needs to be aware of being used in this role.
some probably bad ideas:
rather than trying to get a number of instances of the same plugin
sharing data, is there any way for having a dynamic number of ports
created within one plugin depending on the context (noof channels) it is
placed in?
9:24 p.m.
On Sun, 2009-08-09 at 23:41 +0200, Fons Adriaensen wrote:
On Sun, Aug 09, 2009 at 04:39:01PM -0400, David
Robillard wrote:
I agree.
That said, yeah, replication for anything beyond
1 in 1 out is pretty
unlikely to make sense regardless; unless someone is using 4 outputs as
2 stereo pairs or something like that. Ideally we'll get to the point
where the user can specify they are doing so, so the automatic logic has
more to work with. It's a bit of a weird thing to do anyway, though...
Things like using 4 channels as 2 stereo pairs just shouldn't happen. > I don't think it makes sense to say whether
"replicating a plugin" makes
> sense or not, in general.
[...]
For a simple 'mono' plugin there are at least
three different
cases to consider whem using it in a 'multichannel' situation;
1. A plugin that does e.g. EQ can be replicated without problem
for multichannel use - you expect the same processing on all
channels, the order doesn't matter, and the channels do not
interact.
2. The situation is already different for e.g. a compressor
or limiter. In that case you would expect the same gain profile
on all channels, probably determined (but not always) by the one
with the highest level. In other words the channels *do* interact.
This is a good point I hadn't thought of. I think I will try to
incorporate this into the port groups extension (it describes how
channels interact, and basically anything else to do with multi-channel,
so it more or less belongs there...)
3. Polyphonic synthesis is again different situation,
the voices
would share some control inputs but not all, and many of the voices
could be 'inactive' most of the time - a case that invites some
optimisation.
Actually I would say this is exactly the same as situation 2, in terms
of I/O at least (e.g. active/inactive optimisation can be done inside
the (opaque) port contents, or similar, and must be anyway since it's
not necessarily related to dymamic number of channels)
Clearly at least (2) requires the plugin to be aware
of the situation,
and to be designed to handle it. That in turn is possible only if the
plugin interface can represent this case. But also case (1) would
benefit from being aware of the multichannel use: in many cases the
bulk of the work is not the real signal processing but things like
limiting the rate of change of parameters, computing and interpolating
internal parameter values etc. and all of that can be shared if the
plugin standard is designed for it. It's not possible to 'retrofit'
this to existing mono plugins by an extension. And finally, a plugin
that would do the right thing in case (2) would fail if used in case
(3) - it again needs to be aware of being used in this role.
This is dramatically more complicated than the simple cases for
replication. It is possible though, and very similar to what's needed
for true polyphony. Different scope though (i.e. involves a bunch of
binary stuff and severe design changes), see above about can of worms.
Most importantly, the information needed for the simple cases is needed
in any case (including ones that have nothing whatsoever to do with
replication... we need to know what the heck our plugins outputs are!).
In short what's needed is ports that can actually hold several buffers,
(where the number of which is dynamically configurable). I've actually
been planning on this one for a while because "hidden" (mixed down)
polyphony sucks severely in a modular, but never thought of it in terms
of replication. Interesting that it applies there too.
The fourth multichannel case would be things like
Ambisonics,
where channels are not equivalent. This can be handled only by
plugins designed for these type of signals. They would probably
use special port types to indicate this.
Currently handled. Not special ports, just collections of normal ports
with appropriate metadata (as it should be).
But at the same time a
simple mono EQ could be replicated safely to process even a 16-ch
AMB signal, so that should be possible even if the port types do
not match, and should not require special 'AMB equalisers'.
Yep. That kind of clever is up to the host though (or maybe proxy
plugins if you want to get really fancy, but let's not go there)
So the logic is not going to be as simple as just
requiring the
same port types.
No, but the information needed to solve the simple ladspa+metadata-esque
case is required anyway, and an orthogonal problem. Solving small
independent problems is good. Trying to solve everything at once fails.
Always. No exceptions.
To be clear, what I mean is: first and foremost, the host must know the
specifics of what ports are what. On top of this, dynamic replication
of ports can be done.
That said, one question comes to mind: are there reasonable cases where
different ports (or groups of ports) need different 'replication
factors'?
Building this logic on top of a set of optional
extensions would seem to be a nightmare, and that is and always
has been my main objection to this approach.
FUD, nothing more. It would be no more of a nightmare than implementing
it on top of... well, anything else; presumably you mean something
defined in "The LV2 Specification"(TM). No offense but I doubt you
really understand the mechanism judging by this comment. That
"nightmare" (a.k.a. "good design") is exactly what will allow all of
the
above to be solved. Proof is in the pudding, as they say.
-----
Aside: Since this seems to be misunderstood frequently, I'll harp on the
point a bit for the list in general (this is an explanation, not an
invitation to argument):
There is absolutely nothing second class, or (necessarily) optional,
about LV2 extensions. A lot of thought has been put in to the
extension/feature concept/mechanism, and it has been carefully designed
specifically so that it is not a "nightmare". Solving the above
problems in "extensions" is not worse than if we were to ram it into the
"core" spec itself. There is nothing inferior about it (wannabe
dictator arguments aside, anyway). There are many things superior about
it, however. The most important is social: nobody on this list needs to
be convinced that having one specification define absolutely everything
is a sure-fire way to have any potentially productive discussion devolve
into endlessly long threads that end up nowhere because nobody can agree
on what's "needed" and what isn't. Extensions are simply a
modularisation of this process: problems can be solved independently by
people who care about those particular problems. You can even work on
actual implementations of things to test them out without any
compatibility problems whatsoever. So, we have nice tidy little
tractable problems, that can feasibly be solved well (see: UNIX). The
end result is: the problems actually, really, can get solved.
Saying this is bad is essentially equivalent to saying design by
committee is good... modularisation like this is such a universally
recognized good design principle it's not really necessary to defend it.
UNIX won, and it's not a coincidence. GMPI has produced almost nothing
tangible of worth whatsoever, while LV2 has produced plenty and is
constantly getting better -- this is not a coincidence either.
Mmm, pudding.
Cheers,
-dr
P.S. To reply to the aside, please change the subject, I don't want to
derail the replication discussion; that is an important unsolved problem
10 Aug
10 Aug
6:26 a.m.
New subject: the role of lv2 extensions
David Robillard wrote:
i guess part of the irritation around (and possibly delayed endorsement
as compared to LADSPA) of lv2 stems from those "extensions".
from a design standpoint, i totally agree with all your points, and what
little i've so far grokked of lv2 looks very nice indeed. *but*: it's a
moving target, and few host authors have committed themselves to
implement those extensions.
the problem i see: the extensions mentioned on the lv2 website are of
very different maturity, it's absolutely not clear which of those should
be considered "canonical" and hence a *must-implement* feature, nor has
there been any public discussion about any canonical set of core
extensions (excuse that weird expression, but i can't think of anything
better).
crooked analogy alert... as it is now, lv2 resembles XML: you can do
anything in principle, but there is almost no common semantics. we
should move it to XHTML: define a set of mandatory extensions that
everybody can expect to work pretty much everywhere (to the extent that
it makes sense - i understand a synth host might have different
priorities than, say, ardour).
best,
jörn
Building this
logic on top of a set of optional
extensions would seem to be a nightmare, and that is and always
has been my main objection to this approach.
FUD, nothing more. It would be no more of a nightmare than implementing
it on top of... well, anything else; presumably you mean something
defined in "The LV2 Specification"(TM). No offense but I doubt you
really understand the mechanism judging by this comment. That
"nightmare" (a.k.a. "good design") is exactly what will allow all of
the
above to be solved. Proof is in the pudding, as they say.
-----
Aside: Since this seems to be misunderstood frequently, I'll harp on the
point a bit for the list in general (this is an explanation, not an
invitation to argument):
There is absolutely nothing second class, or (necessarily) optional,
about LV2 extensions. A lot of thought has been put in to the
extension/feature concept/mechanism, and it has been carefully designed
specifically so that it is not a "nightmare". Solving the above
problems in "extensions" is not worse than if we were to ram it into the
"core" spec itself. There is nothing inferior about it (wannabe
dictator arguments aside, anyway). There are many things superior about
it, however. The most important is social: nobody on this list needs to
be convinced that having one specification define absolutely everything
is a sure-fire way to have any potentially productive discussion devolve
into endlessly long threads that end up nowhere because nobody can agree
on what's "needed" and what isn't. Extensions are simply a
modularisation of this process: problems can be solved independently by
people who care about those particular problems. You can even work on
actual implementations of things to test them out without any
compatibility problems whatsoever. So, we have nice tidy little
tractable problems, that can feasibly be solved well (see: UNIX). The
end result is: the problems actually, really, can get solved.
7:41 a.m.
New subject: the role of lv2 extensions
On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn Nettingsmeier wrote:
from a design standpoint, i totally agree with all
your points, and what
little i've so far grokked of lv2 looks very nice indeed. *but*: it's a
moving target, and few host authors have committed themselves to
implement those extensions.
the problem i see: the extensions mentioned on the lv2 website are of
very different maturity, it's absolutely not clear which of those should
be considered "canonical" and hence a *must-implement* feature, nor has
there been any public discussion about any canonical set of core
extensions (excuse that weird expression, but i can't think of anything
better).
crooked analogy alert... as it is now, lv2 resembles
XML: you can do
anything in principle, but there is almost no common semantics. we
should move it to XHTML: define a set of mandatory extensions that
everybody can expect to work pretty much everywhere (to the extent that
it makes sense - i understand a synth host might have different
priorities than, say, ardour).
The evolutive process described and advocated by Dave is
certainly one that can work - it is the way e.g. natural
languages get defined and change over time. It's also why
they tend to be inconsistent and why you need to study a
lot more grammar than would be required otherwise.
This should be compared to the (in most cases) quite
consistent syntax of computer programming languages.
And in the end, a plugin interface is a language that
has to be understood by both the host and the plugin.
Regarding the replication problem ("How to structure
a basic mono plugin, its host and their interaction so
the plugin can be used in a variety of multichannel
contexts having different requirements"), this is
something that can be and IMHO should be analysed
in a systematic way.
I'm just wearing my mathematician's hat of course.
It boils down to graph theory, the way an algorithm
can be split up and the order in which some steps must
be performed. As as simple example the multichannel
limiter must see all inputs before it can produce the
first output, while an EQ would not require this.
Things get mildly more complex if you also consider
parallel execution, but this still can be analysed.
Given a number of reasonable constraints this leads
to a finite number of possible processing graphs,
and these can be decribed in a systematic way. Any
plugin interface should IMHO reflect this systematic
nature, and not be a collection of ad-hoc solutions
to partial problems and special cases.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:49 a.m.
New subject: the role of lv2 extensions
On 10 Aug 2009, at 10:41, Fons Adriaensen wrote:
On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn
Nettingsmeier wrote:
Sure. The original intention was that LV2 1.x would "bless" certain
extensions as being required for that version, but that's not been
necessary so far.
from a design standpoint, i totally agree with
all your points, and
what
little i've so far grokked of lv2 looks very nice indeed. *but*:
it's a
moving target, and few host authors have committed themselves to
implement those extensions.
the problem i see: the extensions mentioned on the lv2 website are of
very different maturity, it's absolutely not clear which of those
should
be considered "canonical" and hence a *must-implement* feature, nor
has
there been any public discussion about any canonical set of core
extensions (excuse that weird expression, but i can't think of
anything
better).
crooked analogy alert... as it is now, lv2
resembles XML: you can do
anything in principle, but there is almost no common semantics. we
should move it to XHTML: define a set of mandatory extensions that
everybody can expect to work pretty much everywhere (to the extent
that
it makes sense - i understand a synth host might have different
priorities than, say, ardour).
The evolutive process described and advocated by Dave is
certainly one that can work - it is the way e.g. natural
languages get defined and change over time. It's also why
they tend to be inconsistent and why you need to study a
lot more grammar than would be required otherwise. This should be compared to the (in most cases) quite
consistent syntax of computer programming languages.
And in the end, a plugin interface is a language that
has to be understood by both the host and the plugin.
Or at least some of it does. There are some (many?) cases where a
plugin is still fully usable by the host, even if it doesn't
comprehend the extension. Port groups is an example of this.
- Steve
1:57 p.m.
New subject: the role of lv2 extensions
On Mon, 2009-08-10 at 11:48 +0100, Steve Harris wrote:
On 10 Aug 2009, at 10:41, Fons Adriaensen wrote:
That extensions can be mandatory for both/either the host and the plugin
makes this unnecessary IMO. This is mostly a social/documentation
problem, that should be solved in social/documentation ways, via the
website.
The core should stay as simple as possible, anyway. If nothing else it
doesn't bump the revision number for no reason and force everyone to
scramble to check if anything has broken, deal with packager delay, etc.
-dr
The evolutive process described and advocated by
Dave is
certainly one that can work - it is the way e.g. natural
languages get defined and change over time. It's also why
they tend to be inconsistent and why you need to study a
lot more grammar than would be required otherwise.
Sure. The original intention was that LV2 1.x would "bless" certain
extensions as being required for that version, but that's not been
necessary so far.
1:52 p.m.
New subject: the role of lv2 extensions
On Mon, 2009-08-10 at 11:41 +0200, Fons Adriaensen wrote:
On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn
Nettingsmeier wrote:
In this domain, it seems pretty clear it's the only one that works...
Consistency problems are simple to deal with, e.g. lv2plug.in can
provide a nice centralized list of extensions and documentation if they
fit certain guidelines. There is a page working towards these here:
http://lv2plug.in/docs/index.php?title=Extension_Conventions
As with everything else, it's not a problem with the tech, it's just
work that somebody needs to do. Welcome to free software. People
whining about the decentralized nature are really just whining that
someone else hasn't done it for them ;)
If you want to be able to point a finger and blame a dictator for
something being crap, use VST.
crooked analogy alert... as it is now, lv2
resembles XML: you can do
anything in principle, but there is almost no common semantics. we
should move it to XHTML: define a set of mandatory extensions that
everybody can expect to work pretty much everywhere (to the extent that
it makes sense - i understand a synth host might have different
priorities than, say, ardour).
The evolutive process described and advocated by Dave is
certainly one that can work - it is the way e.g. natural
languages get defined and change over time. It's also why
they tend to be inconsistent and why you need to study a
lot more grammar than would be required otherwise. This should be compared to the (in most cases) quite
consistent syntax of computer programming languages.
And in the end, a plugin interface is a language that
has to be understood by both the host and the plugin.
And the primary design goal of virtually all languages is to allow
modular decomposition of functionality. Hmmm...
Would a language with no encapsulation (including user defined
functions) and only keywords be a good language? You can't define
everything that you do with a language in the language itself (for a
sufficiently powerful language). Similarly, you can't define everything
that you do with a plugin in the plugin spec itself (for a sufficiently
powerful plugin spec).
A good language defines a simple and consistent framework on which
you /can/ build whatever you want. This is precisely what LV2 does.
Extensions are analogous to modules/objects/abstract interfaces
(depending on language).
Any language worth using has a comparable mechanism. LADSPA, for
example, doesn't, which is exactly why LADSPA is as weak as it was
nearly 10 years ago when it was designed. LV2 currently is a heck of a
lot more powerful than it was when it was designed, and gets better all
the time. The reason for this is precisely that it was designed to
provide a basic framework that can be extended, and not defining
absolutely everything up front (which would have failed outright).
There's not much sense in arguing about the merits of it at this point,
look at reality.
Regarding the replication problem ("How to
structure
a basic mono plugin, its host and their interaction so
the plugin can be used in a variety of multichannel
contexts having different requirements"), this is
something that can be and IMHO should be analysed
in a systematic way.
I'm just wearing my mathematician's hat of course.
It suits you more :)
Of course it should be analysed in a systematic way. If you think this
is in conflict with extensions, you are very mistaken. Being able to
sit down and tackle this problem on its own is the whole point!
It boils down to graph theory, the way an algorithm
can be split up and the order in which some steps must
be performed. As as simple example the multichannel
limiter must see all inputs before it can produce the
first output, while an EQ would not require this.
Things get mildly more complex if you also consider
parallel execution, but this still can be analysed.
Given a number of reasonable constraints this leads
to a finite number of possible processing graphs,
and these can be decribed in a systematic way. Any
plugin interface should IMHO reflect this systematic
nature, and not be a collection of ad-hoc solutions
to partial problems and special cases.
Mathematician's don't usually wave their hands quite this much ;)
The plugin obviously does know about all its inputs (or is free to
ignore some). LV2 does reflect this systematic nature, because all I/O
is still based on ports. This is the reason mentioned earlier why using
multiple instances for this is wrong.
Re: the hand-wavey FUD bit: they are not partial problems or special
cases, they are complete, independent problems. Again, this is straight
out of good design 101. SOMETIMES functionality is relatively large and
intertwined, in which case the extension for it would also be large and
encompass a lot (in the other direction, yes, an extension that solves a
partial problem or a bunch of special cases is also crap). In these
cases, there will be a sound logical argument why things need to be
combined in the same extension. Doing things this way without that
sound logical argument is simply textbook crap design.
There may even be an argument for something going in the "core" spec.
This is extremely, extremely unlikely, but it's possible. Big deal, we
release another revision. It's happened before (minor stuff), it will
happen again, nothing breaks. Again, without the logical argument for
doing so, it's just swingin' hands. The sky is not falling.
Coming up with those arguments = productive discussion, gets things done
Flinging FUD about extensions = worthless noise
You can consider LV2 itself a "work in progress" and all work on
extensions "part of the LV2 committee" or whatever if you like. There
is no difference. The work in progress just happens to be useful and
working right now.
I don't think anyone can claim with a straight face the fact that we
have working plugins with MIDI, and GUIs (both embedded and separate
process), and presets, and dynamic plugin wrapping, and (etc etc etc) is
a bad thing. Pudding.
Anyway, to bring this silliness back into the realm of concrete useful
things, replication in basic form is pretty straightforward: the host
needs a way to pass a 'replication factor' to the plugin. This raises a
few obvious questions:
- Should changing this at run-time be possible? This is more useful
with polyphony than with replication for multi-channel purposes. This
raises nasty realtime issues, but since buffer allocation is the host's
problem and a clever host could possibly do it, I think the spec should
make this possible. Maybe there are problems with internal plugin data
that needs to replicate as well but in a non-realtime way though?
- Do different ports/groups need different replication factors?
- Does the plugin need to be able to refuse a factor dynamically, or can
acceptable ranges just be defined in the data? (latter is better unless
there's a compelling reason for the former)
Cheers,
-dr
1:02 p.m.
New subject: the role of lv2 extensions
On Mon, 2009-08-10 at 10:26 +0200, Jörn Nettingsmeier wrote:
i guess part of the irritation around (and possibly
delayed endorsement
as compared to LADSPA) of lv2 stems from those "extensions".
from a design standpoint, i totally agree with all your points, and what
little i've so far grokked of lv2 looks very nice indeed. *but*: it's a
moving target, and few host authors have committed themselves to
implement those extensions.
the problem i see: the extensions mentioned on the lv2 website are of
very different maturity, it's absolutely not clear which of those should
be considered "canonical" and hence a *must-implement* feature, nor has
there been any public discussion about any canonical set of core
extensions (excuse that weird expression, but i can't think of anything
better).
This is a problem with the site, not the tech/spec. I very much agree
the site needs work. We need to install a CMS and have a more community
driven site etc. Anyone who wants to help out with this, please do...
I have been working on automatic documentation generation for
specifications to address part of this problem. This page is generated
automatically from the port groups schema, for example:
http://lv2plug.in/ns/dev/port-groups.lv2/port-groups.html
crooked analogy alert... as it is now, lv2 resembles
XML: you can do
anything in principle, but there is almost no common semantics. we
should move it to XHTML: define a set of mandatory extensions
"mandatory" in this top-down dictatorial sense is not useful. Plugins
or hosts can make things mandatory if they want.
that
everybody can expect to work pretty much everywhere (to the extent that
it makes sense - i understand a synth host might have different
priorities than, say, ardour)
Exactly. If some things don't work, then they inherently don't work.
It would be no different if the various features were all defined in a
single spec.
There is no problem with things not working. Hosts that don't support
e.g. dynamic polyphony .... well, don't support dynamic polyphony. A
well-written plugin gracefully degrades anyway, most extensions make
this possible.
Cheers,
-dr
2:05 p.m.
New subject: LV2 port groups (was: Re: the role of lv2 extensions)
On Mon, 2009-08-10 at 11:02 -0400, David Robillard wrote:
P.S. Comments on this from anyone with experience in multi-channel stuff
would be appreciated if there's any problems.
It's being used to support proper multi-channel streams for LV2 in
GStreamer (work in progress), in keeping with the theme of getting along
better with them desktop guys :)
Personally I would like to see this sort of metadata get exposed at the
JACK level quite a bit (e.g. so things can do auto-connect logically).
All we'd need is a key/value system...
Cheers,
-dr
16 Aug
16 Aug
2:27 p.m.
New subject: LV2 port groups
David Robillard wrote:
On Mon, 2009-08-10 at 11:02 -0400, David Robillard
wrote:
P.S. Comments on this from anyone with experience in multi-channel stuff
would be appreciated if there's any problems.
It's being used to support proper multi-channel streams for LV2 in
GStreamer (work in progress), in keeping with the theme of getting along
better with them desktop guys :)
Personally I would like to see this sort of metadata get exposed at the
JACK level quite a bit (e.g. so things can do auto-connect logically).
All we'd need is a key/value system...
is anybody using this yet? if not, can i suggest that the ambisonic
groups be renamed to #H#P, and that #H#V be reserved to that new scheme
introduced by travis, as explained in another mail?
3:02 p.m.
New subject: LV2 port groups
On Sun, 2009-08-16 at 18:27 +0200, Jörn Nettingsmeier wrote:
David Robillard wrote:
(The "re-use" of #H#V there seems crazy to me... (re: your other email))
Anyway, no, nobody is using this yet. I'm really just defining things
at this point so future stuff that needs it can use it easily and get
along. First thing's first and all that.
I will name the groups (multi-channel) H#P. I suppose I should use e.g.
acn1Channel rather than wChannel for the roles (single channel) too...
Cheers,
-dr
On Mon, 2009-08-10 at 11:02 -0400, David
Robillard wrote:
P.S. Comments on this from anyone with experience in multi-channel stuff
would be appreciated if there's any problems.
It's being used to support proper multi-channel streams for LV2 in
GStreamer (work in progress), in keeping with the theme of getting along
better with them desktop guys :)
Personally I would like to see this sort of metadata get exposed at the
JACK level quite a bit (e.g. so things can do auto-connect logically).
All we'd need is a key/value system...
is anybody using this yet? if not, can i suggest that the ambisonic
groups be renamed to #H#P, and that #H#V be reserved to that new scheme
introduced by travis, as explained in another mail?
3:22 p.m.
New subject: LV2 port groups
David Robillard wrote:
On Sun, 2009-08-16 at 18:27 +0200, Jörn Nettingsmeier
wrote:
yes. with all that rdf magic, is it possible to include a pointer to
http://ambisonics.ch/standards/channels/ directly in the spec?
David Robillard wrote:
(The "re-use" of #H#V there seems crazy to me... (re: your other email))
Anyway, no, nobody is using this yet. I'm really just defining things
at this point so future stuff that needs it can use it easily and get
along. First thing's first and all that.
I will name the groups (multi-channel) H#P. I suppose I should use e.g.
acn1Channel rather than wChannel for the roles (single channel) too... On Mon, 2009-08-10 at 11:02 -0400, David
Robillard wrote:
P.S. Comments on this
from anyone with experience in multi-channel stuff
would be appreciated if there's any problems.
It's being used to support proper multi-channel streams for LV2 in
GStreamer (work in progress), in keeping with the theme of getting along
better with them desktop guys :)
Personally I would like to see this sort of metadata get exposed at the
JACK level quite a bit (e.g. so things can do auto-connect logically).
All we'd need is a key/value system...
is anybody using this yet? if not, can
i suggest that the ambisonic
groups be renamed to #H#P, and that #H#V be reserved to that new scheme
introduced by travis, as explained in another mail?
5:10 p.m.
New subject: LV2 port groups
On Sun, 2009-08-16 at 19:22 +0200, Jörn Nettingsmeier wrote:
David Robillard wrote:
Good point. They actually have existing URIs for each channel, e.g.
http://ambisonics.ch/standards/channels/ACN3
I could maybe just use these directly as the URI for the channels... how
stable is this URI scheme?
(I'll work in links either way, excellent documentation...)
Thanks,
-dr
On Sun, 2009-08-16 at 18:27 +0200, Jörn
Nettingsmeier wrote:
yes. with all that rdf magic, is it possible to include a pointer to
http://ambisonics.ch/standards/channels/ directly in the spec? David Robillard wrote:
(The "re-use" of #H#V there seems crazy to me... (re: your other email))
Anyway, no, nobody is using this yet. I'm really just defining things
at this point so future stuff that needs it can use it easily and get
along. First thing's first and all that.
I will name the groups (multi-channel) H#P. I suppose I should use e.g.
acn1Channel rather than wChannel for the roles (single channel) too... On Mon, 2009-08-10 at 11:02 -0400, David
Robillard wrote:
> http://lv2plug.in/ns/dev/port-groups.lv2/port-groups.html
P.S. Comments on this from anyone with experience in multi-channel stuff
would be appreciated if there's any problems.
It's being used to support proper multi-channel streams for LV2 in
GStreamer (work in progress), in keeping with the theme of getting along
better with them desktop guys :)
Personally I would like to see this sort of metadata get exposed at the
JACK level quite a bit (e.g. so things can do auto-connect logically).
All we'd need is a key/value system...
is anybody using this yet? if not, can
i suggest that the ambisonic
groups be renamed to #H#P, and that #H#V be reserved to that new scheme
introduced by travis, as explained in another mail?
5:17 p.m.
New subject: LV2 port groups
michael, there are plans to implement the ACN/SN3D scheme in the LV2
plugin standard.
since it's based on rdf, the question is whether it might feasible to
use the URLs for each ACN on ambisonics.ch as unique identifiers (which
would be quite elegant and point users right to the relevant
documentation).
however, that would depend on whether you could guarantee stability of
said URL space. a short excerpt of the preceding discussion is quoted
below. please maintain the cc: list when replying.
best,
jörn
David Robillard wrote:
On Sun, 2009-08-16 at 19:22 +0200, Jörn Nettingsmeier
wrote:
David Robillard wrote:
Good point. They actually have existing URIs for each channel, e.g.
http://ambisonics.ch/standards/channels/ACN3
I could maybe just use these directly as the URI for the channels... how
stable is this URI scheme?
(I'll work in links either way, excellent documentation...)
Thanks,
-dr
On Sun, 2009-08-16 at 18:27 +0200, Jörn
Nettingsmeier wrote:
yes. with
all that rdf magic, is it possible to include a pointer to
http://ambisonics.ch/standards/channels/ directly in the spec? David Robillard wrote:
> On Mon, 2009-08-10 at 11:02 -0400, David Robillard wrote:
>> http://lv2plug.in/ns/dev/port-groups.lv2/port-groups.html
> P.S. Comments on this from anyone with experience in multi-channel stuff
> would be appreciated if there's any problems.
>
> It's being used to support proper multi-channel streams for LV2 in
> GStreamer (work in progress), in keeping with the theme of getting along
> better with them desktop guys :)
>
> Personally I would like to see this sort of metadata get exposed at the
> JACK level quite a bit (e.g. so things can do auto-connect logically).
> All we'd need is a key/value system...
is anybody using this yet? if not, can i suggest that the ambisonic
groups be renamed to #H#P, and that #H#V be reserved to that new scheme
introduced by travis, as explained in another mail?
(The "re-use" of
#H#V there seems crazy to me... (re: your other email))
Anyway, no, nobody is using this yet. I'm really just defining things
at this point so future stuff that needs it can use it easily and get
along. First thing's first and all that.
I will name the groups (multi-channel) H#P. I suppose I should use e.g.
acn1Channel rather than wChannel for the roles (single channel) too...
5:47 p.m.
New subject: LV2 port groups
On Sun, 2009-08-16 at 21:17 +0200, Jörn Nettingsmeier wrote:
michael, there are plans to implement the ACN/SN3D
scheme in the LV2
plugin standard.
since it's based on rdf, the question is whether it might feasible to
use the URLs for each ACN on ambisonics.ch as unique identifiers (which
would be quite elegant and point users right to the relevant
documentation).
however, that would depend on whether you could guarantee stability of
said URL space. a short excerpt of the preceding discussion is quoted
below. please maintain the cc: list when replying.
The stream descriptions could use them as well if there were URIs such
as:
http://ambisonics.ch/standards/filetypes/h1v1
instead of:
http://ambisonics.ch/standards/filetypes/f
or better, http://ambisonics.ch/standards/streams/f if I can nitpick :)
-dr
5:22 p.m.
New subject: LV2 port groups
On Sun, 2009-08-16 at 19:22 +0200, Jörn Nettingsmeier wrote:
David Robillard wrote:
Should the order of channels within a group (which mustn't have gaps)
just match the ACN order? This is different from FuMa.
e.g. directly substituting names gets you something like:
AmbisonicBH1P1Group
"Ambisonic B stream of horizontal order 1 and peripheral order 1."
0: ACN0 (formerly w)
1: ACN3 (formerly x)
2: ACN1 (formerly y)
3: ACN2 (formerly z)
Should this be:
0: ACN0
1: ACN1
2: ACN2
3: ACN3
(No gaps in this case, but H2P0 has channels(*) 0 3 1 8 4, so I'm
asking...)
Thanks,
-dr
(* Unless something's been nuked in the munging)
On Sun, 2009-08-16 at 18:27 +0200, Jörn
Nettingsmeier wrote:
yes. with all that rdf magic, is it possible to include a pointer to
http://ambisonics.ch/standards/channels/ directly in the spec? David Robillard wrote:
(The "re-use" of #H#V there seems crazy to me... (re: your other email))
Anyway, no, nobody is using this yet. I'm really just defining things
at this point so future stuff that needs it can use it easily and get
along. First thing's first and all that.
I will name the groups (multi-channel) H#P. I suppose I should use e.g.
acn1Channel rather than wChannel for the roles (single channel) too... On Mon, 2009-08-10 at 11:02 -0400, David
Robillard wrote:
> http://lv2plug.in/ns/dev/port-groups.lv2/port-groups.html
P.S. Comments on this from anyone with experience in multi-channel stuff
would be appreciated if there's any problems.
It's being used to support proper multi-channel streams for LV2 in
GStreamer (work in progress), in keeping with the theme of getting along
better with them desktop guys :)
Personally I would like to see this sort of metadata get exposed at the
JACK level quite a bit (e.g. so things can do auto-connect logically).
All we'd need is a key/value system...
is anybody using this yet? if not, can
i suggest that the ambisonic
groups be renamed to #H#P, and that #H#V be reserved to that new scheme
introduced by travis, as explained in another mail?
5:28 p.m.
New subject: LV2 port groups
On Sun, 2009-08-16 at 15:22 -0400, David Robillard wrote:
Should the order of channels within a group (which
mustn't have gaps)
just match the ACN order? This is different from FuMa.
e.g. directly substituting names gets you something like:
AmbisonicBH1P1Group
"Ambisonic B stream of horizontal order 1 and peripheral order 1."
0: ACN0 (formerly w)
1: ACN3 (formerly x)
2: ACN1 (formerly y)
3: ACN2 (formerly z)
Should this be:
0: ACN0
1: ACN1
2: ACN2
3: ACN3
(No gaps in this case, but H2P0 has channels(*) 0 3 1 8 4, so I'm
asking...)
Once again replying to myself (done with this soon, promise :])
Found this: http://ambisonics.ch/standards/filetypes/contents
I assume in order makes the most sense, random order derived from FuMa
can't be sane
-dr
5:36 p.m.
New subject: LV2 port groups
David Robillard wrote:
On Sun, 2009-08-16 at 15:22 -0400, David Robillard
wrote:
yes.
gaps are also ok for mixed order, but in all cases the components should
be ordered by ascending ACN.
Should the order of channels within a group
(which mustn't have gaps)
just match the ACN order? This is different from FuMa.
e.g. directly substituting names gets you something like:
AmbisonicBH1P1Group
"Ambisonic B stream of horizontal order 1 and peripheral order 1."
0: ACN0 (formerly w)
1: ACN3 (formerly x)
2: ACN1 (formerly y)
3: ACN2 (formerly z)
Should this be:
0: ACN0
1: ACN1
2: ACN2
3: ACN3
(No gaps in this case, but H2P0 has channels(*) 0 3 1 8 4, so I'm
asking...)
Once again replying to myself (done with this soon, promise :])
Found this: http://ambisonics.ch/standards/filetypes/contents
I assume in order makes the most sense, random order derived from FuMa
can't be sane
5:45 p.m.
New subject: LV2 port groups
On Sun, Aug 16, 2009 at 03:22:52PM -0400, David Robillard wrote:
Should the order of channels within a group (which
mustn't have gaps)
just match the ACN order? This is different from FuMa.
Dave, as I'm reading your post I'm preparing some notes on
AMB technicalities, including order and naming schemes.
You should have them latest tomorrow morning (my local time,
which is UTC+ 2).
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
9 Aug
9 Aug
5:47 p.m.
On Sun, Aug 09, 2009 at 01:52:21PM -0400, Paul Davis wrote:
In this case there shouldn't be a problem as channel counts match.
And Ardour *does* the right thing in the inverse case - more outs
than ins. Since Ardour seems to check channel counts before letting
you insert a plugin, it can't really be that it is unaware of them.
If channel counts don't match, the way to go seems to be:
Step 1. See if it makes sense to replicate the plugin. Probably
yes if it is one in, one out, no in all other cases. If so replicate
it. Else insert one instance.
Step 2. At each interface:
- more sources than destinations -> drop the extra sources
- more destinations than sources -> feed them zeros.
Adding signals doesn't make much sense, if the user wants it
he should say so (by inserting a plugin that does it).
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
wrong maiing list, really. but continuing on ...
Mmm, I'd assume that there are *some* people on LAD using Ardour,
including the devs...
I have an
ardour mixer strip with 4 input and 2 outputs,
and insert (post-fader) a plugin which has 4 inputs (A,B,C,D)
and two outputs (X,Y).
The signals at the output of the strip seem to be
X + C + D and Y + C + D instead of X and Y.
Is this 'documented behaviour', and if yes what
purpose does it serve ?
its certainly not documented, but not much is. it doesn't serve any
purpose other than being one of the several approaches one could take
with this somewhat unusual (but certainly not wrong) i/o
configuration. basically, ardour has the concept of "data streams"
within the signal processing route. imagine the situation *without*
the plugin for a moment: what happens to the "extra" data streams C &
D that don't obviously map to the outputs? executive decision: add
them to the outputs (and do it badly, by adding C *and* D to both
outputs, just for good measure). add the plugin to the situation ....
presumably ardour should know that there are now really just two data
streams post-plugin and that nothing needs to be done. but it appears
that it doesn't discover this, and this may be intentional but more
likely is just a bug.
5527
days inactive
5534
days old
linux-audio-dev@lists.linuxaudio.org
26 comments
6 participants
participants (6)
-
David Robillard -
Fons Adriaensen -
james morris -
Jörn Nettingsmeier -
Paul Davis -
Steve Harris