On Tue, 2 Apr 2002, Sukandar Kartadinata wrote:
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?
Yes, right, originally I wanted to stay close to the original, but it prooved to be to much hassle to do so, at the end the iPaq has other limitations too, not only floating point but screen size, fonts etc. ...
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.
Well, I just replaced the time stuff int the scheduler loop and sys_getrelatime() to int. So I left the clock_ functions the way they are, at least something I have tio think about yet.
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
If I understood you right, your problem isn't floating point in general but double precision ? The scheduler loop for the arm processor eats up 40 % of the CPU when using a double counter ...
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....:))
the float and t_float issues definitely need cleanup. but thats not all there is t_sample (which is the sample type, defaults to float). There is t_float, which is used for floating point messages more or less, and there is t_floatarg, which is the type of floating point numbers passed internally for pd functions.
What can be seen by this setup is that, once cleaned up, it should theoretically be easy toswitch from float to double precision within computations. (Well not for the "magic" oscillators implementation).
Finally, a timer type would help my efforts of beeing able to choose between types for the timer..
Greetings,
Guenter