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