Re: [foo-devel] Buff Bugs

[martin r. <fo...@ru...>]

dear ramon,

On Mon, Jun 06, 2005 at 12:54:54AM +0200, Ramon Gonzalez-Arroyo wrote:
> Aha! I think we find here the point with offset.
>=20
> As far as I understand, and always understood, the task-Offset offsets=20
> in the file the zero time of the context.

according to the documentation, this is the definition of the
reference parameter:

Foo Kernel Reference Manual

Syntax

(make-task ref off out context [srate [bsize]]) [procedure]
Parameters

ref	A number specifying time in s in the output medium that shall
	correspond to time origin of the context (time zero).

off	A number specifying the time offset in s from the contexts time origin
	where the execution (with run-task) should start.

> As far as I can think of there is not such functionality in Foo as you=20
> mention, Martin (rendering from some moment onwards in the context=20
> time). Probably it is a good idea to have such possibility, but not=20

i think it HAS to be there by definition of the semantics of a
context: a context itself is defined along a timeline from minus to
plus infinity.  thus it is simply not possible to render "a context"
itself, you have to specify a region (with off in (make-task) and dur
in (run-task)).  this is to get down to earth, ideally, context would
last infinetely...  or, as steven pope said: "is has to go down
towards silicium eventually".

> with these parameters. Offset and Reference are finally  a mechanism to=
=20
> insert at different moments in the soundfile. Actually, I'm almost=20

but what is the difference then?  since "time" is a 1-dimensional
thing (at least here, philosophy left alone), one number perfectly
specifies the relationship between the context origin and the
soundfile origin.

> completely sure my assumption is the (historically) correct one: think=20
> that the incremental mixing mechanism keeps the context, the scalar and=
=20
> the offset (point in time where the evalutation of the context has to=20

as far as i can see, the incremental mixing file keeps the context,
it's reference and offset and the factor.

btw. the factor is not documented and was introduced later, true?
does it mean a transposition of the context while rendering?

> be inserted in the result mix-file). And you are not expected to make=20
> your context knowing where in the soundfile would it be inserted,=20

the context does not know anything about the task's parameters.  in
the incremental mixing thing, the context gets stored along with the
task's parameters, in order to be able to create an "undo" task out of
the context and these addditional informations.

summarizing, i am still not sure whether we really discovered the
bug.  as we said, there is one, since your example doesn't lead to the
expected result (expected by me, in this case).

i had a look at task.m again, and from what i can see i fixed a thing
regarding to offset: it did the same before (specifying the beginning
of rendering in the context), but it was understood to be in samples
rather than seconds.  given the difference of several orders of
magnitude between samples and seconds, "offset" had almost no impact,
if i am right.

so i think first we have to find out the semantics of the parameters
off and ref.  maybe gerhard can help what the original idea was?

> 2.
>  I don't know what happens with the mails; sometimes I get them so much=
=20
> later than they are sent according to the mails' dates. So I didn't see=
=20

it's natural.  you never know when a mail server delivers mail to the
next.  in these special cases, it's because of my local mailserver,
which caches mails if i am writing them offline (in the train or
whereever).  but the get the timestamp from the time of writing, not
that of finally delivering them to the relay server of the provider.

bests,

martin