[gmpi] Re: Requirements

  • From: "Laurent de Soras [Ohm Force]" <laurent@xxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 16:11:15 +0100

Marc Poirier wrote:
> 
> > - Designed to implement wrappers easily
> 
> I'm not sure I understand this, but it sounds like it might be something=20
> like the AUGraph stuff in AU, am I right?




> > - Process only PCM audio data (not FFT-based nor compressed
> >   data).
> 
> I personally would *love* a spectral plugin interface, but I could=20
> understnad if other folks didn't want to add that degree of flexibility=20
> into this project...

We thought so, passing FFT chunks through the signal graph
thus saving FFT/IFFT operations, but there are too much ways
to handle spectral things (overlapping, FFT size, windowing,
etc) so it's too difficult or restrictive to standardize such
a thing.

> I don't know about x86 chips, but with PowerPC it's very simple to just=20
> turn off denormals mode and then you have no chance of getting denormal=20

It isn't possible on x86, at least with the standard
instruction set (SSE allows it).

> >    - Optional type specification for internal use by plug-in
> >      and complementary use by the host
> 
> What does this mean?

When you have normalized parameters corresponding to
physical or musical data, it would be useful for the
host to have a hint to convert them to "natural"
values and to classify them by units. I.e. you can
set in Hz or pitch a plug-in parameter expressed in
seconds (makes comb filter from a delay).

> >    - Decent string support, for GUI-less plug-ins.
> 
> What do you think of AU's solution to this?  I really like it.

Yes this is the same kind of idea actually.

> >    - 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=20
> APIs...

David also proposed an alternative system to tokens on LAD.
 
> > - Abstract note support
> 
> Again, what do you think of AU's solution to this?  It is a clearer and=20
> more flexible musical event system which can wrap MIDI and optionally=20
> supports straight MIDI.

For me AU way is too close from MIDI. I didn't experiment the
sdk myself (just read the docs and headers), but I thought it
wouldn't solve the problem of handling Note Off after multiple
Note On at the same pitch.

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

I didn't look too much at this part of the SDK, but it could be
a solution. However opaque data is required (at least to be able
to wrap any VST plugins using chunks)

> Sorry to sound so redundant, but again, what do you think of AU's solution=

I should read more carefully the AU SDK :) I think Raph has
more experience with it (he's coding for mac, not me), but
he's currently on holidays.

> >    - 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=20
> the GUI and DSP components in separate address spaces, computers, etc.

There are not only DSP and GUI, but we thought about multi-client
issues (many people trying to change a single parameter at once).
This is also related to token. We wanted in PTAF to prevent
the GUI to control directly the DSP parameters, as it is
done in VST for example. Instead, assume GUI -> Host -> DSP.

-- Laurent

==================================+========================
Laurent de Soras                  |               Ohm Force
DSP developer & Software designer |  Digital Audio Software
mailto:laurent@xxxxxxxxxxxx       | http://www.ohmforce.com
==================================+========================

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