[Algorithms] rotating in world space to have result in screen space

[Andras Balogh]

I have a point 'v0' in world space, that I can only rotate around a
fixed point 'p' and axis 'r'. So movement is constrained on a circle.
Now, I'm looking for the point 'v1' on this circle, so that the three
points (v0, p, v1), when projected to the screen, enclose a given angle.

Any ideas how to compute the world space 'v1', given the screen space angle?

I was thinking of working backwards, rotating first in screen space,
using the given angle, and then trying to figure out the world space
position of v1, but I'm a bit afraid, that this wouldn't be a very
robust solution..

thanks,


Andras

[Ralph Egas]

Hi Andras,

Are you looking for a solution for an arbitrary 'r' and 'p'? What if 'r'
gets perpendicular to the right or up vector in screenspace? Obviously then
there's not going to be any solution for any world space angle..

If you could just elaborate your idea and what you need this solution for,
maybe that could help.

Cheers,

Ralph

----- Original Message -----
From: "Andras Balogh" <***@gmx.net>
To: <gdalgorithms-***@lists.sourceforge.net>
Sent: Thursday, July 21, 2005 8:02 PM
Subject: [Algorithms] rotating in world space to have result in screen space


>I have a point 'v0' in world space, that I can only rotate around a fixed
>point 'p' and axis 'r'. So movement is constrained on a circle. Now, I'm
>looking for the point 'v1' on this circle, so that the three points (v0, p,
>v1), when projected to the screen, enclose a given angle.
>
> Any ideas how to compute the world space 'v1', given the screen space
> angle?
>
> I was thinking of working backwards, rotating first in screen space, using
> the given angle, and then trying to figure out the world space position of
> v1, but I'm a bit afraid, that this wouldn't be a very robust solution..
>
> thanks,
>
>
> Andras
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188

[Andras Balogh]

Ok, so here's the original problem:

I have a rectangle in world space, two of its neighbouring vertices are
locked at a fixed position (so you can rotate the rectangle around the
locked edge). Now, given an arbitrary viewing transform, rotate the
rectangle, so that its screen space size is maximized!

I was thinking that I'll have the maximum area, if the normal vector of
the rotated rectangle is parallel in screen space to the projected
locked edge. So, having the screen space normal, I could compute the
angle between that and the screen space up vector. If I could transform
this angle back to world space, then I could just rotate the rectangle
by this amout..

Ehh, I hope it makes some sense, there more I think about it, the more
confused I become :)


Andras


Ralph Egas wrote:
> Hi Andras,
>
> Are you looking for a solution for an arbitrary 'r' and 'p'? What if 'r'
> gets perpendicular to the right or up vector in screenspace? Obviously
> then there's not going to be any solution for any world space angle..
>
> If you could just elaborate your idea and what you need this solution
> for, maybe that could help.
>
> Cheers,
>
> Ralph
>
> ----- Original Message ----- From: "Andras Balogh" <***@gmx.net>
> To: <gdalgorithms-***@lists.sourceforge.net>
> Sent: Thursday, July 21, 2005 8:02 PM
> Subject: [Algorithms] rotating in world space to have result in screen
> space
>
>
>> I have a point 'v0' in world space, that I can only rotate around a
>> fixed point 'p' and axis 'r'. So movement is constrained on a circle.
>> Now, I'm looking for the point 'v1' on this circle, so that the three
>> points (v0, p, v1), when projected to the screen, enclose a given angle.
>>
>> Any ideas how to compute the world space 'v1', given the screen space
>> angle?
>>
>> I was thinking of working backwards, rotating first in screen space,
>> using the given angle, and then trying to figure out the world space
>> position of v1, but I'm a bit afraid, that this wouldn't be a very
>> robust solution..
>>
>> thanks,
>>
>>
>> Andras

[Megan Fox]

Forgive me if this is off, it's one of those "shouldn't this work?"
sorts of intuition suggestions:

The point at which a quad is most visible is always going to be when
the normal of that quad is pointed directly at the viewer's position
(or directly away from, but then it gets discarded, so ignore that).
So, isn't the real question the closest you can rotate the normal to
"camera lookat"?


Here's where it gets even more dicey... shouldn't transforming the
normalized quad-to-camera vector into the plane you're describing be
able to give you the data necessary to generate the optimal transform?


Sorry, I have no math to prove this, it just seems as if this "should"
work? ... if I have time later, I'll try and work out an equation for
all of this.

-Megan Fox

On 7/21/05, Andras Balogh <***@gmx.net> wrote:
> Ok, so here's the original problem:
>
> I have a rectangle in world space, two of its neighbouring vertices are
> locked at a fixed position (so you can rotate the rectangle around the
> locked edge). Now, given an arbitrary viewing transform, rotate the
> rectangle, so that its screen space size is maximized!
>
> I was thinking that I'll have the maximum area, if the normal vector of
> the rotated rectangle is parallel in screen space to the projected
> locked edge. So, having the screen space normal, I could compute the
> angle between that and the screen space up vector. If I could transform
> this angle back to world space, then I could just rotate the rectangle
> by this amout..
>
> Ehh, I hope it makes some sense, there more I think about it, the more
> confused I become :)
>
>
> Andras
>
>
> Ralph Egas wrote:
> > Hi Andras,
> >
> > Are you looking for a solution for an arbitrary 'r' and 'p'? What if 'r'
> > gets perpendicular to the right or up vector in screenspace? Obviously
> > then there's not going to be any solution for any world space angle..
> >
> > If you could just elaborate your idea and what you need this solution
> > for, maybe that could help.
> >
> > Cheers,
> >
> > Ralph
> >
> > ----- Original Message ----- From: "Andras Balogh" <***@gmx.net>
> > To: <gdalgorithms-***@lists.sourceforge.net>
> > Sent: Thursday, July 21, 2005 8:02 PM
> > Subject: [Algorithms] rotating in world space to have result in screen
> > space
> >
> >
> >> I have a point 'v0' in world space, that I can only rotate around a
> >> fixed point 'p' and axis 'r'. So movement is constrained on a circle.
> >> Now, I'm looking for the point 'v1' on this circle, so that the three
> >> points (v0, p, v1), when projected to the screen, enclose a given angle.
> >>
> >> Any ideas how to compute the world space 'v1', given the screen space
> >> angle?
> >>
> >> I was thinking of working backwards, rotating first in screen space,
> >> using the given angle, and then trying to figure out the world space
> >> position of v1, but I'm a bit afraid, that this wouldn't be a very
> >> robust solution..
> >>
> >> thanks,
> >>
> >>
> >> Andras
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>

[Andras Balogh]

Megan Fox wrote:
> Forgive me if this is off, it's one of those "shouldn't this work?"
> sorts of intuition suggestions:
>
> The point at which a quad is most visible is always going to be when
> the normal of that quad is pointed directly at the viewer's position
> (or directly away from, but then it gets discarded, so ignore that).
> So, isn't the real question the closest you can rotate the normal to
> "camera lookat"?

Hehe, I was just thinking the same during lunch, and I think Mick's
solution is basically the same. Yeah, I think it should work, although I
haven't verified it on paper myself yet. I'll do that now, and report
back soon! :)


Thanks,

Andras

[Mick West]

If A and B are the fixed points, C is one of the other (movable) points
of the rectangle, and V is the viewpoint of the transform, P is the
plane at point A with normal AB and C1 is the projection of C onto P
then the area is maximized by rotating C1 into C2 where AC2 is
perpendicular to the plane defined by ABV. Rotate C (and D) by the
angle between C1 and C2 relative to A (or without C2, the angle between
A->C1 and the normal of ABV).

Mick.

Andras Balogh wrote:

> Ok, so here's the original problem:
>
> I have a rectangle in world space, two of its neighbouring vertices
> are locked at a fixed position (so you can rotate the rectangle around
> the locked edge). Now, given an arbitrary viewing transform, rotate
> the rectangle, so that its screen space size is maximized!
>
> I was thinking that I'll have the maximum area, if the normal vector
> of the rotated rectangle is parallel in screen space to the projected
> locked edge. So, having the screen space normal, I could compute the
> angle between that and the screen space up vector. If I could
> transform this angle back to world space, then I could just rotate the
> rectangle by this amout..
>
> Ehh, I hope it makes some sense, there more I think about it, the more
> confused I become :)
>
>
> Andras
>
>
> Ralph Egas wrote:
>
>> Hi Andras,
>>
>> Are you looking for a solution for an arbitrary 'r' and 'p'? What if
>> 'r' gets perpendicular to the right or up vector in screenspace?
>> Obviously then there's not going to be any solution for any world
>> space angle..
>>
>> If you could just elaborate your idea and what you need this solution
>> for, maybe that could help.
>>
>> Cheers,
>>
>> Ralph
>>
>> ----- Original Message ----- From: "Andras Balogh"
>> <***@gmx.net>
>> To: <gdalgorithms-***@lists.sourceforge.net>
>> Sent: Thursday, July 21, 2005 8:02 PM
>> Subject: [Algorithms] rotating in world space to have result in
>> screen space
>>
>>
>>> I have a point 'v0' in world space, that I can only rotate around a
>>> fixed point 'p' and axis 'r'. So movement is constrained on a
>>> circle. Now, I'm looking for the point 'v1' on this circle, so that
>>> the three points (v0, p, v1), when projected to the screen, enclose
>>> a given angle.
>>>
>>> Any ideas how to compute the world space 'v1', given the screen
>>> space angle?
>>>
>>> I was thinking of working backwards, rotating first in screen space,
>>> using the given angle, and then trying to figure out the world space
>>> position of v1, but I'm a bit afraid, that this wouldn't be a very
>>> robust solution..
>>>
>>> thanks,
>>>
>>>
>>> Andras
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>

[Mick West]

Actualy, thinking about it a bit more, that only minimizes the angle
between the rectangles normal and the viewer. I think this appoximates
maximizing the screen area, but might be especially wrong when very
close to the camera.

What's the REAL problem? Why do you need the screen space maximized?

Mick.

Mick West wrote:

