-

[ghost]

[Danielku15]

I'm not sure if I can follow. Which exact events are you referring to? For midiEventsPlayed I would expect them to be exactly reported once when they were played. . playedbeatchanged
should also only be triggered whenever the beat hanges.

To get a common understanding it is always good to bring concrete examples: What events are you using, how are they behaving today, what do you trying to build and what prevents you from doing so.

[Danielku15]

Ah, I think I understand now. The current events are indeed not very helpful to detect all played beats/notes through events. As you explain: The event is heavily based on the cursor flow. The reported beat in playedBeatChanged is the one the internal system detects as the next one being played and are visually displayed, or differently explained: To which beat will the cursor move next.
If multiple beats are played and multiple voices are shown, you only get one beat, and it might be on different voices, tracks etc.

This is a known limitation and is going to be addressed in #722. The future new event will allow you to receive events whenever any beat starts playing (and likely I will also add an event when they stop playing).
As described in the other discussion and the feature issue: Internally we would know already all beats are playing and which ones not. We use this for highlighting them.

Are these events temporal!?

What I was asking is "the actual behavior in the version you are using today". Any events might be changed/improved over time as part of new releases. Hence the exact version and behavior that we talk about "today" are of relevance. 😉