Closed rtoy closed 6 years ago
Since I have discover that the OscillatorNode.start()
can't schedule a stop (and so we have to schedule a .stop(when)
, I am wondering why is there a duration
attribute for ABSN.start()
?
This can produce a situation where somebody write a scheduler for ABSN only by using .start(when, 0, dur)
and never .stop(when+dur)
, and after this is done, the scheduler is not naturally compatible with the OscillatorNode
interface which has not .start(when, duration)
.
So why keeping two ways to schedule a stop on ABSN?
Good question. I think this is an historical artifact. I think the duration
parameter is to support playing of "grains" so you can specify a short section of an AudioBuffer to be played via start(when, offset, duration)
. This makes sense for an ABSN, but not an Oscilaltor.
But as mentioned in #421, it wasn't really clear what happens when looping is enabled. Hence, duration is defined to be equivalent to stop(when + duration)
. This makes it compatible with the non-looping case, and gives a well-defined meaning when looping is enabled.
Why not add an optional parameter "endSampleTime" to "start"-methode and change loop-definition to duration and/or endSampleTime? In this way the sound will stopped if endSampleTime or duration is reached. If duration is null or undefined and no endSampleTime is given, loop sound will played infinitive.
I think it's way too late to consider changing it now; you'll break existing apps.
Maybe for the next version?
It would be nice if there will be an addional paramter in next w3c start-method-definition to define an endSampleTime. So, if duration is not given or extremly high, the sound will stop at this given sample time. This allow to use sound atlantes in browsers in the furture.
I was going to update the title to reflect better what the request is here.
But I can't tell now. @mamekudz suggests adding an additional parameter endSampleTime
, but from comments https://github.com/WebAudio/web-audio-api/issues/1387#issuecomment-333873653 and https://github.com/WebAudio/web-audio-api/issues/1387#issuecomment-334792214, I can't really tell what this is and how it really differs from duration
.
Hi rtoy, it's about the end of sound condition. If the new definition should be based on the duration parameter, also if loop parameter is set to true, the additional paramter is very important. The additional parameter defines an additional condition to end the sound. If an endSampleTime is defined, the sound will stopped eigther the duration time is reached or the stop sample time (the time without loop, it is the real sample number inside the sound without loop calculations) was played. This is important if there are a sound atlantes where after the sound, which is currently played, an other sound follows. Every synthesiser uses sound atlantes to create sounds with multiple samples for different frequence areas and this feature is needed to implement browser synthesisers easyer. So a second "endSampleTime" parameter will be very helpfully. It is the simple synthesiser function: the user press the key (attack part), hold the key (loop part) and you don't know how long the user will press the key. If the key is released, the rest (release part) of the sound should be played, irrespective of the duration time defintion of the complete sound. Regards Meinolf
Let's leave this as the editorial bug on the clarity of the spec text which it was when @rtoy filed it. We don't see the need for these other changes; please file different issues.
Wow, debugging by changing the description. I think, you have not understand the problem.
No, the actual bug that I filed was that the spec was not clear in a couple of places about what duration meant. It is you and others who piled on and morphed the issue into something else.
Now https://github.com/WebAudio/web-audio-api/issues/1387#issuecomment-342673667 just says the intent is to clarify the original spec text on just this original issue. All of the other points raised should be opened and handled in other issues.
I recommend you open a new issue stating clearly what you think is missing and the use cases for it. Possibly linking back to some of the discussion here if needed.
Closed by #1395 file a new issue as requested
In https://webaudio.github.io/web-audio-api/#looping-AudioBufferSourceNode, we say:
This kind of implies looping continues forever, independent of any specified
duration
used instart()
, as mentioned in https://webaudio.github.io/web-audio-api/#dom-audiobuffersourcenode-start, which says that specifyingduration
is the same as callingstop(when + duration)
.I think this needs to cleaned up a bit. It's causing some confusion on what the
duration
parameter tostart()
really means. See https://bugs.chromium.org/p/chromium/issues/detail?id=769634#c8