On Wed, Sep 29, 2004 at 01:23:46PM -0700, Greg Reddin wrote: > Is there an option 3? Is there another Linux DAW solution that > provides (or seeks to provide) multitrack recording, real-time > mixing, automation, etc.? ecasound. I know that the paradigm is very different from the gui centric daws. But, it does provide the features you request. Automation is a possible exception, but there is a sort of substitute in the flexible envelope controllers and midi CC control. Admitedly the text only paradigm doesn't fit for many people. However, many of your chief complaints about Ardour are not problems with ecsound. It's feature set has been relatively complete and stable for several years now. It is not really under active development in the way that ardour is. The release cycle is fairly slow, so not much changes from day to day or month to month. If you can get used to the way it works you may find that you can get quite a lot done with this tool. The complaints you have about audacity are also not problems with ecasound. ecasound is a realtime system. It does do realtime effect processing and has been used in a wide range of applications, with at least some of those being of professional quality. My limited exposure to audacity leaves me with the impression that the cross platform goal is the major limiting factor to the pace of development (well, that and the focus on the friendly, pretty, cute, soft and comfy gui). Like you, I'm not trying to inflame anyone. It's just that each project's leads have their own priorities and that is entirely their perogative. > I would typically omit option 4 right off the bat. The open source > culture frowns on reinventing something that already exists. But > there's a few reasons why I'm actually considering this option. > First, the problems I have with ardour and audacity don't seem likely > to change. Please don't misunderstand what I'm about to say. I'm > not trying to offend anyone, but these are just my observations. If > they are incorrect, please correct me. I don't gather that there's > much momentum to build audacity into a real-time professional DAW > solution. And it seems like ardour's development has been in a rut > for a while. Development is happening, and new things are being > added, but the stability and usability doesn't seem to be improving. > So, if I'm trying to build a professionally viable DAW for Linux I > could come to the conclusion that there's not currently a workable > solution. Second, I'm not convinced that "three" DAWs for Linux is an > unhealthy number. Look at how many different commercial solutions > are available -- each one doing things a bit differently and > appealing to a different user base. Maybe if there was another > project with a healthy development cycle, good stability, and > essential features, it would encourage the others to compete and help > push Linux over the edge and into professional viability. There are > other reasons, but things like coding style, object model, or testing > strategy are not valid reasons in and of themselves to start a new > project. Since you do have coding ability this strengthens the suggestion for using ecasound. The Ecasound Control Interface (ECI) is a very flexible framework that has been used for a number of different programs. If you choose to take the route of getting something working for what you need, please consider at least looking into building it on top of ecasound. The engine is totally independant of the interface, so you would only need to build the buttons and what not you want to be able to see in front of you. I'm pretty much a complete novice programmer. Even with my minimal abilities I've been able to realize quite a few of my ideas using only ecasound and python. Some sketchy, probably heinously written, but nonetheless functional examples are available here[0]: http://zhevny.com/bin/ The ECI is available in C,C++,perl,python,php and emacs-lisp bindings. There are numerous projects that have attempted to get at least part of what you seem to want working, so there may be examples for you to start from as well, at the very least to see what didn't work. > That brings me to option 5. I've only considered this because I'm > ready to actually spend some money in the interest of making music > instead of twiddling with code and configs. But, I'm not a big fan > of ProTools, Logic, or Cubase. So Digital Performer seems to be my > best option on a mac -- and I really don't know much about DP (my > prior experience is mostly with Sonar and I'm simply not willing to > invest further in a Windows-based platform). So, I'm not certain > that I will be satisfied even if I spend a wad of cash on a Mac and > some DAW software. And of course, this thread of logic implies that > I have some money to throw at it, which, for the time being, is not > the case. > > Now, I think I'm something of a poster-child for Linux audio. I'm > enough of a tech-head that I can write some code and diagnose > problems. I can wade through a mass of complex logic and find what I > need (usually). My sessions are few and far between enough that I > can experiment with stuff between them. And they are low-risk enough > (meaning that I don't get paid or get paid very little for them) that > lack of stability is not a huge risk for me -- just a frustration. I > suspect that by the time I get to a point to actually charge real > money for my services something in Linux might be ready for prime > time whether it be ardour, audacity, or something as yet undeveloped. > And I want to contribute financially and/or intellectually to > whatever I end up with. Here, by anectdote, is a reason for you to avoid this route entirely: Last week I realized that sometime last year Kai had clamped the range of values accepted by the -ei: (pitch shifter) effect because of some instability in either libsamplerate or ecasound's use of it. Knowing that libsamplerate supports rate conversions of up to 256 times in either direction and having an interest in using this purely as a non-realtime effect, I was able to grep the ecasound source tree for the helpful warning printed out by ecasound and find the location of the limits. I know very little of C++, but it was not at all difficult for me to locate the 2 lines where this limit was set. I changed them, recompiled and, voila!, in a mere matter of an hour or so I had successfully modified my tool of choice to provide the functionality I wanted to have. You will _never_ get that opportunity if you choose to return to (join?) the corporate software arena. > So, given what little you know of me and what I'm looking for, what > would you suggest? Would you recommend that I start following Ardour > and/or Audactiy with more interest? Is there something else I don't > know about? Have I actually found a need for something new? Or > should I (for the time being) punt and invest in a Mac-based > commercial solution? Ultimately you need to choose what's right for you. Some others here, Mark Knecht comes to mind and possible Ron Parker (is that correct, I mean the guy w/the studio in Minnesota) have successfully stradled the commercial audio software and linux audio software worlds. Using what works better in Linux, but keeping their proprietary tools working in cooperation with their free software tools. Perhaps there is a hybrid approach available to you for the interim. Good luck to you. Hopefully you find peace soon. ;) -Eric Rz. [0] for what they're worth, I intend these to be GPL ... I've just not done the work to make that official. My personal internet server project had been stalled for months by personal insecurity and grand schemes. So, I got up the gumption this past weekend and just took the plunge even though I wasn't ready. Any advice on how to go about doing the right thing with regard to GPL is very welcome. I have half a clue already, and will do my best to rectify the situation within a week's time, but, still, comments and suggestions will definitely help. -edrz
