Subject: Re: [ecasound] Sanitizing the IAM?
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Sun Mar 25 2001 - 19:57:39 EEST
On Sun, 25 Mar 2001, Kai Vehmanen wrote:
>
> 1. aio-* problems
>
> Ok, as you've noted, the current scheme a bit confusing. Now how about if
> we just drop the whole aio-* cmd set, and replace it with two new:
> ai-* for audio input objects, and ao-* for audio output objects?
>
> Both approaches have their benefits. There aren't many differences between
> input and output objects, so ai-* and ao-* cmd sets would be identical. On
> the other hand, at the chainsetup level, inputs and outputs are clearly
> separate groups. This is why we have two 'add' commands. Similarly, two
> versions of 'select' are needed because it's possible we have "file.wav"
> both as an input and as an output.
Yes, I believe this makes a lot of sense, at all level. (meaning both for
direct use and through ECI) In fact at one point I thought of suggesting
this but, as I said, I got quite confused. Also I had this question:
wouldn't it be useful if we could set the position of multiple objects
with only a few commands? meaning multiple object selection. But then it
wouldn't be much more hassle to do it for inputs and outputs separately.
>
>
> 2. Position info
>
> This is another messy issue. So far, only audio objects have contained
> position info. But this gets confusing when we start using position
> related cmds at global (getpos), chainsetup (cs-getpos) and chain
> (c-getpos) level.
>
> So I propose we add a new chainsetup-level position concept. This would
> mean that global position commands would be equal with chainsetup
> commands (getpos = cs-getpos, length = cs-length, etc). Also, we should
Again this seems just great.
> drop chain-level position commands (c-getpos, c-setpos, etc) altogether.
> These seem to just cause confusion. Then we'd have the audio object
Yes. However here we meet a case where convenience and logic clash together.
While I agree that dropping set/getpos does make sense I'd rather not see
c-fw/rw disappear, they are a very useful way of modifying the position for
all objects attached to one chain, something done relatively often.
> cmds (aio-getpos; or ai-getos, ao-getpos, etc).
>
> As a result, we'd only have two ways to either set or query the current
> position:
>
> [cs level]
> - set position
> - set cs-position
> - set position of all audio objects (inputs and outputs)
> - forward, rewind, etc
> - like setting position, except new position is relative
> to the previous current position
> - get position
> - get cs-position
>
>
> [audio obj level]
> - set position
> - ... for one input/output
> - get position
> - ... of one input/output
And I suggest:
[chain level]
- Query position? no
- Set absolute position (setpos)? no
- Set relative position of objects (c-fw/rw)? yes
(Note that this remains an inconsistency but I think it to be useful enough
to overlook that fact)
Because the IAM is so closely tied to the API such changes are of great
effect (they would basically break any apps linked to ecasound), that's why
they should be done early on. Well, at least the modification of existing
command should as adding new commands wouldn't hurt existing programs.
>
> --
> http://www.eca.cx
> Audio software for Linux!
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request@wakkanet.fi>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sun Mar 25 2001 - 20:05:28 EEST