Aha, yeah that's what I thought. :-)
How about playbackTime?
On Thu, Jul 26, 2012 at 4:04 PM, Stuart Memo <stuartmemo@gmail.com> wrote:
> Sorry, I actually meant that the other way round! Dev and canary - yes.
>
>
> On 26 July 2012 23:58, Stuart Memo <stuartmemo@gmail.com> wrote:
>>>
>>> Can anyone tell me if AudioProcessingEvent.playbackTime or
>>> Oscillator.noteOn are implemented in the Chrome beta, dev, or canary
>>> channels? I like to play with this stuff empirically, and neither of
>>> those exist in Chrome stable...
>>
>>
>> Oscillator.noteOn is only available in the stable and beta releases I
>> believe. In dev and canary an oscillator runs without noteOn starting it.
>> You can simply use the following to stop it throwing any errors...
>>
>> if (typeof oscillator.noteOn !== 'undefined') {
>> oscillator.noteOn(0);
>> }
>>
>> Hope that helps!
>>
>> - Stuart
>>
>> On 26 July 2012 23:45, r baxter <baxrob@gmail.com> wrote:
>>>
>>> Can anyone tell me if AudioProcessingEvent.playbackTime or
>>> Oscillator.noteOn are implemented in the Chrome beta, dev, or canary
>>> channels? I like to play with this stuff empirically, and neither of
>>> those exist in Chrome stable...
>>>
>>> By my testing, AudioProccessingEvents are sample accurate relative to
>>> one another (see: http://jsfiddle.net/eZPJh/), and I think this is the
>>> intent of the spec draft (says, bufferSize "controls how frequently
>>> the onaudioprocess event handler is called and how many sample-frames
>>> need to be processed").
>>>
>>> If I'm right about this, I think it's preferable to polling in a
>>> busy-loop with either setTimeout/setInterval (ugly ~+/-50ms slop in my
>>> experience - really bad / error-prone for audio), or
>>> requestAnimationFrame (presumably sample-accurate, but a more complex
>>> idiom, and outside of the audio API). ... A drawback to this would be
>>> forcing the use of jsNode, which seems like a leap if one just wants
>>> to schedule start/stop of oscillators/audioBuffers and parameter
>>> automations.
>>>
>>> Frankly ... if I had my druthers, I'd like to be able to do something
>>> like this:
>>> var scheduler = ctx.createAudioScheduler(schedulingRate, callback);
>>> and then use ... roughly:
>>> var eventList = [...]; // list of (event procedure, relative event time)
>>> tuples
>>> function callback(evt) {
>>> for (var i in eventList) {
>>> var eventTime = eventList[i].time + evt.playbackTime;
>>> ctx.callbackAtTime(eventList[i].proc, eventTime);
>>> }
>>> }
>>> ...
>>> scheduler.start();
>>> scheduler.pause();
>>> scheduler.reset();
>>> ... etc
>>>
>>> I realize that this is arguably a crazy suggestion, but it could
>>> afford arbitrary nesting of event schedules.
>>>
>>> Thoughts? Curses?
>>>
>>> Cheers,
>>> Roby
>>>
>>> On Thu, Jul 26, 2012 at 8:02 AM, Adam Goode <agoode@google.com> wrote:
>>> > I think you would do node.noteOn(e.playbackTime +
>>> > (samplesWrittenThisCallback / sampleRate)).
>>> >
>>> >
>>> > On Thu, Jul 26, 2012 at 10:56 AM, Peter van der Noord
>>> > <peterdunord@gmail.com> wrote:
>>> >>
>>> >> can you give an example?
>>> >>
>>> >> Let's say i am in my buffer-write loop (in response to an
>>> >> AudioProcessingEvent), and at a certain point in that loop (i may or
>>> >> may not
>>> >> have written a number of values already) i want to call note-on on
>>> >> another
>>> >> node to be fired exactly at the same time that the buffervalue i'm
>>> >> writing
>>> >> (or about to write) would reach the soundcard. how would that work?
>>> >>
>>> >> at least, that's what i understand i can do then...?
>>> >>
>>> >>>
>>> >>> An AudioProcessingEvent exposes the exact time of the audio to be
>>> >>> generated in the sample stream as the "playbackTime" attribute. Not
>>> >>> that
>>> >>> this makes callbacks any more useful as a source of exact timing, but
>>> >>> it
>>> >>> does mean that there is no need to keep track of time in separate
>>> >>> variables.
>>> >
>>> >
>>>
>>
>