[x3d-public] Sound v4 Recommendations - Splitter/Merger/Selector

[GPU Group]

Yes, I won't have all nodes implemented by then, but hopefully the awkward
nodes. I can produce marked-up html of 16 Sound Component
4.1a - show in orange the proposed fields to delete by removing slave-gain
fields and processing node fields inherited from TimeDependentNode
4.1b- after 4.1a removals, shows additions(yellow) and subtractions(orange)
to make nodes more functional and w3c web audio equivalent / compliant
4.1c- shows final clean proposal
Then parts can be adopted for 4.0 as determined necessary by the group
approach.
I'll work up drafts of those in the next few days.
I look forward to the Mar 3 discussion. (I've never been to Crete, but
spent 14 months in Athens).
-Doug Sanden
PS I'm implementing in native code with Labsound lib -- a fork of (audio
parts of) WebKit used in Chrome and Safari.

On Thu, Feb 16, 2023 at 10:48 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Thanos:  Doug Sanden (gpugroup, FreeWRL implementer) has made a number of
> recommendations on x3d-public mailing list regarding X3D 4.0 Sound
> component.
>
>    - X3D4 Architecture, clause 16 Sound component
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/sound.html
>
>
>
> As discussed, am hoping you (and perhaps Efi) can make time to look at
> them.  Our driving factor is correctly achieving full compliance with
>
>    - W3C Web Audio API
>    - https://www.w3.org/TR/webaudio
>
>
>
> Doug: thanks for pointing out alternatives whenever our design does not
> closely/exactly match the Web Audio API.  That is key and a deciding
> factor, since our design goal is to be able to create directly
> corresponding audio graphs for each.  At some future point, I expect to
> demonstrate this by creating XSLT stylesheets that convert X3D audio graphs
> to simple ASCII-text trees (similar to HAnim outputs) and also JavaScript
> source with matching Web Audio class invocations.
>
>
>
> Suggested group approach: first triage and then refine each suggested
> change.  Categories:
>
>
>
>    1. *Essential*. Necessary change for final X3D 4.0 to correctly
>    support Web Audio API Recommendation, completing Draft International
>    Specification (DIS) review corrections.
>    2. *Next*.  Important recommended change for browser implementers and
>    follow-on X3D 4.1 specification.
>    3. *Future*.  Informational, deserving of further extensibility work
>    through implementation and evaluation.
>
>
>
> Am hoping we can have all recommendations and reactions posted and ready
> for X3D Working Group meeting on Friday March 3.  Please advise if you
> think that is possible – thanks for your continuing careful scrutiny.
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *GPU Group
> *Sent:* Thursday, February 16, 2023 6:45 AM
> *To:* X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject:* [x3d-public] Sound v4 Recommendations -
> Splitter/Merger/Selector
>
>
>
> Recommendations:
>
> 1. remove outputs field from ChannelSplitter
>
> 2. add 2 fields to ChannelMerger
>
> MFInt32 indxSrc [in/out]
>
> MFInt32 indxDst [in/out]
>
> 3. remove node ChannelSelector from specifications
>
>
>
> Explanation:
>
> Merger will get is Splitter channels through its children field, and the
> children are in the order of indxSrc[i[, so when making connections, Merger
> iterates over indxSrc[i], and for each one renders the Merger.children[i],
> and communicates indirectly with splitter (through a stack/state variable)
> which of its outputs (or srcIndex) to connect to splitters most immediate
> parent.
>
> If there aren't enough .children for all the indxSrc, the last child is
> repeated/re-used.
>
> I have it working in an example scene
>
> https://freewrl.sourceforge.io/tests/16_Sound/SplitChannels6_children.x3d
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffreewrl.sourceforge.io%2Ftests%2F16_Sound%2FSplitChannels6_children.x3d&data=05%7C01%7Cbrutzman%40nps.edu%7C5c43bc95adce4c669b0208db102c8b30%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638121555752983083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lOjmUJIGy6qCzAYK19LeQpyaIK7m21hbYL14bFaypn8%3D&reserved=0>
>
>
> The indxDst, indxSrc are a 2-tuple, and there should be equal numbers of
> them,  the recommended field names a) are similar to Web Audio srcIndx,
> dstIndx so familiar to those working with web audio b) re-arranged to make
> them alphabetical-order sequential in the specs, so its more obvious they
> go together.
>
> The design eliminates the need for a separate ChannelSelector node (which
> is ill-defined, and web audio doesn't have one) -- the same kind of
> selections can be done with indxDst, indxSrc in ChannelMerger.
>
>
>
> -Doug
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230216/61366657/attachment.html>