[gmpi] Re: NAMM working group meeting report

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: