Typo.

grame-cncm · Aug 17, 2024 · 3021740 · 3021740
1 parent a970c07
commit 3021740
Show file tree

Hide file tree

Showing 5 changed files with 5 additions and 5 deletions.
diff --git a/docs/index.html b/docs/index.html
@@ -477,5 +477,5 @@ <h4 class="modal-title" id="keyboardModalLabel">Keyboard Shortcuts</h4>
 
 <!--
 MkDocs version : 1.4.3
-Build Date UTC : 2024-08-17 08:34:11.994489+00:00
+Build Date UTC : 2024-08-17 08:37:15.573665+00:00
 -->
diff --git a/docs/manual/architectures/index.html b/docs/manual/architectures/index.html
@@ -415,7 +415,7 @@
             </li>
             <li class="nav-item" data-level="3"><a href="#macro-construction-of-dsp-components" class="nav-link">Macro Construction of DSP Components</a>
               <ul class="nav flex-column">
-            <li class="nav-item" data-level="4"><a href="#dsp-decorator-pattern" class="nav-link">Dsp Decorator Pattern</a>
+            <li class="nav-item" data-level="4"><a href="#dsp-decorator-pattern" class="nav-link">DSP Decorator Pattern</a>
               <ul class="nav flex-column">
               </ul>
             </li>
@@ -1494,7 +1494,7 @@ <h3 id="global-dsp-metadata">Global DSP metadata</h3>
 <h3 id="macro-construction-of-dsp-components">Macro Construction of DSP Components</h3>
 <p>The Faust program specification is usually entirely done in the language itself. But in some specific cases it may be useful to develop <em>separated DSP components</em> and <em>combine</em> them in a more complex setup.</p>
 <p>Since taking advantage of the huge number of already available UI and audio architecture files is important, keeping the same <code>dsp</code> API is preferable, so that more complex DSP can be controlled and audio rendered the usual way. Extended DSP classes will typically subclass the <code>dsp</code> base class and override or complete part of its API. </p>
-<h4 id="dsp-decorator-pattern">Dsp Decorator Pattern</h4>
+<h4 id="dsp-decorator-pattern">DSP Decorator Pattern</h4>
 <p>A <code>dsp_decorator</code> class, subclass of the root <code>dsp</code> class has first been defined. Following the decorator design pattern, it allows behavior to be added to an individual object, either statically or dynamically.</p>
 <p>As an example of the decorator pattern, the <code>timed_dsp</code> class allows to decorate a given DSP with sample accurate control capability or the <code>mydsp_poly</code> class for polyphonic DSPs, explained in the next sections.</p>
 <h4 id="combining-dsp-components">Combining DSP Components</h4>

diff --git a/docs/search/search_index.json b/docs/search/search_index.json
diff --git a/docs/sitemap.xml.gz b/docs/sitemap.xml.gz
diff --git a/mkdocs/docs/manual/architectures.md b/mkdocs/docs/manual/architectures.md
@@ -815,7 +815,7 @@ The Faust program specification is usually entirely done in the language itself.
 
 Since taking advantage of the huge number of already available UI and audio architecture files is important, keeping the same `dsp` API is preferable, so that more complex DSP can be controlled and audio rendered the usual way. Extended DSP classes will typically subclass the `dsp` base class and override or complete part of its API. 
 
-#### Dsp Decorator Pattern
+#### DSP Decorator Pattern
 
 A `dsp_decorator` class, subclass of the root `dsp` class has first been defined. Following the decorator design pattern, it allows behavior to be added to an individual object, either statically or dynamically.