Fix typos

src/pages/docs/guides/Making_Sound.md

@@ -108,7 +108,7 @@ Elementary will happily go ahead with that for you, but note that writing `el.mu
 expression `el.mul(6.28318.., t)`. Therefore, instead of `h(x) = f(x) * g(x)` describing three functions, we simply have `h(x) = 6.28318`.
 
 This simple trick is helpful to keep in mind as you write more and more complicated Elementary applications, because
-it lets you compute constant values ahead of time that might otherwise be reduntant to actually compute continuously
+it lets you compute constant values ahead of time that might otherwise be redundant to actually compute continuously
 at audio rate (Elementary can and often will find and perform simple optimizations like this for you, but being explicit never hurts).
 
 Ok, backing up: we've got our `sineTone` function, and we know that we want to use a `phasor` to represent time. What
@@ -119,12 +119,12 @@ let tone = sineTone(el.phasor(440));
 elementary.core.render(tone);
 ```
 
-Simple! We've now arrived at a complete Elementary application for generating a continous sine tone. Let's
+Simple! We've now arrived at a complete Elementary application for generating a continuous sine tone. Let's
 walk this back through one more time. To start, we have our `el.phasor(440)` which generates a ramp from 0 to 1
 continuously, 440 times a second. We take this signal and multiply it by two Pi: `el.mul(2 * Math.PI, t)`. The result
 is then a signal which ramps from 0 to 6.28318... continuously, 440 times a second. Finally, we take the sin of that signal
 with `el.sin()`, and, remembering that [0, 2 * Pi] describes a complete cycle of the sin function, we therefore have a continuous
-signal which outputs a continguous sequence of sine wave cycles, 440 per second. The complete program in Elementary is as follows:
+signal which outputs a continuous sequence of sine wave cycles, 440 per second. The complete program in Elementary is as follows:
 
 ```js
 import {ElementaryPluginRenderer as core, el} from '@elemaudio/core';

src/pages/docs/guides/Sample_Accurate_Rendering.md

@@ -8,7 +8,7 @@ these blocks of audio hold a few (or tens of) milliseconds of audio data.
 
 As you write your audio software, you have some flexibility to decide what changes take effect
 and where, to make your own tradeoffs about the performance and structure of your app. The general
-distiction to be aware of is that any time you execute javascript, changes made to the signal flow
+distinction to be aware of is that any time you execute javascript, changes made to the signal flow
 of your application will only be applied at the beginning of the next audio block (which means that, due
 to the block size, your change might not take effect for several milliseconds).
 

src/pages/docs/guides/Understanding_Keys.md

@@ -4,7 +4,7 @@ This guide assumes that you've already read the [In Depth](../In_Depth) introduc
 and picks up where the In Depth introduction leaves off when it references keys.
 
 If your application only ever makes a single call to `core.render`, then this section won't
-really apply, and in such a case the behavior is well explained in [In Depth](./In_Depth).
+really apply, and in such a case the behavior is well explained in [In Depth](../In_Depth).
 However, audio applications frequently exhibit dynamic behavior, and it's in this context that
 we'll explore what happens when you make multiple successive calls to `core.render`.
 
@@ -56,7 +56,7 @@ Now, after updating our voices, we re-run the `synth` function and then call `co
 where the behavior gets interesting. On the first call to `core.render`, Elementary is starting from a
 blank slate and simply does the work to realize the graph you've provided. On the second call, Elementary will compare the
 new signal to render with the one that it has most recently rendered for you already. While doing this, Elementary
-will look for the the minimal set of changes to apply to the existing rendering to arrive at the new desired state, and
+will look for the minimal set of changes to apply to the existing rendering to arrive at the new desired state, and
 apply those changes. This is much like the "virtual DOM diff" that React.js popularized for web applications.
 
 ## Keys
@@ -119,7 +119,7 @@ function synth(vs) {
       el.const({key: `${v.key}:gate`, value: v.gate}),
       el.cycle(el.const({key: `${v.key}:freq`, value: v.freq}))
     );
