I think the score sort should be internal and binary. I also think that the
score should be translated into on events and off events, and that MIDI
events also would go into this sort in temporal order. That way, the MIDI
notes and the score notes could be handled the same way by the opcodes. In
other words, regular "i" statements would come in through the MIDI opcodes
in addition to the normal procedure. This would enable instrument designers
to leverage their work for both real-time and non-real-time purposes.

For this to work, the "on" event would contain all the information of the
"i" statement or current srt file, and the "off" event would be
substantially identical except that it would have an "o" opcode or something
like that, and no duration.

I think the format of the srt file should be changed to accomodate this
approach, but the "i" statement format need not be changed. Perhaps there
could be an additional score opcode "m" denoting use of the srt format
directly in the score.
-----Original Message-----
From: jpff@maths.bath.ac.uk 
To: csound@maths.ex.ac.uk 
Date: Tuesday, April 27, 1999 8:19 AM
Subject: Re: wave file length accurency


>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.
>
>==John ffitch