1
------------------------------------------------------------------------
4
(edi-19) Separate file format for multitrack setups (.emt).
5
- submitted: kaiv, 18.10.2001
6
- frozen: kaiv, 20.08.2003
8
------------------------------------------------------------------------
9
Reason for the frozen status:
11
- there's already too many alternatives on how to use ecasound; a new
12
file format would jus add confusion and bloat (even though the idea
13
itself is not a bad one)
15
------------------------------------------------------------------------
19
What if ecasound could understand the following file format:
21
file "my_next_big_hit.emt"
28
# name mon/rec gain-% pan-% chain ops
29
drums.wav mon 100 50 -efl:4000
30
303line.wav mon 120 50 -etr:60,0,7
34
You'd write the above (or use a separate frontend app that can save to
35
.emt), and then use it like:
37
ecasound my_next_big_hit.emt -c
39
ecasound ('h' for help)> start
41
... and so on. The benefits of .emt would be:
43
- easier to use (hides ecasound's input, output and chain concepts);
44
anyone who knows how to use cakewalk, cooledit or an analog
45
4-track should be able to understand how the above works (perhaps
46
a gui is needed, but that doesn't change the concept)
47
- faster changing between mix-to-dsp, mix-to-file and
48
record-new-track modes (only one .emt file instead of
53
- conversion from .ecs to .emt might prove to be trickier
54
(.emt cannot express all chainsetup configurations),
55
which again means that changes made in iactive
56
mode are not (necessarily) stored to .emt files
58
Internally ecasound would convert the .emt files to chainsetup (.ecs)
59
files before loading. So something like:
62
# ecasound chainsetup file
65
-sr:44100 -t:20 -z:noxruns -z:nopsr
69
-a:mon2 -i:303line.wav
72
-a:mon1,mon2 -o:/dev/dsp
74
# chain operators and controllers
75
-a:mon1 -ea:100.00 -epp:50.00 -efl:4000.00
76
-a:mon2 -ea:120.00 -epp:50.00 -etr:60.00,0.00,7.00
77
-a:rec1 -ea:100.00 -epp:50.00
82
------------------------------------------------------------------------
83
- Luis Pablo Gasparotto, 18.10.2001
86
What do you think about this?
88
# name mon/rec Start time gain-% pan-% chain ops
89
drums.wav mon 00:00 100 50 -efl:4000
90
303line.wav mon 00:00 120 50 -etr:60,0,7
91
lead.wav rec 01:30 100 50
94
------------------------------------------------------------------------
95
- S. Massy, 19.10.2001
98
> What if ecasound could understand the following file format:
101
> file "my_next_big_hit.emt"
108
> # name mon/rec gain-% pan-% chain ops
109
> drums.wav mon 100 50 -efl:4000
110
> 303line.wav mon 120 50 -etr:60,0,7
111
> lead.wav rec 100 50
113
- I like the way you divide it into either rec (read `input' and write to
114
`name) and mon (read from `name' and write to `output')
115
- Why use up fields for gain and pan while they can be expressed as cops?
116
To make it look like an analog multitrack recorder?
117
- You'd need a field to specify the format for each file.
118
- Cruel lack of identifiers. (see below)
121
> You'd write the above (or use a separate frontend app that can save to
122
> .emt), and then use it like:
124
> ecasound my_next_big_hit.emt -c
126
> ecasound ('h' for help)> start
127
While I agree that it's nice for a new user to have a more simple format to
128
specify a cs, I only see it as I side benefit (if the user is into asci files
129
he might as well write an .ecs.) The real benefit in such format I deem would
131
- Ability to store information into a file format already understood by
133
- Ability to store information in a way that is compatible between different
135
(You can have a simple shell script to create a multitrack spec and then
136
load it into a full-featured x-based c++ program.)
137
You'll say that programs might as well write directly to .ecs and do the
138
vulgarization on its own; that may be true, but .emt would simplify the job
141
So here we come to my point which is the need for identifiers in an
142
hypothetical .emt file; wouldn't it be nice if you could always reuse the
143
template of an .emt file, only changing the filenames? Also, identifiers
144
help make it more concrete (names) and more coherent between different
145
front-ends (you load your .emt file in another app and the tracks are still
146
described the same way.)
147
So here's my idea of an .emt format with a setup that is frequent to me (it
148
uses braces though, be warned, I know some don't like braces.):
152
guitar_recording_stage {
153
# Always have comments allowed in a file format.
162
operators = -erc:1,2 -ea:120
167
target = bass/take2.wav
169
operators = -pn:bassboost
174
target = drums/drums.ewf
180
operators = -pn:metronome,120
185
target = guitar/take1.raw
190
Of course, you seldom need a metronome when you already have other tracks
191
to monitor, I'm just trying to show what we need to have to be happy. :)
193
One thing that I'd like to see would be the ability to set offsets directly
194
from the command-line (and from a file like .emt) because, to quote Janne in
195
an approximate way, "You need to take a breath between the moment you hit
196
start and the moment you start to play." Also, while a metronome isn't
197
altogether required while monitoring with other tracks, some sort of clicks
198
at the beginning would be quite welcome, but right now there aren't any
199
simple way to do it, is there? Apart from wrapping every file into an ewf?
200
Wouldn't it be nice if we could do:
204
offset = 25 # 25 seconds to go from the keyboard to the guitar.
209
length = 4 # 8 clicks
210
operators = -pn:metronome,120
215
offset = 4 # += general offset
221
offset = 4 # += general offset
228
> ... and so on. The benefits of .emt would be:
230
> - easier to use (hides ecasound's input, output and chain concepts);
231
> anyone who knows how to use cakewalk, cooledit or an analog
232
> 4-track should be able to understand how the above works (perhaps
233
> a gui is needed, but that doesn't change the concept)
234
> - faster changing between mix-to-dsp, mix-to-file and
235
> record-new-track modes (only one .emt file instead of
236
> multiple ecs-files)
237
I'm not sure to understand what you mean here...
241
> - conversion from .ecs to .emt might prove to be trickier
242
> (.emt cannot express all chainsetup configurations),
243
> which again means that changes made in iactive
244
> mode are not (necessarily) stored to .emt files
245
Ah, well, that's the price to pay for gained simplicity.
247
> Internally ecasound would convert the .emt files to chainsetup (.ecs)
248
> files before loading. So something like:
249
BTW, with the format I described above, you could store multiple templates
250
in one .emt file, possibly describing each stage of a recording. Then, it
251
would be transformed into multiple cs by ecasound and you'd only have to
252
select the appropriate one.
255
> # ecasound chainsetup file
258
> -sr:44100 -t:20 -z:noxruns -z:nopsr
261
> -a:mon1 -i:drums.wav
262
> -a:mon2 -i:303line.wav
265
> -a:mon1,mon2 -o:/dev/dsp
267
> # chain operators and controllers
268
> -a:mon1 -ea:100.00 -epp:50.00 -efl:4000.00
269
> -a:mon2 -ea:120.00 -epp:50.00 -etr:60.00,0.00,7.00
270
> -a:rec1 -ea:100.00 -epp:50.00
272
Here comes again the problem of identifiers that I spoke of earlier, in
273
this way, how would the front-end app know which chain is which?
276
------------------------------------------------------------------------
b'\\ No newline at end of file'
added
removed
Documentation/edi-19.txt
