11 Apr
2011
11 Apr
'11
10:52 p.m.
On 10/04/11 06:21 PM, Tim Goetze wrote:
[Jeff McClintock]
No, the pragmatic thing to do is not deliberately break your plugin when
several knowledgeable people have pointed out that doing so can cause
countless problems.
One test with one version of one host certainly does not outweigh that..
particularly when one of said knowledgeable people is the primary author
of that host!
-dr
What happens when you modify version-1 of your
plugin and remove a port
(making Version2), then later re-add a new (unrelated) port with different
semantics? (Version 3)... Then load a project created with version 1.
Does the host in THIS situation set the new port to it's default value, I
doubt it. More likely it 'restores' it to some invalid setting.
Do you want a fragile, crash-prone, plugin ecosystem?, or a robust one?
The plugins in CAPS clamp all control inputs to the valid range.
Whatever the host sends, including inf and nan, there is no "invalid"
setting. Moreover, the plugins will not crash even if run without
connecting their control ports at all.
The above experiment, by the way, is exactly what I did, and it did
not cause any abnormal behaviour: no crash, no segfault, no bus error,
no assertion failure in any part of the executed code; no inf or nan,
not even a single sample value of or in excess of 1f absolute in the
audio output.
I think your fear of a fragile and crash-prone plugin ecosystem is
unfounded and exaggerated.
I Agree with Paul on this one.
I can very well see how a host author would want plugin port
signatures to be stable, and I was never happy about invalidating this
assumption.
However, the evolved plugin doesn't even break ardour or its session
files, so the pragmatic thing is to just get on with it and not waste
as much breath on a triviality like this as we do now.