[gmpi] Re: Topic 1: Audience for and users of plugins

  • From: "Mikael Hillborg" <mikael@xxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Mon, 17 Feb 2003 10:43:19 +0100

> I think that the topic of discussion right now is (2): Support <how many> 
> kinds of applications.

How about these 4:

1. Generators (audio, midi etc)
2. Processors (audio, midi etc)
3. Applications which can be both generators and processors. (e.g. a synth with 
an "external" input)
4. Combined "networks" of the above. (e.g. a modular synth)
 
> Most of us here are very well versed in the domain of floating point DSP,
> written in C/C++ (primarily), running on Windows, Mac and Linux (primarily),
> packaged as in-process plugins.  Does this mean that the scope of GMPI
> should therefore be restricted to the aforementioned?  Let's not assume so,
> not just yet.

No, but it's a good start. If we can't get it to work for the above three 
platforms, 
then it'll be very difficult to specify something useful for say Sharc DSP 
systems, 
like the Cremware stuff or Digidesign's Protools system. See Mac/Win/Linux as a 
test, because going beyond that to support a wide range of DSP systems is even 
more 
complicated.

 
> It's safe to assume that GMPI needs to cover at least that much ground.  But
> what more?
> - DSP based systems.  Is it feasable that one plugin API can allow the same
> source to be cross-compiled for DSPs and native systems?

The difference between fixed point DSP system which has say a Harvard 
architecture and a Windows system is just too big. We have the floating point 
vs 
fixed point issue, and systems like the Creamware Pulsar / Sharcs (and Protools
I assume) might do load balancing over several DSPs, which is very hard to deal 
with on such a generic level. 
 
> I am also an incrementalist in my approach to development.  But I believe
> that if we set out to develop a standard that covers only the ground that we
> are familiar with, then our success will be confined to a little fishbowl.

But we must start somewhere, and we shouldn't omit these platforms should we? 

> Someday soon, other "standards" will emerge to cover those unfamiliar bits
> (PDAs, cell phones, game consoles, embedded) in a way that looks similar yet
> is incompatible.

But trying to get all PDAs, cell phones and game consoles into this standard
is an impossible task, believe me. I've worked a lot with small handheld devices
(and written books about development for such). And you won't be able to support
all, because they all behave different and have limitations in all kinds of 
ways.
Each device has its own set of limitations, which is not necessarily the same
kind of limitations on another device. Not even J2ME works in practice. It is 
supposed to execute on all small handheld devices (e.g. phones) that support 
it, but since many manufacturers implement their own virtual machine they 
also have their own set of bugs in the virtual machine... 

But the trend is clearly moving towards "standard" operating systems for 
small handheld devices and the future battle seems to be between two flavours:
embedded Windows or Linux. So if our plugin format is developed for Win/Linux
then it'll probably be less of a problem to port it to these type of devices.
 
> Perhaps the answer is not to set out design a fully comprehensive
> specification.  Better would be to recognize where future work is needed,
> designate those areas for subsequent spec versions, and make sure we don't
> design ourselves into a corner.

Yes, maybe we should identify what already works (and consequently doesn't
have to be reinvented) and where work needs to be done. 

MH



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