23 Jan
2007
23 Jan
'07
4:46 a.m.
On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote:
2007/1/22, Dmitry Baikov <dsbaikov(a)gmail.com>om>:
This works fine, and was in the design brief for LV2. When asked what
effects your LV2 plugin supports, you can return a list.
On 1/23/07, Stefano D'Angelo
<zanga.mail(a)gmail.com> wrote:
That could be a very wise solution, but there's one big problem with
it: when you load a LV2 plugin, you load only one plugin!
To be clearer I make an example: I have 10 VST plugin, and I want to
write a LV2 plugin which loads VST plugins. When the LV2-aware
application asks me which plugin I want to load I should specify the
VST plugin loader... but then? There's no way for my LV2 plugin to
determine which VST plugin it should load. Good point! This is true, but there are lots of
sound processing
plugins around, so maybe instead of creating a new API and then
apply
some "compatibility layer", it should
be better to create a
wrapping
tool natively. I think it should be also easier
to expand.
Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA
and anything you want.
Or if you want something not possible with LV2, write an extension
proposal.
I think LV2 was designed as a very extendable API.
If it is not, in your opinion, then help the guys to improve it. But also if this is an overcomeable problem, for each
VST plugin I
load I have to waste memory space with a new instance of the LV2 VST
loader plugin.
No you don't. A LV2 VST loader would be a single shared object, so
the OS would only load one instance of it.
Then, it is quite absurde from the user point of view
to open a plugin
which lets you open other plugins... it's just illogical!
It doesn't look like that to the user, they will just see a list of
plugins, some of which will be VST and some will not be. Have you
tried the DSSI VST reflector? It would work the same as that.
Don't misunderstand me, LV2 is great, I think that
it's the best
processing architecture out there, but it's designed with a 1:1
relationship in mind (one plugin = one effect). That's absolutely not
an LV2 weakness, it just does its job and nothing else (as it should
be).
You need to read the spec again.
The terminology is confused, not least in the spec documents, but a
single .lv2 "plugin" can host multiple effects with different ports
and so on.
- Steve
23 Jan
23 Jan
8:17 a.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
2007/1/23, Steve Harris <steve(a)plugin.org.uk>uk>:
On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote:
Oops... seems like I'm a bit confused! Well, I'm going to reread the
LV2 spec and try to figure out how to manage this kind of situations.
Sorry for wasting your time!
Sincerely,
Stefano
2007/1/22, Dmitry Baikov
<dsbaikov(a)gmail.com>om>:
This works fine, and was in the design brief for LV2. When asked what
effects your LV2 plugin supports, you can return a list.
On 1/23/07, Stefano D'Angelo
<zanga.mail(a)gmail.com> wrote:
That could be a very wise solution, but there's one big problem with
it: when you load a LV2 plugin, you load only one plugin!
To be clearer I make an example: I have 10 VST plugin, and I want to
write a LV2 plugin which loads VST plugins. When the LV2-aware
application asks me which plugin I want to load I should specify the
VST plugin loader... but then? There's no way for my LV2 plugin to
determine which VST plugin it should load. Good point! This is true, but there are lots of
sound processing
plugins around, so maybe instead of creating a new API and then
apply
some "compatibility layer", it should
be better to create a
wrapping
tool natively. I think it should be also easier
to expand.
Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA
and anything you want.
Or if you want something not possible with LV2, write an extension
proposal.
I think LV2 was designed as a very extendable API.
If it is not, in your opinion, then help the guys to improve it. But also if this is an overcomeable problem, for
each VST plugin I
load I have to waste memory space with a new instance of the LV2 VST
loader plugin.
No you don't. A LV2 VST loader would be a single shared object, so
the OS would only load one instance of it.
Then, it is quite absurde from the user point of
view to open a plugin
which lets you open other plugins... it's just illogical!
It doesn't look like that to the user, they will just see a list of
plugins, some of which will be VST and some will not be. Have you
tried the DSSI VST reflector? It would work the same as that.
Don't misunderstand me, LV2 is great, I think
that it's the best
processing architecture out there, but it's designed with a 1:1
relationship in mind (one plugin = one effect). That's absolutely not
an LV2 weakness, it just does its job and nothing else (as it should
be).
You need to read the spec again.
The terminology is confused, not least in the spec documents, but a
single .lv2 "plugin" can host multiple effects with different ports
and so on.
- Steve
9:04 a.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote:
Not at all, at the very least it points out that the LV2 spec needs
to be clearer, and probably needs better examples.
- Steve
You need to read the spec again.
The terminology is confused, not least in the spec documents, but a
single .lv2 "plugin" can host multiple effects with different ports
and so on.
- Steve
Oops... seems like I'm a bit confused! Well, I'm going to reread the
LV2 spec and try to figure out how to manage this kind of situations.
Sorry for wasting your time!
9:19 a.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
2007/1/23, Steve Harris <steve(a)plugin.org.uk>uk>:
On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote:
Not at all, at the very least it points out that the LV2 spec needs
to be clearer, and probably needs better examples.
- Steve
Well, maybe it's because I'm not very good at English :-)
However I have another question: how would a LV2 VST loader plugin
could communicate to the host a VST plugin info? This could be done
only via an extension?
Then, if I understood correctly, such LV2 VST loader plugin, when
asked for effects, should return a list of all effects of all VST
plugins it knows about?
Stefano
You need to read the spec again.
The terminology is confused, not least in the spec documents, but a
single .lv2 "plugin" can host multiple effects with different ports
and so on.
- Steve
Oops... seems like I'm a bit confused! Well, I'm going to reread the
LV2 spec and try to figure out how to manage this kind of situations.
Sorry for wasting your time!
10:40 a.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 23 Jan 2007, at 13:19, Stefano D'Angelo wrote:
2007/1/23, Steve Harris <steve(a)plugin.org.uk>uk>:
That's the slightly tricky part, the VST reflector would have to
generate an RDF file describing all the VST plugins it knows about.
That will work fine, and is not particularly difficult, but it could
be made slicker with an extension that allowed the VST reflector to
generate that file dynamically.
On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote:
the
Well, maybe it's because I'm not very good at English :-)
However I have another question: how would a LV2 VST loader plugin
could communicate to the host a VST plugin info? This could be done
only via an extension? >
> You need to read the spec again.
>
> The terminology is confused, not least in the spec documents,
but a
> single .lv2 "plugin" can host
multiple effects with different
ports
and so
on.
- Steve
Oops... seems like I'm a bit confused! Well, I'm going to reread LV2 spec and try to figure out how to manage this
kind of
situations.
Sorry for wasting your time!
Not at all, at the very least it points out that the LV2 spec needs
to be clearer, and probably needs better examples.
- Steve
Then, if I understood correctly, such LV2 VST loader
plugin, when
asked for effects, should return a list of all effects of all VST
plugins it knows about?
Yes, it can just return the URIs of all the installed VST effects as
return values of the lv2_descriptor() calls. The host calls it
repeatedly until it's found all the effects.
- Steve
12:14 p.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
2007/1/23, Steve Harris <steve(a)plugin.org.uk>uk>:
On 23 Jan 2007, at 13:19, Stefano D'Angelo wrote:
Just some last questions and I'll stop shouting and fooling around :-)
This issue should also have been faced with vstserver, fst and so, but
I never used them, so I'm just asking (I'm doing all of these because
I'm working on a DSP program): how would a LV2 VST loader handle VST
plugins with various effects, banks and programs, expecially in the
case (if any and/or possible) where such plugin makes some fades when
changing while playing (real-time processing)?
Then... I see in VST docs that a getInputLatency and getOutputLatency
functions are defined. I think that these could be used as extensions
on a LV2 host, but such values are to be trusted under wine?
And what about the combination of LASH and VST storing system?
Anyway, thanks a lot!
Regards,
Stefano
2007/1/23, Steve Harris
<steve(a)plugin.org.uk>uk>:
That's the slightly tricky part, the VST reflector would have to
generate an RDF file describing all the VST plugins it knows about.
That will work fine, and is not particularly difficult, but it could
be made slicker with an extension that allowed the VST reflector to
generate that file dynamically.
On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote:
Well, maybe it's because I'm not very good at English :-)
However I have another question: how would a LV2 VST loader plugin
could communicate to the host a VST plugin info? This could be done
only via an extension? >
> You need to read the spec again.
>
> The terminology is confused, not least in the spec documents,
but a
> single .lv2 "plugin" can host
multiple effects with different
ports
> and so on.
>
> - Steve
>
Oops... seems like I'm a bit confused! Well, I'm going to reread
the
LV2 spec and try to figure out how to manage this
kind of
situations.
Sorry for wasting your time!
Not at all, at the very least it points out that the LV2 spec needs
to be clearer, and probably needs better examples.
- Steve
Then, if I understood correctly, such LV2 VST
loader plugin, when
asked for effects, should return a list of all effects of all VST
plugins it knows about?
Yes, it can just return the URIs of all the installed VST effects as
return values of the lv2_descriptor() calls. The host calls it
repeatedly until it's found all the effects.
- Steve
12:32 p.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 23 Jan 2007, at 16:14, Stefano D'Angelo wrote:
Just some last questions and I'll stop shouting and fooling around :-)
This issue should also have been faced with vstserver, fst and so, but
I never used them, so I'm just asking (I'm doing all of these because
I'm working on a DSP program): how would a LV2 VST loader handle VST
plugins with various effects, banks and programs, expecially in the
case (if any and/or possible) where such plugin makes some fades when
changing while playing (real-time processing)?
I've no idea, you'd have to ask the authors of those other converters.
Then... I see in VST docs that a getInputLatency and
getOutputLatency
functions are defined. I think that these could be used as extensions
on a LV2 host, but such values are to be trusted under wine?
LADSPA has _latency ports, I don't remember what we said for LV2. The
latency should only be algorithmic, so wine should not be relevant.
And what about the combination of LASH and VST storing
system?
Sorry, I don't know anything about the VST storing system.
- Steve
12:49 p.m.
New subject: [linux-audio-dev] Sound processing objects architecture, is it possible?
2007/1/23, Steve Harris <steve(a)plugin.org.uk>uk>:
On 23 Jan 2007, at 16:14, Stefano D'Angelo wrote:
No problem, as I said before, thanks a lot!
Stefano
Just some last questions and I'll stop shouting and fooling around :-)
This issue should also have been faced with vstserver, fst and so, but
I never used them, so I'm just asking (I'm doing all of these because
I'm working on a DSP program): how would a LV2 VST loader handle VST
plugins with various effects, banks and programs, expecially in the
case (if any and/or possible) where such plugin makes some fades when
changing while playing (real-time processing)?
I've no idea, you'd have to ask the authors of those other converters.
Then... I see in VST docs that a getInputLatency
and getOutputLatency
functions are defined. I think that these could be used as extensions
on a LV2 host, but such values are to be trusted under wine?
LADSPA has _latency ports, I don't remember what we said for LV2. The
latency should only be algorithmic, so wine should not be relevant.
And what about the combination of LASH and VST
storing system?
Sorry, I don't know anything about the VST storing system.
- Steve
6646
days inactive
6646
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
2 participants
participants (2)
-
Stefano D'Angelo -
Steve Harris