On Wed, Sep 29, 2004 at 08:33:03PM -0400, Peter Lutek wrote: > On Wed, 2004-09-29 at 18:38, Eric Dantan Rzewnicki wrote: > > (disclaimer: take this all with a grain of salt. I've been a bit giddy > > all week. 8) -edrz) > > On Wed, Sep 29, 2004 at 06:02:34PM -0400, Peter Lutek wrote: > > > thanks for your thoughts, greg! > > > i am in a very similar position to you, and agree with most of what you > > > have to say. irrespective of ardour's current status, it IS a shame that > > > there is not at least one other viable professional > > > multitracking/editing package nearing completion. > > Am I just a complete nut? (which I'm ready to admit is entirely > > possible ;) ) or does no one else see ecasound as an alternative for > > getting work done? it is stable and fairly complete, reasonably well > > documented ... it's just different ... Why is it that having a "viable > > professional <foo> package" means having a GUI that looks like something > > from the commercial world? Just because it's the dominant paradigm for > > 96, or whatever, % of computer users doesn't have to mean it has to be a > > requirement for "professional" use. I much prefer mutt to any lookout > > clone, for example. > i am not for a minute suggesting that a commercial-look-alike GUI is > important, and i assure you that i do appreciate the value of a text > interface for many, many things -- that is a huge part of why i am > almost entirely "linuxized" at this point. > i've spent some time with ecasound (no, not enough to be called fluent, > but still...) and love the flexible manner in which it operates and the > efficiency with which you can do many things. however, i found myself > constantly running up against one big problem (and perhaps you can offer > a solution?): accurate location of edit points is nearly impossible > without seeing a waveform display. yes, i know one can edit analog tape > by "rock-n-rolling" the reels to find edit points, but we can't even do > that, and we demand finer control in the digital environment. the other > issue is still that of being able to roll back changes or modify > settings in a multi-layered task like audio editing. more on that later, > re SND... ok. so I am complete nut after all. :) I'm realizing in this discussion that most people don't work the way I work. That's ok. But, there have been a number of attempts at providing higher level interfaces to ecasound via the ECI interface. I've just this morning finished reading the August 2003 ecasound-list archive. In August and September of last year there was much discussion, and even some trial implementations, of features that come close to providing a lot of what, I think, typical multitrack editor users want to have. Check out the SuperEcasound and related threads from that time frame. For instance the emacs lisp interface implements position markers. I believe a number of these interfaces had rudimentary support for cut, copy, paste operations. Admitedly this stuff is not all fully implemented and I'm not sure if it is all actively developed. However, the OP (was that you?) did see building a tool himself as an option. With ecasound much of the ground work has already been laid ... I suspect what ever else is needed could be made to work by building on what's already been done, or even just learning from it. Maybe it's not the best answer, but is at least worth a look. > > ... it is > > > near-impossible to step back and tweak an EQ you adjusted a few days ago > > > on a particular component of your mix. > > can't one simply back up a file and work on a copy? ... > well, yes, but......say, for example, you have three tracks, each of > which you're modifying in three ways (i.e. amplitude, EQ, compression). > if you wish to retain the ability to undo any one of those three > changes, you must maintain three backups of each track (each with only > two of the changes applied). so, nine backups for EACH change of all > three characteristics on all three tracks (retaining detailed records of > what changes were applied at each pass). then, if you mix it all down, > and decide you then want to change the EQ on track two, you must dig up > the track-2 backup with only amplitude and compression applied, apply a > different EQ, and re-write the mix. and this is a VERY simple example. > surely it is more efficient to have an environment (and, yes, i would be > much happier with a text UI with a bunch of cells of values -- a mix > spreadsheet, if you will) in which all of these changes to all of the > tracks are applied non-destructively in realtime. that way you can > change any given parameter on any given track at will. > on another front, say you make a track by taking bit of takes and > editing them together. surely it is a lot more efficient and flexible > (in terms of editability) to have that track exist as a bunch of > adjustable regions which refer, on the fly, to base takes, rather than > as a single, written composite which must be re-assembled and re-written > for any change. > again, please let me know if there are ways of approaching these issues > which i have overlooked! i would love to be using SND and/or ecasound > fulltime! I don't have good answers for this. I see that a typical work flow is very different from my own. But, there may be some hope in ecasound's ewf control files. I do see that having unlimited levels of undo-redo builtin to the app would make what you describe much less difficult. One thought I had thinking about all this earlier this morning ... Much of this could be managed by keeping ecasound chainsettups in scripts. You could set up a script with all of your original input files, tweak the effect settings, do a trial run only outputting to your monitors, lather, rinse, repeat ... and then only add the mixdown file outputs when you are satisfied with the effect settings. Instead of keeping many different versions of the actual audio files, you would keep different iterations of the mixdown/effect settup scripts. Would that be more manageable? I think I've read examples in the docs and mailing list where Kai describes this sort of workflow in his own use of ecasound. -Eric Rz.
