I don't understand why npm install needs sudo here.

npm WARN deprecated [email protected]: use uuid module instead
npm ERR! Darwin 16.4.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v6.9.0
npm ERR! npm  v3.10.8
npm ERR! path /Users/$USER/.npm/duplexify/3.5.0
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall mkdir

npm ERR! Error: EACCES: permission denied, mkdir '/Users/$USER/.npm/duplexify/3.5.0'
npm ERR!     at Error (native)
npm ERR!  { Error: EACCES: permission denied, mkdir '/Users/$USER/.npm/duplexify/3.5.0'
npm ERR!     at Error (native)
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/Users/$USER/.npm/duplexify/3.5.0',
npm ERR!   parent: 'vinyl-fs' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

Note: I am running macOS Sierra 10.12.3 (16D32). $USER is my home directory.

With big graphs it could be useful to be able to click on some nodes in the graphic view of the graph, and add labels. LocalStorage could be use to save/load the mapping.
Or maybe color (or add a border color) the nodes belonging to some "logical modules in the webaudio app".

I think it's a tradeoff. I'm leaning towards showing realtime values, but not letting the user vary them.

Varying AudioParam's is neat - it can be useful to experiment / tinker, but the feature implies maintaining a reference to nodes, preventing GC. Blocking a source node from getting GCed could prevent its entire AudioBuffer from getting GCed ... which might be bad?

If we just let the user view AudioParam values in realtime, we might not need to maintain references to the nodes. We would just I think override the getters and setters of the value properties to issue a message when values change, maybe by defining a proxy.

A challenge here is that it seems like we have to maintain a reference to tracked nodes in the inspected page. That might prevent garbage collection ...

Currently, their AudioParam ports overlap.

Why do we need Node and Gulp when Closure does all the heavy lifting? Perhaps we can just use the shell script to run the compiler?

Details: https://developer.chrome.com/webstore/images

All the ports are placed in the left-top corner of the node rect.

I don't think this is our bug though. Something must have been changed in SVG or Canvas.

Today, users can delete edges by nabbing a reference to the node via the __node__ method and then disconnecting.

var node = __node__([NUMERIC NODE ID]);
node.disconnect();

It might be nice to enable deleting nodes in the UI itself. The extension would pass a message from the dev tools panel to the content script of the web page telling the web page to remove the disconnect the node.

This task involves

1. Making the edges interactive via JointJS's API. This introduces an X button atop each edge when the user hovers over it.
2. Introducing a new type of message AudionRequestNodeDisconnectMessage to externs/audion-specific-externs/messages-extern.js.
3. Sending a message from the panel to the dev tools script when the user clicks X.
4. Routing that message from the dev tools script to the background script to the content script of the web page.
5. Actually disconnecting the node in tracing.js (the code that runs in the context of the web page).

See the attache image. When the extension starts the initialization, it renders all the nodes at the origin. Can they be hidden until the rendering is completely finished?

Occasionally, building the extension errs because the CSS name mapping cannot be found by Closure.

chizeng-macbookpro:audion chizeng$ gulp
[23:55:06] Using gulpfile ~/Desktop/audion/gulpfile.js
[23:55:06] Starting 'default'...
[23:55:06] Finished 'default' after 26 ms
Full name optimization profit : 251
Word-by-word optimization profit : 249
Recommended method : 'full'
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: ENOENT: no such file or directory, lstat '/tmp/audion-build-temporary-files/rename-mapping.js'

Re-running would often suffice, but this behavior is random and unexpected, so it ought to be fixed.

Remove dagre-d3 and its extern from this code base. Keep graphlib + dagre (Install those via npm).

They'd look something like this.

FooBarNode

• 0 *

• AudioParam

• AudioParam

where *s are ports that could connect to edges.

If the script in element gets executed slightly before the injection script (wrappers), we don't get any visual. How do we ensure the injection happens first?

http://semver.org/

What's the initial public version? We have to think about the release tag and branch.

• Create a wrapping container for the panel.
• The warning message should be centered vertically and horizontally.
• Give some edges on the style. :)

The black-ish overlay when redrawing causes excessive flickering.

Overriding AudioParam values is useful. We should I think work out details. For instance,

• If the inspected page tries to override a user-set value, which value should audion heed?
• If the user sets a value during a ramp, what happens?
• Similarly, what if the user sets a value when an oscillator connects to the AudioParam?

Hi, this example: https://codepen.io/w3devcampus/pen/GWGdjK?editors=0010
A frequency analyser I wrote, that uses an ES6 class that inherit from the AnalyserNode, stops working when the extension is activated. If I disable the extension it works (works also with FF, opera etc.)

It seems that the fact that the class inherits from a WebAudio node confuses the extension/browser, and raises erros when I try to call internal methods from the code in the class.

Ideally, our tests should run on say jenkins with a web hook for GitHub. However, I don't know if Closure jives with jenkins. I haven't seen solid examples.

What we can do is set up Closure-based testing. The user would run a terminal command and then visit a web page to run tests.

