[gmpi] NAMM working group meeting report
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 26 Jan 2004 10:10:22 -0500
Hi folks,
We held a working group meeting on Sunday, January 18 after at the annual
MMA meeting at NAMM. Since many of the people who have been most active on
this reflector were not present, the meeting was mostly a walk through the
requirements document to date. In the course of the discussion the some
questions and issues came up (listed below).
At the meeting I also explained the status of how GMPI will proceed given
the current rules of MMA membership. It's important that anyone on this
reflector who wants to contribute to writing the GMPI spec be able to ds so,
whill still being an MMA effort. The MMA is considering 2 possible
directions to achive this goal. One is to create a new membership class
(with a different cost structure), to make it easier for more of you to
join. Another is to create new separate special interest group (SIG),
similar to the IA-SIG (Interactive Audio SIG), have it live within the MMA
organization.
Tom White asked me when I thought the requirements document would be
finished. I thought we could finish it easily by the end of 2004. As luck
would have it, we have an opportunity that might make us want to accelerate
this a little bit.
This year's AES conference chairman, John Strawn, is seeking a colloboration
between the AES and the MMA, with a special focus on music technology. We
have the opportunity to host a workshop or present a paper at the
conference. I was thinking we submit an abstract about GMPI, and then
present it at the convention. My assumption is we would present the
*completed* requirements document and future direction. This of course
means the requirements need to finished by October or thereabouts.
Any thoughts about this plan?
Working group meeting minutes:
ATTENDEES
John Brinkman - Line 6
Paul Davis - Linux Audio Systems
Nick Haddad - Cakewalk
Kurt Heiden - SRS Labs
Ron Kuper - Cakewalk (MMA w.g. chairman)
David Miller - Microsoft (MMA w.g. tech board representative)
Bill Stewart - Apple
Dan Timis - Muse Research
There was some discussion about the role of GMPI on game console, i.e., does
GMPI need to support consoles like XBox, Playstation and Gamecube; is there
a market for it? It was suggested that since there are already game audio
middleware packages (such as Renderman), that GMPI might be a good fit.
Multiprocessor issues were raised when discussing profiles and different
platforms. There are issues that need to be considered regarding
multiprocessor and realtime best practices when developing the SDK. What
are the SMP issues for the different platforms?
Section 3.5 : Threading questions: A question was raised about running
multiple plugin instances on a multiprocessor/multithreaded host. The
requirements and/or specification may need to include real time best
practices to avoid mistakes like using static global data across shared
instances.
Section 3.7 questions: File I/O services seem to be missing from the
requirements document, under host services. They need to be added.
Requirement 23: Asynchronous operations were discusses briefly and it was
agreed that this requirement needs a little more fleshing out.
Requirement 63 : GMPI will use no raw MIDI. It was brought up in the
meeting that we should be cautious about this during the requirement phase.
A question was raised as to how we could exclude MIDI, given its ubiquity
and commercial success. Also, if we exclude MIDI, what replaces such things
as SysX, MIDI channels, instrument voices?
There was some general discussion about the need to evangelize GMPI once it
is done. Someone suggested that a host app needs to really endorse it for
the plugin vendors to use it. I pointed out that our current plan is ship
with wrappers to/from all existing plugin formats, which should hopefully
speed adoption.
There was some concern about how to uniquely identify plugins. Possible
solutions discussed included GUIDs or some other unique identification
method.
Membership question: Is it possible to have one MMA member act as a proxy
for a community (such as the Linux audio community)?
Other related posts:
