associated. So, the first playlist for a track called "Cowbell" will be called
"Cowbell.1", the next one "Cowbell.2", etc. This name can be changed at any
time, to anything: Ardour does not require playlist names to be unique,
- although it will make the user's life easier if they are. Suggested examples
+ although it will make the user's life easier if they are. Suggested examples
of user-assigned names for a playlist might include <kbd class="input"> Lead
Guitar, 2nd take</kbd>, <kbd class="input">vocals (quiet)</kbd>, and <kbd
- class="input">downbeat cuica</kbd>. Notice how these might be different from the
+ class="input">downbeat cuica</kbd>. These might be different from the
associated track names, which for these examples might be <kbd
class="input">Lead Guitar</kbd>, <kbd class="input">Vocals</kbd> and <kbd
class="input">Cuica</kbd>. The playlist name provides more information because
<p class="note">Using the fact that playlist names are based on the active one with
an incremented version number, one can rename a playlist "Cowbell take.1" so that
- the next playlist crated is automatically named "Cowbell take.2" etc. This allows
+ the next playlist created is automatically named "Cowbell take.2" etc. This allows
for a quick way to label different takes.
</p>
slightly unusual thing that should be noted when sharing is that edits to the
playlist made in one track will magically appear in the other. It is an
obvious consequence of sharing. One application of this attribute is parallel
- processing, described in <a href="@@playlist-usecases">Playlist Usecases</a>.
+ processing, described in <a href="@@playlist-usecases">Playlist Use Cases</a>.
</p>
<p>
To avoid this kind of behaviour, and nevertheless use the same (or substantially