Are events of singular points guaranteed to be fired?

Imagine this scenario:

• You register a singular cuepoint at 1.25.
• The sequencer checks the current position, reads 1.1, and fires nothing.
• The sequencer's timer "ticks" again after 0.2s.
• The sequencer checks the current position and reads 1.3.
• Is the cue point for 1.25 skipped?

[ingararntzen]

It will be fired yes.

…

On Sat, Aug 5, 2023, 02:03 Kaito ***@***.***> wrote: Imagine this scenario: - You register a singular cuepoint at 1.25. - The sequencer checks the current position, reads 1.1, and fires nothing. - The sequencer's timer "ticks" again after 0.2s. - The sequencer checks the current position and reads 1.3. - Is the cue point for 1.25 skipped? — Reply to this email directly, view it on GitHub <#31>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLUZOXZRATW5JANNERLW2TXTWEWJANCNFSM6AAAAAA3E2CIBI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

I have tested it and it worked, but I was wondering if it is guaranteed (meaning required) by the spec.

The docs simply say that singular points' events are emitted during playback.
Also, the fact that it checks the exact time position made me worry.

Events

singular points

Intervals that are singular points will emit both “enter” and “exit” events during playback. If the timing object is paused precisely within a singular Interval, only the “enter” event is emitted, just like a non-singular Interval. The “exit” event will then be emitted as the position is later changed.

The "event delay" subsection is not clear.

It suggests that the Sequencer will handles this case (replaying events that should ideally have been emitted earlier) if it the TimingObject has a TimingProvider.
But what if there is no TimingProvider?
Must the Sequencer emit events that should ideally have been emitter earlier were it not for the period gap between tick (timeout) calls?

event delay

Note that event delay is not a direct measure of the timeliness of the Sequencer. This is because dueTs is derived from the timestamp of the underlying timing object. In particular, whenever a timing object connected to an online timing resource is updated, the effects will suffer network delay before clients (Sequencers) are notified. The Sequencer is aware of the distributed nature of the timing object, and takes such delays into account. In short, the Sequencer replays events that should ideally have been emitted earlier, were it not for the network delay. This effect can only be observed for a brief moment following “change” events from the timing object. In these cases, dueTs effectively means the time when the event would have been emitted if network delay was zero. This behavior of the Sequencer also ensures consistent behaviour between distributed Sequencers (provided that they are working on the same collection of timed data).

[ingararntzen]

Hi. Thank you for this feedback.

The doc for version 2, which I think you are referring to, is not maintained any more. Please use the version 3 doc instead.

1. Singular points. Yes events are fired during playback (velocity != 0), and they might also be fired when the timing object changes in some way (position changed, velocity changed). Playback is regarded as continuous movement, so there should be exactly one enter event and one exit event for each point which is exited or entered. If the positition of the timing object is updated discretely (skipto) - this is not a continuous movement, so no intermediary points are passed. Events will only reflect exiting previous position - and entering new position. The key idea anyway is that observer should be able to trust the event sequence from the sequencer to be correct. Also, singular points trigger events exactly as regular intervals, with the execption that they are shorter (i.e. length 0).

2. I agree that the section about event delay is confusing. I think this was removed in version 3. In any case, whatever the delay in execution (busy webpage or otherwise), the sequencer is obligated to provide a correct sequence. This implies that all events that "should have been emitted" since last sequencer invocation, must be emitted.