> If A and B are the fixed points, C is one of the other (movable)
> points of the rectangle, and V is the viewpoint of the transform, P
> is the plane at point A with normal AB and C1 is the projection of C
> onto P then the area is maximized by rotating C1 into C2 where AC2 is
> perpendicular to the plane defined by ABV. Rotate C (and D) by the
> angle between C1 and C2 relative to A (or without C2, the angle
> between A->C1 and the normal of ABV).
> Mick.
>
> Andras Balogh wrote:
>
>> Ok, so here's the original problem:
>>
>> I have a rectangle in world space, two of its neighbouring vertices
>> are locked at a fixed position (so you can rotate the rectangle
>> around the locked edge). Now, given an arbitrary viewing transform,
>> rotate the rectangle, so that its screen space size is maximized!
>>
>> I was thinking that I'll have the maximum area, if the normal vector
>> of the rotated rectangle is parallel in screen space to the projected
>> locked edge. So, having the screen space normal, I could compute the
>> angle between that and the screen space up vector. If I could
>> transform this angle back to world space, then I could just rotate
>> the rectangle by this amout..
>>
>> Ehh, I hope it makes some sense, there more I think about it, the
>> more confused I become :)
>>
>>
>> Andras
>>
>>
>> Ralph Egas wrote:
>>
>>> Hi Andras,
>>>
>>> Are you looking for a solution for an arbitrary 'r' and 'p'? What if
>>> 'r' gets perpendicular to the right or up vector in screenspace?
>>> Obviously then there's not going to be any solution for any world
>>> space angle..
>>>
>>> If you could just elaborate your idea and what you need this
>>> solution for, maybe that could help.
>>>
>>> Cheers,
>>>
>>> Ralph
>>>
>>> ----- Original Message ----- From: "Andras Balogh"
>>> <***@gmx.net>
>>> To: <gdalgorithms-***@lists.sourceforge.net>
>>> Sent: Thursday, July 21, 2005 8:02 PM
>>> Subject: [Algorithms] rotating in world space to have result in
>>> screen space
>>>
>>>
>>>> I have a point 'v0' in world space, that I can only rotate around a
>>>> fixed point 'p' and axis 'r'. So movement is constrained on a
>>>> circle. Now, I'm looking for the point 'v1' on this circle, so that
>>>> the three points (v0, p, v1), when projected to the screen, enclose
>>>> a given angle.
>>>>
>>>> Any ideas how to compute the world space 'v1', given the screen
>>>> space angle?
>>>>
>>>> I was thinking of working backwards, rotating first in screen
>>>> space, using the given angle, and then trying to figure out the
>>>> world space position of v1, but I'm a bit afraid, that this
>>>> wouldn't be a very robust solution..
>>>>
>>>> thanks,
>>>>
>>>>
>>>> Andras
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> GDAlgorithms-list mailing list
>> GDAlgorithms-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>

[Andras Balogh]

Mick West wrote:
> Actualy, thinking about it a bit more, that only minimizes the angle
> between the rectangles normal and the viewer. I think this appoximates
> maximizing the screen area, but might be especially wrong when very
> close to the camera.

Why is that? I can't see why minimizing the normal/view vector angle
would be wrong, could you give an example?

> What's the REAL problem? Why do you need the screen space maximized?

Haha, that's the REAL problem! :) Really, I have to render text on these
quads, and the more you see, the better. But the quads have to remain
fixed at an edge (this is a design restriction).

Cheers,


Andras

[Mick West]

Andras Balogh wrote:

> Mick West wrote:
>
>> Actualy, thinking about it a bit more, that only minimizes the angle
>> between the rectangles normal and the viewer. I think this
>> appoximates maximizing the screen area, but might be especially wrong
>> when very close to the camera.
>
>
> Why is that? I can't see why minimizing the normal/view vector angle
> would be wrong, could you give an example?
>
Hold a book about a foot in front of your face, close one eye, tilt the
top edge towards you. I'm not at all sure, but you could imagine the
widening of the projection of the book due to perspective might be more
(in terms of area) than the vertical foreshortening, especially with a
very wide angle lens. Still, it should be fine for your application.

Mick.

[Andras Balogh]

Mick West wrote:
> Andras Balogh wrote:
>
>> Mick West wrote:
>>
>>> Actualy, thinking about it a bit more, that only minimizes the angle
>>> between the rectangles normal and the viewer. I think this
>>> appoximates maximizing the screen area, but might be especially wrong
>>> when very close to the camera.
>>
>> Why is that? I can't see why minimizing the normal/view vector angle
>> would be wrong, could you give an example?
>>
> Hold a book about a foot in front of your face, close one eye, tilt the
> top edge towards you. I'm not at all sure, but you could imagine the
> widening of the projection of the book due to perspective might be more
> (in terms of area) than the vertical foreshortening, especially with a
> very wide angle lens. Still, it should be fine for your application.

Hah, that's interesting! Fortunately perspective not only adds to the
area on the near side, but also removes on the far side! Anyway, I think
I can safely ignore that! :)

Thanks again,

Andras

[Bill Baxter]

Seems like a small extension of standard ray-picking would do the trick.
You can get one world space ray from the camera location and world
space point p .
Get another world space ray by taking some point on the screen with
the desired angle and turning that into a ray using the standard way
used ray-picking techniques.

Those two world space rays define a world space plane (they both
contain the camera origin, so it is a plane.)

Now solve a quadratic equation to compute the intersections of the
world space circle with the world space plane. Pick the one of the
two answers that's right.


--bb

On 7/22/05, Andras Balogh <***@gmx.net> wrote:
> I have a point 'v0' in world space, that I can only rotate around a
> fixed point 'p' and axis 'r'. So movement is constrained on a circle.
> Now, I'm looking for the point 'v1' on this circle, so that the three
> points (v0, p, v1), when projected to the screen, enclose a given angle.
>
> Any ideas how to compute the world space 'v1', given the screen space angle?
>
> I was thinking of working backwards, rotating first in screen space,
> using the given angle, and then trying to figure out the world space
> position of v1, but I'm a bit afraid, that this wouldn't be a very
> robust solution..
>
> thanks,
>
>
> Andras
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>


--
William V. Baxter III, Ph.D.
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan 154-0023
[phone]

[Andras Balogh]

Hey Bill, I've just finished implementing the solution suggested by Mick
and Megan, and it works like a charm, and result looks great!! And this
solution is also very simple and super robust! So I think I'll stick to
it! :)

Thanks,

Andras


Bill Baxter wrote:
> Seems like a small extension of standard ray-picking would do the trick.
> You can get one world space ray from the camera location and world
> space point p .
> Get another world space ray by taking some point on the screen with
> the desired angle and turning that into a ray using the standard way
> used ray-picking techniques.
>
> Those two world space rays define a world space plane (they both
> contain the camera origin, so it is a plane.)
>
> Now solve a quadratic equation to compute the intersections of the
> world space circle with the world space plane. Pick the one of the
> two answers that's right.
>
>
> --bb
>
> On 7/22/05, Andras Balogh <***@gmx.net> wrote:
>
>>I have a point 'v0' in world space, that I can only rotate around a
>>fixed point 'p' and axis 'r'. So movement is constrained on a circle.
>>Now, I'm looking for the point 'v1' on this circle, so that the three
>>points (v0, p, v1), when projected to the screen, enclose a given angle.
>>
>>Any ideas how to compute the world space 'v1', given the screen space angle?
>>
>>I was thinking of working backwards, rotating first in screen space,
>>using the given angle, and then trying to figure out the world space
>>position of v1, but I'm a bit afraid, that this wouldn't be a very
>>robust solution..
>>
>>thanks,
>>
>>
>>Andras
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>GDAlgorithms-list mailing list
>>GDAlgorithms-***@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>>Archives:
>>http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>>
>
>
>

[Bill Baxter]

Were those private messages? All I could see of that conversation
with Mick was the snippet you quoted which didn't make any sense out
of context.

If it was a personal conversation, would you mind repeating what the
solution was?

If it took place on the list here, then seems I've got a problem with
the list. Traffic has seemed awfully light recently on gdalgo...

--bb

On 7/22/05, Andras Balogh <***@gmx.net> wrote:
> Hey Bill, I've just finished implementing the solution suggested by Mick
> and Megan, and it works like a charm, and result looks great!! And this
> solution is also very simple and super robust! So I think I'll stick to
> it! :)
>
> Thanks,
>
> Andras
>
>
> Bill Baxter wrote:
> > Seems like a small extension of standard ray-picking would do the trick.
> > You can get one world space ray from the camera location and world
> > space point p .
> > Get another world space ray by taking some point on the screen with
> > the desired angle and turning that into a ray using the standard way
> > used ray-picking techniques.
> >
> > Those two world space rays define a world space plane (they both
> > contain the camera origin, so it is a plane.)
> >
> > Now solve a quadratic equation to compute the intersections of the
> > world space circle with the world space plane. Pick the one of the
> > two answers that's right.
> >
> >
> > --bb
> >
> > On 7/22/05, Andras Balogh <***@gmx.net> wrote:
> >
> >>I have a point 'v0' in world space, that I can only rotate around a
> >>fixed point 'p' and axis 'r'. So movement is constrained on a circle.
> >>Now, I'm looking for the point 'v1' on this circle, so that the three
> >>points (v0, p, v1), when projected to the screen, enclose a given angle.
> >>
> >>Any ideas how to compute the world space 'v1', given the screen space angle?
> >>
> >>I was thinking of working backwards, rotating first in screen space,
> >>using the given angle, and then trying to figure out the world space
> >>position of v1, but I'm a bit afraid, that this wouldn't be a very
> >>robust solution..
> >>
> >>thanks,
> >>
> >>
> >>Andras
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> >>from IBM. Find simple to follow Roadmaps, straightforward articles,
> >>informative Webcasts and more! Get everything you need to get up to
> >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> >>_______________________________________________
> >>GDAlgorithms-list mailing list
> >>GDAlgorithms-***@lists.sourceforge.net
> >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> >>Archives:
> >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> >>
> >
> >
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>


--
William V. Baxter III, Ph.D.
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan 154-0023
[phone]

[Andras Balogh]

All the mails were sent to this list, looks like you have a problem with
your subscription/mail account... I'll forward you those messages in
private.

cheers,

Andras


Bill Baxter wrote:
> Were those private messages? All I could see of that conversation
> with Mick was the snippet you quoted which didn't make any sense out
> of context.
>
> If it was a personal conversation, would you mind repeating what the
> solution was?
>
> If it took place on the list here, then seems I've got a problem with
> the list. Traffic has seemed awfully light recently on gdalgo...
>
> --bb

[g***@erwincoumans.com]

>Traffic has seemed awfully light recently on gdalgo...
in case you are bored and have windows machine, watch these demos.

http://www.continuousphysics.com/p/bullet0.1demos.zip

Also you can visit my continuous collision detection and physics forum, for
the source, demos and discussions in that area:

http://www.continuousphysics.com/Bullet/phpBB2/index.php

[work in progress]

Erwin Coumans

[Willem de Boer]

For the bored, a sort of hand-wavy geometric proof
of this would go like this:

For a rectangle, R, with edges {e1,e2,e3,e4}, and
normal n. Edge e1 being fixed, rotate R about e1
such that n and the view vector v lie on the same
line, call this normal n_m. Call e3 the edge
opposite to e1. Let the screen-space area of R
be a function of its normal, A(n). We
want to show that n_m maximises A(n). Let V
be the plane constructed from the viewpoint and
e3.

Construct a cylinder C with its axis parallel to
e1 and such that e1 and its opposite edge, call
it e3, lie on the surface of the cylinder. Then
the surface of the cylinder represents the
constraint of e3, when we rotate R about e1. Also
V is a tangent plane of the cylinder. We now note
that in order for A(n) to not be a maximum at n_m,
the cylinder would have to intersect V somewhere
else than e3(n_m), but it doesn't because it is
a tangent plane to C.

Hmmm, very hand-wavy, but by its geometric construction
intuitively understandable.

---
Willem H. de Boer
Homepage: http://www.whdeboer.com

