[gmpi] Re: using another plugin API
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 25 Apr 2003 07:09:17 -0400 (EDT)
On Thu, 24 Apr 2003, Steve Harris wrote:
> I think its very unlikly that anyone will be using current or near future
> plugin technologies in 20 years time.
I'm not so sure... we're still using VST2 (1999) and VST (1996) now, and
even if AU replaces it to a large extent, it will still be seeing
considerable use for, at the very least, the next 2-3 years and more.
> MIDI basicly survived that long because its very hard to upgrade (it
> involves hardware) and it's good enough.
It's -sort of- good enough, and I would agree that it's hard to upgrade a
hardware synth from MIDI to another spec (although adapters or bridges
make this possible in hardware just as they do in software). The REAL
reason MIDI has survived so long is inertia, and because getting everyone
to agree on standards is actually a rather difficult task. You will see
the same thing happen with GMPI if it becomes succesful. You also have the
issue that many products, and even companies, in this business do not have
a long production life, but continue to be valued by users for many years
afterwards. The same is true of software. Even if GMPI were ready
tomorrow, and everyone leapt aboard, apps would have to maintain backwards
compatibility with DX and whatever else for a considerable time. Look at
the fuss the Cubase users made when Steinberg threw out a bunch of legacy
stuff in SX.
> The requirements for host based
> processing can, and most likly will, change much more rapidly and there is
> a much lower barrier for change.
I'm really not so sure. The barrier for change is bigger than you
appreciate, and until such time as machines are fast enough for
"per-sample" plugins to make sense, the basic requirements in terms of
connectivity, events, parameters and DSP architecture, are not likely to
move beyond a certain level.
> It's not that I think we should ignore potential future directions, but
> they can introduce unnecessary complexity if you're not careful.
> Too many standardisation programs get to the end and find that thier
> obsolete. For me, solving the problems that we have here and now, simply
> and efficiently is the best thing we can do.
That's fair enough. I guess I just don't see the problems with the
existing second generation architectures as being all that bad when you're
talking about developing second-generation hosts and plug-ins. I would not
want to base a third-generation architecture on any of those foundations,
though!
I thought that the raison d'etre for GMPI was partly that the current
architectures were lacking in capabilities in some ways (although the
lack-of-clarity problem is not completely unrelated to lack of
capabilities). If most here perceive the problem to be addressed as simply
a lack of standardization and clarity within the second generation, and
think that's a simple problem to solve that can be done without
reengineering large parts of the event model, so be it - AU or an AU-like
design is the way to go for sure. AU does feel a bit like MIDI, though...
a sort-of-good-enough, designed-for-today architecture that we may well
find we're stuck with in 10 or even 20 years' time.
Regards,
Angus.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
