Subject: Re: [ecasound] cs-edit might be broken
From: Jeremy Hall (jhall@uu.net )
Date: Mon Jan 10 2000 - 07:43:17 EET
Hi,
Jeremy Hall said:
>
> We need a way to "execute" a set of instructions. so we can add new chains
> and then activate them. or set some effects in motion then activate all of
> them, a sort of "commit" command.
>
perhaps one could try creating a new chain setup. :-)
well this worked fine except signal processing did not automatically start
after the new chain setup was selected. Perhaps if signal processing was
active in the old setup, it should be active in the new one?
what does flags: P mean?
perhaps we could have a cs-copy command that copies one setup (or selected
setup) to a new name
or, cs-inherit which picks up defaults from another chain setup. that way
cs-add cs-select, then cs-inherit would result in a copy.
_J
> Ideally, a "hot" mode could be selected so that the current behavior is
> seen, this would be the default. A "pasv" command could be entered that
> places ecasound in a passive mode where it queues commands.
>
> When somebody is cs-editing, ecasound should still continue providing
> sound until the editor comes back. When the editor comes back, the new
> file is syntactically checked. If an error is detected, the user is
> placed back in the editor so he can fix his error. After all is said and
> done, the user should be shown some diffs and asked if he wishes to check
> the diffs in or accept them.
>
> How about creating an ecatools_parse command that checks the items in some
> file for errors, exiting wiht 0 if all is ok and 1 if all is not. A shell
> script could be provided that runs the diff and displays it, then decides
> whether to accept the changes or not (similar to our rcsedit script)
>
> As soon as the editor comes back, ecasound should accept the new changes
> and activate them.
>
> _J
>
This archive was generated by hypermail 2a24 : Mon Jan 10 2000 - 07:44:08 EET