10 May
2007
10 May
'07
10:41 a.m.
the problem will be rather: why has this plugin a GUI
in ardour and
ingen and not in qtractor.
while this other plugin has a gui in qtractor and non in ardour and
ingen.
That is an exact example of one case that is certainly possible.
What has understanding internals to do with this?
All that will need to be understood is that is-an-LV2 is not
enough to describe a plugin or host.
And how is it doing to be described is my point. At the moment it is
being described as a function of what internal extensions are there in
the case of something that does beyond the spec. If this was one or two
extensions it wouldn't be bad at all, but since we are aiming for
expandability BEYOND what we can thing of right now I think it is a
large mistake to not plan for what would happen if there are 50
different extensions.
Do you propose to not have a plugin standard that can
be extended for
various current and possible future needs to avoid some possible user
confusion?
Absolutely not, and nowhere did I say that.
What I am attempting to propose is a good, end-user-friendly, be found
other than just describing individual extensions that gives end-users a
strong idea of what will and will not work. That is it.
Shall all hosts be forced to support all extensions
available so
that a sample editor would have to "support" MIDI plugins?
Again no. A host could still choose whatever they support. However,
for example, an audio host might support the audio extensions, a video
host might support the video extensions, and a host that is midi capable
the midi extensions. If you are dealing with 20 or 30 extensions there
for whatever reason, are you honestly going to have an end-user go
through and say, ok this extension is present, this one is present, this
one is not, crap my plugin won't work or will be missing a gui.
Do not get me wrong, as I have said repeatedly thus far, LV2 is nice and
highly expandable, and I certainly don't want to change that, but that
by itself will not make it usable for the end user. Power and
flexibility do not necessarily equate ease of use, and personally I do
not see a reason why this could not have all three, it is close as it is
and the only thing holding it back are clear definitions of what will
and won't work where for an end user that doesn't require 20 minutes
worth of work for each plugin to see if it SHOULD work. This has much
less to do with the technical requirements of the spec, and much more to
do with looking down the road and realizing that if this spec IS fully
taken advantage of, things might very well get messy.
Seablade