I will state my current implementation of such a feature, and let you decided if its good / bad / ugly :D

enum TrackState {
  TRACK_STATE_NORMAL,
  TRACK_STATE_EVENT_QUEUED,
  TRACK_STATE_EVENT_NOW,
};

process()
{
  if ( state == TRACK_STATE_EVENT_QUEUED && time == topOfTrack )
    processQueuedEvent();
  else if ( state == TRACK_STATE_EVENT_NOW )
    processNowEvent();
   // process your MIDI output or whatever your doing..
}

I'm storing all the "events" in a ringbuffer that another thread can write to, so say GUI stuff all gets updated trough "Event::setX()" style functions, and then they're read "raw" on the other side (public member variables..) its not strictly OOP, but I don't want to write the 30+ functions & structs* to pass back exactly what is expected every time :)

I think its a pretty OK way of going, each track will have a "TrackState" variable, and that tells you everything you need about the track. Of course if you want to have multiple things like playing - paused - relocating, as well as normal - queued - now, then you should convert them to bitfields, or separate enums to keep yourself sane...

I've just the one, but my "BufferAudioSource" doesn't have that many states that can be active at the same time, so I've just kept it like above. Simple :)
HTH, -Harry

PS: Re RT-ness, enum's are just ints, so its a RT safe & cheap.
PSS: Perhaps you could elaborate on what these "Events" could be, like just a single event per track, or are we talking hundreds?