[PD-dev] MIDI scheduler

[Miller Puckette]

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 at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev