Sequence can't be re-scheduled if Transport is cancelled.

[Nearoo]

Not sure if this behavior is intended, but it feels very counter intuitive. It appears that I can schedule a Sequence to start at most once. If I cancel the Transport afterwards and re-schedule it again, it won't start anymore.

To Reproduce

Here's Codesandbox that demonstrates the issue. What I'm doing is this:

• I instanciate a Sequence object
• When pressing "start", I first cancel the transport (i.e. clear it of all scheduled events), then schedule the Sequence to start at time 0 by invoking Sequence.start(0).
• Pressing "stop" simply stops the Transport.

If you now press "start", the Sequence will work as intended, the callbacks gets called repeatedly, until you press "stop". However, if you now press "start" again, and the Sequencer does not works as intended, and won't call its callback.

Expected behavior The sequencer to start calling the callback every time I press "start".

What I've tried ToneEvent behaves the same way.

[Nearoo]

Looking a bit into the source code, I think I found the problem. ​Looking at the code here, it seems the events that trigger the callback of the Sequence are only rescheduled when calling start(t) if the internal state of the Sequence is considered stopped at time t.

That state is not updated if the Transport is cleared. Thus, if the Sequence was running while the Transport was stopped, the Sequence will consider itself to be running even if all events are cleared. As a result, when calling start again, it won't reschedule the events, and so no callback will ever be triggered.

A workaround is to call Sequence.stop() right before calling start again, like this. Not sure how robust that is though.

[Nearoo]

I ended up implementing my own scheduler, with a slightly different sets of constraints; I didn't need a seekable, permanent timeline, but I did have to be able to schedule events in a non-monotonous fashion. It works similar to setTimeout, but with the precise callback time as an argument to callbacks.

I wondered if that design might benefit tone.js as well. I see two benefits:

• It does allow a permanent transport to be build on top of it, similar to tone.js' current transport. Since the scheduler doesn't care about event time monotony, events can be added and removed while the transport is running without problems, contrary to tone.js transport; and transports can easily be "chained", in that one transport event can trigger the start of another entire transport, also contrary to tone.js "Part". Multiple transports can run at the same time with different speeds without issue.
• It also allows turing-complete programs to schedule events arbitrarily without worrying about monotony, including as a reaction to previous events, which might be interesting for programmatic music creation.

Let me know if you're interested. The issue itself can be closed.

[giohappy]

Interesting. Are you going to share your scheduler?