Having thought about it some more I think this way of presenting defaults is fine, but I'm still not happy with the way latency or units are specified.
If latency can't be changed programatically then lets not have it in the struct (few hosts can use it anyway, and they all use RDF), if it can be changed programatically then it should be a well-known port, as it is now be convention (but possibly with a different label).
Fixed latency is not a big issue because a plugin can report the maximum latency it could ever reach, and if the actual latency is lower it can artificially delay its output internally. But i think this is ugly, particularly because of the fact that we already have a working setup with the "latency" control output which allows for changing latency as well -- and this does make sense, since latency may depend on sampling rate in a large number of cases, and since sample rate may vary almost an order of magnitude, i think it would be suboptimal to impose a needless delay on the whole processing line.
As i said before, i support everything else in Tim's proposal, which is (to me) well-thought and clean. I will adapt my reverb to make use of the new features as soon as i have a little time (few days).
Tom
