Add offset between context.currentTime and clock current time

[echo66]

Greetings!

Suggestion: save the context.currentTime when "start" is invoked and use that to establish an offset between the clock start time and the audio context time. This way, the time of the clock events are relative to the clock time.

[sebpiq]

There should be only one reference time, and this is context.currentTime. You can schedule things either relatively to current time by using WAAClock.setTimeout or absolutely with WAAClock.callbackAtTime.

I don't manage to see a use case for having a local time relative to the start time of the clock. Can you explain?

[echo66]

Imagine you are using WAAClock in a DAW. You could advance and go back in time in the DAW timeline. If you use the context.currentTime, you need to reschedule all the timeline pieces/events each time you advance or go back. If you use WAAClock currentTime, you don't need to reschedule the pieces/events in that situation.

[sebpiq]

Alright, I understand the idea, but the problem is that to schedule some event on an AudioNode you will always eventually need to know the time in the reference of the AudioContent.currentTime. Consider the following case :

// timeInClockReference is relative to an hypothetical "WAAClock time"
var timeInClockReference = 10

clock.callbackAtTime(function() {
    // here time is relative to context.currentTime! 
    // So you gotta convert the time timeInClockReference to a time in that reference
    aBufferSource.start(time)
}, timeInClockReference)

So in the end it really wouldnt help

[echo66]

If you do not save the offset between the start time and the context.currentTime, you have that problem.

I'm hacking a small solution for this issue. Give me 10 minutes and I will get back to you, @sebpiq .

[echo66]

Sorry for the (big) delay.

Can you take a look at the code I just uploaded?

[echo66]

By using such solution, we can have many independent schedulers for one audio context (for whatever reason one may need that).

[sebpiq]

It doesn't matter in what reference you specify when an event should occur. When in a WAAClock callback you need to schedule something on an AudioNode, you still need to express it in the AudioContext.currentTime reference (see my example above).

I understand why you would want such a feature, but if you want to be able to express time in a different reference than AudioContext.currentTime you need to build an extra layer not only on WAAClock, but also on each method of AudioNode or AudioParam taking a time argument. I prefer to keep WAAClock very low-level and simple, therefore I won't include such a functionality in the library. Sorry :(

[echo66]

I understand your position. Farwell, thanks for the discussion, @sebpiq .

[sebpiq]

Thanks for the suggestion :)