- I don't wont to be too negative with respect to
the GMPI effort,
because it's a great chance for free software developers to take part in
the discussion of the spec of what could be become an important
standard.
its not just a great chance. its the ONLY chance.
- BTW, after the "Phase 1" of GMPI developing
process, developers who
are not member of MMA will have to sit and wait. Hoping:
there is nothing stopping "LAD" from joining the MMA. it is very
likely that Linux Audio Systems will join the MMA, and i will be happy
to act as a proxy for LAD if necessary.
a) that the final standard will be similar to what
she/he wanted (i.e.
what was decided on the mailing list);
b) that the license and the way the standard is designed will be really
"free".
the license is part of the agenda. we haven't reached it yet, but i
think it was clear from the very beginning (a meeting at NAMM) that
the outcome would be very close to the LGPL. everybody admires the
openness of MIDI and the lack of proprietary control, while also being
aware of the risks of stuff like GM and XM that were added to MIDI by
Roland and Yamaha.
I want an API that may be extensible ...
I want those extensions to be contributed ...
I want to develop open source plugins ...
I want to allow skilled company to write wonderful plugins ...
I certainly don't want to pay *any* money (at least to be payed:-) ...
I want to be involved in the design process, ...
What I want is an API with the spirit of free software ...
you seem to want a lot.
look, most of the people on the GMPI list would love to be able to
define the plugin API they use to meet all their own needs and
desires. unfortunately, we've already seen the result of this approach
- multiple API's most of which have identical core functionality and
make life miserable for developers and users. this is the prime reason
why the GMPI effort exists at all, but unless the API that will
hopefully emerge from it is actually accepted and used by major host
applications, it will be pointless. what is the chance that your (or
my) pet API will succeed in that sense?
sense). If XAP will abandoned, maybe I should simply
create my API, host
and plugins. I would like to call it GAP (GNU Audio Plugin)
Great. Another API. Besides, the GNU project already has Octal, which
probably overlaps with this very significantly.
a) Hope that MMA will reconsider the design phase.
b) Develop my own API (hopefully with other free software developers).
c) Don't care, and do other things in my free time.
i hope its (c). (a) is important because we've already seen how slow
the requirements process is when its open to anyone on a mailing
list. (b) is just going to make things more confusing for
everyone. please wait for GMPI to fail first.
- I'm having difficulties to follow the item on the
agenda as some of my
ideas for an ideal (i.e. to be used in many years to come) API are not
completely in accordance with some concept of the agenda.
i'm afraid you're late to the party. i seem to recall you saying you
were relatively new to this. i would pay close attention to what the
core tech guys from Cakewalk, FXpansion, Adobe, DestroyFX, Prism,
Steve Harris Inc., and several other organizations have to say. Tim
Hockin has done a wonderful job, aided by David Olofson, representing
a more expansive vision of what GMPI might be. the agenda wasn't put
together by a bunch of suits - it was the result of discussions by a
few dozen of the most experienced audio programmers around. if you
have something to contribute, join the GMPI list rather than talking
about it on LAD.
--p