Subject: Re: [ecasound] improving the multitracking experience
From: janne halttunen (jhalttun_AT_pp.htv.fi)
Date: Wed Jun 26 2002 - 11:26:37 EEST
On Wed, 26 Jun 2002 00:48:01 +0300 (EEST)
Kai Vehmanen <k_AT_eca.cx> wrote:
> Although the ideas I'm about to present might never be implemented
> (the multitrack file format, anyone? :)), but I'll go ahead anyway.
> One solution is to provide a more flexible, or should I say more
> integrated, user-interface. Ecasetupedit, Eco, Heteca and Qtecasound
> represent this approach.
As author of two of these frontends, (heteca and ecasetupedit) I have to admit that they are shamefully out of date (especially heteca). Also there will not likely be updates to them in the foreseeable future. Rewrites are possible, though.
> But the problem is that you have to do quite a
> lot of work to reach the usability level of the console mode ecasound.
Not to mention flexibility level.
> And sometimes libecasound (or ECI) just doesn't provide enough flexibility
> to implement GUI controls for all ecasound functions, so work is needed on
> both sides.
I think that ECI is not bad, it just has not been used to it's full extent.
> Any other alternatives? First of all, what functionality is actually
> needed? Here's my list of the most important ones:
(all important points)
> ... now one obvious solution is that someone writes an ardour-like
> interface on top of libecasound. Sounds nice, but unfortunately I don't
> see this happening, ever. And especially as we have ardour, what's the
Though I have not ever tested ardour, I gather it's aimed at more of a high end audio system. And then ecasound, if not specifically aimed at, fulfils the role of the audio multitracker for middle and low end systems. So Kai, I guess you just have to downgrade to your crappy old soundcard again! ;P
> So what would be the easiest solution (thinking aloud here)? One
> possibility would be to extend the ECI interface to allow multiple
> ECI clients to attach to the same ecasound session. So you'd run the
> ecasound console interface in one xterm (or virtual console) and the
> status screen in another. This means we need some kind of
> process-to-process communication. Pipes and tcp/ip are both viable
If you find the resources, by all means, do it!
> This opens up some very interesting possibilities. First, if implemented
> in a general fashion, it would be easy to write alternative "status apps".
> We could for instance have both ncurses and text-only status apps, or
> possibly turn qtecasound into a ecasound status screen with a nice (if not
> written by me :)) Qt-based interface. This might also encourage use of
> ecasound frontends like Heteca and Eco as you could always fall back to
> the ecasound console-mode interface if the frontend cannot do everything
> you want.
Not to mention C, Perl and Python frontends living together in harmony. :)
> So any comments? How do you see this from usability point of view? If we
> take one specific example, running "ecasound -c" in one console and a
> status application in another, is this something you'd find useful?
Though many users prefer integrated solutions, sometimes this is just not attainable (not in one step anyway). Allowing users to write very specific little frontends would be the the other alternative, and in this case, I think is the way to go. Not to say it would be easy, the frontends would have to be constructed very carefully. They'd have to constantly reflect the current state of ecasound engine (in other words, a frontend should be aware that it is possibly not the only one manipulating the engine). Of course plain status apps would not have this problem.
But all in all, a great idea.
> Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Jun 26 2002 - 11:27:38 EEST