What was wrong with the 'a' event is that it did not produce the proper behavior when I tested it. If you can get it to produce the proper behavior, I'll be happy to put the 'a' event back, since I do understand what you are saying about MIDI files.

The designed behavior is this. Suppose the host is performing a Csound score, and the user has set a loop that begins at bar 5 and plays through bar 8. When the use presses "Play", Csound should immediately begin playing from bar 5 in the score, play through bar 8, and immediately jump back and begin playing from bar 5 again. (In reality, the times are calculated in sample frames.) 

I will try putting the 'a' code back and playing with it to see if I can get this behavior.

As for pause or mute, in this context they are functionally equivalent, because when a host loops over a section of score (which is what these APIs are all about), the host will always execute the sequence of calls that I quoted from CsoundVST. Therefore, muting instead of pausing is an acceptable implementation, because the host will immediately reset the score offset at the same time as it un-mutes, which has the same effect as un-pausing. If you can come up with a more efficient or better way of doing this, that would be great. Of course, my approach has the advantage of being brain-dead simple and apparently lackiing side effects.

In real life, in the context for which I designed and implemented this API, setting the score offset before actually performing has no meaning and no effect since the host will always do that over again when it starts looping. That's why I removed setting the score offset from Csound itself. Only the host should be setting the score offset, Csound should only be responding to it.

I feel a need to remind people that I designed and originally implemented these APIs, and they used to work. Therefore, any changes that are made simply must produce the originally designed behavior. I am glad to learn about the faults and shortcomings such as problems with MIDI files etc., and I welcome any thoughts or contributions to improve the code, but the fact is that my fixes do enable synchronization of Csound scores with notation and real-time MIDI performance in VST hosts, and this is much better than the way it was.

If anyone wants different behavior, and I don't agree that that behavior is correct for these APIs, then they should define new API calls for their desired behavior.

Regards,
Mike

-----Original Message-----
From: Istvan Varga 
Sent: May 11, 2005 4:50 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Score Rewinding

Michael Gogins wrote:

> In musmon.c and in csound.c, I removed the code that inserted an 'a' 
> score event to advance the time,

What was wrong with that ?

> and I added code that simply subtracts  the offset seconds from the current
 > score time and beat.

Which will not work at least in the case of MIDI files (unlike 'a', which
did), and beat mode.

> I also added code to test for csoundIsScorePending_. If true, processing 
> is exactly as before. If false, processing is also exactly as before, 
> every score event is read, times are computed, and so on, except that 
> 'i' events are simply not inserted into the performance, so they don't 
> sound.

However, this does not pause playback, but rather than that, mutes events.
And, needless to say, has no effect at all on notes from MIDI files.

@@ -305,11 +305,8 @@
        csound->Message(csound, Str("playing from cscore.srt\n"));
        O->usingcscore = 0;
      }
      csound->Message(csound, Str("SECTION %d:\n"), ++ST(sectno));
-    /* apply score offset if non-zero */
-    if (csound->csoundScoreOffsetSeconds_ > FL(0.0))
-      csound->SetScoreOffsetSeconds(csound, csound->csoundScoreOffsetSeconds_);

Why was this removed ?

                                       /* since we are running in components */
      return 0;                        /* we exit here to playevents later   */
  }

@@ -796,10 +795,10 @@
          case 'q':
          case 'i':
          case 'f':
          case 'a':
-          p->nxtim = (double) e->p[2] + p->timeOffs;
-          p->nxtbt = (double) e->p2orig + p->beatOffs;
+          p->nxtim = (double) e->p[2] + p->timeOffs - csound->csoundScoreOffsetSeconds_;
+          p->nxtbt = (double) e->p2orig + p->beatOffs - csound->csoundScoreOffsetSeconds_ / p->beatTime;

p->nxtbt is wrong. You did assume that tempo can never change during performance, right ?


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> What was wrong with the 'a' event is that it did not produce
 > the proper behavior when I tested it. If you can get it to produce
 > the proper behavior, I'll be happy to put the 'a' event back, since
 > I do understand what you are saying about MIDI files.

You still did not describe what the expected "proper behavior" is in the
context of the API (and not Cubase and CsoundVST of which I use neither).
However, I guess that while skipping time you do not want the perform
functions to return for every single skipped frame. So, I reverted to the
old code, but changed csoundPerformKsmps and related functions to not return
until the advance is complete and the requested time is reached.

> As for pause or mute, in this context they are functionally equivalent,

No, an API call should do what it is documented and expected to do,
and not just what is functionally equivalent for a single specific host
application. It may very well make sense to have a function that mutes
notes in this particular way, but then it would better be named something
like csoundMuteNonMIDINotes().

> Of course, my approach has the advantage of being brain-dead simple and
 > apparently lackiing side effects.

It also mutes all non-MIDI real time events (line events, event, schedkwhen, etc.).
Does that count as a side effect ?



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net