[gmpi] Re: NAMM working group meeting report
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 26 Jan 2004 09:07:21 -0800
Thanks for the update, Ron!
On Mon, Jan 26, 2004 at 10:10:22AM -0500, RonKuper@xxxxxxxxxxxx wrote:
> and future direction. This of course means the requirements need to
> finished by October or thereabouts.
>
> Any thoughts about this plan?
If we're STILL not done by October, I'm going to be really disappointed. :)
I say we go for it.
> 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?
What are concerns? It should just work. The simple rule of a plugin not
being re-entrant (or minimally and well-definedly re-entrant) should be
enough. SMP is really only a hard problem for operating systems and
parallelized apps. If hosts want to be SMP-smart, they do have issues to
solve, but they are not particularly new issues. It's a matter of
partitioning the problem. I have a number of thoughts on this (I love multi
processing :) but they really are the host's issues.
> 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.
Any one who uses static globals across multiple instances is begging for a
hurting with multiple instances. Adding multithreading makes a plugin
library (shared object) re-entrant, but not a plugin instance. Anything
global needs to be locked. Yes, examples and best practices should cover
some of that.
> Section 3.7 questions: File I/O services seem to be missing from the
> requirements document, under host services. They need to be added.
I thought we had decided that the best answer was either:
a) POSIX
b) ANSI C
c) some other cross-platform lib
On re-reading that, I see you said "host services". What level of file IO
do we want to provide? Do we want to provide host-centric open, close,
read, write routines? how about seek? poll/select? async IO? There are
a LOT of file IO options. Do we really want to build that into the API?
> Requirement 23: Asynchronous operations were discusses briefly and it
> was agreed that this requirement needs a little more fleshing out.
Suggestions?
> 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?
I think we have or can have answers for all of the concerns. BUt we're not
that far in the req's review. We can't make it through 3.8, much less 3.16
:)
> 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.
This is something I really worry about. It would be nice to know that SOME
HOST will support (even if they add conditions for timeframe or
quality or ...).
> There was some concern about how to uniquely identify plugins.
> Possible solutions discussed included GUIDs or some other unique
> identification method.
This is a simple problem. centrally administered *anything* is a mess, but
we CAN find a way to do it.
----------------------------------------------------------------------
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:
