Re: Reflections on writing a sequencer

>
> 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.
> >
> >
>
>