Re: Reflections on writing a sequencer

Not to nitpick (which is, of course, what someone says right before they
nitpick), but theoretically you can just say "if (oscillator.noteOn)"
instead of doing a typeof check. Not like the overhead is that much, but
just saying.

Matt

On Thu, Jul 26, 2012 at 3:58 PM, 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.
>> >
>> >
>>
>>
>