<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1605380467;
mso-list-type:hybrid;
mso-list-template-ids:330340992 541255748 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:22.5pt;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:58.5pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:94.5pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:130.5pt;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:166.5pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:202.5pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:238.5pt;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:274.5pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:310.5pt;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoPlainText>I have the following comments on the minutes (Shown in red):<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><span style='color:red'>In my opinion, the new X3DSoundSourceNodes should not have the work “Source” in the names of the concrete nodes as the node names are clear without it, it is redundant, and also is different from the existing nodes.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:red'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:red'>The concrete node derivations need to replace “AudioNode” with the appropriate abstract node type.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:red'><o:p> </o:p></span></p><p class=MsoPlainText style='margin-left:22.5pt;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-family:Wingdings'><span style='mso-list:Ignore'>n<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>Dick<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>/******************************************<o:p></o:p></p><p class=MsoNormal>| Richard F. Puk, Ph.D., President<o:p></o:p></p><p class=MsoNormal>| Intelligraphics Incorporated<o:p></o:p></p><p class=MsoNormal>| 7644 Cortina Court<o:p></o:p></p><p class=MsoNormal>| Carlsbad, CA 92009-8206<o:p></o:p></p><p class=MsoNormal>| Tel: +1-760-753-9027 Mobile: +1-760-809-9027<o:p></o:p></p><p class=MsoNormal>| Email: <a href="mailto:puk@igraphics.com">puk@igraphics.com</a><o:p></o:p></p><p class=MsoNormal>\****************************************** <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: x3d-public [mailto:x3d-public-bounces@web3d.org] On Behalf Of Don Brutzman<br>Sent: Wednesday, July 1, 2020 1:29 PM<br>To: X3D Graphics public mailing list<br>Cc: Efi Lakka; Athanasios Malamos<br>Subject: [x3d-public] X3D Specification Editors: Audio and Sound, 1 July 2020 (corrected)</p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>[corrected copy follows]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Attendees: Efi Lakka, Thanos Malamos, Dick Puk, Don Brutzman<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Confirming: no member-only Web3D Consortium material is included here.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>----<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>1. *Plans*<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>We are working towards editing the draft X3D4 component. Weekly document updates attached.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>We plan to submit both paper and tutorial to Web3D 2020 Conference, to be held virtually in November 2020. Deadlines are now announced:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>* Web3D 2020, Important Dates<o:p></o:p></p><p class=MsoPlainText> https://2020.web3dconference.org/important-dates<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>- Paper and poster submission: July 27, 2020<o:p></o:p></p><p class=MsoPlainText>- Paper/poster acceptance: September 7, 2020<o:p></o:p></p><p class=MsoPlainText>- Tutorial and workshop submission: September 12, 2020<o:p></o:p></p><p class=MsoPlainText>- Industrial use cases submission: September 19, 2020<o:p></o:p></p><p class=MsoPlainText>- Standards session submission: September 19, 2020<o:p></o:p></p><p class=MsoPlainText>- Camera-ready paper/poster: September 21, 2020<o:p></o:p></p><p class=MsoPlainText>- Demonstration submission: September 26, 2020<o:p></o:p></p><p class=MsoPlainText>- Tutorial/workshop/demonstration/industrial use cases acceptance: October 12, 2020<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Because of tight schedules and late decision to support a virtual conference, no deadline extensions are expected.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Certainly high-fidelity spatial sound directly supports the conference theme "3D for a Hyperconnected World!"<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Tasks:<o:p></o:p></p><p class=MsoPlainText>- Efi will begin refactoring the documentation papers as a conference paper.<o:p></o:p></p><p class=MsoPlainText>- Dick and Don will continue refactoring as specification prose for X3D4.<o:p></o:p></p><p class=MsoPlainText>- All of us continue resolving the short set of remaining design issues.<o:p></o:p></p><p class=MsoPlainText>- After paper submission, we produce tutorial proposal.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>----<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>2. *Reference material*<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> Dear all,<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> please find attached the documents for today's meeting (01/07/2020).<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> Best regards,<o:p></o:p></p><p class=MsoPlainText>> Efi Lakka<o:p></o:p></p><p class=MsoPlainText>updates to follow.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>3. *Questions and Answers*<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>a. We are wondering about representation of AudioContext, not seeing that in your document. Is it an X3D node?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>In the initial structure, we have used the AudioContext as new node in X3D (in order to match with Web Audio API structure). At the moment, we decide to extent X3D only with the important and necessary nodes from Web Audio API. Hence, we don’t use it as X3D node.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Given that approach, how do we describe correspondences between X3D4 and Web Audio specifications?<o:p></o:p></p><p class=MsoPlainText>- Table of correspondences (see document),<o:p></o:p></p><p class=MsoPlainText>- Seems like we we need a specification EXAMPLE showing alignment of a thorough example<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>----<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>b. Terminology.<o:p></o:p></p><p class=MsoPlainText>- In general, should "Audio" refer to aural inputs and "Sound" refer to sonic outputs?<o:p></o:p></p><p class=MsoPlainText>- If so, does "X3DSoundSourceNode" become more appropriately "X3DAudioSourceNode"?<o:p></o:p></p><p class=MsoPlainText>- If so, are there any backwards compatibility issues? (primarily in implementations and concepts, not in any example X3D content)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Audio is anything audible that has been produced, recorded or processed by something electronic or digital.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Sound is anything audible, from any format or instrument(music, bird singing…). Sound can be broken down into Wavelength, Frequency, Amplitude, Pressure, Intensity, Speed of Sound and Direction.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>While audio is a sound, not all sounds are audio. Audio means the reproduction of sound.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>So... we will leave this business alone.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>----<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>c. One small problem with your attachment caused by an error in the X3D Interface Hierarchy: ViewpointGroup is not derived for X3DViewpointNode. Instead, it is derived directly from X3DChildNode. This is because ViewpointGroup is a catalog of viewpoints rather than a viewpoint itself. We have created a Mantis issue to fix the spec.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>* Mantis 1317: ViewpointGroup listed in incorrect location within X3D Interface hierarchy<o:p></o:p></p><p class=MsoPlainText> https://www.web3d.org/member-only/mantis/view.php?id=1317<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Resolved.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>----<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>4. *Discussion*<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>a. Abstract node types.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>We should be careful about abstract node types and not add any that don't offer common functionality. Their purpose is to<o:p></o:p></p><p class=MsoPlainText>- define common fields,<o:p></o:p></p><p class=MsoPlainText>- simplify validation of parent-child node relationships,<o:p></o:p></p><p class=MsoPlainText>- simplify object-oriented software implementations, and<o:p></o:p></p><p class=MsoPlainText>- (optionally) facilitate future extensions for adding potential new nodes.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Let's try to avoid adding any excess abstract node types, if possible.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Note that SoundProcessingGroup is _not_ a node type. Rather it is a way to establish parent-child node relationships and potentially facilitating creation of audio graphs, which may have multiple levels in a tree. (Similarly for SoundAnalysisGroup and SoundChannelGroup, can we avoid them?)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Discussion: appropriate rename X3DSoundProcessingNode, X3DSoundAnalysisNode, X3DSoundChannelNode. (Updated document attached)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>For example, perhaps these names actually suggest field names for X3DSoundProcessingNode concrete nodes, such as<o:p></o:p></p><p class=MsoPlainText>a. [in out] MFNode effects [BiquadFilter,Convolver,Delay,DynamicsCompressor,Gain,WaveShaper,PeriodicWave]<o:p></o:p></p><p class=MsoPlainText>b. [in out] MFNode analysers [Analyser]<o:p></o:p></p><p class=MsoPlainText>c. [in out] MFNode channels [ChannelSplitter,ChannelMerger] # is there a Channel?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Since there are many "effects" a plausible combination abstraction is<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>a'.[in out] MFNode effects [X3DSoundProcessingNode]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>... but perhaps avoid X3DSoundAnalysisNode, X3DSoundChannelNode since they are so specialized. Looking at details of node definitions and example graphs will give us much better confidence whether we need an abstract node type for future extensions.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Whenever we can define SFNode/MFNode child fields with well-defined relationships, that eliminates need for any grouping. This is terser and easier for authors (programmers) to model as well.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>==== last week, to be rechecked =====<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>b. Remove "SoundProcessingGroup", this will likely be an field in each parent node rather than an explicit node. Goal to achieve: if we have that field within the processing nodes themselves, then we do not need to group them or use ROUTE connections. We want to construct an audio graph with equal expressive power as Web Audio API (and other sound approaches).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>* [in out] MFNode soundProcessing [X3DSoundProcessingNode]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>c. Gain might also be a field, rather than a node. Units in decibels seems preferred, though amplification is possible too.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>* [in out] SFFloat gain 0.0<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Web Audio API uses amplification factors, but sound equipment uses decibels. Possible UNIT addition for sound? Must be careful because amplification factors are linear and decibels are logarithmic. Perhaps<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>* [in out] SFString gainFactorType "AMPLIFICATION" ["AMPLIFICATION" "DECIBEL"]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>[1] Wikipedia: Decibel<o:p></o:p></p><p class=MsoPlainText> https://en.wikipedia.org/wiki/Decibel<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Of note is that decibel amplification is a logarithmic power ratio to a reference level. This is typical of audio hardware, and usually (but not always) consistent. So what would our reference level be?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Choices:<o:p></o:p></p><p class=MsoPlainText>i. avoid decibels<o:p></o:p></p><p class=MsoPlainText>ii. use reference in the enumeration value, e.g. "DECIBEL-XYZ" which seems extremely confusing and error prone.<o:p></o:p></p><p class=MsoPlainText>iii. just pick most common reference for "DECIBEL" e.g. + (or -) 3dB equals amplification factor of sqrt(2) (or 0.5) - unambiguous.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>There is some disagreement on this topic. For example, allowing sound engineers or mixing decks to be modeled in these audio graphs is an important use case. Decibels to appear in some of the other nodes... Worth a close look.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>d. (confirmed) We agreed to stay consistent with Analyser, not Analyzer.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>e. Generality - we continue to consider whether this is mappable to other engines, e.g. MPEG4 or Dolby or whatever. Also whether it is mappable to audio engineers putting together audio equipment, mixer board, room (or auditorium or arena) setups, etc.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>- (confirmed) identify field signature questions that need resolution, for example MicrophoneSource. Suggestions welcome.<o:p></o:p></p><p class=MsoPlainText>- (TODO) SpatialSound url field to load a Javascript Web Audio API (perhaps with optional support). Similar to X3D Script node, either external or embedded source with ecmascript: prefix.<o:p></o:p></p><p class=MsoPlainText>- (not needed) Hoping to explain how we apply the terms "audio" and "sounds" so that the distinction is sensible to readers. Already pretty clear: "acoustics" for reflection absorption etc.<o:p></o:p></p><p class=MsoPlainText>=====================================<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Our goals for next week are to follow this path forward:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>- look at multiple examples of audio graph(s) and define parent-child field relationships,<o:p></o:p></p><p class=MsoPlainText>- (hopefully) eliminate need for any grouping,<o:p></o:p></p><p class=MsoPlainText>- minimize (but allow if appropriate) abstract types, e.g. X3DSoundProcessingNode<o:p></o:p></p><p class=MsoPlainText>- update X3D4 specification draft to include (currently) well-defined nodes,<o:p></o:p></p><p class=MsoPlainText>- check and recheck examples to make sure that they match specification hierarchy and prose.<o:p></o:p></p><p class=MsoPlainText>- recheck, is AudioContext needed?<o:p></o:p></p><p class=MsoPlainText>- We expect many more questions can then be evaluated (for example, representing hardware input-output hookups corresponding to software-component audio graphs).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Next week: look for "80% solution" audio graph that let's us check most relationships in the Sound component.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>4. Step by step: continuing convergence. Time to press ahead: "better is the enemy of good enough" !<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Next week's meeting: Thursday, same time.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Have fun with X3D Audio and Sound! 8)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>all the best, Don<o:p></o:p></p><p class=MsoPlainText>-- <o:p></o:p></p><p class=MsoPlainText>Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu<o:p></o:p></p><p class=MsoPlainText>Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<o:p></o:p></p><p class=MsoPlainText>X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman all the best, Don<o:p></o:p></p><p class=MsoPlainText>-- <o:p></o:p></p><p class=MsoPlainText>Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu<o:p></o:p></p><p class=MsoPlainText>Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<o:p></o:p></p><p class=MsoPlainText>X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman<o:p></o:p></p></div></body></html>