[gmpi] Re: using another plugin API
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 25 Apr 2003 07:54:27 -0400
>> 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.
i don't think that it would be that difficult to get a new MIDI
standard *if* MIDI wasn't as good as it is. it does have lots of
problems, but they are nearly all corner cases and/or the concern of a
very small number of potential users. its documented in great detail,
completely open to reimplementation by anyone, and within its stated
goals, its works extremely well. we can only hope to do as well with
GMPI.
> 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.
if you look at what has happened in the software world and compare the
longevity of free-as-in-speech software to its counterparts in the
not-free-as-in-beer variety, the former tend to have very long lives
when valued by users. editors like vi and emacs are now more than 25
years old and still in wide use. this is precisely and entirely
because there is no company around to decide to drop the product, or
revise it beyond recognition, or go bankrupt, or whatever. we also
haven't reached the denoument of "shakeout" in the DAW market that has
already happened with (for example) word processing, where ms-word has
come to dominate everything else. right now we've still got a group of
a half-dozen to a dozen (depending on who you include) DAW's battling
it out for user loyalty. the evidence from what happened to the many
early windows + macos word processors does not suggest that most of
them will survive, though who knows?
>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.
if a GPL'ed DAW like ardour gets subjected to major
revisions like the cubase vst->sx transition, users would be free to
continue with a fork of the older line. conversely, if someone wanted
to take things in a completely new direction, they can start from an
existing codebase, not from scratch. once free-as-in-speech software
has gained a sizeable user base that includes some programmers, these
qualities tend to create the opposite phenomenon than you describe
above: programs live on and flourish *after* their creators have moved
on to other things.
however, this doesn't address the backward compatibility issue that
you bring up, and thats a big one.
>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
we already have machines that are fast enough for that. i think there
are wide classes of plugins that could already run with per-sample
processing. i've done per-sample processing on a PII-450 using an ISA
audio interface; not much, i admit, but delays and so forth. assuming
that the DSP requirements are not overwhelming (and thats handled by
the ever increasing speed of general purpose CPUs), i think that if we
had seen the widespread use of a system bus and audio interfaces that
encouraged the use of a memory-mapped ringbuffer and per-sample access
(i.e. no block transfer), you'd already see per-sample processing in
widespread use.
however, what we'd actually have would be a mess, because many
DSP-heavy plugins couldn't run per-sample, and so we'd have to support
both models. it might be worth us considering this aspect of things.
>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
that's certainly part of the goal, but another other large part is that
people are tired (as i understand it) of the proliferation of plugin
APIs: it costs host and plugin developers time and effort, and it
costs users confusion and money. it wouldn't be that terrible to
simply have a unified "2nd generation" plugin API, but i agree that
while we're here we should be considering "3rd generation"
functionality and design.
--p
----------------------------------------------------------------------
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:
