[gmpi] Re: Reqs 5, 6, 11 for debate

  • From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Tue, 25 Nov 2003 19:55:13 -0500

Frankly, I think the acceptability of a portability library depends almost
entirely on its quality. Many developers (I, anyway) would use such a
library not only for a few VST plugins, but also for other things that they
do. Right now, I automatically use libsndfile for reading and writing
soundfiles no matter what I'm doing. I'd be happy to have a portability
library of similar scope and quality, and if i did, I would use it all over
the place.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Marc Poirier" <fipnid@xxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, November 25, 2003 4:59 PM
Subject: [gmpi] Re: Reqs 5, 6, 11 for debate


>
> --- RonKuper wrote:
> > >>>
> > Req 5 - Portable Runtime
> >
> > The GMPI design group should research options for a cross-platform
> > portability library for GMPI plugins.  And existing library may be
> > adopted, or a new library may be drafted.  This should be a separate
> > specification from the GMPI API.  Plugins that wish to be most portable
> > should use this API instead of native APIs whenever possible.  This API
> > is not the host services API, which should handle certain host-specific
> > services tasks.
> > <<<
> >
> > To me this is drifiting away from the whole reason for wanting a runtime
> > system.  At least it's drifiting away from *my* reasoning.
> >
> > We need a way for plugins to allocate memory, access the disk, and
> > manage threads, in a way that allows the host to manage and/or
> intervene.
> > The host might the OS, or the host might be the host application.
> >
> > In other words, when a GMPI plugin needs to allocate memory, it asks the
> > host for it.  The host exposes a memory allocator for the plugin.  The
> > plugin doesn't have a memory allocator compiled in, because that means
> > different hosts can't customize allocations to their requirements.
> >
> > To me, the requirement is: the GMPI host interface must expose core
> > services to the plugin: memory management, disk IO, threading.  It is
> > the responsibility of every GMPI host to expose these services.  A
> > deliverable in the final GMPI developers kit will be reference
> > implementations of these services for hosts to expose to plugins.
>
> I think that, until GMPI is The Only Plugin Format (and I don't think that
> that will happen for a really long time, I don't even think that it will
> be Yet Another Plugin Format anytime within the next couple of years),
> this is going to make things difficult for authors developing for multiple
> plugin APIs.  I just think that's worth thinking about.  I can see
> developers either resenting this or not doing it at all.
>
> Marc
>
> __________________________________
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
>
> ----------------------------------------------------------------------
> 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
>


----------------------------------------------------------------------
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:

  1. Home
  2. gmpi
  3. Archive
  4. 11-2003