[gmpi] Re: Reqs final draft

That of course we all agree (and I wish VSTi's would behave like that)

But I think that a plugin could also assume the FPU state to be a constant in all hosts. It'd help it to be able to do common roundings without having to change it. Although yes, today you can do roundings by other means.

I'd have thought that we'd all agree that exceptions should be masked, and that rounding should be set to nearest, but apparently not.

It should also be required that a plugin that changes the FPU state, clears the pending exceptions first. Since they can be masked by the hosts, there can be exceptions that would be triggered in the poor plugin changing the state.



Maybe a way to restate this is: a GMPI plugin must always *preserve* the
state of the floating point flags.  If it wants to change them, fine,
but it must restore them.

-----Original Message-----
From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
Behalf Of Mike Berry
Sent: Thursday, January 13, 2005 11:04 AM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: Reqs final draft

Paul Davis wrote:
I can see lots of reasons to have all exceptions disabled (it's made
for
realtime apps - you don't want exceptions here more than you'd do in
apps
that use openGL), but what's your reason to want exceptions unmasked? 


if a plugin does a divide-by-zero, its an error on the part of the
developer AFAICT. as a host author, i would want to catch such
actions, and remove the plugin from my "graph". you can, i believe,
mask certain exceptions and allow others.


I'm going to jump in here with a different opinion. The rule
should be
that the plugin may never change the cpu/fpu flags. Ever. The host is
free to set the state however it pleases. The thread that calls a plugin

may be used in the host for lots of other things. The host has the
correct context to know what the fpu state should be, and the plugin
doesn't. Nor does GMPI know what the correct state should be. If we make

a decision on the processor flags that is an undue burden on the host,
because it may be regular switching of these flags in and out of
plugins, which is not a good RT practice. If the host chooses 24 bit
precision, for instance, a lot of plugins may sound bad. But the host
presumably made that decision for some reason that outweighed the
considerations of the plugin, so it should stand.

--
Mike Berry
Adobe Systems

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


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




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