Subject: [ecasound] improving the multitracking experience
From: Kai Vehmanen (k_AT_eca.cx)
Date: Wed Jun 26 2002 - 00:48:01 EEST
Although the ideas I'm about to present might never be implemented
(the multitrack file format, anyone? :)), but I'll go ahead anyway.
For operating ecasound I've found a combination of external editor (for
writing the ecs-files or sh-scripts) and interactive mode (with history
and command completion provided by GNU readline) very efficient. But
one big problem is getting feedback. And especially if and when something
goes wrong. While doing test recording sessions with the latest CVS-tree,
this has happened far too many times. For instance, it seems that with
current CVS, when using the JACK plugin, 'setpos' doesn't work properly.
Arrggh! This kind of bug is just _so_ annoying when you are trying to do
recording. :(
One solution is to provide a more flexible, or should I say more
integrated, user-interface. Ecasetupedit, Eco, Heteca and Qtecasound
represent this approach. But the problem is that you have to do quite a
lot of work to reach the usability level of the console mode ecasound.
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.
Any other alternatives? First of all, what functionality is actually
needed? Here's my list of the most important ones:
- ability to use the 'ecasound -c' interface for control and
configuration (and emacs for writing the sh-scripts :))
- automatically updating status information (so I don't have
to stop playing to see what is happening):
- critical chainsetup parameters: connected/disconnected,
buffersize, sampling rate, buffering mode, name, current
position and length
- engine state (running/not running/finished)
- list of all audio inputs, outputs, chains and
operators and connections between them (basicly
name of input and output for each chain is enough
to cover all connections)
- current position of all audio inputs and outputs (!)
- current parameters of chainops and controllers
- a simple signal meter for each chain
channel so it's easy to "see" the audio going
(even something simple like a single value describing
the average amplitude during last X secs)
- MIDI-activity flag (bytes in/out during last X secs)
I specifically could live without:
- possibility to edit the configuration outside EIAM
- information of non-connected chainsetups (one fatal
mistake in qtecasound's current design)
- waveform-view
- detailed description of active objects
... 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
point?
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
options.
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.
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?
-- http://www.eca.cx 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 - 00:50:11 EEST