[gmpi] Re: Topic 3: Cross platform

> Since discussion on this point seems to have wound down, I'll take a stab
at
> summarizing:
>
> 1. What processors (or processor architectures) are to be supported?
>
> The API should fully support 64 bit processors, and either be portable to
> such processors or explicitly utilize 64 types where possible.  Also,
> standard ANSI C type names should be used instead of platform-specific
type
> names such as DWORD.

Maybe "emulate" 64-bit on 32-bit machines? I think C/C++ can do this
automatically, but I thought it might be worth mentioning.

I like Chris's idea of having types such as int32 and int64, as this reduces
ambiguity, however I don't think that floats need to specifically have a
"bit depth", since the values might be -1.0 to +1.0 regardless of the type?

If we're going to use floats internally, it'd improve portability, since
64-bit processors can just have more accurate FP operations, while 32-bit
processors can still work with the code not having to be modified.



> 2. What operating systems are to be supported?
>
> In general, all popular contemporary O/S, leaning towards more recent
> versions: Windows 2000, Windows XP, Mac OS-X, Linux, other Unix variants,
> Windows CE, Palm O/S, BeOS.

Yes.


> The specification should explain the ramifications of making platform
> specific calls in functional areas where poor choices can degrade system
> performance, specifically memory allocation, threading/synchronization,
and
> disk I/O.  The working group needs to determine the mechanism whereby
> plugins gain access to these services while still being able to
> cross-compile into other plaforms and environments.  These services may be
> provided as part of GMPI itself, or as a separate cross-platform library.

I've been looking into this, since currently I use wxWindows, and it seems
very bulky and difficult to optimise.

I have several solutions:
1) Create a form of API which will emulates native API calls (eg:
CreateWindow on Windows), but which maps these calls to the target
platform's equivalent. The primary development platform could then be used
and the program made easily portable. Not a good option, because it'd take a
LONG time to implement (see WINE for example!)
2) Create a new API which encapsulates GUI, disk, threads, memory?, etc.
into a new C API, which is also wrapped by a C++ API. This could be similar
to an advanced form of the VST GUI.
3) Just stick to using other 3rd party libraries for this purpose.

GMPI should stick to being a plugin interface, I think. The GUI/platform
stuff should be a separate project/issue. Dealing with it as part of GMPI
might confuse our goal.


> 3. What kinds of addressing models are to be supported?
>
> The plugin and the host are assumed to share the same memory address
space.
> If a plugin needs to run in another space, i.e. out of process or an an
> external DSP accelerator, it is the plugins responsibility to perform the
> necessary translations on its side of the interface.

If I understand what this means, I agree.


> 4. What programming languages are to be supported?
>
> ANSI C (which supports C++ by extension), with very clearly specified
> application binary interface (ABI).  The actual calling convention may
vary
> from platform to platform, though the "default" calling convention is ANSI
> C.

Don't forget Delphi :) Although I haven't used it for a while now, I still
remember being aggravated by the lack of support for APIs which C/C++ can
use.

-SB


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