I think Windows XP, Linux, and Mac OS X can all support this -- if the
programmer knows his or her stuff. Unfortunately the really effective
mechanisms are different on different platforms (e.g. on Windows, one might
have to write a kernel driver).
Developing an open source library of abstract primitive operations, with
good implementations on these 3 platforms, to enable this kind of
programming would be a huge boon to audio programming and many other kinds
of progrmaming as well.
Original Message:
-----------------
From: Angus F. Hewlett angus@xxxxxxxxxxxxx
Date: Mon, 31 Jan 2005 14:34:42 +0000
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: NAMM follow-up, some major decisions to make
Ron Kuper wrote:
>What we need is some compelling business reason for companies to want to
>do this today. Is there something truly broken that GMPI will fix? (I
>have ideas about what the answer is, but I'm curious what you all
>think.)
>
>
The one thing that's really broken is something that, ironically, GMPI
probably won't fix :(
With plugs becoming as complex as hosts, seems like it's time to
investigate mechanisms that can combine the benefits of inter-app
communication pipes like JACK and ReWire with the user convenience of
plug-ins. Benefits like - each plug-in being its own process, having
memory protection from the others and its own clearly defined contexts
and resource pools.. and yet still able to persist its state with a song
save.
My guess is tho', this would require support in the OS for very
efficient, deterministic, low-latency context switching and fast IPC-
not sure how well current desktop OS match up to this :-/
Cheers,
Angus.
>-----Original Message-----
>From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
>Behalf Of gogins@xxxxxxxxxxxx
>Sent: Friday, January 28, 2005 1:27 PM
>To: gmpi@xxxxxxxxxxxxx
>Subject: [gmpi] Re: NAMM follow-up, some major decisions to make
>
>I don't regard these points as likely to influence host vendors. They
>all
>got where they are today by doing the opposite, so their whole
>experience
>works against us.
>
>When they start losing sales to open source competition or to GMPI-based
>commercial competition, that will influence them.
>
>I see two technical paths to this end:
>
>First, base GMPI's reference implementation on OSC, or some other
>network
>protocol capable of beating MIDI at its own game, especially in
>precision
>timing and flexible control.
>
>Second, make adapters so that anyone who develops with the reference
>GMPI
>SDK automatically gets VSTi, DXi, JACK, etc.
>
>Then the first host vendor who adopts GMPI as a native protocol gets a
>musical advantage over the others, and a lot of people will probably
>have
>written GMPI plugins that will leverage that advantage for the vendor.
>
>Original Message:
>-----------------
>From: Mike Berry mberry@xxxxxxxxx
>Date: Fri, 28 Jan 2005 10:19:47 -0700
>To: gmpi@xxxxxxxxxxxxx
>Subject: [gmpi] Re: NAMM follow-up, some major decisions to make
>
>
> I believe that one of the reasons that some large companies have
>not
>seen any value in GMPI is that they don't see any need for
>interoperability in this arena, unlike with MIDI or IPv6. They regard
>their applications as platforms (in some cases, like Apple or MS, they
>actually ARE platforms). They see little benefit in encouraging
>multi-platform development - they would prefer to win the platform
>battle and make everyone write to their platform.
> I think it is incumbent on those of us who do not share this
>view to
>make it crystal clear why a common multi-platform plugin system is
>beneficial to all.
>
> So in that spirit I want to start a list of the points in favor
>of a
>standardized, multi-platform plugin environment in hopes of producing a
>document which might persuade some of the reluctant MMA members (I am
>assuming here that all of the companies in question primarily develop
>hosts):
>
>- Widest possible variety of 3rd party plugins available for your host.
>This may be of particular interest to hardware developers who rarely
>have had access to 3rd party plugin innovation.
>
>- Lower development costs since you only need to support one plugin API.
>
>- Never having to support a plugin API controlled by a competitor.
>
>- No developer support required since you do not control the API.
>
>- Increased ability to create a single working environment for your
>customers. Currently, customers may need multiple hosts in order to
>access plugins or specific features only available on particular hosts.
>In the GMPI environment, particularly with nested hosts, the user can
>stay within their chosen host for all operations.
>
>- A chance to discard legacy baggage accumulated over a number of years
>within your own proprietary API.
>
>
> Please add to this list is you see other benefits to companies
>with
>established hosts and/or plugin APIs.
>
>
>
--
=========================================================
Angus F. Hewlett, Managing Director (CEO)
FXpansion Audio UK Ltd - http://www.fxpansion.com
Registered in the UK - #4455834 - VAT: GB 798 7782 33
=========================================================
----------------------------------------------------------------------
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
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe