Unified 2.5D WFS Framework

[fs446]

We might add the driving functions of plane wave, point/line source of the unified 2.5D WFS framework for different referencing schemes / positions of amplitude correct synthesis (PCS) into the toolbox based on the findings https://doi.org/10.1109/TASLP.2017.2689245 , see also 142nd Audio Eng. Soc. Conv, Berlin, #9722 for general vector notation of these driving functions. Then, 'only' the referencing function must be adapted to work in general vector notation for desired reference curves.

[hagenw]

Nice idea. @fs446 or @gfirtha do you have time to create a small first pull request with an example implementation, or should I have a try at it?

[fs446]

Good. We’ll initially provide some stuff, like

get_unified_25D_WFS() general driving function get_dir_derivatives() for point/line/plane set_ref_function() for different feasible referencing schemes and SSD contours, that’s the most critical part to solve for arbitrary setups get_PCS() positions of amplitude correct synthesis for check and debug, not known before in detail

Hope this fits into the actual framework. Once this is realized, all currently used 2.5D WFS driving functions just need a customized set_ref_function()-case to work within this framework. That was in fact the idea ;-)

On 04 Apr 2017, at 12:41 PM, Hagen Wierstorf notifications@github.com wrote:

Nice idea. @fs446 or @gfirtha do you have time to create a small first pull request with an example implementation, or should I have a try at it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[fs446]

init dev in branch 'unified_25d_wfs'

[fs446]

[D, xPCS] = driving_function_mono_unified_25d_wfs(x0,xs,dx0,src,f,conf) is working as expected with the current state dab14a1cb411058083f70c9a60e32347aff473d0 Fig. 3,4,9,10 from https://doi.org/10.1109/TASLP.2017.2689245 created with this one->ok

Now we need a meaningful implementation for defining a referencing function somewhere outside the calculation of the sound field with sound_field_mono_wfs(X,Y,Z,xs,src,f,conf). A further input parameter could do this. Any ideas, how we should proceed to be most consistent with the current toolbox handling.

[fs446]

added a test script in 916fc76cb3d3d9f3afbeb64b63671b28bf71dbc6 that checks the driving functions.

[hagenw]

Cool, thanks for your effort. I will have a look at this next week.

[hagenw]

The driving functions look ok, but I think I would integrate them under the 2.5D parts of the virtual source type driving functions we have at the moment, see the point source example. This is something I could do easily.

If I understand it correctly, the reference line/point is defined by the dx0 amplitude values you have to provide for every source. Is there a more user friendly way to get this done? It is good that the user would have the possibility to define whatever she/he want, but it would also be great if for simple cases like a point or a line parallel to the secondary sources the calculation would work automatically.

[fs446]

On 05 May 2017, at 4:50 PM, Hagen Wierstorf notifications@github.com wrote:

The driving functions look ok, but I think I would integrate them under the 2.5D parts of the virtual source type driving functions we have at the moment, see the point source example. This is something I could do easily.

Yes, that’s probably a good compromise. Can you do this initially? But keep in mind, that the user might want to have access to dx0, a parameter other driving functions don’t have, or?. And perhaps one would read back the points/locations of amplitude correct synthesis (PCS), when a certain dx0 was setup and one wants to check the PCS.

If I understand it correctly, the reference line/point is defined by the dx0 amplitude values you have to provide for every source. Yes, that’s correct.

Is there a more user friendly way to get this done? I don’t think so, since this is the essence of 2.5D WFS referencing. Referencing depends heavily on the source type (e.g. for plane waves on the propagatin direction) since the local wavenumber along the SSD is evaluated. Thus, I’d rather specify this for each source type separatly for consistency. That’s already done so, I think.

It is good that the user would have the possibility to define whatever she/he want, Yes, IMO definitely the way to go.

but it would also be great if for simple cases like a point or a line parallel to the secondary sources the calculation would work automatically. Yes, for that we have to check the referencing schemes in general vector notation for cases of arbitrary SSD setups. That should/could be done, when we aggreed to some consistent handling. So, please go for a first implementation into the existing driving functions.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.