> -----Original Message-----
> From: gdalgorithms-list-***@lists.sourceforge.net
> [mailto:gdalgorithms-list-***@lists.sourceforge.net] On
> Behalf Of Megan Fox
> Sent: Thursday, July 21, 2005 9:32 PM
> To: gdalgorithms-***@lists.sourceforge.net
> Subject: Re: [Algorithms] rotating in world space to have
> result in screen space
>
> Forgive me if this is off, it's one of those "shouldn't this work?"
> sorts of intuition suggestions:
>
> The point at which a quad is most visible is always going to
> be when the normal of that quad is pointed directly at the
> viewer's position (or directly away from, but then it gets
> discarded, so ignore that).
> So, isn't the real question the closest you can rotate the
> normal to "camera lookat"?
>
>
> Here's where it gets even more dicey... shouldn't
> transforming the normalized quad-to-camera vector into the
> plane you're describing be able to give you the data
> necessary to generate the optimal transform?
>
>
> Sorry, I have no math to prove this, it just seems as if this "should"
> work? ... if I have time later, I'll try and work out an
> equation for all of this.
>
> -Megan Fox
>
> On 7/21/05, Andras Balogh <***@gmx.net> wrote:
> > Ok, so here's the original problem:
> >
> > I have a rectangle in world space, two of its neighbouring vertices
> > are locked at a fixed position (so you can rotate the
> rectangle around
> > the locked edge). Now, given an arbitrary viewing transform, rotate
> > the rectangle, so that its screen space size is maximized!
> >
> > I was thinking that I'll have the maximum area, if the
> normal vector
> > of the rotated rectangle is parallel in screen space to the
> projected
> > locked edge. So, having the screen space normal, I could
> compute the
> > angle between that and the screen space up vector. If I could
> > transform this angle back to world space, then I could just
> rotate the
> > rectangle by this amout..
> >
> > Ehh, I hope it makes some sense, there more I think about
> it, the more
> > confused I become :)
> >
> >
> > Andras
> >
> >
> > Ralph Egas wrote:
> > > Hi Andras,
> > >
> > > Are you looking for a solution for an arbitrary 'r' and
> 'p'? What if 'r'
> > > gets perpendicular to the right or up vector in screenspace?
> > > Obviously then there's not going to be any solution for
> any world space angle..
> > >
> > > If you could just elaborate your idea and what you need this
> > > solution for, maybe that could help.
> > >
> > > Cheers,
> > >
> > > Ralph
> > >
> > > ----- Original Message ----- From: "Andras Balogh"
> > > <***@gmx.net>
> > > To: <gdalgorithms-***@lists.sourceforge.net>
> > > Sent: Thursday, July 21, 2005 8:02 PM
> > > Subject: [Algorithms] rotating in world space to have result in
> > > screen space
> > >
> > >
> > >> I have a point 'v0' in world space, that I can only
> rotate around a
> > >> fixed point 'p' and axis 'r'. So movement is constrained
> on a circle.
> > >> Now, I'm looking for the point 'v1' on this circle, so that the
> > >> three points (v0, p, v1), when projected to the screen,
> enclose a given angle.
> > >>
> > >> Any ideas how to compute the world space 'v1', given the screen
> > >> space angle?
> > >>
> > >> I was thinking of working backwards, rotating first in screen
> > >> space, using the given angle, and then trying to figure out the
> > >> world space position of v1, but I'm a bit afraid, that this
> > >> wouldn't be a very robust solution..
> > >>
> > >> thanks,
> > >>
> > >>
> > >> Andras
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDAlgorithms-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies from IBM. Find simple to follow Roadmaps,
> straightforward articles, informative Webcasts and more! Get
> everything you need to get up to speed, fast.
> http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>

[Gaël LEQUEUX]

Hi there,
I'm currently searching an accurate sound mixing algorithm.
I have two 16 Bits samples S1 and S2 and I'd like to find SMix, the new
sample I must put in my sound data to obtain the exact same volume as S1 and
S2 were played on 2 speakers.

The formulas I found are (Of course I have to saturate SMix after that):
- Simply add S1 and S2
- Average S1 and S2
- SMix = Log(10^S1+10^S2)
- SMix = 20*Log(10^(S1/20)+10^(S2/20))

Is there an 'official' formula?

Cheers,
Gaël LEQUEUX

[Nils Pipenbrinck]

Gaël LEQUEUX wrote:

>Hi there,
>I'm currently searching an accurate sound mixing algorithm.
>I have two 16 Bits samples S1 and S2 and I'd like to find SMix, the new
>sample I must put in my sound data to obtain the exact same volume as S1 and
>S2 were played on 2 speakers.
>
>
Hi Gaël,

You'll simply want to add the samples.

There's always a lot of confusion when it comes to energy, multiple
speakers and perceived volume. Playing the same signal twice on two
loudspeakes doubles the energy but not the perceived volume. Adding
those samples and playing them over one speaker does the same (assuming
that the speakers and amplifiers work linear, which I do).

You need the log-equations when you want to double the perceived volume
or you want to mix two signals and have the same perceived volume as a
single signal.

Nils

(and now I'm expecting to get yet another autoreply from Dennis :)

[Jon Watte]

The "official" mixing formula is to just add them.

The log formulas have to do with converting between voltage values (what
samples are) and decibels (which you can show to the user) and will
sound like crap if you play them.

The average formula is just the same as adding, and then reducing gain
by 6 dB to avoid clipping. (A+B)/2


However, you're talking about two speakers, without any more
qualification. There is a difference in perceived volume between a
signal playing out just a single speaker, and a signal playing out two
speakers. Typically, you'll compensate for this using something called
the "log3 rule" IF you manually introduce panning into your mix.

However, for cases like a stereo->mono downmix, it's just mixing, and
you just add the numbers.


Cheers,

/ h+


Gaël LEQUEUX wrote:
> Hi there,
> I'm currently searching an accurate sound mixing algorithm.
> I have two 16 Bits samples S1 and S2 and I'd like to find SMix, the new
> sample I must put in my sound data to obtain the exact same volume as S1 and
> S2 were played on 2 speakers.
>
> The formulas I found are (Of course I have to saturate SMix after that):
> - Simply add S1 and S2
> - Average S1 and S2
> - SMix = Log(10^S1+10^S2)
> - SMix = 20*Log(10^(S1/20)+10^(S2/20))
>
> Is there an 'official' formula?
>
> Cheers,
> Gaël LEQUEUX
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>
>

--
-- The early bird gets the worm, but the second mouse gets the cheese.

[Jon Watte]

> the "log3 rule" IF you manually introduce panning into your mix.

By that, I meant the "3 dB pan rule"; sorry about the typo.

Cheers,

/ h+


--
-- The early bird gets the worm, but the second mouse gets the cheese.

[Lorenzo Pastrana]

Hi,

I understand that the simple addition is usually the way to go, but,
when it comes to mix various signals and keep the output signal between
a certain range things becomes more complicated ...

Say you have a float normalized (-1 / 1) signal path and want to keep
the mixer's output in that range.

When using the sum it simply doesn't work ... When using the average, an
input gets divided by N inputs no matter what are the others signals.
Supposing that's not what typical mixers do, what would be a working
solution ?

Wouldn't that be using a log(?) scale on the output ?

Thanks.

Jon Watte wrote:
>
> The "official" mixing formula is to just add them.
>
> The log formulas have to do with converting between voltage values (what
> samples are) and decibels (which you can show to the user) and will
> sound like crap if you play them.
>
> The average formula is just the same as adding, and then reducing gain
> by 6 dB to avoid clipping. (A+B)/2
>
>
> However, you're talking about two speakers, without any more
> qualification. There is a difference in perceived volume between a
> signal playing out just a single speaker, and a signal playing out two
> speakers. Typically, you'll compensate for this using something called
> the "log3 rule" IF you manually introduce panning into your mix.
>
> However, for cases like a stereo->mono downmix, it's just mixing, and
> you just add the numbers.
>
>
> Cheers,
>
> / h+
>
>
> Gaël LEQUEUX wrote:
>
>> Hi there,
>> I'm currently searching an accurate sound mixing algorithm.
>> I have two 16 Bits samples S1 and S2 and I'd like to find SMix, the new
>> sample I must put in my sound data to obtain the exact same volume as
>> S1 and
>> S2 were played on 2 speakers.
>>
>> The formulas I found are (Of course I have to saturate SMix after that):
>> - Simply add S1 and S2
>> - Average S1 and S2
>> - SMix = Log(10^S1+10^S2)
>> - SMix = 20*Log(10^(S1/20)+10^(S2/20))
>>
>> Is there an 'official' formula?
>>
>> Cheers,
>> Gaël LEQUEUX
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September
>> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>> & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> GDAlgorithms-list mailing list
>> GDAlgorithms-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>>
>>
>

[Jon Watte]

> I understand that the simple addition is usually the way to go, but,
> when it comes to mix various signals and keep the output signal between
> a certain range things becomes more complicated ...

> When using the sum it simply doesn't work ... When using the average, an
> input gets divided by N inputs no matter what are the others signals.
> Supposing that's not what typical mixers do, what would be a working
> solution ?

You need to come up with a reasonable gain structure. There is X dB of
dynamic range to play with, and you have to figure out where to allocate
what bits of it. That's part of the art and science of sound design;
that's one of the things that a game sound designer does.

Some rules of thumb are:
- You're unlikely to get more than 50 dB of usable dynamic range out of
typical crappy TV or PC speakers.
- If two uncorrelated equal-strength signals are mixed, the maximum
voltage level (sample value) will be +6dB from the individual signals,
but the effective (perceieved) volume will only be +3dB.
- If the signals are percussive (effects rather than clear sustained
tones) and uncorrelated, it's often good enough to just mix them
together and saturate if you go beyond -1/1.
- Radio stations usually use duckers, compressors and limiters to avoid
saturating, even when they have an announcer going on top of a song and
start a commercial a little bit early. The draw-back is that you get
that ultra-compressed "FM" sound.

Also, lots of different sounds that all play at the same loudness at the
same time very quickly turn into mush, so that's not a case you want to
design your software for.

You probably should find an experienced game audio sound designer, or a
recording studio engineer who also knows math (they do exist), and have
them explain the concepts of mixing and gain structure to you while
illustrating with live signals. You also should make sure that the
requirements for your project come from someone with that kind of
background, else what you end up with is unlikely to be what the audio
people actually want.

Without knowing anything more about your project, here's a straw man
proposal to start from:

1) Each sound (as placed by the sound designer) has individual gain.
This allows the sound designer to use existing samples for varying sound
source needs.
2) sound categories (ambient, gunshots+explosions, foley, other effects)
should be mixed together into submixes, each of which has individual
gain. This allows the sound designer to strike a good balance between
the different kinds of sound without having to adjust all the source
sounds (which would be a huge PITA).
3) The categories are mixed together into a master output, which has a
master gain, and then does hard saturation. Typically, this master gain
will start out in the range of -3 to -6 dB, to allow two-to-four
full-volume sounds to mix without too much distortion.

If you want to go one up from that, I would add a peak-following
compressor with a fast attack envelope, and a release of maybe 0.5
seconds, triggering at around -6 dB and with a 3:1 compression ratio,
after the master gain. This will make multiple percussive sounds playing
together much less likely to saturate, while keeping levels generally
around where they are designed.

I would rather go with saturation than adding a limiter to the chain,
but I'm sure there are sound designers that would rather have a limiter
than saturation. It's an aesthetics choice where there's no right or wrong.

I have a small page at
http://www.mindcontrol.org/~hplus/misc/compressor.html that talks a
little bit about how an audio compressor works, if you're unfamiliar
with the concept.


> Wouldn't that be using a log(?) scale on the output ?

PCM samples is a linear signal. Applying any non-linear function to the
values of those samples will introduce new harmonics to the signal (i e,
distortion).

Cheers,

/ h+

--
-- The early bird gets the worm, but the second mouse gets the cheese.

[Lorenzo Pastrana]

