Message written at 27 Apr 1999 10:12:54 +0100
--- Copy of mail to jlemoin@ibm.net ---

Some time back while I was away there was a discussion about
innaccuracies in the length of time of notes.  I have been thinking
about this a little and I think there is a problem on some platforms
in the printing of the score.srt and re-reading the numbers.  This is
done with standard C IO routines, and on some implementations these
seem highly inaccurate.
  I can think of a couple of ways round this.  Perhaps teh simplest
would be to write the score.srt file in binary rather than characters,
and so preserve all teh bits.  This woudl of course mean that one
could not guarantee that one could transport the score.srt file to
another machine -- does anyone actually do that?
  A second approach would be to write ones own printing and reading so
it would be consistent, but that sounds liek real work!  
  Or, we could abandon the external sore.srt and use in-memory data
rather than an external file.

So, any thoughts or recommendations?  I am willing to do the coding if
we have a reasonable consensus on what to do.

>   Or, we could abandon the external sore.srt and use in-memory data
> rather than an external file.

i would vote for this - with a temp.srt file for large
scores that cant fit in memory - and blow away the thing automatically
when done.

-matt

>  I can think of a couple of ways round this.  Perhaps teh simplest
> would be to write the score.srt file in binary rather than characters,
> and so preserve all teh bits.  This woudl of course mean that one
> could not guarantee that one could transport the score.srt file to
> another machine -- does anyone actually do that?
>  A second approach would be to write ones own printing and reading so
> it would be consistent, but that sounds liek real work!  
>  Or, we could abandon the external sore.srt and use in-memory data
> rather than an external file.

I vote for the first option. Using a binary score.raw would
both be precise, and would cause a speed-up in both writing
the file, and reading into CSound.

(One could even add an external score.raw->score.srt converter,
 so that the sorted score could be translated back to ASCII,
 if really neccesary)


// Anders  (Optimize! Optimize! :D)