-  });
+  }));
 }
 ```
 

src/pages/docs/guides/Virtual_File_System.mdx

@@ -13,7 +13,7 @@ and allows the audio processing nodes to remain lightweight.
   which maps from an arbitrary string name (key) to a single-channel buffer of audio data (value).
 
   In future versions, the API naming may be updated to reflect this. The native C++ interface already
-  referes to the same feature as a "shared resource map."
+  refers to the same feature as a "shared resource map."
 </Callout>
 
 ## Loading data into the VFS

src/pages/docs/in_depth.md

@@ -120,7 +120,7 @@ core.initialize();
 
 Now our example is prepared for change: each time the user moves the slider, we'll receive a callback
 informing the new value, and we simply describe the new audio graph and call `core.render()`. In this example,
-we're calling `core.render()` many many times in succession as the user drags the slider: that's the idea!
+we're calling `core.render()` many times in succession as the user drags the slider: that's the idea!
 
 Ok so now we have an appropriate backdrop to discuss what actually happens inside the call to `core.render()`.
 Let's pick a point right in the middle of the lifetime of our application: we have already called `core.render()`
@@ -140,6 +140,6 @@ that we're building and discussing here are extremely lightweight, virtual repre
 It's only after the reconciliation process has completed that we introduce the corresponding native audio processing
 nodes that actually handle the realtime audio data. Elementary can already assemble and then reconcile graphs of thousands and
 thousands of deeply interconnected nodes within a couple milliseconds, and we expect to make this faster still. Of course, undergoing that process does add
-those few millseconds of overhead, and this is exactly the tradeoff we aim to make to ensure one thing: you as an audio
+those few milliseconds of overhead, and this is exactly the tradeoff we aim to make to ensure one thing: you as an audio
 application author never need to think about _how_ to address dynamic audio graph behavior. You can always rely on one simple
 paradigm: describe how your audio graph should sound now, and let Elementary handle the rest.

src/pages/docs/packages/core.md

@@ -7,7 +7,7 @@ integrations.
 
 ## Installation
 
-```js
+```sh
 npm install --save @elemaudio/core
 ```
 
@@ -30,7 +30,7 @@ documentation on exactly which nodes are available and what they do, see the Ref
 
 ### createNode
 
-```js
+```typescript
 function createNode(kind: string, props: Object, children: array<ElemNode>): NodeRepr_t;
 ```
 
@@ -41,15 +41,15 @@ Typically, you'll only need to pay attention to this API for referring to your o
 
 ### isNode
 
-```js
+```typescript
 function isNode(a: any): bool;
 ```
 
 A simple utility for identifying if the input argument is of type `NodeRepr_t`.
 
 ### resolve
 
-```js
+```typescript
 function resolve(n: NodeRepr_t | number): NodeRepr_t;
 ```
 

src/pages/docs/packages/offline-renderer.md

@@ -6,7 +6,7 @@ the actual encoding/decoding to and from file is not handled here, just the audi
 
 ## Installation
 
-```js
+```sh
 npm install --save @elemaudio/offline-renderer
 ```
 
@@ -72,7 +72,7 @@ The options object expects the following properties:
 * `numOutputChannels: number` – default 2
 * `sampleRate: number` – default 44100
 * `blockSize: number` – default 512
-* `virtualFileSystem: Object<string, Array<number>|Float32Array>` – default `{}`
+* `virtualFileSystem: Object<string, Array<number>|Float32Array>` – default `{}`
 
 **Note** the difference here in the `initialize` API between the `offline-renderer` and the `web-renderer`: when initializing
 the `web-renderer` we must use the `processorOptions` field to propagate the `virtualFileSystem` argument due to the nature of

src/pages/docs/packages/web-renderer.md

@@ -4,7 +4,7 @@ The official package for rendering Elementary applications in web browsers using
 
 ## Installation
 
-```js
+```sh
 npm install --save @elemaudio/web-renderer
 ```
 
@@ -49,7 +49,7 @@ Web Audio application as you like. See `initialize()` for connecting to WebAudio
 ### initialize
 
 ```js
-core.initialize(ctx: AudioContext, options: AudioWorkletNodeOptions) : Promise<WebAudioNode>`
+core.initialize(ctx: AudioContext, options: AudioWorkletNodeOptions) : Promise<WebAudioNode>
 ```
 
 Initializes the Elementary runtime within the provided AudioContext. Here, Elementary will construct

src/pages/docs/playground_api.md

@@ -20,7 +20,7 @@ Part of being able to successfully re-evaluate your code as you type requires ma
 do that, the Playground initializes itself by requesting any state that you might want to persist to the running instance, such as entries
 in the [Virtual File System](./guides/Virtual_File_System).
 
-During initialization, the Playground runtime will updates its internal virtual file system with the contents of the object that you return
+During initialization, the Playground runtime updates its internal virtual file system with the contents of the object that you return
 from this function. This function is _only_ called upon initialization, so if you make changes you will need to press the Reset button
 on the Playground to rerun the initialization steps.
 

src/pages/docs/reference/Math.md

@@ -131,7 +131,7 @@ None
 
 ### el.eq
 
-Compares the first input to the second input, returning 1 when the the two signals
+Compares the first input to the second input, returning 1 when the two signals
 have equal values, and 0 otherwise.
 
 #### Props