One meaningful test would be to ensure that the correct graph is created when a certain sequence of events is passed to the panel script. We would include the panel script in the test and mock onMessage so that the test could manually pass messages to the panel.

I marked this as a post-launch priority because there are some significant challenges we have to figure out about Closure in GitHub, but tests would later enable others to contribute more easily.

We should show when AudioBufferSourceNodes start and stop playing in the pane:

Maybe we could add a Play Status section to the pane for AudioBufferSourceNodes. This section could have 3 properties, perhaps start time (the absolute time at which the node starts playing), offset (at what point - seconds - into the buffer we start playing), and duration (how long in seconds the node played for).

This bug entails

1. overriding the AudioBufferSourceNode.prototype.start method to issue a message when the node starts playing.
   https://github.com/google/audion/blob/master/js/entry-points/tracing.js
   The message's properties should be added to messages-extern.js:
   https://github.com/google/audion/blob/master/externs/audion-specific-externs/messages-extern.js
   The message's type should be added to this enumeration:
   https://github.com/google/audion/blob/master/js/messaging/message-type.js

2. Within tracing.js, listen for AudioBufferSourceNodes to dispatch an ended event to handle when the node stops playing: https://www.w3.org/TR/webaudio/#widl-AudioBufferSourceNode-onended

3. adding a new category of widgets in the pane (a section in the pane) for Play Status:
   https://github.com/google/audion/blob/795545d1692d11a0348556827622c997dbc9502e/js/ui/pane/audio-node-mode.js#L91
   that only appears if the node is an AudioBufferSourceNode.

Create a pane on the right that expands and contracts. This sets the stage for letting users vary audio params with sliders.

Since macOS does not have JDK out of the box, gulp-closure-compiler fails when it runs java command line tool. Certainly you can just install it, but this needs to be documented in the prerequisite section.

I'm working on a beat production app. You can see it in progress here:
http://bb.upchicago.org
I was really excited to try this chrome extension, but as you can see if you visit the site with the extension installed, you get a node connecting error of some sort:
Uncaught Error: error connecting to node: [object DynamicsCompressorNode]

Uninstall the extension and the site immediately works again.
Any ideas? Happy to change my code to make this work, just not sure where to begin.
Thanks!

It seems like a use case for Web Audio Inspector is obtaining an image of the graph. Users today generally use native screenshot tools (depending on the OS).

It would be nice if the user could screenshot through the extension. There could be a button for it in the dev tools panel.

A first step would be to find out at what layer to do this. JointJS is SVG-based - maybe we can let the user download that SVG image. Or maybe Chrome has an extension API for screenshotting dev tools.

The extension needs a square icon. At least a 48x48 and 128x128 one.

Details:
https://developer.chrome.com/apps/manifest/icons
https://developer.chrome.com/webstore/images

It'd be nice to start us off with some sort of graph visualization.

BaseAudioContext.prototype includes createSpatialPanner. This is incorrect; there is no such property defined for BaseAudioContext.

Wrapping of properties should be more careful and only create wrappers for properties that actually exist in a BaseAudioContext.

• Need to capture IIRFilterNode.
• Need to define color scheme for IIRFilterNode and Media* nodes.

I used a synchronous XHR request in 8bbce3b to solve #13, but regret since it causes a console warning.

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.

I personally like a clean console. :) It might mean embedding tracing.js another way. Maybe as a string.

Here is the list of events that might be interesting to track, possibly with HighResDomTimestamp:

• ContextCreated (contextID)
• ContextSuspended (contextID)
• ContextResumed (contextID)
• ContextClosed (contextID)
• NodeCreated (nodeID)
• NodeToNodeConnected (nodeID_a, nodeID_b)
• NodeToParamConnected (nodeID_a, nodeID_b, paramName)
• NodeFromNodeDisconnected (nodeID_a, optional nodeID_b)
• NodeFromParamDisconnected (nodeID_a, nodeID_b, paramName)
• ParamAutomationStarted (nodeID, paramName, automationType)
• SourceStarted (nodeID)
• SourceStopped (nodeID)
• TypeChanged (nodeID, newTypeValue)

I believe every operation in the graph should be accountable with one of events above.

If a content script (for a frame) sends a web audio update to the background script, and no dev panel is open for that tab, then the background script should track the IDs of tabs that missed web audio updates. That way, the dev panel can notify the user that some updates had been missed (and the user might want to refresh).

The implementation is here:
https://github.com/hoch/canopy/blob/master/app/spiral-elements/spiral-audiograph/spiral-audiograph.html#L551

Making the dagre graph interactive is quite messy. We might have to find a better way.

Today, our unit test is a large, monolithic test that

1. constructs a graph by passing messages to the panel script and
2. performs a massive object comparison:

