## multiplying vs. dividing in audio domain

Feb 14, 2008 at 9:17am

# multiplying vs. dividing in audio domain

I am perhaps an incredible idiot, and am overlooking something
obvious, but I’m getting a rather odd response from some of the math
objects. I have a simple patch to scale the file position output of
sfplay~ to 0.-1. for window driving purposes. Offset and multiply,
the scaler’s mantra. Well, dividing by 1000. works fine, but,
multiplying by .001 generates crazy numbers. Sitting on my mother’s
knee, she told me that dividing by 1000. was the same as multiplying
by 0.001, but something seems a bit of here. I assume I’m whacking a
limit on the number size, but why with mult & not divide? If I throw
it together in straight max, btw,either of them work fine.

max v2;
#N vpatcher 203 223 1160 797;
#P window setfont “Sans Serif” 9.;
#P window linecount 2;
#P comment 474 73 100 196617 3. compare multiply vs divide;
#P window linecount 1;
#P comment 474 56 100 196617 2 fire away;
#P window linecount 3;
#P comment 648 386 100 196617 this generates some very interesting
numbers;
#P user number~ 459 347 596 362 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 443 258 580 273 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 637 349 774 364 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P window linecount 1;
#N sfplay~ 2 120960 1 ;
#P newobj 487 129 110 196617 sfplay~ 2 0 1;
#P newex 638 319 84 196617 /~ 0.001;
#P newex 638 295 33 196617 -~ 0.;
#P newex 662 268 74 196617 t 1000. 2500.;
#P window linecount 4;
#P message 388 27 50 196617 open , preload 2 1000 2500;
#P user number~ 119 341 256 356 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user ezdac~ 385 476 429 509 0;
#P user number~ 103 252 240 267 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P user number~ 297 343 434 358 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221
221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 386 95 50 196617 2;
#N sfplay~ 2 120960 1 ;
#P newobj 147 123 110 196617 sfplay~ 2 0 1;
#P newex 298 313 84 196617 /~ 1000.;
#P newex 298 289 33 196617 -~ 0.;
#P newex 322 262 74 196617 t 1000. 2500.;
#P window linecount 3;
#P comment 294 376 100 196617 this properly scales the file position
index to 0-1;
#P window linecount 1;
#P comment 474 40 100 196617 1. load it up;
#P connect 5 2 8 0;
#P connect 3 0 10 0;
#P connect 11 0 5 0;
#P connect 6 0 5 0;
#P connect 4 0 7 0;
#P connect 5 2 3 0;
#P connect 3 0 4 0;
#P connect 2 0 3 1;
#P connect 6 0 2 0;
#P connect 15 2 17 0;
#P connect 13 0 18 0;
#P connect 11 0 15 0;
#P connect 6 0 15 0;
#P connect 14 0 16 0;
#P connect 15 2 13 0;
#P connect 13 0 14 0;
#P connect 12 0 13 1;
#P pop;

#35807
Feb 14, 2008 at 9:59am

in your patch you are not multiplying by 0.001 you are dividing by .001 this is mostly the cause of your confusion. Also you have the ’2′ message triggering 1000 into the – object on the left but on the right it’s not connected. This will also mess you up.

#122462
Feb 14, 2008 at 9:59am

look carefully at your patch

1- your right-hand trigger is not plugged
2- your right-hand *~ is actually a /~…

pa

#122463
Feb 14, 2008 at 10:42am

Also note that your mother’s knee assumed you were working with infinite precision decimal numbers.

Your computer is working with finite precision binary. There are some surprises in there. Google the list on, say ‘floating-point precision’ for numerous discussions. Peter Elsea has a helpful tutorial for a more structured explanation.

Also, the fine-print of the documentation for /~ points out that the object internally multiplies by the inverse when the divisor is constant. Your mother probably didn’t tell you that floating point division is typically about 4-5 times more CPU load than mult.

– P.

#122464
Feb 14, 2008 at 3:44pm

Aside form the fact that I had not had enough coffee when I threw the
example together, I was right in principle….

And my mother did tell me about the efficiency of mult vs. div – thus
while I was trying to to use mult. Nice to know it’s built in…..

thanks,

M

On Feb 14, 2008, at 11:42, Peter Castine wrote:

>
> Also note that your mother’s knee assumed you were working with
> infinite precision decimal numbers.
>
> Your computer is working with finite precision binary. There are
> some surprises in there. Google the list on, say ‘floating-point
> precision’ for numerous discussions. Peter Elsea has a helpful
> tutorial for a more structured explanation.
>
> Also, the fine-print of the documentation for /~ points out that the
> object internally multiplies by the inverse when the divisor is
> constant. Your mother probably didn’t tell you that floating point
> division is typically about 4-5 times more CPU load than mult.
>
> — P.
>
>
> –
> —-
> Peter Castine
> Litter Power: < http://www.bek.no/~pcastine/Litter/>
> iCE Tools: <
http://www.dspaudio.com/software/ice/ice_overview.html>
>

#122465

You must be logged in to reply to this topic.