src/pages/docs/reference/compress.md

@@ -4,7 +4,7 @@ A simple hard-knee compressor with parameterized attack, release, threshold,
 and ratio, with an optional sidechain input.
 
 * `@param {Node | number} atkMs` – attack time in milliseconds
-* `@param {Node | number} relMs` – release time in millseconds
+* `@param {Node | number} relMs` – release time in milliseconds
 * `@param {Node | number} threshold` – decibel value above which the comp kicks in
 * `@param {Node | number} ratio` – ratio by which we squash signal above the threshold
 * `@param {Node} sidechain – sidechain` signal to drive the compressor

src/pages/docs/reference/meter.md

@@ -9,9 +9,9 @@ maximum and minimum peak value each block. The result is emitted through the
 core Renderer event interface with an event object matching the following
 structure.
 
-```javascript
+```typescript
 interface MeterEvent {
-  source: string?;
+  source?: string;
   min: number;
   max: number;
 };

src/pages/docs/reference/metro.mdx

@@ -19,7 +19,7 @@ rising edge of its output signal.
 For example, consider a graph like the following:
 
 ```js
-core.on('load' function(e) {
+core.on('load', function(e) {
   core.render(el.train(5));
 
   setTimeout(function() {
@@ -37,7 +37,7 @@ will ever share a synchronized rising edge in time.
 Alternatively, consider this example:
 
 ```js
-core.on('load' function(e) {
+core.on('load', function(e) {
   core.render(el.metro({interval: 200}));
 
   setTimeout(function() {
@@ -55,7 +55,7 @@ Further, we can now listen for event callbacks to coordinate some JavaScript wit
 metronome timing.
 
 ```js
-core.on('load' function(e) {
+core.on('load', function(e) {
   core.render(el.metro({interval: 200}));
 });
 
@@ -68,9 +68,9 @@ core.on('metro', function(e) {
 
 Finally, the event object emitted with the "metro" event follows the given structure.
 
-```javascript
+```typescript
 interface MetroEvent {
-  source: string?;
+  source?: string;
 };
 ```
 

src/pages/docs/reference/saw.md

@@ -8,7 +8,7 @@ Outputs a naive sawtooth oscillator at the given frequency. Expects exactly one
 specifying the cycle frequency in `hz`.
 
 Typically, due to the aliasing of the naive sawtooth at audio rates, this oscillator
-is used for low frequencly modulation.
+is used for low frequency modulation.
 
 #### Props
 

src/pages/docs/reference/scope.md

@@ -7,9 +7,9 @@ sidebar_label: el.scope
 A pass-through node which buffers its incoming signal(s), and reports them to the
 JavaScript environment through the core Renderer event emitting interface.
 
-```javascript
+```typescript
 interface ScopeEvent {
-  source: string?;
+  source?: string;
   data: Array<Array<Number>>;
 };
 ```

src/pages/docs/reference/skcompress.md

@@ -10,7 +10,7 @@ same input both as the input to be compressed and as the sidechain signal itself
 for standard compressor behavior.
 
 * `@param {Node | number} atkMs` – attack time in milliseconds
-* `@param {Node | number} relMs` – release time in millseconds
+* `@param {Node | number} relMs` – release time in milliseconds
 * `@param {Node | number} threshold` – decibel value above which the comp kicks in
 * `@param {Node | number} ratio` – ratio by which we squash signal above the threshold
 * `@param {Node | number} kneeWidth` – width of the knee in decibels, 0 for hard knee

src/pages/docs/reference/square.md

@@ -8,7 +8,7 @@ Outputs a naive square oscillator at the given frequency. Expects exactly one ch
 specifying the cycle frequency in `hz`.
 
 Typically, due to the aliasing of the naive square at audio rates, this oscillator
-is used for low frequencly modulation.
+is used for low frequency modulation.
 
 #### Props
 

src/pages/docs/reference/triangle.md

@@ -8,7 +8,7 @@ Outputs a naive triangle oscillator at the given frequency. Expects exactly one
 specifying the cycle frequency in `hz`.
 
 Typically, due to the aliasing of the naive triangle at audio rates, this oscillator
-is used for low frequencly modulation.
+is used for low frequency modulation.
 
 #### Props
 

src/pages/docs/tutorials/distortion-saturation-wave-shaping.mdx

@@ -74,7 +74,7 @@ export function playEx02(sliderValue) {
 
   core.render(
     el.scope(el.select(vs, wl, dl)),
-    el.select(vs, wl, dl),
+    el.select(vs, wr, dr),
   );
 }
 ```