Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unified 25d WFS referencing scheme #143

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Unified 25d WFS referencing scheme #143

wants to merge 5 commits into from

Conversation

hagenw
Copy link
Member

@hagenw hagenw commented May 5, 2017

For the start of the discussion have a look at #136.

fs446 added 5 commits April 17, 2017 11:19
…09/TASLP.2017.2689245 checked.

The current handling is far from being nice, but it allows to check the referencing functions d(x0) of the Spors, Ahrens, Start WFS approaches compared to the unified framework.
Some ideas for a suitable handling within the toolbox are welcome.
@fietew
Copy link
Member

fietew commented May 15, 2017

As far as I could follow the discussion in #136, the integration of the code into the existing framework is still an issue. My suggestion to integrate this unified scheme a little bit more into the existing code would be the following (asterisk for driving_function_mono_ or driving_function_imp_):

  • extend *_wfs_<src>, etc. about the optional input parameter dx0
  • in *_wfs_<src> for conf.dimension = '2.5D':
    • compute pre-filter
    • compute the directional gradient of the desired sound field (as done in driving_function_mono_unified_25d_wfs)
    • If dx0 is given, ignore conf.driving_function. If no dx0 is given, compute dx0 based on conf.driving_function.
    • compute xPCS and driving function

The drawback would be, that some driving functions, e.g. for point source and focused source, might not fit into this framework.

@hagenw
Copy link
Member Author

hagenw commented May 15, 2017

I'm also in favour to integrate this in the existing framework.
This pull request will not be merged into master, but we should integrate the changes in another branch I would suggest. I created this pull request mainly in order to easily review the changes proposed by @fs446.
Unfortunately, I'm still a little bit short with time at the moment, but in a few weeks I should also be able to work on this issue. I would propose that we maybe first prepare a new release of the toolbox including all the LSFS changes and after that start integrating this one. Does this sound ok?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants