I don't have any SGI machines left to test things on... so if the MIDI queue stuff actually works on SGI machines that's great, but I'm scared to throw it in without testing it...
cheers Miller
On Tue, Oct 15, 2002 at 11:01:25PM +0200, Sukandar Kartadinata wrote:
Hi again, as I've been having a closer look at the scheduler, I was wondering about one thing: why does s_SGI.c call the MIDI functions in x_midi.c directly, while all the other implementations use the MIDI queue in s_unix.c
just curious - not that I plan to implement MIDI, but me too has to schedule events....
Thanks, Sukandar
also here's a copy of my last post which I sent to the wrong list (just in case someone only reads pd-dev...):
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
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev