1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
<?xml version="1.0" standalone="no"?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
]>
<section id="sn-working-with-playlists">
<title>Working with Playlists</title>
<para>
As described earlier <link linkend="gt-playlist">playlists</link> are one of
the central objects in a digital audio workstation. A playlist is a list of
<link linkend="gt-region">regions</link> ordered in time. It defines which
parts of which source files should be played and when.
</para>
<para>
Each track in Ardour is really just a mechanism for taking a playlist and
generating the audio stream that it represents. As a result, editing a track
really means modifying its playlist in some way. Since a playlist is a list
of regions, most of the modifications involve manipulating regions: their
position, length and so forth. This is covered in
<xref linkend="sn-working-with-regions"/>. Here, we cover some of the things
you can do with playlists as objects in their own right.
</para>
<section id="tracks-are-not-playlists">
<title> Tracks are not Playlists </title>
<para>
It is important to understand that a track is <emphasis>not</emphasis> a
playlist. A track is a mechanism for generating the audio stream
represented by the playlist and passing it through a signal processing
pathway. At any point in time, a track has a single playlist associated
with it. When the track is used to record, that playlist will have one or
more new regions added to it. When the track is used for playback, the
contents of the playlist will be heard. Old tape operators will feel
comfortable thinking of the playlist as the tape, and the track as the tape
machine.
</para>
<para>
However, you can change the playlist associated with a track at (almost)
any time, and even share playlists between tracks. There is more on this
<link linkend="playlist-operations">below</link>.
</para>
</section>
<section id="playlists-are-cheap">
<title> Playlists are cheap </title>
<para>
One thing you should be clear about is that playlists are cheap. They don't
cost anything in terms of CPU consumption, and they have very minimal
efforts on memory use. Don't be afraid of generating new playlists whenever
you want to. They are not equivalent to tracks, which require extra CPU
time and significant memory space, or audio files, which use disk space, or
to plugins that require extra CPU time. If a playlist is not in use, it
occupies a small amount of memory, and nothing more.
</para>
</section>
<section id="playlists-as-takes">
<title> Playlists as "Takes" or "Virtual Tracks" </title>
<para>
If you have a background in audio engineering, then it might be easiest for
you to think of playlists as "takes". This isn't a particularly useful
analogy by itself, and it can be misleading. But if you are working with
music where most tracks feature single-pass recordings of a single
instrument, then the idea of using one playlist per "take" can make life
very convenient. Each time you need to record another take, create a new
playlist list first. You will then end up with a simple way of switching
back and forth between each version, or even listening to several at the
same time.
</para>
<para>
If you have some experience of other DAWs, then you might have come across
the term "virtual track", normally defined as a track that isn't actually
playing or doing anything, but can be mapped/assigned to a "real track".
This concept is functionally identical to Ardour's playlists. We just like
to be little more clear about what is actually happening rather than mixing
old and new terminology ("virtual" and "track") into confusing terminology.
</para>
</section>
<section id="playlist-operations">
<title> Playlist Operations </title>
<para>
At this point, all operations on playlists start by clicking on the
playlist button (labelled <guibutton>p</guibutton>) in the control area of a track in the
editor. Clicking the button will popup a menu with the following choices:
</para>
<variablelist>
<title></title>
<varlistentry>
<term><guilabel>Current</guilabel></term>
<listitem>
<para>
shows the name of the current playlist used by this track
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><guilabel>Rename</guilabel></term>
<listitem>
<para>
pops up a dialog that allows the current playlist to be renamed
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><guilabel>New</guilabel></term>
<listitem>
<para>
creates a new <emphasis>empty</emphasis> playlist, and switches this
track to use it
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><guilabel>New Copy</guilabel></term>
<listitem>
<para>
creates a new playlist that is a copy of the current playlist, and
switches this track to use it
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><guilabel>Clear Current</guilabel></term>
<listitem>
<para>
removes all regions from the current playlist
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><guilabel>Select</guilabel></term>
<listitem>
<para>
pops up a playlist browser to manually choose which playlist this track
should use
</para>
</listitem>
</varlistentry>
</variablelist>
<section id="renaming-playlists">
<title>Renaming Playlists</title>
<para>
Playlists are created with the name of the track of which they are
associated, plus a version number. So, the first playlist for a track
called "Cowbell" will be called "Cowbell.1". This name will be used to
define the names of any regions added to the playlist by recording. You
can change the name at any time, to anything you want. Ardour does not
require that your playlist names are all unique, but it will make your
life easier if they are. Suggested examples of user-assigned names for a
playlist might include "Lead Guitar, 2nd take", "vocals (quiet)", and
"downbeat cuica". Notice how these might be different from the associated
track names, which for these examples might be "Lead Guitar", "Vocals" and
"Cuica". The playlist name provides more information because it is about a
specific version of the material that may (or may not) end up in the final
version of the track.
</para>
<para>
If you are going to rename your playlists, do so before recording new
material to them.
</para>
</section>
<section id="selecting-playlists">
<title>Selecting Playlists</title>
<para>
If you click on the "Select" choice of the playlist button menu, a dialog
will appear that displays all playlists in a tree-structure (many will be
hidden). Playlists will be grouped by the track for which they were
created, with all those created for the current track displayed. Other
tracks are hidden in a collapsed tree that can be expanded as you wish to
find other playlists.
</para>
</section>
<section id="sharing-playlists">
<title>Sharing Playlists</title>
<para>
It is entirely possible to share playlists between tracks. The only
slightly unusual thing you may notice when sharing is that edits to the
playlist made in one track will magically appear in the other. If you
think about this for a moment, its an obvious consequence of sharing.
</para>
<para>
You might not want this kind of behaviour, even though you still want two
tracks to use the same (or substantially the same) playlist. To accomplish
this, select the chosen playlist in the second track, and then use
<guilabel>New Copy</guilabel> to generate an independent copy of it for
that track. You can then edit this playlist without affecting the
original.
</para>
</section>
<section id="using-playlists-for-takes">
<title>Using playlists for takes</title>
<para>
You have several choices here. You can obviously record new takes directly
over an existing one, because of the non-destructive nature of digital
audio editing. You can also use the <guilabel>Clear Current</guilabel>
operation each time you want to start a new take. This is a
non-destructive operation that removes all existing regions from the
current playlist. Although you won't lose any information doing this, its
probably not appropriate unless the last take was so awful that you want
to discard it (although without the finality of <emphasis>Remove Last
Capture</emphasis> ). Finally, and probably most useful, you can use the
<guilabel>New</guilabel> operation in the playlist button menu to create a
new empty playlist, ready for the next take. Later, you can
<guilabel>Select</guilabel> your way back to previous or later takes as
desired, either in this or some other track.
</para>
</section>
</section>
</section>
|
