Hi! I finally updated the gluiph to 0.35 as well as the newest TriMedia SDK, and basically everything's still working with a few noticable improvements.
One of them is the faster handling of double precision floats, however it's still a software emulation and thus to be avoided. So of course I stick with my fractional phase implementation of osc~ and friends.
Now, the disturbing thing was that I only learned today that floating point constants are treated as doubles unless they're suffixed with an F. For some reason I'd always thought that it's the other way around (i.e. doubles have to be tagged with a D), but the TriMedia Docu as well as MSDN tell me that the implicit double is ANSI compliant.
So one F added to my osc~ implementation, and boom, 7x faster for the critical code section!
So far so good - but after some browsing thru the pd source it seems there's lots of places where the F is missing but surely no double precision is intended/required. I assume for PCs this only causes a small performance hit as the FP ALU does doubles in hardware so there's only the additional memory access for the extra 4 bytes (if at all).
OK, so I guess I have to find all those constants by hand and hit that F key. Bad enough. The real issue though is that I probably have to do it again once 0.36 becomes available.
Which brings me to my actual question: Could I check out the latest version of the CVS, make my changes (which might affect a lot of files), commit them back to the CVS, and everything's fine for future releases? Or would this create a separate branch off of the standard release? Or does Miller have to decide for every change being made if it should be rolled into the standard release?
Sorry if this sounds a little dumb to the CVS pros, but this version control stuff is all rather new to me. And maybe it's actually not so much the technical questions but the social/political ones, i.e. who decides what changes are valid.
Thanks, Sukandar