Subject: Re: [ecasound] small utils under planning
From: Luke Tindall (luke@maths.ex.ac.uk)
Date: Wed Feb 07 2001 - 12:04:42 EET
On Wednesday 07 February 2001 04:23, you wrote:
> When comparing the various ecasound based utils and user-interfaces, it
> seems that the small, well targeted utils have a much better
> time-spent/usefulness ratio. This of course nicely matches the good old
> free software agenda: small useful utils, which can easily be used as
> parts of a more complex software package.
>
> This becomes particularly real when we compare qtecasound and ecawave.
> Although quite an old app, qtecasound hasn't advanced very far. Every time
> I think about its design and possible new features, I get overwhelmed by
> the work I would need to do to write a proper generic GUI frontend. On the
> other hand, ecawave has an amazing time-spent/effort ratio. It only has
> the basic editing features, but still, with same amount of code as in
> qtecasound, ecawave is useful for real work, now.
>
> How do you feel about these? Have these little utils like 'ecaconvert',
> 'ecasignalview', etc been of use to you?
>
> My plan is to continue concentrating on use-case specific utils. First in
> line are:
>
> - GUI-based realtime effect processor
> - simple one-window app which reads from /dev/dsp,
> does some effect processing and outputs to /dev/dsp
> - "guitar effect box" concept;
> - best name candidate so far: "ecamegapedal" :)
> - should be easy to implement: just take the
> effects dialog from ecawave .. that's about it, all
> the hard work is already done
> - package: qtecasound
> - GUI-based equivalent to 'ecasignalview'
> - 'qtsignalview'
> - package: qtecasound
> - GUI-based preset editor
> - for creating effects presets -> .ecp files
> - ecasound-based MixMagic clone
> - package: perhaps separately a'la ecawave
> - name: ecamegamixdown (just joking ;))
I was looking at doing this recently. I'ver been using gtk ever since
switching to linux development so don't feel inclined to use qt. I would
rather have the mixing interface as the general interface. A gui is the
better bet for intuitive recording session. I tried to use ecasound to record
a vocalist and he became impatient by the slow progress I made setting up new
tracks through console interface (not to mention dropouts, but I have now
followed some of the steps in low latency howto). Clicking on a button (or
keybindings) to add a new track is a lot quicker than typing into a console
interface. I guess what I am describing is the kind of interface ardour has.
The Mixmagic interface (not that good really) could be knocked up in glade in
an hour or so (i've done one), the tricky part is plumbing the signal
handlers to ecasound ie use of ECI or pipes, particuarly getting stuff back
ie building up a wave plot, updating a visible timer etc.
> - MIDI i/o monitor
> - ncurses-based utils for monitoring and interpreting
> MIDI-traffic
> - code for MIDI parsing will be added to libecasound,
> so why not use it
> - package: ecatools
> - etc, etc, ...
>
Would you be using alsa-sequencer routines?
> More ideas, volunteers, etc...? The above utils/apps don't necessarily
> have to be part of any existing ecasound package, and neither have to
> be written in C++ (that's why we have ECI!).
Ok, I'll look into the ECI stuff and see how if I'll be able to contribute.
It'll be gtk though as it would be a waste of time for me to learn qt (not
that I have anything against qt or kde).
-- Luke Tindall -- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Feb 07 2001 - 12:05:24 EET