> >>> - 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). > > Why bother with normalized parameters then? > > In AU world you specify name, min, max, default value, entity (indexed, > dB, Hz whatsoever) and some flags like "Hi res", "Writable", "Readable" > etc. for a parameter plus (optionally) value strings and everything is > clear to the plug and it's outside environment. > > If your process needs to have another scale than say -100% to +100%, it > can easily transform that. That's exactly what I thought, Urs. ;) The only thing that I would like to see extended about the AU system is another parameter attribute specifying the value distribution curve. There could be constants for all of the popular ones (exp, squared, sqrt, log, pow, etc.) and perhaps even a "custom" option which then would require the plugin to specify a custom curve function, but maybe that's not even necessary. As it is now, the curve can be implied by the parameter unit type (i.e. Hz probably ought to use a log curve, etc.), but making it explicit would be an improvement, so that generic UIs could be extra nice. :) Marc ---------------------------------------------------------------------- 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