oh, and the 32bit integer version of phasor~ sounds quite alright. Thanks for the suggestion. (Couldn't find it in CSound though)
Where do you have it from ?
oh, just did some quick (dirty) coding myself not much to do for a phasor than some simple accumulating and only slightly more difficult for the other oscillators (and a good excercise in dsp, after all that system design in the past years)
Regarding the timer and stuff, I have a fixed point pd version for the iPaq, which is halfway done, I would be happy if we could team up.
I'd be happy to exchange ideas where possible ! However, I think our general goals are slightly different as I try to stay as close to the original distribution as possible, while I assume that you have spawned off quite far with your pure integer implementation, no? So I guess we couldn't even exchange oscillators. (could send you the code though if you're interested)
But for the timers I'd be curious how you handled this. Do you reduce the timing precision with a single 32bit int ? Or use two of them ? But then this would require much more changes to the code (operator overloading would come handy here...). Maybe not a problem for you if you're rewriting most of the code anyway. Anyway I decided to stick with double for now as it's working OK and there are more important issues to solve. Maybe I'll try something with a forced fixed point representation (like the original phasor~ code), so I can keep double for the calling files, and restrict the code changes (some simplified double arithmetic) to m_sched.c and s_unix.c
Q: would it be possible to define timing variables/functions with something like t_systime instead of double ? That would make certain things easier... (also, I'm kinda confused about the mixed use of float and t_float - is there a scheme behind this ? And while I'm at it: why is printing and error reporting encapsulated in s_print.c but still many fprintf commands etc. in other files ? (if this just needs some spring cleaning I'd volunteer....:))
best, Sukandar