Timing

[walterbender]

pikurasa:
If we could design MB2.0 to not need the user to specify "No Clock", then I think it would be easier to use.
Perhaps, MB could infer from the structure of the code whether or not to use "No Clock" block.
Otherwise, we may need to give users some debugging "warnings", which may not be bad anyway.

meganindya
We intend to use a scheduler called Transport, provided by tone.js. One of the main objectives is ideally to cut down on a lot of the runtime complexity which causes unwanted drifting. Can't tell about the performance yet though.

No Clock serves a somewhat different purpose than compensating for drift. It is for inserting things into the schedule independent of the "internal" clock. We probably don't need it if we switch to using Transport.

However, there is a slightly different problem we do need to address. When something is added to the schedule, do we want to force alignment to the master beat? e.g., start on the next beat? or start on the next strong beat? or start on the next measure? or start now.

[meganindya]

Wouldn't that be forcing the user to have sufficient understanding of the concepts? RN we allow any random value on the note.

[walterbender]

I am perhaps not explaining myself clearly.

Here are two examples:
(1) a canon where when once finishes, it broadcasts a measure for the next voice to start. It would be expected to align to the next measure.
(2) in an interactive scenario, e.g., a video game, when a character's theme music starts due to some button press, it might be desirable to align with the theme music rhythm so as not to introduce an unexpected polyrhythm.

[pikurasa]

These are good examples.

The majority of projects, however, seem to steer more for a "start now" functionality. Therefore, it may be better to require "start on beat/measure" be explicit rather than the other way around.