Well I realize that my question was too fuzzy about the context... I'm
not concerned about any particular platform (although any implementation
consideration is the point) but rather about the theory of it. In
addition I must tell I do have some sound design notions forged on user
side of the world, but not on the math side of it. I mean I know about
mix (sub)structure and most of the common sound processing tools
(dynamics, eq/filters, phase/time ...) and their overall structure.

John Miles wrote:
> Ask yourself what the effect of adding a silent sample into an
> existing mix will be: if the answer isn't "nothing," you're doing it
> wrong.

That was exactly the intent of my question : how do you achieve this
with n signals.

I found a quite interesting page on the MusicDsp list faq (I confess I
hooked this thread before I did the usual research myself just because
it popped up here and was a question I had lately)

<http://www.musicdsp.org/phpWiki/index.php/how%20do%20i%20mix%20n%20sounds%20together%3F?PHPSESSID=22dba66d704057c14baddccd7977463e>

Jon Watte wrote:
> You need to come up with a reasonable gain structure. There is X dB of
> dynamic range to play with, and you have to figure out where to allocate
> what bits of it.

Is this what you mean by gain structure ? :

John Miles wrote:
> We've always used bits 11-26 of an int32 for this purpose. Bits
27-31 give
> you enough headroom to mix 32 samples without intermediate overflows,
while
> bits 0-10 are for level scaling.

The last sentence on the above page says (about floats) : "Nowadays we
can afford the computational cost, so it makes sense to reserve lots of
headroom in all signals to deal with the extra bits generated while
processing. Going about it this way simplifies our algorithms considerably."

But that doesn't solves the silent input problem ...

In floating point what does headroom means ? Or how does 'reserve lots
of' could be implemented ?

After a coarse description of floating point, in :
<http://service.steinberg.de/knowledge_pro.nsf/0/640f2835d6038517c1256baa004f6717>

I can read :
"Nuendo uses a nominal operating level inside this floating point range,
such that there is a more than sufficient accuracy to represent the
finest detail but still have a massive head room"

That's more or less what I'm trying to figure out : what is this
'nominal operaing level' and how is it implemented supposing I want to
do something like, not Nuendo of course, but a modular audio tool (read
not a fixed path system).

Also : "Lowering the master fader is changing the scaling value as the
floating point values are converted to integer bits for the audio card.
The advantage is that you can pile on the tracks and if the final output
clips you can just turn down the master fader, and not be forced to
reduce each fader in tern until the clipping at the output disappears."

That triggers two questions :

1 - Does that mean the master output recives signal in the MAX_FLOAT <=>
-MAX_FLOAT range and scales it by 1 up to MAX_FLOAT only in the end (if
needed) ?

2 - Plugging a sort of enveloppe follower between the input and that
scaling factor would be what Stephen J Baker calls dimming. I can figure
what would be the effect (dramatic ducking) on particularly disparate
dynamics, but I guess it would be usefull if the ranges are carefully
tuned ?

As usual any pointer that could help me figure all this out is wellcome :)

Thanks y'all.
Lo.

[Jon Watte]

> > You need to come up with a reasonable gain structure. There is X dB of
> > dynamic range to play with, and you have to figure out where to allocate
> > what bits of it.
>
> Is this what you mean by gain structure ? :
>
> John Miles wrote:
> > We've always used bits 11-26 of an int32 for this purpose. Bits
> 27-31 give
> > you enough headroom to mix 32 samples without intermediate overflows,
> while
> > bits 0-10 are for level scaling.


Sort of. Even if you have floating point data, you will saturate to a
fixed point output DAC in the end. This DAC is most often 16 bits, but
sometimes 20 or 24, even on fairly low-end modern systems.

If you're making a squad-based modern-military combat game, you need to
make it so that a single gunshot sound will not sound too wimpy, while a
full squad doing suppressive fire, while there's incoming artillery,
still doesn't saturate too much. Finding what levels and compression
schemes work best for this is another way of phrasing the problem. Your
approach of adding -6 dB of gain to everything, and then mixing and
saturating, is a fine start.

> In floating point what does headroom means ? Or how does 'reserve lots
> of' could be implemented ?

Floating point has about 147 dB of signal-to-noise between the MSB
peak-to-peak signal and the quantization noise floor (actually,
dithering will typically add 3 dB, but at these resolutions, who's
counting? :-)

Furthermore, the 8 bits of exponent give you "headroom" of about 768 dB
or so before the internal representation starts clipping. Thus, you can
mix a practically unlimited amount of channels before you start reducing
gain to go out to the DAC, and just not worry about it. With integer
mixing, you have to have a maximum number (like 32 in the suggested bit
allocation scheme by John Miles).

Almost all floating-point audio processing represents signals such that
value 1 will reach the saturation point of the end stage (output DAC); i
e, 1.0 == 0 dBV.


I would stick with what you have now until it shows itself unable to
handle; at that point, I'd look into putting a 3:1 compressor on the
main output signal with a knee around -6 dB. Your sound designers may
also ask for specific effects in specific situations; you may want to
implement sub-mixes ("busses") to efficiently deliver these effects to them.


Cheers,

/ h+


--
-- The early bird gets the worm, but the second mouse gets the cheese.

[Tom Plunket]

Jon Watte wrote:

> If you're making a squad-based modern-military combat game, you
> need to make it so that a single gunshot sound will not sound too
> wimpy, while a full squad doing suppressive fire, while there's
> incoming artillery, still doesn't saturate too much.

It sounds like a solution like HDR would work well for this, and
might allow us to best utilize the crappy resolution of consumer
audio equipment most fully, since human hearing has such a huge
dynamic range (although doesn't have anything like the eye's
iris, it may be handy to mimic it anyway?).

I suppose that's the kind of effect that you'll get if you have a
compressor on at the high-end anyway, but I wonder if true volume
scaling based on the "large magnitude" content would be
effective?

-tom!

[Ken Noland]

Hey

I'm new to the list and this is my first post, so please correct me if
I'm wrong.

When I was working on our own sound mixer I thought it would be a
quick and easy task, but I was mistaken. By simply adding two sounds
together and then taking the average, you are effectively increasing
the attenuation and therefor cutting the volume in half. Capping it
doesn't work either simply because sound is measured in difference
from one wave to the next, so if you cap it, you'll introduce static
into your sound.

Do to time constraints, I had to stick with a global attenuation that
I applied to all 32 buffers and tweaked that value to a range that was
acceptable and that wouldn't create too much static, however during my
research I stumbled across some far better techniques. Doing some
research into DSP and wavelets will help you get a better
understanding of how the sound processing units actually mix the
samples together. Furthermore, I devised my own hybrid system, which I
must add that I have not had the time to fully implement.

My system analyzes the sound signal to determine the peaks and valleys
and grouped those together in what I called envelopes. When a sound is
submitted its envelope was placed in a queue while the other sound
samples applied a slight linear fade if needed, meanwhile other
properties where being applied such as distance, attenuation,
intensity, etc... The envelope would finally make its way into the
primary buffer and viola, you have sound!

I am curious though, does anyone on this list know of a good software
mixing algorithm that would work with lots of sounds and be as dynamic
as possible?

-Ken Noland



On 8/2/05, Lorenzo Pastrana <***@ultraflat.net> wrote:
>
> Hi,
>
> I understand that the simple addition is usually the way to go, but,
> when it comes to mix various signals and keep the output signal between
> a certain range things becomes more complicated ...
>
> Say you have a float normalized (-1 / 1) signal path and want to keep
> the mixer's output in that range.
>
> When using the sum it simply doesn't work ... When using the average, an
> input gets divided by N inputs no matter what are the others signals.
> Supposing that's not what typical mixers do, what would be a working
> solution ?
>
> Wouldn't that be using a log(?) scale on the output ?
>
> Thanks.
>
> Jon Watte wrote:
> >
> > The "official" mixing formula is to just add them.
> >
> > The log formulas have to do with converting between voltage values (what
> > samples are) and decibels (which you can show to the user) and will
> > sound like crap if you play them.
> >
> > The average formula is just the same as adding, and then reducing gain
> > by 6 dB to avoid clipping. (A+B)/2
> >
> >
> > However, you're talking about two speakers, without any more
> > qualification. There is a difference in perceived volume between a
> > signal playing out just a single speaker, and a signal playing out two
> > speakers. Typically, you'll compensate for this using something called
> > the "log3 rule" IF you manually introduce panning into your mix.
> >
> > However, for cases like a stereo->mono downmix, it's just mixing, and
> > you just add the numbers.
> >
> >
> > Cheers,
> >
> > / h+
> >
> >
> > Gaël LEQUEUX wrote:
> >
> >> Hi there,
> >> I'm currently searching an accurate sound mixing algorithm.
> >> I have two 16 Bits samples S1 and S2 and I'd like to find SMix, the new
> >> sample I must put in my sound data to obtain the exact same volume as
> >> S1 and
> >> S2 were played on 2 speakers.
> >>
> >> The formulas I found are (Of course I have to saturate SMix after that):
> >> - Simply add S1 and S2
> >> - Average S1 and S2
> >> - SMix = Log(10^S1+10^S2)
> >> - SMix = 20*Log(10^(S1/20)+10^(S2/20))
> >>
> >> Is there an 'official' formula?
> >>
> >> Cheers,
> >> Gaël LEQUEUX
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >> September
> >> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> >> & QA
> >> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> >> _______________________________________________
> >> GDAlgorithms-list mailing list
> >> GDAlgorithms-***@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> >> Archives:
> >> http://sourceforge.net/mailarchive/forum.php?forum_ida88
> >>
> >>
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>

[Stephen J Baker]

The problem is in many ways just like that of high dynamic range rendering
in graphics.

You have a device with finite dynamic range which is attempting to reproduce
a signal of unlimited dynamic range.

Just as with graphics, if you have a scene containing 'normal' lighting
and you turn on a bright light, the graphics system has to either dim down
the rest of the scene in order to make the light look bright (which is
what happens if you average your two sounds) - or it has to simply clamp
the bright light (which distorts colours in exactly the way that sounds
are distorted if you add and clamp them).

You can even do nonlinear tricks (using gamma curves in graphics and
logarithmic representations in audio).

What works in graphics is some kind of perceptual approach where you fake
the PERCEPTION of a bright light by doing blooming and such whilst also
doing a compromise between dimming down the background and clamping the
bright light.

Presumably there is an acoustic analog of that?

-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker [phone] (Vox/Vox-Mail)
L3Com/Link Simulation & Training [phone] (Fax)
Work: ***@link.com http://www.link.com
Home: ***@airmail.net http://www.sjbaker.org

[Thatcher Ulrich]

On Aug 02, 2005 at 12:48 -0400, Ken Noland wrote:
>
> My system analyzes the sound signal to determine the peaks and
> valleys and grouped those together in what I called envelopes. When
> a sound is submitted its envelope was placed in a queue while the
> other sound samples applied a slight linear fade if needed,
> meanwhile other properties where being applied such as distance,
> attenuation, intensity, etc... The envelope would finally make its
> way into the primary buffer and viola, you have sound!

My 2 cents on the original question: I agree with everyone who said
"just add and saturate".

I also agree with the sentiment that choices about mixing and
compression are basically aesthetic decisions, not a matter of
implementing a "correct" algorithm.

BUT, I also happen to think that most game sound is mixed poorly,
especially for my (pedestrian) living room listening environment.
Granted, one big problem is that I'm an old fart who wants to keep the
volume down. I suspect another big problem is that most sound
designers mix for maximum impact with their decent studio and
equipment, and there's not much we coders can do about that.

Yet another big problem is probably that designers don't have ideal
tools -- since game sound is dynamic and unpredictable, you can't just
tweak the mixer settings over and over until it sounds great, like
music or movie sound engineers do. Just giving game sound designers
some faders and compressors is good, but not enough to totally solve
things.

So I think Ken's ideas are interesting. IMO there absolutely is room
for sophisticated automated mixing that would help sound designers get
good game sound mixes all the time. If I understand correctly, I
think Ken is suggesting a sort of look-ahead compressor -- when a new
sample is triggered, you already know its envelope, so your compressor
can use that information instead of looking at the mixer output after
the fact, in order to trigger the compressor.

Other random ideas I've had, but never tried:

* perceptual compression (probably this exists) -- trigger compression
based on the perceptual volume of a particular mix, not just the
signal level. I guess "perceptual volume" would take into account
spectral distribution and such.

* "importance mixing" -- channels get tagged with metadata that
indicates how important the sound is; in a dense mix, less important
sounds get attenuated more. This is basically automated ducking;
I'm sure somebody out there has used it in a game.

* distortion as a stand-in for gain -- a clipped sound sounds "louder"
at the same peak-to-peak level (simple saturation does this, which I
think is one reason it's not so terrible). Anyway, let's say the
mixer has to attenuate some less-important channel -- perhaps it
could also add some distortion to make the sound perceptually
louder at the same time as its gain is being reduced.

* "importance timing" -- let's say two very important sounds are
triggered so they overlap -- importance timing would delay one of
the sounds until the other sound had played completely, so the
player hears both clearly. Makes a lot of sense for voice-overs and
dialogue (I suspect some games have coded this explicitly).

--
Thatcher Ulrich
http://tulrich.com

[Jon Watte]

> think Ken is suggesting a sort of look-ahead compressor -- when a new
> sample is triggered, you already know its envelope, so your compressor

Turns out, look-ahead almost never sounds good, unless you have a LOT of
look-ahead. And you don't want a 2 second latency on your sound
effects... (2 seconds might not even be enough).

> * perceptual compression (probably this exists) -- trigger compression

Similar to how FM stations compress their outgoing signal. They use a
spectral compressor, where the signal is split into N bands (somewhat
like an equalizer) and different bands have different compression
settings, and different linkage to other bands/channels. There's a whole
science to developing the "right sound" for various FM stations.

> * distortion as a stand-in for gain -- a clipped sound sounds "louder"
> at the same peak-to-peak level (simple saturation does this, which I
> think is one reason it's not so terrible). Anyway, let's say the

That's because the standard deviation (and RMS) keeps going up. Be very
careful about the spectral contents of your distortion, though. A
saturation has essentially infinite spectral spread, and thus aliases
and folds down on itself, so it doesn't sound very musical (which might
not matter for an explosion :-). A polynomial of order 3 (which can be
made to fold a signal back towards 0 after saturating) will only
introduce harmonics up to 3x the original harmonics, which are easily
dealt with using oversampling and filtering.

Cheers,

/ h+


--
-- The early bird gets the worm, but the second mouse gets the cheese.

[Dennis Gustafsson]

Hi,


I am currently on vacation and will be back on August 22. For business inqueries please contact ***@meqon.com. For technical inqueries, contact ***@meqon.com.


Regards,
Dennis

[Shawn Hargreaves]

The audio equivalent would be some kind of compressor. That's basically a
dynamic level adjustor, which turns up the gain when quiet sounds are
played, then turns it down if they get too loud, but it has a nonlinear
response curve to clip the highest levels more aggressively, and a time
delay (usually described as attack and release speeds) so it takes some time
to respond to changes in level.

If you are listening to quiet sounds and then something much louder comes
along, the non linear response prevents excessive clipping, but it can still
sound dramatically louder. Then over a period of a second or so, the overall
level adjusts to the new context, so if the loud sound goes away, the
quieter sounds will seem much quieter in contrast, but then gradually fade
back to maintain a roughly constant overall level.

Audio engineers will happily pay thousands for ancient valve circuits that
do this kind of thing in a particularly musical fashion: it is one of the
most important steps in getting a good audio mix.


--
Shawn Hargreaves




-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net]On Behalf Of
Stephen J Baker
Sent: 02 August 2005 17:59
To: gdalgorithms-***@lists.sourceforge.net
Subject: Re: [Algorithms] Mixing sound samples


The problem is in many ways just like that of high dynamic range rendering
in graphics.

You have a device with finite dynamic range which is attempting to reproduce
a signal of unlimited dynamic range.

Just as with graphics, if you have a scene containing 'normal' lighting
and you turn on a bright light, the graphics system has to either dim down
the rest of the scene in order to make the light look bright (which is
what happens if you average your two sounds) - or it has to simply clamp
the bright light (which distorts colours in exactly the way that sounds
are distorted if you add and clamp them).

You can even do nonlinear tricks (using gamma curves in graphics and
logarithmic representations in audio).

What works in graphics is some kind of perceptual approach where you fake
the PERCEPTION of a bright light by doing blooming and such whilst also
doing a compromise between dimming down the background and clamping the
bright light.

Presumably there is an acoustic analog of that?

-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker [phone] (Vox/Vox-Mail)
L3Com/Link Simulation & Training [phone] (Fax)
Work: ***@link.com http://www.link.com
Home: ***@airmail.net http://www.sjbaker.org



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188

[John Miles]

Guys, all you have to do is add the samples using a data type that has
enough headroom to let you postpone saturation until all of the samples have
been added. (That way, clipping can actually be inhibited by the addition
of subsequent samples if they happen to be out of phase with what's already
in the accumulator.)

We've always used bits 11-26 of an int32 for this purpose. Bits 27-31 give
you enough headroom to mix 32 samples without intermediate overflows, while
bits 0-10 are for level scaling.

The resulting constraints (32 samples max, 66 dB of volume-control range)
are fine for most purposes, but our next major reincarnation of the mixer
will probably be float-based to eliminate them. Not a huge deal either way.

It's not exactly a PhD-level topic. If all you want to do is mix, then you
don't do log functions, moving averages, compression, HDR modelling, or any
of that junk. (Ask yourself what the effect of adding a silent sample into
an existing mix will be: if the answer isn't "nothing," you're doing it
wrong.)

-- john

[Alen Ladavac]

Hi all,

Is there a good way to detect which bandwidth is a client running on? When
using udp traffic, one clearly needs to prevent flooding the pipe with too
much traffic and choking the link. So far, I've mostly seen games either
doing some static assumptions (something like 5000Bps for internet, some
other value for LAN, based on netmask I guess), and/or let the user setup
the number properly.

We've been researching this somewhat lately, and it is definitely possible
to detect incoming bandwidth at clientside, and then report to server so it
doesn't send more than that. But it is hard to let that dynamically adjust
over the time, because if you send more than acceptable, flooding the pipe
will cause ping to jump up, what is clearly undesireable. We had some ideas
about using oscillating bandwidth to detect where's the top of the pipe,
without overfilling it for a long period of time, but we are not sure this
would be ideal, as ping would still oscillate, and it would be a slow
process.

We've also thought of periodically sending a small timer packet immediately
after a normal packet to see what's the delta at arrival. Not sure if that
would be a relevant measure.

Does anyone know of some other solution for that? Or are we on the right
track somewhere here?

Thanks,
Alen

[Tony Cox]

Specifically, the *physically correct* thing to do is just linearly add
the samples, without saturating the intermediate stages (so use a big
enough datatype). You have to saturate for final output, of course,
because your speakers are only physically capable of so much range (just
like monitors can only display pixels so bright).

However, for *artistic* reasons, your sound designer might want the
ability to add different behavior, such as compression, soft-clipping,
or ducking. The key point is that those are *artistic* choices, that
depend on the nature of your soundscape and the effect the sound
designer is trying to achieve. It's just not a choice that a programmer
should be hard-wiring into the low-level mixer.

For example: if you have two gunshot sounds playing simultaneously, then
your audio designer probably just wants you to do the usual thing, with
no special treatment. Whereas if you have a voiceover, your audio
designer *might* ask you to "duck" the other sounds while the voiceover
is happening. There's no way that a generic mixer can differentiate
between the two cases, because it depends on the semantics of the signal
- in one case gunshots and the other case human voice.

Finally: why write your own mixer anyway? It's ubiquitous functionality
that probably already exists on your target platform, either as a core
platform library or via middleware, and in some cases may take advantage
of hardware mixing.

Tony Cox - Development Manager
Studio ZR, Microsoft Game Studios

-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net] On Behalf Of John
Miles
Sent: Tuesday, August 02, 2005 10:25 AM
To: gdalgorithms-***@lists.sourceforge.net
Subject: RE: [Algorithms] Mixing sound samples

Guys, all you have to do is add the samples using a data type that has
enough headroom to let you postpone saturation until all of the samples
have
been added. (That way, clipping can actually be inhibited by the
addition
of subsequent samples if they happen to be out of phase with what's
already
in the accumulator.)

We've always used bits 11-26 of an int32 for this purpose. Bits 27-31
give
you enough headroom to mix 32 samples without intermediate overflows,
while
bits 0-10 are for level scaling.

The resulting constraints (32 samples max, 66 dB of volume-control
range)
are fine for most purposes, but our next major reincarnation of the
mixer
will probably be float-based to eliminate them. Not a huge deal either
way.

It's not exactly a PhD-level topic. If all you want to do is mix, then
you
don't do log functions, moving averages, compression, HDR modelling, or
any
of that junk. (Ask yourself what the effect of adding a silent sample
into
an existing mix will be: if the answer isn't "nothing," you're doing it
wrong.)

-- john

[Brian Hook]

On Tue, 2 Aug 2005 10:44:55 -0700, Tony Cox wrote:
> Finally: why write your own mixer anyway? It's ubiquitous
> functionality that probably already exists on your target platform,
> either as a core platform library or via middleware, and in some
> cases may take advantage of hardware mixing.

The quality, robustness, and compatibility of the different mixing
subsystems out there is highly hit or miss. Hardware mixing on
Windows is a flat out joke, for example.

For getting things working on a wide variety of platforms I have
always had more luck writing a mixer that just has to spit out
2/16/44.1KHz to a single platform's buffer mechanism.

Brian

[Brian Hook]

On Tue, 2 Aug 2005 10:25:13 -0700, John Miles wrote:
> It's not exactly a PhD-level topic.

No, but there are a lot of nuances. The common problem being "sample
is too quiet on its own, too loud with others". And there are other
issues as well, such as the various flanging effects that occur if you
have too many of the same samples playing back to back, etc.

Floating point mixing is ultimately the way to go but it requires a
system that can handle floating point data or at least having a very
fast float -> 16-bit conversion function. Although with today's
systems that's probably not even a concern.

Brian

[John Miles]

> On Tue, 2 Aug 2005 10:25:13 -0700, John Miles wrote:
> > It's not exactly a PhD-level topic.
>
> No, but there are a lot of nuances. The common problem being "sample
> is too quiet on its own, too loud with others". And there are other
> issues as well, such as the various flanging effects that occur if you
> have too many of the same samples playing back to back, etc.

None of which have anything at all to do with mixing.

