Re: Changing default panner model to equalpower instead of HRTF?

I'm not necessarily opposed, and I would like to provide automation, but
could we not at least k-rate animate parameters in HRTF?


On Thu, Jul 17, 2014 at 10:47 AM, Hongchan Choi <choihongchan@gmail.com>
wrote:

> Hello Ray,
>
> I had the impression that the reason behind this decision was "to support
> awesome 3D sound that plays nicely with WebGL game demo." In other words, a
> 3D coordinate from WebGL code can be passed to the panner node directly.
>
> I believe this decision rather caused another problem: the panner node
> does not support parameter automation. There is no standard mapping
> mechanism between the motion in 3D space and the parameter automation in
> audio application. So the panner node dropped the support on AudioParam and
> chose to be WebGL-friendly. (Not sure if it is a good call though...)
>
> I know this is a long shot - but how about separating the panner node to
> 2D version and 3D version? HRTF and equal-power panning are quite different
> in terms of the signal processing. The latter can be easily automated with
> AudioParam and developers can decide to save processing power from the
> unnecessary HRTF load.
>
> Best,
> Hongchan
>
>
>
>
> On Thu, Jul 17, 2014 at 10:07 AM, Raymond Toy <rtoy@google.com> wrote:
>
>> The HRTF panner takes significant resources to load impulse responses as
>> well as in processing power. For low-end mobile devices this represents
>> significant resources that we may not want to use.
>>
>> Since the current default panner model is HRTF, once a panner is created,
>> the HRTF database must be loaded, even if the user immediately switches to
>> the equalpower panner.
>>
>> If we make the default be the equalpower model, we won't have this
>> problem. Only if the application wants to use the HRTF panner will the
>> extra memory be used.
>>
>> Can we change the default to equalpower? This would, obviously, be a
>> breaking change in the spec.
>>
>> Ray
>>
>>
>>
>>
>
>
> --
> Hongchan Choi
>
> PhD Candidate, Research Assistant
> Center for Computer Research in Music and Acoustics (CCRMA)
> Stanford University
>
> http://ccrma.stanford.edu/~hongchan
>

Received on Thursday, 17 July 2014 19:01:29 UTC