Subject: Re: [ecasound] Some little ideas
From: janne halttunen (email@example.com)
Date: Thu Mar 01 2001 - 11:45:04 EET
Ok, I think the time is right for releasing too early some non-functional software. ;)
The thing is that some of the below suggestions would propably be easier to implement on a higher level wrapper than in ecasound core.
So this not usable for doing anything yet, but it gives perhaps some inspiration/whatever to someone.
(make sure you have pyeca installed)
> 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
> 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...
> 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 <firstname.lastname@example.org>.
> * Next message: Luke Tindall: "[ecasound] compile problems with ecasound-1.9dev2 on rh7.0"
> * Previous message: Marco Ciampa: "Re: [ecasound] newbie in need for help!"
> New Message
> This archive was generated by hypermail 2b28 : Tue Feb 27 2001 - 23:55:40 EET
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Thu Mar 01 2001 - 12:02:56 EET