The original question was the perennial "How do I mix two samples," not
"Tell me everything there is to know about time-domain effects."

> Floating point mixing is ultimately the way to go but it requires a
> system that can handle floating point data or at least having a very
> fast float -> 16-bit conversion function. Although with today's
> systems that's probably not even a concern.

Yeah, audio's pretty low-bandwidth these days. Systems have been getting
faster (at least until recently), but our cochleas aren't growing new
receptors.

Although it's still pretty easy to hand-wave your way into a performance
problem, even in the audio world. I just did that myself. ("Nah, that
mixer code shouldn't need to be optimized any further. Huh? WTF do you
mean it takes 1% per sample on a Xenon?!")

-- john

[Brian Hook]

On Tue, 2 Aug 2005 11:19:47 -0700, John Miles wrote:

> The original question was the perennial "How do I mix two samples,"
> not "Tell me everything there is to know about time-domain effects."

Well, sure thing, except to someone who is new to mixing they're not
going to magically know that "hey, that flanging effect is actually
correct", they'll think it's a bug.

That's why I said "nuances" =)

> Yeah, audio's pretty low-bandwidth these days. Systems have been
> getting faster (at least until recently), but our cochleas aren't
> growing new receptors.

The other problem, of course, are systems that still don't have good
floating point such as almost anything that's handheld.

Brian

[Ken Noland]

To answer the initial question, just add the two together and call it
good, but for much more complicated systems where you can expect 32 or
more independant sounds coming through and you have to mix them with a
variety of variables including distance, attenuation, and intensity
and then further process the effects such as echo, reverb and any
other type of effect you want to process, things get very complicated
very fast.

The system I proposed earlier could work, but it requires a
preprocessing stage on each sound, and unfortunately I do not know if
I will have that luxury.

My question is, how do other game developers deal with this? Are there
any great resources that I should look into?

-Ken Noland

On 8/2/05, Brian Hook <***@bookofhook.com> wrote:
> On Tue, 2 Aug 2005 11:19:47 -0700, John Miles wrote:
>
> > The original question was the perennial "How do I mix two samples,"
> > not "Tell me everything there is to know about time-domain effects."
>
> Well, sure thing, except to someone who is new to mixing they're not
> going to magically know that "hey, that flanging effect is actually
> correct", they'll think it's a bug.
>
> That's why I said "nuances" =)
>
> > Yeah, audio's pretty low-bandwidth these days. Systems have been
> > getting faster (at least until recently), but our cochleas aren't
> > growing new receptors.
>
> The other problem, of course, are systems that still don't have good
> floating point such as almost anything that's handheld.
>
> Brian
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>

[Chris Butcher (BUNGIE)]

Halo 2 has an adaptive bandwidth model similar to what you describe. If
you like I can send you the ppt slides from the talk that Bart House and
I gave at GDC this year, just drop me an email.

It's built on top of our UDP streams which provide packet
acknowledgement. We watch every stream and monitor the round trip time,
data throughput, and packet loss numbers. We do this in windows of 2-5
seconds. If we detect congestion on a stream (increase in RTT, packet
loss over some threshold, or plateau in data throughput) then we will
back off that stream's data rate.

Over time we will speculatively try to increase data rate, looking for
potential congestion and being very cautious about backing off unless
the stream remains smooth.

You can store information about past connection profiles so that you
know where to start with an initial guess at total available bandwidth
when the game begins. This can also be used to select the best host
before the game starts.

These ideas are based off the DirectPlay link tuning algorithms (thanks
to Aaron Ogus, who was a great help). They have been very successful and
allow us to operate online without any user configuration. Our
implementation is able to seamlessly scale from <8kbps (low-bandwidth
client) to 1Mbps (15x 70Kbps server streams).

The approach you mention about using timer packets is more commonly
referred to as a "packet pair" technique. It works great for estimating
the capacity of a medium that is controlled by a literally
bandwidth-limited, like a DSL line. However if your bandwidth limitation
is imposed by something else, like software at an ISP that's controlling
the user's allotment, or a cable modem that has shared traffic, then
packet pairs are not a good way to measure available bandwidth. This is
what the Xbox Live QoS APIs use and it's just not something you can rely
on as the only source of bandwidth estimates.

--
Chris Butcher
Networking & Simulation Lead
Halo 2 | Bungie Studios
***@bungie.com

-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net] On Behalf Of Alen
Ladavac
Sent: Tuesday, August 02, 2005 13:06
To: gdalgorithms-***@lists.sourceforge.net
Subject: [Algorithms] Bandwidth control

Hi all,

Is there a good way to detect which bandwidth is a client running on?
When
using udp traffic, one clearly needs to prevent flooding the pipe with
too
much traffic and choking the link. So far, I've mostly seen games either
doing some static assumptions (something like 5000Bps for internet, some
other value for LAN, based on netmask I guess), and/or let the user
setup
the number properly.

We've been researching this somewhat lately, and it is definitely
possible
to detect incoming bandwidth at clientside, and then report to server so
it
doesn't send more than that. But it is hard to let that dynamically
adjust
over the time, because if you send more than acceptable, flooding the
pipe
will cause ping to jump up, what is clearly undesireable. We had some
ideas
about using oscillating bandwidth to detect where's the top of the pipe,
without overfilling it for a long period of time, but we are not sure
this
would be ideal, as ping would still oscillate, and it would be a slow
process.

We've also thought of periodically sending a small timer packet
immediately
after a normal packet to see what's the delta at arrival. Not sure if
that
would be a relevant measure.

Does anyone know of some other solution for that? Or are we on the right
track somewhere here?

Thanks,
Alen



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188

[Gaël LEQUEUX]

Thx everybody for your answers.
I finally used the sum algorithm but I reduced all my samples before
(Dividing by two) to avoid too much saturation and it works just fine.

Gaël.


-----Message d'origine-----
De : gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net] De la part de Ken
Noland
Envoyé : mardi 2 août 2005 20:54
À : gdalgorithms-***@lists.sourceforge.net
Objet : Re: [Algorithms] Mixing sound samples

To answer the initial question, just add the two together and call it
good, but for much more complicated systems where you can expect 32 or
more independant sounds coming through and you have to mix them with a
variety of variables including distance, attenuation, and intensity
and then further process the effects such as echo, reverb and any
other type of effect you want to process, things get very complicated
very fast.

The system I proposed earlier could work, but it requires a
preprocessing stage on each sound, and unfortunately I do not know if
I will have that luxury.

My question is, how do other game developers deal with this? Are there
any great resources that I should look into?

-Ken Noland

On 8/2/05, Brian Hook <***@bookofhook.com> wrote:
> On Tue, 2 Aug 2005 11:19:47 -0700, John Miles wrote:
>
> > The original question was the perennial "How do I mix two samples,"
> > not "Tell me everything there is to know about time-domain effects."
>
> Well, sure thing, except to someone who is new to mixing they're not
> going to magically know that "hey, that flanging effect is actually
> correct", they'll think it's a bug.
>
> That's why I said "nuances" =)
>
> > Yeah, audio's pretty low-bandwidth these days. Systems have been
> > getting faster (at least until recently), but our cochleas aren't
> > growing new receptors.
>
> The other problem, of course, are systems that still don't have good
> floating point such as almost anything that's handheld.
>
> Brian
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88

[Ken Noland]

I still have a few questions on this topic and I would like to
continue discussing it if possible.

What are some of the more dynamic algorithms for sound software mixing
used in game engines that you guys have seen? Are there any good
resources of sound programming and mixing?

-Ken Noland

On 8/3/05, Gaël LEQUEUX <***@laposte.net> wrote:
> Thx everybody for your answers.
> I finally used the sum algorithm but I reduced all my samples before
> (Dividing by two) to avoid too much saturation and it works just fine.
>
> Gaël.
>
>
> -----Message d'origine-----
> De: gdalgorithms-list-***@lists.sourceforge.net
> [mailto:gdalgorithms-list-***@lists.sourceforge.net] De la part de Ken
> Noland
> Envoyé: mardi 2 août 2005 20:54
> À: gdalgorithms-***@lists.sourceforge.net
> Objet: Re: [Algorithms] Mixing sound samples
>
> To answer the initial question, just add the two together and call it
> good, but for much more complicated systems where you can expect 32 or
> more independant sounds coming through and you have to mix them with a
> variety of variables including distance, attenuation, and intensity
> and then further process the effects such as echo, reverb and any
> other type of effect you want to process, things get very complicated
> very fast.
>
> The system I proposed earlier could work, but it requires a
> preprocessing stage on each sound, and unfortunately I do not know if
> I will have that luxury.
>
> My question is, how do other game developers deal with this? Are there
> any great resources that I should look into?
>
> -Ken Noland
>
> On 8/2/05, Brian Hook <***@bookofhook.com> wrote:
> > On Tue, 2 Aug 2005 11:19:47 -0700, John Miles wrote:
> >
> > > The original question was the perennial "How do I mix two samples,"
> > > not "Tell me everything there is to know about time-domain effects."
> >
> > Well, sure thing, except to someone who is new to mixing they're not
> > going to magically know that "hey, that flanging effect is actually
> > correct", they'll think it's a bug.
> >
> > That's why I said "nuances" =)
> >
> > > Yeah, audio's pretty low-bandwidth these days. Systems have been
> > > getting faster (at least until recently), but our cochleas aren't
> > > growing new receptors.
> >
> > The other problem, of course, are systems that still don't have good
> > floating point such as almost anything that's handheld.
> >
> > Brian
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDAlgorithms-***@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_ida88
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>

[Jon Watte]

> What are some of the more dynamic algorithms for sound software mixing
> used in game engines that you guys have seen? Are there any good
> resources of sound programming and mixing?

The next step up is adding sub-mixes, and one or more
compressors/limiters to your mix chain. See quick write-up at:
http://www.mindcontrol.org/~hplus/misc/compressor.html

A great resource on all things audio-processing-on-computers is the
MusicDSP mailing list and its web site:
http://www.musicdsp.com/

You might also want to have a professional sound designer, or a sound
engineer with a flair for math, explain to you how a typical live mix is
done to get a good sound, and compare it to something like TV post.
Knowing how the pros do these things in real life will likely help a lot!

Cheers,

/ h+


--
-- The early bird gets the worm, but the second mouse gets the cheese.

[John Miles]

> But that doesn't solves the silent input problem ...

If you add your samples algebraically, without dividing them by N first,
then a silent (signed) sample will simply add zero to the mix, leaving the
others untouched.

If you divide your samples by the number of samples being mixed, a
hypothetical silent sample will cause everything else to get quieter, which
is obviously wrong in any conceivable situation.

If you divide your samples by 32 (or whatever your maximum number of mixable
samples is), then silent samples won't hurt anything, but you will lose 5
(e.g.) LSBs worth of precision from the audible samples, which isn't good.

Dividing everything by two to drop 6 dB before mixing is OK, I guess, in the
absence of any other volume-control scheme... but if you do that, you still
have to do it even when there's only one audible sample, or the "silent
sample" problem will become apparent.

> In floating point what does headroom means ? Or how does 'reserve lots
> of' could be implemented ?

When you add your samples in the mixer loop, you will ultimately have to
saturate the result at [-32768,32767]. Saturation is a form of distortion,
obviously, but it's a heck of a lot better than the alternative. (If you
just grab the lower 16 bits and send them to the sound card DAC, the
distortion will be horrific due to frequency-domain effect of numerical
wraparound.)

