Subject: [ecasound] Some little ideas
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Tue Feb 27 2001 - 23:45:36 EET
Ok, here are a few ideas:
-tl :: It seems looping can only be enabled when there's a processing
time specified, which makes sense in most cases except when you want
the whole process to be looped. You then have to retrieve the length
of the longest object to use it as parameter to -t. Couldn't looping
default to the actual length of the whole processing when no -t is
given?
Command aliasing :: A bit of work in interactive mode with ecasound
and you soon realize that some commands are really awkward to use when
needed often, aio-get-position for example. Of course some commands
like status, start, stop, etc. have some useful aliases but not all of
them do. So I've thought maybe an "alias" command would be a good
thing for ecasound's interactive mode, here's why:
-- Hardcoding aliases for every command would take a lot of time
compared to the benefit it would bring.
-- Different people have different ideas of what is a good alias for a command.
-- Different people use ecasound for different things and therefore do
not use the same commands at the same ratio.
-- People could just build up their own ecasound.alias files and so
everyone would be happy.
Does that sound like a good idea?
Variables :: Another thing that can be awkward sometimes while using
ecasound's interactive mode is the handling of numbers. For example,
let's say you want to copy a portion of audio out of a larger
file; of course you delimit the boundaries by listening to it. So you
arrive to the point where you want to start copying and do a
aio-get-position. You get a funny number, let's say 489.31. Then you
go on to the point where it will stop and you get something like,
561.06. Well, it can sometimes get hard to remember, so I thought,
what if there were variables, shell-like, you know...
A=`aio-get-position`
setpos $A
Of course maybe it's not worth the bother and I should just train
my memory but still, in complex situations I think it might be an
interesting feature.
Sourcing in preset files :: Sourcing other preset files from within
the main presets, something like:
source my_presets
I see three reasons why this would be useful:
-- The stock preset file (/usr/local/share/ecasound/effect_presets) is
overwritten when upgrading between releases so that any
customizations are lost. With this, one would be allowed to maintain
her or his own preset file which could be sourced directly from the
main preset file.
-- Where a user cannot (or don't want to) be login as root but still
want to use both the stock preset file and a homemade preset
file. They would specify their own preset file as the main one in
ecasoundrc and then source the stock one therein.
-- Where someone would have grown a very large preset file and would
like to modularize it: put all the filter presets in one file and all
the timebased effects in another for example.
What do you think?
PS: the ALSA assertion warnings went away after recompiling ecasound
though the segfault is still there...
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Feb 27 2001 - 23:55:40 EET