Re: [ecasound] Could someone explain (me too) how chain setup works?

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] Could someone explain (me too) how chain setup works?
From: Kai Vehmanen (k@eca.cx)
Date: Sat Mar 03 2001 - 17:29:55 EET


On Fri, 2 Mar 2001, Marco Ciampa wrote:

> I have dowloaded from CVS ecasound 1.9dev3.
[...]
> file i1.ewf
> >start-position = 5
[...]
> -> connected to chains "1": position (0.000/96.549) seconds.
> ^^^^^
[...]
> And you see i1 has a WRONG start position!
> But if I do a start it really starts at 5.000 !

No, it's actually the right position. When file is wrapped inside a
ewf, ecasound never sees the actual file, it only sees what ewf
presents it. So if you have 200sec file wrapped inside a ewf-file
with startpos 150sec and length 5sec, ecasound will just see those
5 secs. So the 150->155 range of the original file is mapped to
ecasound-visible range of 0->5.

> -> connected to chains "1": position (1.741/96.549) seconds.
[...]
> But in reality i1 is started at 5.000 (and it signals a lenght of 96.549
> that is of 5.000 seconds longer than the real sound-object)

The length should be 91.549 ... in other words a bug. I'll put the fix
in CVS.

> if I do a setpos 0 ...
[...]
> Input (i1): "i1.ewf" - [Ecasound wave file]
> -> connected to chains "1": position (0.000/96.549) seconds.
[...]
> and now :-( what I see is really corrispondant to what I ear, ewf setup
> cleared and I have to do a cs-disconnect and a cs-connect to re-set the

If you mean that you are hearing audio from the original file between
position 0sec and 5sec, then this too is a bug. If you have specified a
starting position in the ewf-file, doing a "setpos 0" in ecasound
shouldn't provide you with access to data before the defined start
position. Today, I fixed at least one bug, that might trigger this
behaviour.

Hmm, so we have...:

one.wav: a +15 sec audio file
one.ewf:
--cut--
source = one.wav
start-position = 10.0
offset = 5.0
length = 5.0
--cut--

pos 0 5 10 15
one.ewf |--- offset ----|--- length -----|
one.wav |------------ start-pos ---------| used audio ---| unused audio

If you encounter situations where ecasound behaves differently, it's
most likely you've found a bug...

> get-position now works correct but it eats the last (ms) digit...
[...]
> -> connected to chains "1": position (2.531/96.549) seconds.
[...]
> get-position
> 2.53

This is normal. The routines ecasound uses for printing float values have
a default precision of two digits. But it's important to note that this
only affects printing. The real values are not truncated. The 'rw' and
'fw' bugs you found were different, because there the real values where
truncated. Now a different matter is whether 'get-position' (or perhaps
all functions) should use three-digit precision when printing values.

> and the round operation is wrong because if fs shows respectively
> 3.654
> 3.655
> 3.656
[...]
> get-position shows
> 3.65
> 3.65
> 3.66

In computer arithmetic, truncation is not the same as mathmatical
rounding. Ie. the extra digits are just left out (ie. always rounded
down).

>> > ecasound ('h' for help)> rw 1.000
>> [...]
>> > -> connected to chains "1": position (10.000/96.549) seconds.
> > Yup, it's a bug alright. Fixed in the CVS-tree...
> No,I downloaded CVS iesterday and it works like before...truncating the
> decimals

Are you sure? I've fixed the 'fw' and 'rw' bug, but this is not related to
the above 'get-position' issue, where float values are truncated when they
are printed on the screen.

-- 
 . http://www.eca.cx ... [ audio software for linux ] /\ . 
 . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .

-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Mar 03 2001 - 17:30:08 EET