The reason you want "headroom" is that you do NOT want to do the saturation
after every sample point is added. Saturation loses information that you
may be able to get back when a later sample that's out of phase with the
current mix is added in. So, you need to do your mixing at, say, 24 or
32-bit precision instead of just 16. Mixing with floats will take care of
that, or you can just use int32s.

Floats are nice because in most cases, you'd also like to perform volume
scaling on each sample point as it's added into the mix. To do that, you
need "floor room" -- i.e., more bits beneath the sample LSB to hold the
downscaled values.

This is why our fixed-point mixer uses 11 extra low-order bits, the 16 bit
sample, and 5 extra high-order bits. The extra LSBs let us do level
scaling, and the extra MSBs let us postpone the clamping operation until
after all 32 (potential) samples have been added in the mixer. Again, there
are any number of valid ways to represent your data; this is just one of
them.

-- john

[Tom Plunket]

John Miles wrote:

> When you add your samples in the mixer loop, you will ultimately
> have to saturate the result at [-32768,32767]. Saturation is a
> form of distortion, obviously, but it's a heck of a lot better
> than the alternative. (If you just grab the lower 16 bits and
> send them to the sound card DAC, the distortion will be horrific
> due to frequency-domain effect of numerical wraparound.)

Well, there are other alternatives, as Jon Watte has suggested.

His posts have made me want to post my own experiences here, but
my experiences in this domain are at a mixing console, not at a
computer keyboard...

Nominally, I want to run all of my tracks at "full" volume, so
that I can keep as much precision as necessary. In general, I
don't get saturation problems, though, because the drum track
isn't typically peaking in phase with the bass track, say. So,
first-pass, I'd suggest that you want to just try adding your
tracks and see what you get. In other words, don't try solving
this problem until it actually is a problem.

Next, there is the case of really "hot" signals, which actually
tend to swing from -Vmax to +Vmax, and actually worse in my
recordings, they don't truly swing that far except for
"sometimes". I don't want to munge every track if only one of
them is causing me problems. So, what I do in this case is throw
a compressor onto the problem tracks, but set up so that only the
top few dB are "tuned". Basically, I want to avoid saturation
because it /always/ sounds bad IMHO. Maybe I have exceptionally
good and/or bad hardware that just does something not musically
nice, but wow. Ick. The compressor then scales everything above
X dB by some ratio. I tend to like exponential ratios too so
you're cutting the highly-overboard signals by more while leaving
the slightly-overboard ones virtually untouched.

At the same time I'm doing the compression on these hot signals,
there are also invariably some tracks which aren't coming
anywhere near my desired volume, so I actually want to expand
those signals. An expander is an anti-compressor, so it actually
*raises* low signals by multiplying. On top of that, I also have
a fairly high noise floor, so I set a compressor of sorts up on
those signals as well, sort of like a soft gate.

So yeah, I'm distorting the hell out of my signals, but the end
result seems to be ok to me. The gain curve is 0:1 at 0 signal,
hits 1:1 at the target dB (I usually go for something between -6
and -3), and then infinity:1 at 0dB. The derivatives of the
curve (if it helps visualize) are 0 at 0 signal, 0 at the target
dB, and a vertical tangent at 0db (I can't remember the right
term now! ack).

-tom!

[Lorenzo Pastrana]

Thanks for all your answers :) I guess I can picture this better now ...
I now understand that in the case of the mixer my preoccupation had
nothing to do actually with mixing, but rather with the nature of the
output signal (witch the normalisation is about knowing what comes in,
no matter the mixing algo).

If I read you well, a tipical (simple) mixer could be :

Assuming floats

for all inputs
out = out + (input * (1 + gain)) * (1 - attenuation)

where inputs are -1 to 1, gain and attenuation are 0 to 1.

Adding all channels together (not even the -6dB thing) and scaling down
in the end IF necessary just before saturating would work ok for my
mixer (agree with T.U. that compression and other processings is an
artistic matter here).
Normalization ... I realize my perplexity came from a generalisation
atempt to the + operator in the usual flow diagrams as in :

<http://www.harmony-central.com/Effects/Articles/Delay/delay-f3.gif> or
<http://www.harmony-central.com/Effects/Articles/Flanging/flanger-f5.gif>

with regard to the normalisation of signals in a float path ...

Is the + operator actually an (A+B)/2 thing ? or does it depends on the
context ? Is it a simple sum ? If so and all levels are 1 in the
multitap delay example, it turns possibly into an amplitude * 4 block
... would normalizing the output mean :

out = (T1 + T2 + T3 + T4) / 4 as it seems obvious since there is no
reduction ?

But in the case of the feedback gain and the depth (0 to 1) in the
flanger, parameters can lead to the silent signal problem ...

would a correct normalisation be :

delayin = input * (1 - fbgain) + delayout * fbgain
output = input * (1 - depth) + delayout * depth

Of course, if this is getting off topic please answer on the private
line (& I'll post a summary if needed).

Thanks for all.

Lo.

[Peter Suwara]

A simple way to approach these issues is to apply various compression
techniques to the final output signal. Or a subgroup, such as the firing
sound effects.

There are many tutorials on basic compression algorithms on the
internet. Such an approach will maintain a non-linear relationship to
the sounds that gives the perceived loudness in a realistically modelled
way, and does not saturate and distort the actual signal. Depending on
your compression settings you could also provide a limiting component at
the end of your sound processing to prevent that tragic digital
distortion you get with traditional mixing methods.

PETER - SIAQUA - TORUS

-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net] On Behalf Of Tom
Plunket
Sent: Thursday, 4 August 2005 10:23 AM
To: gdalgorithms-***@lists.sourceforge.net
Subject: Re: [Algorithms] Mixing sound samples

Jon Watte wrote:

> If you're making a squad-based modern-military combat game, you
> need to make it so that a single gunshot sound will not sound too
> wimpy, while a full squad doing suppressive fire, while there's
> incoming artillery, still doesn't saturate too much.

It sounds like a solution like HDR would work well for this, and
might allow us to best utilize the crappy resolution of consumer
audio equipment most fully, since human hearing has such a huge
dynamic range (although doesn't have anything like the eye's
iris, it may be handy to mimic it anyway?).

I suppose that's the kind of effect that you'll get if you have a
compressor on at the high-end anyway, but I wonder if true volume
scaling based on the "large magnitude" content would be
effective?

-tom!


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88

[Tom Lowe]

I have little experience with sound mixing, but here's my thoughts from a
mathematical point of view:
Assumption/approximation 1: The perceived volume of a sample is based on the
standard deviation of the sound signal. I'll call this standard deviation v.
Assumption/approximation 2: We can model the sound signal as having a normal
distribution(the extreme values in the signal are less common than small
values).

if you add two sound samples with strengths v1 and v2 together, the
resulting sound wave has a strength of: v*v = v1*v1 + v2*v2 (sum of normal
distributions formula)

This approximation allows you to find the volume of any combination of
signals, and so allows you to scale down the resulting signal if you so
wish.

eg, if you have a sound at volume 1, and want to add naration at volume 0.5,
the resulting volume is v = sqrt(1*1 + 0.5*0.5), so if you want the mixed
result to be no louder, scale the result by 1/sqrt(1.25).

The formula also works for multiple samples:
v*v = v1*v1 + v2*v2 + v3*v3 + .... + vn*vn
Plus it clearly works for the 'add a zero sample' case since this will be
adding 0*0.

This is untested, but seems correct (if the assumptions are reasonable).

Tom.


-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net]On Behalf Of Peter
Suwara
Sent: 04 August 2005 00:32
To: gdalgorithms-***@lists.sourceforge.net
Subject: RE: [Algorithms] Mixing sound samples


A simple way to approach these issues is to apply various compression
techniques to the final output signal. Or a subgroup, such as the firing
sound effects.

There are many tutorials on basic compression algorithms on the
internet. Such an approach will maintain a non-linear relationship to
the sounds that gives the perceived loudness in a realistically modelled
way, and does not saturate and distort the actual signal. Depending on
your compression settings you could also provide a limiting component at
the end of your sound processing to prevent that tragic digital
distortion you get with traditional mixing methods.

PETER - SIAQUA - TORUS

-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net] On Behalf Of Tom
Plunket
Sent: Thursday, 4 August 2005 10:23 AM
To: gdalgorithms-***@lists.sourceforge.net
Subject: Re: [Algorithms] Mixing sound samples

Jon Watte wrote:

> If you're making a squad-based modern-military combat game, you
> need to make it so that a single gunshot sound will not sound too
> wimpy, while a full squad doing suppressive fire, while there's
> incoming artillery, still doesn't saturate too much.

It sounds like a solution like HDR would work well for this, and
might allow us to best utilize the crappy resolution of consumer
audio equipment most fully, since human hearing has such a huge
dynamic range (although doesn't have anything like the eye's
iris, it may be handy to mimic it anyway?).

I suppose that's the kind of effect that you'll get if you have a
compressor on at the high-end anyway, but I wonder if true volume
scaling based on the "large magnitude" content would be
effective?

-tom!


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88

[Stuart Harrison]

I've been following this with some interest and even (at times) some
understanding.

I throw my mad-cap plan in for your amusement, but not to be taken too
seriously.

Can you scale the sound_to_be_mixed (StbM) by the remaining space you
have for sound?
(assuming +1.0 .. -1.0 range for the samples)

e.g. if you have a sample at +0.6, and you want to mix it with another
one at +0.5:
space_remaining = 0.4
therefore, StbM is scaled by 0.4 and added => +0.6 + ( 0.4 * +0.5 ) =>
+0.8

This works for zero sounds (in both directions):
Sample=X, StbM=0.0 => X + ( (1-X) * 0.0 ) => X
Sample=0.0, StbM=X => 0 + ( 1 * X ) => X

No clamping is required (it's automatically done by the scaling as you
go).

It's commutative (order of mixing not is important).

You could argue that the space_remaining for -ve sound is 1.0 when
mixing with a +ve sample:
+1.0 ..xxxxxxxx|.......... -1.0 <<-- sample is +0.8, so 0.2 space to
+1.0; 1.0 space to -1.0, so:
Sample=+0.8, StbM=-0.8 => +0.8 + (1.0) * -0.8 => 0.0 (correct)

Ok, you can stop laughing now...

-Dino.

__________________________________________________________________________________________________________________________________________
Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may be the subject of Legal Professional Privilege. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited.The views of the author may not necessarily constitute the views of Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd in any contract or obligation.

The contents of an attachment to this e-mail may contain software viruses which could damage your own computer system. While Kuju Entertainment has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.

__________________________________________________________________________________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
_________________________________________________________________________________________________________________________________________

[Jon Watte]

This would work as a form of compression for "power envelopes".

The problem is that samples are instantaneous voltage readings, and
doing this mixing on a per-sample basis would introduce significant
distortion. Consider the case when mixing a 1.0 with a 0.6 and compare
to mixing a 1.0 with a 0.0, for example.

If you're working with power envelopes, you get into envelope shape
curves, look-ahead size, and other such compressor-like parmameters, and
pretty soon, you'll be designing a general-purpose compressor.

Cheers,

/ h+



Stuart Harrison wrote:
> I've been following this with some interest and even (at times) some
> understanding.
>
> I throw my mad-cap plan in for your amusement, but not to be taken too
> seriously.
>
> Can you scale the sound_to_be_mixed (StbM) by the remaining space you
> have for sound?
> (assuming +1.0 .. -1.0 range for the samples)
>
> e.g. if you have a sample at +0.6, and you want to mix it with another
> one at +0.5:
> space_remaining = 0.4
> therefore, StbM is scaled by 0.4 and added => +0.6 + ( 0.4 * +0.5 ) =>
> +0.8
>
> This works for zero sounds (in both directions):
> Sample=X, StbM=0.0 => X + ( (1-X) * 0.0 ) => X
> Sample=0.0, StbM=X => 0 + ( 1 * X ) => X
>
> No clamping is required (it's automatically done by the scaling as you
> go).
>
> It's commutative (order of mixing not is important).
>
> You could argue that the space_remaining for -ve sound is 1.0 when
> mixing with a +ve sample:
> +1.0 ..xxxxxxxx|.......... -1.0 <<-- sample is +0.8, so 0.2 space to
> +1.0; 1.0 space to -1.0, so:
> Sample=+0.8, StbM=-0.8 => +0.8 + (1.0) * -0.8 => 0.0 (correct)
>
> Ok, you can stop laughing now...
>
> -Dino.
>
> __________________________________________________________________________________________________________________________________________
> Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may be the subject of Legal Professional Privilege. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited.The views of the author may not necessarily constitute the views of Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd in any contract or obligation.
>
> The contents of an attachment to this e-mail may contain software viruses which could damage your own computer system. While Kuju Entertainment has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.
>
> __________________________________________________________________________________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> _________________________________________________________________________________________________________________________________________
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>
>

--
-- The early bird gets the worm, but the second mouse gets the cheese.

[Christian Schüler]

No laughing here, its would actually sound like an interesting effect, but you dont't want do to this for mixing :)

You're doing soft add for samples

A + ( 1 - A ) * B

which can be rewritten

A + B - A * B

so you have the mix of A plus B plus the ringmodulation of A and B.
As I said, will sound quite funny.



-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net [mailto:gdalgorithms-list-***@lists.sourceforge.net] On Behalf Of Stuart Harrison
Sent: Friday, August 05, 2005 7:24 PM
To: gdalgorithms-***@lists.sourceforge.net
Subject: RE: [Algorithms] Mixing sound samples


I've been following this with some interest and even (at times) some
understanding.

I throw my mad-cap plan in for your amusement, but not to be taken too
seriously.

Can you scale the sound_to_be_mixed (StbM) by the remaining space you
have for sound?
(assuming +1.0 .. -1.0 range for the samples)

e.g. if you have a sample at +0.6, and you want to mix it with another
one at +0.5:
space_remaining = 0.4
therefore, StbM is scaled by 0.4 and added => +0.6 + ( 0.4 * +0.5 ) =>
+0.8

This works for zero sounds (in both directions):
Sample=X, StbM=0.0 => X + ( (1-X) * 0.0 ) => X
Sample=0.0, StbM=X => 0 + ( 1 * X ) => X

No clamping is required (it's automatically done by the scaling as you
go).

It's commutative (order of mixing not is important).

You could argue that the space_remaining for -ve sound is 1.0 when
mixing with a +ve sample:
+1.0 ..xxxxxxxx|.......... -1.0 <<-- sample is +0.8, so 0.2 space to
+1.0; 1.0 space to -1.0, so:
Sample=+0.8, StbM=-0.8 => +0.8 + (1.0) * -0.8 => 0.0 (correct)

Ok, you can stop laughing now...

-Dino.

__________________________________________________________________________________________________________________________________________
Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may be the subject of Legal Professional Privilege. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited.The views of the author may not necessarily constitute the views of Kuju Entertainment Ltd. Nothing in this email shall bind Kuju Entertainment Ltd in any contract or obligation.

The contents of an attachment to this e-mail may contain software viruses which could damage your own computer system. While Kuju Entertainment has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.

__________________________________________________________________________________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
_________________________________________________________________________________________________________________________________________


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_ida88

[Lorenzo Pastrana]

PreScriptum :
Posted this reply this morning but seems it never reached the
list...(??) Sorry if it pops two times.

Thanks for all your answers :) I guess I can picture this better now ...
I now understand that in the case of the mixer my preoccupation had
nothing to do actually with mixing, but rather with the nature of the
output signal (witch the normalisation is about knowing what comes in,
no matter the mixing algo).

If I read you well, a tipical (simple) mixer could be :

Assuming floats

for all inputs
out = out + (input * (1 + gain)) * (1 - attenuation)

where inputs are -1 to 1, gain and attenuation are 0 to 1.

Adding all channels together (not even the -6dB thing) and scaling down
in the end IF necessary just before saturating would work ok for my
mixer (agree with T.U. that compression and other processings is an
artistic matter here).
Normalization ... I realize my perplexity came from a generalisation
atempt to the + operator in the usual flow diagrams as in :

<http://www.harmony-central.com/Effects/Articles/Delay/delay-f3.gif> or
<http://www.harmony-central.com/Effects/Articles/Flanging/flanger-f5.gif>

with regard to the normalisation of signals in a float path ...

Is the + operator actually an (A+B)/2 thing ? or does it depends on the
context ? Is it a simple sum ? If so and all levels are 1 in the
multitap delay example, it turns possibly into an amplitude * 4 block
... would normalizing the output mean :

out = (T1 + T2 + T3 + T4) / 4 as it seems obvious since there is no
reduction ?

But in the case of the feedback gain and the depth (0 to 1) in the
flanger, parameters can lead to the silent signal problem ...

would a correct normalisation be :

delayin = input * (1 - fbgain) + delayout * fbgain
output = input * (1 - depth) + delayout * depth

Of course, if this is getting off topic please answer on the private
line (& I'll post a summary if needed).

Thanks for all.

Lo.

[Nils Pipenbrinck]

Lorenzo Pastrana wrote:

> Is the + operator actually an (A+B)/2 thing ? or does it depends on
> the context ? Is it a simple sum ? If so and all levels are 1 in the
> multitap delay example, it turns possibly into an amplitude * 4 block
> ... would normalizing the output mean :
>
> out = (T1 + T2 + T3 + T4) / 4 as it seems obvious since there is no
> reduction ?


The little triangles are symbols for variable gain
amplifiers/attenuators. The variable gain is just left out (as the
variable delay times are) because it's a schematic drawing of the signal
flow. There's no need to specify them because unity gain amplifiers are
drawn as a triangle with a '1' in it's center.

> But in the case of the feedback gain and the depth (0 to 1) in the
> flanger, parameters can lead to the silent signal problem ...

In flagers this total signal cancellation is wanted behaviour, it's so
prominent that it even has it's own name: through zero flanging or TZF.
Btw, the moment of silence will happen only for one frequency group at
one instant of time. You'll never have a prolonged period of silence,
not even with a sine wave.

If you see diagrams like this the triangle is a multiplication with a
value ranging from 0 to 1 (inclusive). Self-oscillation is a wanted
feature most of the time, and the analog implementation (e.g. circuit)
will keep care that the signal never reaches infinity. If you want to
reproduce that in software you have to limit/saturate the signal to an
arbitrary maximum amplitude.

Nils

[Lorenzo Pastrana]

Nils Pipenbrinck wrote:
> The little triangles are symbols for variable gain
> amplifiers/attenuators.

Yop! got this one but,

> There's no need to specify them because unity gain amplifiers are
> drawn as a triangle with a '1' in it's center.

actually I read the value range of those particular ops (flanger case)
are ranged 0 to 1

> In flagers this total signal cancellation is wanted behaviour, it's so
> prominent that it even has it's own name: through zero flanging or TZF.

got this one too but, cancellation is not the problem here, it's the
other condition ... I was wondering about how would I normalize the
output at -1 to 1 considering :
an input at -1 to 1
an hypothetical fb gain of say 0.5
in that case the result of the sum ranges -1.5 to 1.5 and so the delay
output witch, folowing the flow, gets added to the input at say 1.0 so
the output might range at -2.5 to 2.5 ...

Would correct normalization be dividing the signal by 1 + gain ?

In the case of the flanger :

delayin = (input + delayout[-1] * feedback) / 1 + feedback
ouput = (input + delayout[0] * depth) / 1 + depth

Is that correct ?

Thanks.

[Nils Pipenbrinck]

Lorenzo Pastrana wrote:

Uh. it's getting slightly OT, but I'll answer anyways.. Just for the
archive and to end this thread with an answer.

If you still have open questions we'll do it offlist, or ask around at
the musicdsp / analog-heaven mailing lists.

> Would correct normalization be dividing the signal by 1 + gain ?
>
> In the case of the flanger :
>
> delayin = (input + delayout[-1] * feedback) / 1 + feedback
> ouput = (input + delayout[0] * depth) / 1 + depth


No. In the case of a flanger it is possible that the signal at the
output is much larger than unity. It is an undamped oscillator. They are
numerically unstable. If you add scale factors at the feedback that take
care that the output cannot exceed unity, you damp the oscillator and
it's not a full working flanger anymore. It might not sound bad, but
it's not the same thing anymore.

If you program one it's your task to choose a way to deal with that
problem (that has been discussed before.. you can saturate, clamp,
compress, all of it or do whatever you like).

In the analog world (where the flangers come from) there is a built in
clamp at the point where the feedback adds to the dry signal. A
simplified view of it might make it more clear: Adding two voltages in
analog can never exceed the supply voltage. Therefore the amplitude at
the summation point never exceed the supply voltage just because it's
impossible (or half of it to be exact since the signal must be able to
swing symetrically). Furthermore a analog delay line has a very limited
dynamic range and thus works as a very strong compressor/limiter as a
side-effect. All this keeps the output signal within range, and
typically it won't be hotter than twice the maximum input signal, even
if the flanger is full oscillating.

Nils

[Lorenzo Pastrana]

Nils Pipenbrinck wrote:

> Uh. it's getting slightly OT, but I'll answer anyways.. Just for the
> archive and to end this thread with an answer.

> If you still have open questions we'll do it offlist, or ask around at
> the musicdsp / analog-heaven mailing lists.

Sure ;) Thanks I'll be looking there ...

> No. In the case of a flanger it is possible that the signal at the
> output is much larger than unity. It is an undamped oscillator. They are
> numerically unstable. If you add scale factors at the feedback that take
> care that the output cannot exceed unity, you damp the oscillator and
> it's not a full working flanger anymore. It might not sound bad, but
> it's not the same thing anymore.

Ok, right..

> If you program one it's your task to choose a way to deal with that
> problem (that has been discussed before.. you can saturate, clamp,
> compress, all of it or do whatever you like).

> In the analog world (where the flangers come from) there is a built in
> clamp at the point where the feedback adds to the dry signal. A
> simplified view of it might make it more clear: Adding two voltages in
> analog can never exceed the supply voltage. Therefore the amplitude at
> the summation point never exceed the supply voltage just because it's
> impossible (or half of it to be exact since the signal must be able to
> swing symetrically). Furthermore a analog delay line has a very limited
> dynamic range and thus works as a very strong compressor/limiter as a
> side-effect. All this keeps the output signal within range, and
> typically it won't be hotter than twice the maximum input signal, even
> if the flanger is full oscillating.

Well, I'll be reading more DSP literature and ask in a related place
next time... Anyway thanks for this nice insight Nils, and thank y'all
for the bootstrap.

Lo.