Re: Input buffer's time coordinate

On Mon, Nov 2, 2015 at 12:30 AM, Akira Sawada <aklaswad@gmail.com> wrote:

> Hi Raymond,
>
> Am sorry my question sounds only about app implementation. I also just
> wondering that AudioProcessing ( and current draft for audioWorker's
> AudioProcess ) Event should have some information about original playback
> time. `e.originalPlaybackTime` is a missing feature for me, I don't know
> enough use cases are in the world, though.
>

For an AudioWorker, I would think your originalPlaybackTime is the context
currentTime.  Not sure what we're doing with this currently.


>
>
> And, the reason why I don't use offlineAudioContext is very clear. Chrome
> has a bug around thread pool and crashes when many (around 1024 or 2048?)
> offlineAudioContext has created.
> https://code.google.com/p/chromium/issues/detail?id=433479#c3
>

Oops.  I forgot about that one.  Yes, it should be fixed.  But do you
really expect to create 1000 contexts?  I played around with your example
and it looks like you actually draw the curves as you drag the points
around but you don't actually have the actual output until you finish
dragging.  That would only be one context after each drag.  I played around
for a bit and probably would have only generated 10-20 contexts.

But yeah, I understand if you don't want to crash the browser.

Really neat demo, BTW.  We could have used something like this last week at
TPAC.


>
> Sébastien,
>
> JFYI, I implemented the timecode channel as you suggested, and it works
> very well, on both chrome and firefox. thanks Again!
>
>
> Akira
>
> 2015-11-02 13:06 GMT+09:00 Raymond Toy <rtoy@google.com>:
>
>> This has kind of drifted off-topic for the public-audio list, which is
>> about the spec itself.  You should try public-audio-dev list instead.
>>
>> But for your particular case, why not use an offline audiocontext with an
>> AudioBufferSource node with a constant signal followed by a gain node?
>> This is how the automation diagram in the spec
>> <http://webaudio.github.io/web-audio-api/#example1-AudioParam> was
>> produced.  The source for the diagram is
>> https://googlechrome.github.io/web-audio-samples/samples/audio/timeline.html
>> .
>>
>> On Mon, Nov 2, 2015 at 12:13 AM, Akira Sawada <aklaswad@gmail.com> wrote:
>>
>>> Hi Sébastien,
>>>
>>> Thanks for the advice!
>>> ChannelMerger was completely out of my sight! Yes, your code looks that
>>> I want.
>>> Will try this idea, and also tackle more simple way (e.g. use
>>> param.linearRampToValueAtTime(LENGTH_OF_A_DAY, LENGTH_OF_A_DAY) to generate
>>> timestamp instead ).
>>>
>>> P.S.
>>> I'm also feeling sad to know there's no way to do this in non hacky way
>>> ;)
>>>
>>> thanks so much!
>>>
>>> Akira
>>>
>>>
>>> 2015-11-02 0:10 GMT+09:00 s p <sebpiq@gmail.com>:
>>>
>>>> Hi Akira,
>>>>
>>>> I had the same problem a while ago. For this I find a hack, which works
>>>> well in Chrome but not in Firefox (at the time there was a bug I think with
>>>> ChannelMergerNode which was causing a problem there, but now maybe it is
>>>> fixed?). You can find the code there :
>>>> https://github.com/WhojamLab/WAARecorderNode/blob/master/lib/TimeTaggedScriptProcessorNode.js
>>>>
>>>> The basic idea is to use a BufferSourceNode playing a ramp - which is
>>>> basically your timeline - and merge that audio signal with the signal you
>>>> want to send to your ScriptProcessorNode. That way you both the signal you
>>>> are interested in AND the timeline which gives you a precise time tag for
>>>> each sample of your signal.
>>>>
>>>> I could also package this as a separate library, but considering that
>>>> things are going to change soon enough, and ScriptProcessorNode will
>>>> disappear, and these problems of unpredictable latency should disappear
>>>> with it (will they?)
>>>>  ... it is probably not worth ...
>>>>
>>>> Cheers
>>>>
>>>> On Sun, Nov 1, 2015 at 7:26 AM, Akira Sawada <aklaswad@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi group,
>>>>>
>>>>> I'm writing an audioParam automation editor (
>>>>> http://aklaswad.github.io/alligata/envelope/ ) and using
>>>>> scriptProcessor as simple peek meter in it.
>>>>>
>>>>> So, I want to know the exact time the samples in inputBuffer was
>>>>> processed for.
>>>>> Those input samples could have an information about context based time
>>>>> coordinate because they're also processed on top of the time coordinate.
>>>>>
>>>>> Is there a way to know that?
>>>>>
>>>>> thanks.
>>>>>
>>>>> --
>>>>> 澤田 哲 / Akira Sawada / aklaswad
>>>>>
>>>>> email me: aklaswad@gmail.com
>>>>> visit me: http://blog.aklaswad.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Sébastien Piquemal*
>>>>
>>>>  -----* @sebpiq*
>>>>  ----- http://github.com/sebpiq
>>>>  ----- http://funktion.fm
>>>>
>>>
>>>
>>>
>>> --
>>> 澤田 哲 / Akira Sawada / aklaswad
>>>
>>> email me: aklaswad@gmail.com
>>> visit me: http://blog.aklaswad.com/
>>>
>>
>>
>
>
> --
> 澤田 哲 / Akira Sawada / aklaswad
>
> email me: aklaswad@gmail.com
> visit me: http://blog.aklaswad.com/
>