[gmpi] Re: Requirements

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 17:33:53 +0100

On Tuesday 11 February 2003 15.42, Marc Poirier wrote:
[...]
> > - Process only PCM audio data (not FFT-based nor compressed
> >   data).
>
> I personally would *love* a spectral plugin interface, but I
> could=3D20 understnad if other folks didn't want to add that degree
> of flexibility=3D20 into this project...

Well, for XAP, we have a rather generic approach that could be used=20
for this: Raw data controls. (Basically raw shared memory blocks=20
passed by reference using timestamped events.) The only standard=20
format is strings (for file names and stuff), but the raw data API=20
will be open to custom stuff, such as preset data that cannot=20
sensibly be expressed as normal controls (ie float values).

Anyway, details on this are yet to be finalized. No working prototype=20
yet.

And either way, I think it's very hard to specify on a standard way of=20
passing FFT spectra around. It would be more like a private data type=20
that works only with a set of plugins that are designed to work=20
together. The detailes would be in the plugin code, and just marked=20
by a unique datatype ID, to avoid confusion with other custom stuff=20
of other plugins.


> >    - Identification of silent input and output for CPU
> >      saving
> >    - Normalized values for communication with the host,
> >      floating point data.
>
> I don't know about x86 chips, but with PowerPC it's very simple to
> just=3D20 turn off denormals mode and then you have no chance of
> getting denormal=3D20 values.

It's not possible on x86 chips, AFAIK, except for the SIMD extensions.

Either way, I think it's sufficient to say that plugins that tend to=20
generate denormals (anything with a feedback loop is a potential=20
risk) should take measures to avoid it. If a plugin outputs=20
denormals, it will most likely be pumping them around internally as=20
well, and this cannot be prevented by the host in any simple,=20
standard way.


[...]
> >    - Locking : token system designed to handle conflicts
> >      between host and plug-in for parameter changes.
>
> This is one thing is one thing that always seems to be missing
> from=3D20 APIs...

I don't see why it's needed, if plugin/GUI action is handled properly.=20
If a GUI acts as a plugin in relation to the net, a GUI control (say,=20
a slider) would have an input for "motorization" and an output for=20
output from the control. Automation override would be handled by an=20
"active" flag on the output, so the host (or rather, automation=20
sequencer) can see when the user has grabbed the knob.

No need for tokens, and priorities and routing would become a pure=20
host implementation thing.


[...]
> > - Internal opaque state loading and saving.
>
> Personally I think that totally opaque is not so good.  I like
> AU's=3D20 solution with a non-opaque XML settings structure with
> standard keys and=3D20 values which can easily be extended to include
> any personalized opaque or=3D =3D20
> non-opaque data.

I would prefer it plugins just used standard control types as far as=20
possible, resorting to strings or raw data blocks only when nothing=20
else makes sense.

As to the XML part, that's a great idea for a standard preset file=20
format (so all hosts can use the same presets), but IMHO, it's too=20
high level and too complex for a real time plugin API.


> > - Preset support
> >    - On the host side.
> >    - Static factory presets.
>
> Sorry to sound so redundant, but again, what do you think of AU's
> solution=3D =3D20
> to this?  I think it's great, presets really are static,
> non-volatile=3D20 presets and since the settings format is XML, any
> configuration and=3D20 hierarchy of single or multiple preset storage
> is very straight-forward,=3D20 with all of the burden of management
> falling on the host, since the plugin=3D =3D20
> only manages a single user state.

Sounds great to me, and apart from the XML format, it's what we're=20
trying to do with XAP. (Which might become a proposal for GMPI.)


> > - Notification-style API to avoid constant polling overhead.
>
> Yes, this is sooo important and useful!  I recommend checking out
> AU's=3D20 property listener and parameter listener systems for
> example.

We just use timestamped events for everything in XAP. Seems like we=20
won't even have anything but controls; no separate parameter/property=20
API or anything like that. I feel that a distinct separation between=20
them is pointless and restrictive, since they're so similar, but=20
there *are* issues with using the same interface for everything. We=20
haven't figured everything out yet, but at least, nothing seems to=20
make it *impossible* to use only controls for everything.


> > - GUI
> >    - Independent window at system level: host does not have
> >      to dispatch and filter events.
> >    - Resizable window.
> >    - Communicates with the DSP part via the host, which is
> >      an arbiter for concurrent access to parameters.
>
> I think that the OS would be a better arbiter.  This would allow
> running=3D20 the GUI and DSP components in separate address spaces,
> computers, etc.

I'm not sure what you mean. These two sentences seem mutually=20
exclusive in some way... ;-)

Anyway, running GUIs in separate processes is *required* on some=20
platforms, and being able to run them on other machines is really=20
rather interesting as well. (Let's just say that Un*x users tend to=20
consider anything that can't do that broken.)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---


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