The events in the score are positioned on a temporal grid that depends
on the control rate and `csound->icurTime' is increased of ksmps after
every k-cycle. It means that we could have problems with `csoundScoreEvent'
during the programming with the Csound API because it uses

  insert_score_event_at_sample(csound, &evt, csound->icurTime);

Example:

  - 1 thread with `csoundPerform' + INF score in RT
  - 1 thread to send the events with `csoundScoreEvent'

  No problems with only one event, but we can get a time delay
  (1/kr + score grid quantize) with more `csoundScoreEvent' that
  happen among two k-cycles.

The very simple solution that I would like to apply is a new

  PUBLIC int csoundScoreEventAbsolute(CSOUND *csound, char type,
                                      const MYFLT *pfields, long numFields,
                                      double time_ofs)

      .... /* like `csoundScoreEvent' */

      return insert_score_event(csound, &evt, time_ofs);
  }

In this way we are sure that

  time_ofs = csoundGetScoreTime(cs) + LITTLE_LATENCY;

  for (i=0; i<100; i++)
    csoundScoreEventAbsolute(cs, 'i', pfseq[i], numFields, time_ofs);

won't fail (without considering the Murphy's law). Besides, I think that this
function adds flexibility to the programming of the score from the API. 
For example it is simple to send the same pfields for a delay effect without
modifying the p2 values.

Let me know if I can add it.

tito

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net