On Tue, 16 Nov 2004, Tim Blechmann wrote:
the problem is still ... what if a useful patch will be rejected? as miller pointed out at the convention, he won't add the simd stuff, because he feels, he can't maintain it. but still the simd instructions are very useful, since they provide a speedup of about 100% ... the intention is very good, but still, it doesn't bring us further ...
although i don't like the idea, but in this case a "pd extended" might be some way to publish the devel branch at a point, we consider as stable ... (at a certain point earlier this year, devel_0_37 has been more stable than 0.37 in terms of denormal handling)
another way would be the possibility of having maintainers for certain parts of pd ... so if someone submits a patch, he should be say that he will maintain that piece of code in future ...
I think the situation is somehow comparable to the patches that exist against the linux kernel. Some of then live a life of their own during several kernel releases, then at some point the get included (well, or not). There are people who distribute patched kernels too. I, for example might be tempted to distribute a version with simd within Debian. But I would prefer to do that with a patch that gives me simd, instead of using the complete devel branch.
Maintaing the simd improvements apart is a viable solution too, if you can separate them enough that they can be activated by a configuration setting they should not get into the way of normal operation.
Guenter