In all cases it should define a FULL FPU control state, since the only goal
here is to allow both host & plugins to be able to round to nearest (the
most common) without having to change the FPU state.
I think we all agree that all exceptions should be masked, rounding to
nearest (standard in all languages I guess). Now as for the precision..
64bit or 80bits? It still matters for divisions.
It could be required that the plugin restores the original FPU state if it
has to change it, but it'd be less efficient for it.
I think that this should be very clear, because it's important. In case a
plugin had a built-in timer, and started to change the FPU state from the
GUI thread at any time, there would be no way for the host to detect this.
This is a problem for me with VSTi's. Several VSTi's change the FPU state to
other rounding modes, and we have to restore the FPU state after the
plugin's processing, parameter change, etc. And this still can't guarantee
the plugin won't change the FPU state in other cases. You may think it
should be the normal behavior of a plugin not to mess with the FPU state, or
at least restore it properly, but apparently not for every programmer. And
we can't even tell them it's a bug, because the VSTi specs aren't clear
about it.
More, if you change the FPU state and don't clear pending exceptions before,
you'll get an exception.
Yes, especially if this could be set up as a mechanism whereby it's the host's responsibility to ensure that the plugin audio processing thread always takes place in a NaN - free context without the plugin having to fiddle with FPU registers/add noise/use offsets ;-)
NaN-free? i don't understand what you might mean by that ... I agree with Angus that we need to define the rules for these shared resources (other examples might include X colormaps, which are vaguely analogous to part of a resource context in MacOS). But NaN-free? what happens when a plugin divides by zero?
---------------------------------------------------------------------- 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
---------------------------------------------------------------------- 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
