[gmpi] Re: Reqs final draft

I agree with Didier.. if the plugin developer cannot rely on the CPU state, they will have to set it.

I feel that GMPI should be able to spec a state which is acceptable for 95%+ of plug-in operations. For *most* plug-ins, it's not so much that a particular behaviour is vital, but that *PREDICTABLE* behaviour is vital. It's easy to write code to deal with the behaviour, as long as it's the same everywhere. Bear in mind, a lot of less experienced plug-in developers aren't even aware of these kind of issues - in today's plug-in architectures, they run in to problems where code that works on one host will break on another.

For the small percentage of plug-ins that need a specific state, they can still set-and-restore.

Yes, this imposes an extra burden on the host, but given that, in a lot of hosts, most or all of the plug-in processing is done together in one block, the host will not have to do this too often - set the state, process all the plugs, set it back.

Regards,
      Angus.



Mike Berry wrote:

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.



--
=========================================================
Angus F. Hewlett, Managing Director (CEO)
FXpansion Audio UK Ltd - http://www.fxpansion.com
Registered in the UK - #4455834 - VAT: GB 798 7782 33
========================================================= 


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