---
<p>A typical <dfn>MIDI track header</dfn> looks like this:</p>
-<img src="/diagrams/typical-midi-track-controls.png" alt="midi track controls"
+<img src="/images/typical-midi-track-controls.png" alt="midi track controls"
/>
<p>
<h3>External Monitoring</h3>
<img class="right"
-src="/diagrams/external-monitoring.png" />
+src="/images/external-monitoring.png" />
<p>When using <dfn>external monitoring</dfn>, Ardour plays no role in
monitoring at all. Perhaps the recording set-up has an external mixer which
can be used to set up monitor mixes, or perhaps the sound-card being used
settings are less flexible and not saved with the session.</p>
<h3>JACK-Based Hardware Monitoring</h3>
-<img class="right" src="/diagrams/jack-monitoring.png" />
+<img class="right" src="/images/jack-monitoring.png" />
<p>Some sound cards have the ability
to mix signals from their inputs to their outputs with very low or even zero
latency, a feature called <dfn>hardware monitoring</dfn>.
</p>
<h3>Software Monitoring</h3>
-<img class="right" src="/diagrams/ardour-monitoring.png" />
+<img class="right" src="/images/ardour-monitoring.png" />
<p>With the <dfn>software monitoring</dfn> approach, all monitoring is
performed by Ardour — it makes track inputs available at track
outputs, governed by various controls. This approach will almost always have
<p>
The solo-mute arrangement with a monitor bus is shown below:
</p>
-<img src="/diagrams/solo-mute.png" alt="mute/solo signal flow" />
-<p>
+<img src="/images/solo-mute.png" alt="mute/solo signal flow" />
+<p>
Here we have a number of tracks or busses (in orange). Each one has an
output which feeds the master bus. In addition, each has PFL and AFL
outputs; we have a choice of which to use. PFL/AFL from each track or
<h2>The Latency chain</h2>
-<img src="/diagrams/latency-chain.png" title="Latency chain" alt="Latency chain" />
+<img src="/images/latency-chain.png" title="Latency chain" alt="Latency chain" />
<p>
<em>Figure: Latency chain.</em>
The numbers are an example for a typical PC. With professional gear and an
In order to compensate for latency, JACK or JACK applications need to know
exactly how long a certain signal needs to be read-ahead or delayed:
</p>
-<img src="/diagrams/jack-latency-excerpt.png" title="Jack Latency Compensation" alt="Jack Latency Compensation" />
+<img src="/images/jack-latency-excerpt.png" title="Jack Latency Compensation" alt="Jack Latency Compensation" />
<p>
<em>Figure: Jack Latency Compensation.</em>
</p>
the video Frame boundaries.
</p>
-<img src="/diagrams/ltc-transport-alignment.png" title="LTC frame alignment" alt="LTC frame alignment"/>
+<img src="/images/ltc-transport-alignment.png" title="LTC frame alignment" alt="LTC frame alignment"/>
<p><em>Figure: LTC frame alignment for the 525/60 TV standard</em></p>
<p>
if 'link' in header:
explode.write('link: ' + header['link'] + '\n')
- if 'uri' in header:
- explode.write('uri: ' + header['uri'] + '\n')
-
if 'style' in header:
explode.write('style: ' + header['style'] + '\n')
explode.write('include: ' + inclFile + '\n')
filenames.append(inclFile)
+ if 'uri' in header:
+ explode.write('uri: ' + header['uri'] + '\n')
+
explode.write('part: ' + header['part'] + '\n' + '---\n')
# Only parts have no content...
if 'link' in header:
implode.write('link: ' + header['link'] + '\n')
- if 'uri' in header:
- implode.write('uri: ' + header['uri'] + '\n')
-
if 'style' in header:
implode.write('style: ' + header['style'] + '\n')
implode.write('include: ' + header['include'] + '\n')
implode.write('exclude: yes\n')
+ if 'uri' in header:
+ implode.write('uri: ' + header['uri'] + '\n')
+
implode.write('part: ' + header['part'] + '\n' + '---\n')
# Only parts have no content...