Closed mulshine closed 8 years ago
Could be that notes are still added to the cluster until after the clusterThreshold is surpasses, but the synchronicNotes start happening when they should 400ms after first note. This would result in the possibility that notes could be added to the set of current synchronicNotes as they are pulsing.
that is correct! the pulses begin while the cluster is still being formed, so it gets larger with each new note, but its phase remains unchanged.
On Nov 9, 2016, at 6:11 PM, Mike Mulshine notifications@github.com<mailto:notifications@github.com> wrote:
Could be that notes are still added to the cluster until after the clusterThreshold is surpasses, but the synchronicNotes start happening when they should 400ms after first note. This would result in the possibility that notes could be added to the set of current synchronicNotes as they are pulsing.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Princeton-CDH/bitKlavier/issues/3#issuecomment-259553694, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKpmttX8DK-4RLYSO3qF8iuS7V-kFrf1ks5q8lMFgaJpZM4KuFuC.
and note that the behavior is the same with last-note-sync, except that the phase gets reset with each new note added. the pulse can start while the cluster is still being expanded.
What happens if the period of the tempo is smaller than the clusterThreshold in FirstNoteSync modes?
i.e. Tempo = 150 (period == 400 ms), clusterThreshold = 500ms, beatsToSkip = 0 . This test case within current functionality would result in 100ms blip (500-400): a pulse is supposed to happen at 150bpm, 400 ms after the first note, but a new set of synchronic notes cannot be configured from the cluster until the clusterTimer surpasses the clusterThreshold (500ms after first note). So the first note will come 100ms late.