https://github.com/google/audion/blob/master/tests/panel_test.js
This takes the unit out of unit testing. :(

Instead of doing a massive object property comparison, the test should assert for specific details such as the existence of various nodes as well as the specific connections.

Relatedly, we need to test more cases as noted in the TODO within that file. Making the test more concise is a first step that would enable that.

Writing tests is grungy, but important: As we develop more features, we must ensure that we preserve old behavior. I will contribute to this bug and expand test coverage - and anybody else is encouraged to as well.

I implemented it like this:
https://github.com/hoch/canopy/blob/master/app/spiral-elements/spiral-audiograph/spiral-audiograph.html#L412

I wish there is a more structured way of doing this, but I don't think dagre supports it. Let's hack together. :)

Currently, only opening Chrome dev tools is not enough to trigger the panel to track the audio graph. The user has to actually click on the 'Web Audio' tab. This is bad because the user might expect web audio calls to start being tracked as soon as they open the dev panel in general, and only the panel JS owns tracking the audio graph.

The problem stems from how Chrome dev tools only creates panel.html when the user clicks the tab. dev-tools.js runs

One way we can solve this is queue audio graph updates til the Web Audio panel opens, then send them all at once.

Or we can just force the user to activate the panel when the user opens dev tools then clicks the Web Audio tab for the first time after opening dev tools.

Or we can make it clear to the user that navigating to the Web Audio tab finally starts tracking web audio calls.

It may be useful to visualize audio entering the numeric input channel of each AudioNode. First, we should research and justify what type of visualization(s) would be most useful - a waveform/oscilloscope? A histogram of the frequency domain?

For starters, a user may want to know whether any audio is going into an input at all. Beyond that, I wonder what information is most useful to visualize.

After making that design call, we use native AnalyserNodes to collect the data needed for visualization. That logic will reside in js/entry-points/tracing.js.

If an audio graph starts out small / narrow, it gets perpetually constrained into this rectangle despite later zooming.

Lets just make the svg container of the graph be as tall and wide as possible (fill the dev page).

Occasionally, a user may want to disable web audio tracking. For instance, the user may be benchmarking performance - this extension's web audio tracking logic adds unwanted overhead.

Today, the user disables the extension by visiting chrome://extension. The user could alternatively uninstall the extension from its icon to the right of Chrome's URL bar.

It would be nice if the extension itself could allow for disabling or enabling web audio tracking, perhaps via buttons within the Web Audio panel in dev tools. Then, the extension could always be "enabled" by the user, which probably leads to to fewer uninstallations. Furthermore, disabling / enabling web audio tracking within the Web Audio panel seems like a smoother flow than the aforementioned alternatives.

For instance, we could use a pointer cursor, add a special stroke, and a maybe change bg color on hover.

When the user hovers over an AudioParam port, show the name of the param in a tooltip.

With Audion enabled, navigate to the Box-2D demo. The demo fails with the following console message:

prototype-1.6.0.2.js:209 Uncaught TypeError: Failed to construct 'AudioContext': Please use the 'new' operator, this DOM object constructor cannot be called as a function.
    at new <anonymous> (prototype-1.6.0.2.js:209)
    at T (<anonymous>:4:23)
    at new AudioContext (<anonymous>:24:19)
    at init (box2d-audio.html:190)
    at wrapper (prototype-1.6.0.2.js:3877)
(anonymous)	@	prototype-1.6.0.2.js:209
T	@	VM11451:4
AudioContext	@	VM11451:24
init	@	box2d-audio.html:190
wrapper	@	prototype-1.6.0.2.js:3877

Just like AudioParams.

This feature was in the original Canopy visualizer. It is often useful to inspect the source and the destination of a connection.

See https://gist.github.com/hoch/5d2bfc3d7d6ee009ac2c#file-timewarp-js.

This is what I get from the extension:

This is how it should be:

We have to detect one more event: a node connects to an audio param.

• create a blob (node) for the audio param.
• make a connection from the audio node to the param.

The extension maintains a mapping between node ID (a unique value assigned to each AudioNode) and AudioNode for each web page.
https://github.com/google/audion/blob/795545d1692d11a0348556827622c997dbc9502e/js/entry-points/tracing.js#L108

This means that AudioNodes are never garbage-collected, but we do allow the user to obtain a reference to any AudioNode via the __node__ function. However, when Developer Tools is closed, there should be no reason for the extension to maintain references to AudioNodes.

Today, when the extension's background script receives a web audio update from a tab, it tries to find a connection to a dev tools instance (and such a connection only exists if dev tools is open for that tab):
https://github.com/google/audion/blob/795545d1692d11a0348556827622c997dbc9502e/js/entry-points/background.js#L119

We should add an else block to that logic: If dev tools is closed, we send a MISSING_AUDIO_UPDATES message ...
https://github.com/google/audion/blob/795545d1692d11a0348556827622c997dbc9502e/js/entry-points/background.js#L192

back to the content script of the tab telling the page to drop all references. This message is routed through the content script to code injected within the page itself.
https://github.com/google/audion/blob/795545d1692d11a0348556827622c997dbc9502e/js/entry-points/inject-tracing.js#L30

The injected logic would then handle that message appropriately.
https://github.com/google/audion/blob/795545d1692d11a0348556827622c997dbc9502e/js/entry-points/tracing.js#L1184