Remove references to SOUL project.

docs/index.html

@@ -465,5 +465,5 @@ <h4 class="modal-title" id="keyboardModalLabel">Keyboard Shortcuts</h4>
 
 <!--
 MkDocs version : 1.4.3
-Build Date UTC : 2024-03-26 20:30:26.421817+00:00
+Build Date UTC : 2024-03-26 22:14:27.315082+00:00
 -->

docs/manual/architectures/index.html

@@ -1436,7 +1436,7 @@ <h3 id="the-base-dsp-class">The Base <code>dsp</code> Class</h3>
 <li>the<code>metadata(Meta* m)</code>method can be called with a <code>Meta</code> object to decode the instance global metadata (see next section)</li>
 </ul>
 <p>(note that <code>FAUSTFLOAT</code> label is typically defined to be the actual type of sample: either <code>float</code> or <code>double</code> using <code>#define FAUSTFLOAT float</code> in the code for instance).</p>
-<p>For a given compiled DSP program, the compiler will generate a <code>mydsp</code> subclass of <code>dsp</code> and fill the different methods (the actual name can be changed using the <code>-cn</code> option). For dynamic code producing backends like the LLVM IR, Cmajor or the Interpreter ones, the actual code (an LLVM module, a Cmajor module or a bytecode stream) is actually wrapped by some additional C++ code glue, to finally produces  a <code>llvm_dsp</code> typed object (defined in the <a href="https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/llvm-dsp.h">llvm-dsp.h</a> file), a <code>soulpatch_dsp</code>  typed object (defined in the <a href="https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/soulpatch-dsp.h">soulpatch-dsp.h</a> file) or an <code>interpreter_dsp</code> typed object (defined in <a href="https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/interpreter-dsp.h">interpreter-dsp.h</a> file), ready to be used  with the <code>UI</code> and <code>audio</code>  C++ classes (like the C++ generated class). See the following class diagram:</p>
+<p>For a given compiled DSP program, the compiler will generate a <code>mydsp</code> subclass of <code>dsp</code> and fill the different methods (the actual name can be changed using the <code>-cn</code> option). For dynamic code producing backends like the LLVM IR, Cmajor or the Interpreter ones, the actual code (an LLVM module, a Cmajor module or a bytecode stream) is actually wrapped by some additional C++ code glue, to finally produces an <code>llvm_dsp</code> typed object (defined in the <a href="https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/llvm-dsp.h">llvm-dsp.h</a> file), a <code>cmajorpatch_dsp</code> typed object (defined in the <a href="https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/cmajorpatch-dsp.h">cmajorpatch-dsp.h</a> file) or an <code>interpreter_dsp</code> typed object (defined in <a href="https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/interpreter-dsp.h">interpreter-dsp.h</a> file), ready to be used  with the <code>UI</code> and <code>audio</code> C++ classes (like the C++ generated class). See the following class diagram:</p>
 <p><img src="img/DSPHierarchy.png" class="mx-auto d-block" width="85%"></p>
 <h3 id="global-dsp-metadata">Global DSP metadata</h3>
 <p>All global metadata declaration in Faust start with <code>declare</code>, followed by a key and a string. For example:</p>

mkdocs/docs/manual/architectures.md

@@ -747,7 +747,7 @@ The dsp class is central to the Faust architecture design:
 
 (note that `FAUSTFLOAT` label is typically defined to be the actual type of sample: either `float` or `double` using `#define FAUSTFLOAT float` in the code for instance).
 
-For a given compiled DSP program, the compiler will generate a `mydsp` subclass of `dsp` and fill the different methods (the actual name can be changed using the `-cn` option). For dynamic code producing backends like the LLVM IR, Cmajor or the Interpreter ones, the actual code (an LLVM module, a Cmajor module or a bytecode stream) is actually wrapped by some additional C++ code glue, to finally produces  a `llvm_dsp` typed object (defined in the [llvm-dsp.h](https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/llvm-dsp.h) file), a `soulpatch_dsp`  typed object (defined in the [soulpatch-dsp.h](https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/soulpatch-dsp.h) file) or an `interpreter_dsp` typed object (defined in [interpreter-dsp.h](https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/interpreter-dsp.h) file), ready to be used  with the `UI` and `audio`  C++ classes (like the C++ generated class). See the following class diagram:
+For a given compiled DSP program, the compiler will generate a `mydsp` subclass of `dsp` and fill the different methods (the actual name can be changed using the `-cn` option). For dynamic code producing backends like the LLVM IR, Cmajor or the Interpreter ones, the actual code (an LLVM module, a Cmajor module or a bytecode stream) is actually wrapped by some additional C++ code glue, to finally produces an `llvm_dsp` typed object (defined in the [llvm-dsp.h](https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/llvm-dsp.h) file), a `cmajorpatch_dsp` typed object (defined in the [cmajorpatch-dsp.h](https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/cmajorpatch-dsp.h) file) or an `interpreter_dsp` typed object (defined in [interpreter-dsp.h](https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/interpreter-dsp.h) file), ready to be used  with the `UI` and `audio` C++ classes (like the C++ generated class). See the following class diagram:
 
 <img src="img/DSPHierarchy.png" class="mx-auto d-block" width="85%">