[gmpi] Re: Reqs final draft

Didier Dambrin wrote:


Well, I think that this is an undue burden on hosts. Lets say GMPI chooses to require me to mask exceptions, but I don't like that decision 



ok but.. why?

doesn't it make sense that an exception due to the math unit is the LAST thing you'd want in your mixing thread? Those can crash an app real bad.

Catching exceptions is great.. when you debug your code.

I was only making an example. My point is that the CPU state that GMPI chooses may not be the state I as an application developer choose. To put it another way, what if the GMPI state is not one that you the plugin developer like. Then the host is going to switch the state to the GMPI state, and then the plugin will change it again (possibly back), then restore it, followed by the host restoring it again.




for my host. Then for every GMPI plugin I have to change the CPU flags on the way in and the way out, even though most plugins won't care. If it is the plugin's responsibility, then only the plugin's that care will need to make the change, and only if the host has a disagreement with the plugin and has the thread set differently. Or, even better, the plugin can simply run in the environment set by the host, even if that means that the plugin may not sound its best in a particular host.


Note that the FPU precision can be critical in some cases. There are fast tricks to truncate floats, and if the precision is not what you expect, they will just not work. But ok, a plugin that uses them will probably set the precision itself for safety.


And more: restoring the FPU state is just a matter of setting it when you know it's a constant. When you don't know, you will first have to read it. Today's hosts render in smaller & smaller slices (considering the user always wants a shorter latency), playing with the FPU state all the time can waste a little CPU - won't be huge, but it's still wasted.

I agree - it is wasted time I want to avoid. I suggest that the host never have to change the state, and that plugins simply assume that the host wants the plugin to run in that state, even if it makes the plugin sound nasty.

Second, if you as the plugin developer really really don't want to run in the state provided by the host, you only have to test it once per processing run. If you don't like the state, then you can do the change and restore. Each subsequent process call you know the state to change to and the state to restore. No more testing, and lighter weight than the host version.

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

Other related posts: