Re: GMPI

[Jeff McClintock-2]

>From: Chris Cannam <cannam@...>


On Sun, Nov 8, 2009 at 6:41 AM, Jeff McClintock <jef@...> wrote:
> GMPI is quietly and successfully in use as the new native plugin format of
> SynthEdit.

>Interesting.  Can you link to an API reference or the like?

Hi Chris,
The download link is below. The current version is tested on Windows only,
I'm pretty sure it's potentially Linux friendly because it's a refinement of
the original prototype which was jointly developed with Tim Hocken on Linux.
Any MSWindows-specific, or SynthEdit-specific features are implemented as
extensions. I periodically check it compiles cleanly with GCC.

http://www.synthedit.com/sdk.htm

-----------------------------

From: Emanuel Rumpf <xbran@...>

>From the KVR site:
"Like MIDI, GMPI will be license free and royalty free."
>"...and will cost you ~ $88 to acquire."
My addition.
>FLOSS people - let's rather ignore GMPI as long as we can.

The prototype was developed by members of the GMPI mailing list who are not
members of the MMA.  

"Req 113:   The GMPI SDK must be released under a license with similar terms
to the BSD license."

It is under the BSD license, it costs nothing to acquire or to use.
 Every plugin I've written with GMPI (aka SEM) is also BSD and source code
is available with the SDK.  My own plugins are aimed at modular synthesis
though, so maybe not widely useful.

------------------------------

I'm don't believe GMPI has much chance of widespread popularity, much of the
design was considered too radical, e.g. my proposal to ditch MIDI. MIDI
support *was* eventually included as an option, but I also support MIDI-less
synths controlled via polyphonic control-ports.

I will continue using my branch of GMPI, it's far cleaner, more advanced and
more efficient (for me) than anything else.

Here are the official GMPI requirements...

http://retropaganda.info/archives/gmpi/gmpi-requirements-2005-04-05-final-dr
aft.html

Here (bottom of page )... list which GMPI requirements are currently
supported.

http://www.synthedit.com/sdk3_docs/index.htm


Jeff McClintock.


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Paul Davis]

On Mon, Nov 9, 2009 at 1:35 AM, Jeff McClintock <jef@...> wrote:

from the SEM/GMPI reqs list:

  # In-place processing (reusing an input buffer as an output buffer)
must be supported by GMPI. Not critical, in fact VST has removed this
feature.  Possible future enhancement.

say it ain't so jeff! This is a ridiculous bit of cache thrashing. I
haven't followed VST carefully, and you certainly know more about it
than me, but i thought that steinberg did the opposite and got rid of
process_adding() and process_replacing() and required
process_replacing() ("in place") semantics?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Jeff McClintock-2]

From: Paul Davis <paul@...>

>  # In-place processing (reusing an input buffer as an output buffer)
must be supported by GMPI. Not critical, in fact VST has removed this
feature.  Possible future enhancement.

>say it ain't so jeff! This is a ridiculous bit of cache thrashing. I
haven't followed VST carefully, and you certainly know more about it
than me, but i thought that steinberg did the opposite and got rid of
process_adding() and process_replacing() and required
process_replacing() ("in place") semantics?

Good point. In-place is super-easy to support anyhow, just use the same
buffer as both input and output.

Jeff


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev