<div dir="ltr">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<div>4.1a - show in orange the proposed fields to delete by removing slave-gain fields and processing node fields inherited from TimeDependentNode</div><div>4.1b- after 4.1a removals, shows additions(yellow) and subtractions(orange) to make nodes more functional and w3c web audio equivalent / compliant</div><div>4.1c- shows final clean proposal</div><div>Then parts can be adopted for 4.0 as determined necessary by the group approach.</div><div>I'll work up drafts of those in the next few days.</div><div>I look forward to the Mar 3 discussion. (I've never been to Crete, but spent 14 months in Athens).</div><div>-Doug Sanden</div><div>PS I'm implementing in native code with Labsound lib -- a fork of (audio parts of) WebKit used in Chrome and Safari.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 16, 2023 at 10:48 AM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg3971681753716395943"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_3971681753716395943WordSection1"><p class="MsoNormal">Thanos:  Doug Sanden (gpugroup, FreeWRL implementer) has made a number of recommendations on x3d-public mailing list regarding X3D 4.0 Sound component.<u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in">X3D4 Architecture, clause 16 Sound component<u></u><u></u></li><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in"><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/sound.html" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/sound.html</a><u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As discussed, am hoping you (and perhaps Efi) can make time to look at them.  Our driving factor is correctly achieving full compliance with <u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in">W3C Web Audio API<u></u><u></u></li><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in"><a href="https://www.w3.org/TR/webaudio" target="_blank">https://www.w3.org/TR/webaudio</a><u></u><u></u></li></ul><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Suggested group approach: first triage and then refine each suggested change.  Categories:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="1" type="a"><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in"><i>Essential</i>. Necessary change for final X3D 4.0 to correctly support Web Audio API Recommendation, completing Draft International Specification (DIS) review corrections.<u></u><u></u></li><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in"><i>Next</i>.  Important recommended change for browser implementers and follow-on X3D 4.1 specification.<u></u><u></u></li><li class="m_3971681753716395943MsoListParagraph" style="margin-left:0in"><i>Future</i>.  Informational, deserving of further extensibility work through implementation and evaluation.<u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">all the best, Don<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">-- <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">Don Brutzman  Naval Postgraduate School, Code USW/Br        <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New"">X3D graphics, virtual worlds, Navy robotics https://</span> <span style="font-size:10pt;font-family:"Courier New""><a href="http://faculty.nps.edu/brutzman" target="_blank">faculty.nps.edu/brutzman</a><u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web3d.org</a>> <b>On Behalf Of </b>GPU Group<br><b>Sent:</b> Thursday, February 16, 2023 6:45 AM<br><b>To:</b> X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br><b>Subject:</b> [x3d-public] Sound v4 Recommendations - Splitter/Merger/Selector<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Recommendations:<u></u><u></u></p><div><p class="MsoNormal">1. remove outputs field from ChannelSplitter<u></u><u></u></p></div><div><p class="MsoNormal">2. add 2 fields to ChannelMerger<u></u><u></u></p></div><div><p class="MsoNormal">MFInt32 indxSrc [in/out]<u></u><u></u></p></div><div><p class="MsoNormal">MFInt32 indxDst [in/out]<u></u><u></u></p></div><div><p class="MsoNormal">3. remove node ChannelSelector from specifications<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Explanation:<u></u><u></u></p></div><div><p class="MsoNormal">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. <u></u><u></u></p></div><div><p class="MsoNormal">If there aren't enough .children for all the indxSrc, the last child is repeated/re-used.<u></u><u></u></p></div><div><p class="MsoNormal">I have it working in an example scene<u></u><u></u></p></div><div><p class="MsoNormal"><a href="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" target="_blank">https://freewrl.sourceforge.io/tests/16_Sound/SplitChannels6_children.x3d</a> <u></u><u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">-Doug<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div>