[gmpi] Re: Item 0: Agenda

  • From: "Silver Blade" <silverblade_uk@xxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Wed, 12 Feb 2003 16:51:54 -0000

No doubt other people will probably come up with my answers to these
questions, but I thought I'd post them anyway. Let me know if I'm straying

I hope my ideas will be of some use. Let me know if you need anything

> 1.  Cross-platform
> What processors, O/S, addressing models and programming languages do we
> to support?

Processors: x86/pentium/athlon/etc. (not sure what Mac uses?) I'm not sure
what others are available.
O/S: Windows, Mac OS X (others?), Linux?
Languages: C, C++, Delphi, Visual Basic?, Java?

> 2.  Plugin flavors
> Audio and/or MIDI processors, sure, but what about driver plugins,
> controllers, visuaulization plugins?

Sample effects
Music (MIDI) effects (simple "emulated" effects like delay, arpeggio?)
Sample input/output
Music (MIDI) input/output (support patch lists, controllers, etc.)
Sample visualization (oscilloscope, spectrum, etc.)
MIDI visualization? (notes & velocities)

Maybe there could be realtime and non-realtime effects for audio, so like
someone suggested, FFT and other effects requiring a large block of samples
could be used. This would be excellent for sample editors.

How about allowing people to create their own interfaces for things like
mixers and other panels? This might be difficult, but it's something I've
been trying to do recently. However this is probably best suited as a
separate application, since it'd mean you could choose your own components
and build a virtual studio with custom mixer, etc.

> 3.  Host interface
> In-process or out-of-process?  What kinds of special needs are there in
> events to/from a plugin?  Is the host a plugin too?

This is similar to what I suggested in the last question - a music app could
be built solely out of plugins. But maybe the actual GUI would be a plug-in,
and the host would simply be a module which does processing and doesn't have
a GUI of its own?

The host should be able to run in-process and out-of-process (if I'm
understanding this correctly.) Possibly make the GMPI work as a
client/server, when on different computers (networked.) But when on the
local machine, keep them as a single process?

If out-of-process implementation could be done efficiently, that'd be best
because applications could share plugin instances then. I'm pretty sketchy
on this though, so I'll leave this to the experts.

Hosts should provide information to the plugins, and the plugins should
provide the desired functionality to the host. This is pretty standard, I

See (4) for more.

> 4.  Audio packaging
> What do we prefer for interleave, audio sample data types, allocation,
> timestamping?

Personally, I think the GMPI should make things as easy as possible for both
host and plugin developers. Actually, you can't really change how plugin
specs are implemented! But if the GMPIs functionality can be extended by
plugin support modules (as I suggested in my basic design which I sent to
Ron last month), then GMPI should provide a fairly straightforward method of
creating new support modules for plugins (ie, one support module could be
for VST, another for DirectX...) This would probably be best done in a

> 5.  Time representation
> Samples or "ticks" or both/neither?  How are discontinuities expressed?

The best thing would probably be to provide a way of converting from ticks
to samples, or h:m:s based on time signature and tempo, etc. This would of
course require the GMPI to be informed of the host's parameters regarding

Internally, I think samples would provide a higher timing resolution - after
all, there may be 500 or so ticks in a beat, but there could be thousands of
samples in the same space of time.

> 6.  Parameter representation
> What data type for values, for names?  How do we support validation, value
> distribution?

I think floats would work well here. These can be scaled easier than having
to convert from int to float and back again. I believe VST uses a range
like -1.0 to +1.0 while ASIO uses a larger range (-32767.0 to +32767.0 ?) So
it's simply a case of multiplying.

> 7.  Persistence
> Whose reponsibility?  How do we deal with endian issues?

Not sure what this means, but it seems to be related to data formats... I'd
say GMPI would be responsible for translating as appropriate, if possible.
Maybe force developers to specify endian mode at compile-time?

> 8.  Threading
> What kind of realtime guarantees?  Does the host provide some kind of
> threading environment?

If so, try to make use of it. Again, maybe allow developers the choice when
compiling which mode to use?

> 9.  GUI
> Can GUI be avoided at this point?  What does the interface boundary to the
> GUI need to be?

The host application should be responsible for end-user interaction/GUI.
However, where plugins have their own GUI, platform-dependent data will need
to be passed to the plugins.

See also (10)

> 10.  The role of MIDI
> How important is it?  How do we ensure something new is still backwards
> compatible?

It's very important. Although a way to automatically retrieve patch lists
from devices would be desireable, if GMPI could provide the user with a
dialog for editing patch lists, that should be sufficient.

It'd be brilliant if controller/RPN/NRPN values could be "cached" so the
host app could retrieve values later. I've spent ages getting my programs to
remember the last controller value sent to a device, so it'd be nice to have
this already done.

I suggest having a way to translate to/from MIDI messages, so MIDI input can
be processed, as well as allowing applications to use MIDI messages to
communicate with GMPI (although I really doubt anyone would want to do so!)

Since GMPI's name implies it's for plugins, the focus should be on providing
maximum functionality for plugins. However, MIDI should most definitely be
in the design somewhere, if only to make GMPI more complete.

It'd be nice to just be able to tell GMPI to do something with audio/MIDI,
and actually have it done without having to worry about all the different
I/O and plugin technologies available.

> 11.  Component packaging
> Is there a "base level" possible that's still cross platform?  How do we
> support all target platforms?

Support for GUI will be the most difficult part, along with different
methods of loading and using plugins.

A class providing methods to the host application shouldn't have much (or if
at all possible, any) platform-dependency. On the other side (GMPI to
plugins), there may need to be some platform-dependency. I'm not sure

Taking wxWindows as an example of cross-platform development, I think it'd
be best to implement platform-dependent stuff in a way that all platforms
can work with. For example, the method of creating a window on Windows would
most likely be different to creating one on Linux, for example. Thus for
platform-dependent things, the low-level stuff that actually works with the
platform should be hidden from software developers, wrapped in a class which
provides as much functionality as possible. And if something isn't supported
on a platform, provide an alternative method or do something that doesn't
involve the application developers re-writing code to work on different

If that makes sense?

> 12.  Enumeration (creation, discovery, etc.)
> Create for use vs. query, what can a plugin do at creation time, RT

Have a cache file that updates as new plugins are found, and old ones
deleted. Open up a separate process to query new plugins and create a
description entry in the "cache" file. Attempt to open the GUI if there is
one, and pass a few samples to test the plugin is OK. If it crashes, it only
brings down the plugin query process, and not other applications. Have some
way of dealing with this. Not sure how to sync. the host and the plugin
query process though.

> 13.  Copy protection
> How should plugins address DRM streams?  How to sign OpenSource plugins?

Never worked with DRM streams.

> 14.  Localization
> How does the host specify its language?  Logical vs. human-readable names?

Again haven't worked with this.

> 15.  DSP state
> When and how does a plugin reset?  How to respond to format changes?

These should ideally be "do-able" in real-time. Other than that, I have no
other suggestions.

> 17.  Source code
> How are headers and host libraries/source licensed?  What kind of sample
> code is required?

Host sample, plugin support module sample (dll source or .cpp ?) to extend
support for any plugin types not currently "wrapped" by GMPI.

I'd suggest allowing the specification to be updated, but with a main
distribution being maintained, so no stray code gets added and it's kept
clean. For example, plugin support could be extended and the code to support
additional plugin types could be added to the official distribution.

Maybe have special licenses for GMPI developers (if source is
modified/updated, it should be incorporated into GMPI releases once
thoroughly debugged?)

-Silver Blade

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: