### if to expr…wtf?

Can someone kindly tell me why the combined expression in the included patch is not a valid substitute for the split expression that utilizes [if]? Logically, how do they differ?

Specifically, why is the "else" element of [if $f1<0.5 then $f1 else out2 $f1] not equivalent to ($f1>=0.5) ?

I suspect the nan error is related to the sqrt but it doesn’t make sense why the same error doesn’t occur with the variation using [if].

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 711.3oc2V1saZCCEG+5vSgUzt.XgnXmDfLsMzdNZqpBIFvcINY1lV1p569rc 9fDJDXcP0X2D3Xe7w+8O6yw94dFlyy1f4lfOAtAXX7bOCCcSpFLJsMLSC2Dk Dx0tYlh47vkXSqh9xCEQqHzk2yvQhh3D.scr.HWnsuEvSa.mZ6.tqbHjXcfx l+vHe2p3rHiJngoXcWeiQBSp5IasHAKD+LGWDdSy5HQWmRnxN0JC0HRbxuzd CQxYu12hHocFpZ7kd8TerNwUdTVZJlJpzk.uQufMmMaV8pfsbtpMm5ocO7AF 3ZijnA4GnXiaAtbN.gfGmPsv.7OACNuALPwOIE1qn.dSNCz+CKfe1w1evP4m g8g1i3+fIT+5YOLO6IU+2dqEZvfAeT8+u9ksNq8bT+9H6gxdFLx0dvvsVPa4 Pje53bGzywdhjqvI9Jh5ilnN.dHv5M47czCdoO5ktNQP3IjXLqK.3FnA.BMU mz4o+A42..brPpaYrKFgi1u8CH3zsSEShGAlcOlFNOQu7bNHhrZhoLFQlxDJ HYzliJRBp3PQXS3sWh1FcUo3hUjnuSw7Vtlyv7p4pAT7mLt.Ji04YNke.2cw 1Fbgk42mksAWzUx1vk6XcYdcwF3eKNg++hytpLedJw5IuHWcztdSny6tjdcE Ui8nzqqay553afWKl4LsalEb8yLxBP4CA.hUXpx.fS3Xfb5PJqSAWPOMm7b6 DW9NuEbYcdPFpAxzgyLgP284z50np81bjmslEUInpGj.1tHiwbAgVWi4lsOX F.qcZEINF2pFTLgqJlEe3W2cp5QUo7n5YGQeI0yIwG0iVdmzit51QEj5562M AE7OlfTImGeKaGYe4UD7nJ586TzIkksKHOcAUTUJLO+QLiWFTsVj0weHioLG aoMIzBScAPSF9QRk+t5VBYxJ0BYY50rhRralN1rmZddo2uAIUjqj -----------end_max5_patcher-----------

The result of ($f1>=0.5) is 0 or 1. $f1 can be any value.

The result of ($f1>=0.5) is 0 or 1. $f1 can be any value.

That’s the whole point of using a relational function in the expression.

If ($f1=0.5) is true, then ($f1>=0.5) is false and vice versa.. so the expression reduces to one of two possibilities: [0*x + 1*y] or [1*x + 0*y]. Hence, it should output either x or y for any input [0..1].

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 510.3oc2UtsaiBCDF9Z3o.Y0KfTpEP.RS0tqz9bztpxAlz3VhMx1zxtU8ce8 AnIsa1lnd5hdQHYN3w+9KyXt22Csf2CRTvYAmG34cuumm0kwg2fsGZMoupgH sogV20nnxFZMHPwt3sDU0JJ6pKEPkxUqx43j3fxBbQbP5rbiQVJNI3WCKQBp 0TltvtzSLIrcbZscy3Kt9jhjM6ifrFTf3RfQVz.lTRFhw6TMfR86VvUQDJV+ 4w5wETfoHJJms8pp3LUMQQL9RG7w5zJSWK4yb51Aq2rAupUzpaXfiLoFeO36 adD+A.yrDGkdazLe1WWZtrgqq7dAYpqsb1LGU+ObpbrNK0mJllT1P+TPIMuJ BpEGQYv3BB6pMnbm7wrkR5erKMMCmrar8wQn4yO..U7UDPL3N8gaT+Jn2xED z2JBBCOZY52RvEQSxwSZ42Yru3h3oQQGa94O9tMVn9oMZXXFdh1ezIY3HadG mhi1e64zByWSOc9Kh+78i++cJ9cfpaOXZKGpgxd9qPrGNi+mhZIuSTMJlwor fMmuZPpnrGuW47MWYsURqn00vSt2olJMcWV3jry+zOX8TbH5I+ySO4GhdJ+z zi4cw6WOEuR83ZmHss2BB4PMsRQOidMWXLKislTlyz14hDvszw7mZ8PD5YKk dvpS3lK5OsD4a1mG7+qA9TQ0 -----------end_max5_patcher-----------

hold

The "else" statement of [if $f1==0.5 then $f1 else out2 $f1] is ($f1!=0.5).

If $f1 = 15 then ($f1==0.5) = 0 and ($f1!=0.5) = 1.

Look at it this way

`"Specifically, why is the "else" element of [if $f1<0.5 then $f1 else out2 $f1] not equivalent to ($f1>=0.5) ?"`

`"Specifically, why is the "else" element of[ if 15.<0.5 then 15. else out2 15.] not equivalent to (15.>=0.5) = 1?"`

I think you are right, the issue is the ‘nan’ mixed with floats.

<code>

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 1237.3oc6ZssjZiCD8Y3qvkq7.CC3xstXIu09x9cjrUJOfXvYACqsIgcSk+8 UWr4RlXilYsEPp7xLkExtac3bNpUa95vA9OsYunv2627du2fAec3fA5gTCLn 55A9qS1OaURgdZ9KVsIa2Z+IlOZwlrxhz+Un9H.EDVMrbFoYqDk5aApFbatn PjUlTltI6i4hYklvxQn.5DOBiq9Wn7Yn9i2eVcWa1UJePk+yVgY5pDHozehm +SIYO6eXdxPZlpNln5XlTNaYZ1yMFOpNfnSiX5b8BcySeZJJ9zEZVxZcR3+G 4oIq7ODhb43kh7OJxRdZkdFgpO5aCGp9yDKA1LwWjgr9oVJ1qyWew9s4duaA 7H7Vv7WfdMAXPy.FiqALbLWAUQ7VALdK.1a.Td6rsNm2vnD64ML2wat8fHjg ibAHhdaHsfwE+cd4HoB6gql.y.aXJSAXw3VgMb2JvVKJJRdV7BrQFdDCcvyY UZlX1lcYkmx.rAmPsa9CwFyX.Ym4+a.cADDvzwfZBkJHXnA3EbC7BA9cGHhw jpUXTE.18nHJx39cJHB7F.wvep3nHoVTAuXDs2fWfVGCs5ucRJD2s3aC1ioK T0c76gAdkKEYxkrmXUgv60QcuPweHVb.Rst48H1xvZ6UtFZALpM+UHxUb2Nz .fQ3ZTjPv8lMZTXULP7K6..j6OFZW.RTfYnywfMbM70Dkji0gBYfPMFXQ39a OHy1bGDxwsBtHm.tlZHClRBFucyWTkQ9gOLAc0JkTV4sBhPwDMDgZsVR.tC8 5hjULp8gXrdyqiHIwLq85BuCUwcAJgipj70lcspGicCWaptnPJm12UEFI2qU yCC6u8bogf8UExcme2noiFgBFqNy7TbvCiOdED7vCWa9Xs4Gi0FejcG58Qih qpyq+79vDi2GECG4bM48QcGm6cKPiGEFPGO5P+Zd70x1P8.aiv0GLFns1WTh KAJ3QIXcsvETXnt+nTcuHXs2sXWoAI.idryY+u2Rnapw3kxrlr1oX2pyzxLY QsGTZWMUVU8r0hLRqV5jt1Se2pxzhUoyE49utMulb5hclLYlmTlb5sXcK0ij EWor7iL5IfXDTzFpEk2Zqyq+BeY5r+JSTb9hHOsdGmSmagnTthkvhIcza4nY o263ImaAdhQ+BOaGOAvnPAhMvIbKCms4JdrviVK8UUQxU6n+xyeo+lHDLeG. sd1ehCOuvY6m7xlkb8Nxf50YbJlExaGybbi2oly5KuvbXe4hB0cm3eRyPF5x PVjYqXR6cXhZYyQz2rtvru6GihNCTieNLVrYW9r5UR8O7.ui4vbQQYZ1A6h2 e7mywISZY574hyrSlmVnbil27KZ157AaS9vcW9PsIev2X3CyY4ipcwWNejJO OvM4SjM4Sn6xGvh7Q8hIukvG0ABtovmHmwmILKxG04JcD9XU9ftsj6DGZ+Xi cn5sp5J5rM4i6RGaHOf617hXi1xcRKKUVtIahsj3DdCYK6NeGrU4C3r7wFgk 6JZ1FtCDdS45vcV1XE0wc6XYyFn.+FSXoNNpqbdnmSTaZKctiynKWjg6z6ee r9wYD1gkER38YBY5xQx1seVjWT8L04h+5jOsIWcYzD8koYlK0cuwOW74z54S 0ijjOaYZoXV4tbSGU1yi7Gphy2F9e3S7zC. -----------end_max5_patcher-----------

</code>

G

PS the difference, I guess, is that in one case the if is within the expression and thus the ‘nan’ is messing up the computation as it is always calculated (the sum of the two and in one there is ‘nan’).

in the other case the if is outside the computation and the program checks for what is true and based on that compute a value.

`"Specifically, why is the "else" element of[ if 15.<0.5 then 15. else out2 15.] not equivalent to (15.>=0.5) = 1?"`

`(15<0.5)`

is false. `(15>=0.5)`

is true. So the value of 15 gets passed out the second outlet instead of the first. Perfectly logical.

By the same token, `[(15<0.5)*x + (15>=0.5)*y]`

is equivalent to [0*x + 1*y] = y

Again, no logical inconsistency.

The if outputs 15. The expr outputs 1.

OK… answering my own question – at least in terms of getting the expression to work. I’m still not sure why the same expression doesn’t fail when split by the if object. Somehow, a negative value is generated within expr as it is evaluating the two conditions.

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 807.3oc4X1saZCCE.95vSQTzt.XgnXmXHYZaU64nspJj3VbWvgYaZYqp2tWf 8FtmjY67CAJDxXTFrgDVbbN19b974Gfm5XXMNaAlaY9NyKMMLdpiggdJ0DFE xFVSiVDmFw0pYEmMcJlJrryel.uPnm+me+GkycK6twp4bcbKlYVjHdBgd2ML brH+zPCQNPjsILLTplIPOBkKw75hEQRzab136G3Ws0YTAMZJV+jOwHQokOgN eJglhEZqDTScN4aZ0AvJyQpa1bQoxUFICykdVjfjQWwPAZC0yU4OlkClWqV0 yc5nFrOxvyyys8vC9pBu8fBSmmJH7TRBlYsceDLJvYjh6Hj1G8CzNIplSxwB ocK267UnuZ.aFBfkmDSh.AlcClFMNEWOBH2uDecFNeCsrrkuq1tLFoL9n9ph kbJIRDUmcaDnqRNXYPvDR7moX9JptkXQvnv5L4OJVjheTBlWDJhWLiY18M2B duqCpWe4P+t.mA7uvDciFyUe12o+rrGU5b0U1vdxWuUI7wOrbEUpOnaWnSe4 S6MvyoW+kR.G05jisIDHO.GEBbPaON2a2w4u7BtZi1+T.v9jBHuuitC+B5Si nMvCo+qRA7zXvWK.B1LLPGPZ.esow1JKdwEW7aUVDD5kWVDoiW7.MUVDAN0p KtGYjaJabyIiMlHtq7PeWcdHXjtrCBNpo7P+QmSIhsqWjWdcWHL3PzKJ3LoY zqFO8.EIpGDd5A+emmkInCAGBbB92EmMUh8vTqzW1QVEZWcIzXSHoVmQEK2I 8ZpsTSgug9qvL2flYV34OyH2ZVzQ2TLASUBl3TN1TdbPkTavEvWyIeuFwExc evk8gAYvZHSucVoD55+iCZeTM+pbjmMmEWZPEeCeyk9XBlKHzpRLWV8C8poy DRRBdkJPIDtpTVx1+RZs1Z.svb7NsLGcvvQxfxOKvtrHUEvipEsSFopubrrn 0NqsDDAOhFTvokAo90D69JK3zJMaMi9uNeT+a.0xDau8jWxNZ1rGvLdwdpME YSt6yXJwg1ZQBMWT2cvhgefTpumdlHlrMlP1CaNKu+yhfgVcTmyyc9Ui0cBN -----------end_max5_patcher-----------

as I said above I think the issue is an expression with a non number as one of the element to be calculated.

By adding the ‘abs’ you are getting rid of the ‘nan’ from the negative value inside of ‘sqrt’

that’s all…

see my example above and the expression adding nan to real, the result is surprise surprise nan.

G

PS to be sure it is clear:

<code>

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 437.3ocyT0saBBCF8Z3ofzrK1OLi.h.6t8brrXJRUqAKr1hiMiu6q8qvltEb DxhyaJoe8zdN8v4q6rsPoE0DAx4Ammbrr1YaYAkzErZlag1fqmmiE.Lzh7BV 0FjqYoEELof9NQujm+nwMkUHnrbhD1hWSwRNQPXRrjVvlwIykFZi88GE55LI JV+Yr5LzCNO2rqhJo5fjuURLv0B.KQtNnTLaI5SbJJMPAN8a4DKmuhxV1Ieg .g9GxHMCtnEoqu2O4vKJCuADA5QNEmi9jBtptjvmQX3zb.wX8R6ss0Ct8zXY jWUT1dpRRMnWDotj6b0Bu67Fhm+C2qKCyqaCKJFLrfjXsUMM9jFV7ILrAXJC Os8mmahBmz+bSz4K2b4YQ9lLxuXQgWFsVd2JdgKuV0gcy+VClw1BBizFVRvI ssf90fA6EkSYe+0cfec8i8KQQEed6cnsS14KIjQDRJCd69PPIGAZEMKi.q25 YYTg9GWV2+45sdB5idhOe5IrO5I3ByehFndLwIbY4VBWzblfTTMZqK35oScg oTlYJj2QbxVZK9PnBlqh+RU1uhaht0wSUAWEO6s+.bNa9WH -----------end_max5_patcher-----------

</code>

The if outputs 15. The expr outputs 1.

No… using your example, the expr outputs 1 * 15.

Follow me here… `[if $f1<0.5 then $f1 else out2 $f1]`

( with out1 feeding to x and out2 to feeding to y) you can use `[expr ($f1<0.5)*$f1*x + ($f1>=0.5)*$f1*y]`

. iow, the if object outputs the input to one of two outputs, which is then processed by an expression. The expr object multiplies 1 or 0 by the input ** an expression*. It’s the same logic in a single object.

By adding the ‘abs’ you are getting rid of the ‘nan’ from the negative value inside of ‘sqrt’ that’s all…

Well, yeah.. that’s why I used it. I admit it came in a "duh" moment.

But my original confusion still hasn’t been addressed… Why does the same sqrt expression fail when the logic is evaluated internally by the expression object yet work when the logical is handled by the if object?

because inside the expr object there is no type check?

just had a quick look, can it be that you need to put another bracket around everything behind the boolean?

[expr ($f1>0.5)*((0.5)*…) + … ]

Nope.. that was the first thing I checked. But I agree the 0.5 does look kinda naked.

There is something internal happening in [expr].. somehow signed values are being created in the process of evaluating the logic.. even if for only a flash moment.. and then whammo… NAN.

because inside the expr object there is no type check?

I thought that was defined by the operators… > is boolean… sqrt is not, etc.

as you can see i deleted my first response before you copied it.

now lets see if my second version is better. :)

"Why does the same sqrt expression fail when the logic is evaluated internally by the expression object yet work when the logical is handled by the if object?"

Because in the combined expr equation one side is always nan. The if removes the nan.

<code>

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 720.3oc6W10aaCBEF9ZmeEVncQbVhkA+Yl1M62Q6TEIlzPmCNCSZyVU+uO9v NeTkZSqxrV6xMXA9.7xiO7djebfCXV4VREv8KtW45373.GG8PpAbp66.Vg2N u.WoCCrnnjsYEXr4Uqwh4KoraugSlKLKCJJ0GEO1MNJyOP9HP0hjsteudRzb 8JUN6tIvv8qDGuhHH7aHL7rBhJjf52snjIXx2pm123TbQyrjRgxJHBs1f0CV tQHGR7q0DihTZFK.icAyvraA6zgbxlP0yFcvlUQ+sdtPjefZzmFLP0L1RFwH OHObMZTP1pQCXjKz2FvE.UHKD4G2B3ffWGbPsCmW.JvyGT5LwAFC0m+HTb2I NweDya5DQgoo0HJpaDk7QDQq1THnUEzbBuQnUDgToxnLRRyD3AHQrjN+GLR0 QGjSk+EknwYJRuBF6KUt3ofapMvct77liE3iHHmRXBrfVxNLT6nsBzuHjOeF Ujsq4RNFOZX0O4hgSFND4O5SKfdSB88FsuGz2y6yxlVyX0eOByBMzD1VFaF3 LkU1C1YchNn+DM8jOi7Gst7ggRlc80iQddsAr5rvFfEj0Fvl9NBXc6+We+CZ g2Vz+o1+HCgB6lPnKt+uR2+.+TYo0DnEt+gvK1+1Y+mDooJrNysc+eI0uTAX WlXCyZuD.LZ56elQW3JQyWkTyUrjvTcbIEUDWoJPpd1fqPCmhBaEWwAmMb01 swtQldlfBJ64++s9LpF+XNVUtgOuYuaLgb2eHyIUBJamyxUGbdOHpkz7bxQV O4zJkwkFQm9SpsBxrWvtTj5RdupnNYj5JTeonmsWmVQQ8ndxrPOndSO1nljd SM17sJt2TSpEpY5+Tpo+tomXy8b3Q1S+MkSrsxomtkaUohv2ndLUxvqWeOgW UulZoHq8eWIW0MYrtKkY5pqoB3j6oMwaB.ykU2ExR6a3lxxayR.CT6ySC9SG dhCg -----------end_max5_patcher-----------

</code>

Rick, you’re right! I don’t know how I missed that. For some reason I was thinking that a false evaluation would equal 0… while somehow overlooking 0 * x. In most cases, multiplying by zero generates a zero.. which is enough to get the job done. But this time, I was one who was goosed. Thanks for the exchange.

0*NaN => NaN. Always.

The other thing that trips people up is evaluating (x == x) when x=NaN.

0*NaN => NaN. Always.

It’s as though 0 and 1 are the Trumps in the deck of numbers… but NaN is the Joker.

Don’t forget to watch out for infinity.

What do you expect to get from `0*Inf`

?

What do you expect to get from 0*Inf?

Well it looks like NaN reigns supreme.. but maybe there is a way to cheat? :)

**all**of the following text. Then, in Max, select

*New From Clipboard*.

----------begin_max5_patcher---------- 716.3ocyWssaZCCF95jmBKqcwZEEEGmDH8t8brVMY.C0cA6HGSKsU8ce9PxV ZGDBUVgf.r7gX+8+ku+C9sv.3BwdZEDbK3mfff2BCBrCYFHnte.bKY+xBRkc YPN8YwhGgSbSon6U1gKkLtBH1oZlguaqtWAUYern5QWK3pJ1qTyXn3oMCWRT Kefw27KIcoxgl34Y5oAInYllTam3noQf6qeF1J6AqAyMHLr09yIas6O7GRFo nEdX7F3fLi8dXn4uI9vvuNxW1MJOpscm1ocGe4r6WK.ajhck.7gs73y1xmal EfmkXZlg6zvQmog2fFG.UuTRcmIDNQ+Cbuu0C2dkuzCNVoQNf5hUxubpg0Rw 1pW1tPTbX6Fc99ANoOFO+zxgry0vOpZvmJAEHZp2XCz7oo+kMvcJCR8EartP PTiVJoNbQeXjjwKivTToeYj3jYt3ncwH3QoGSEs.v3qAbB+vbB9qpRhrpj73 t3jyMYJ9XbxBBeiIuRSqecgD9MNasnYVOByhFkhlmn6KkfusFcsGC25JBCka yAMOpSWo3QIs3y.K0zgqhbW.2ixFW3HKaoUUjMz+iNtAMMUm7Ana7Lqjla8b rtQ5rzGlUR7V8p9TiX8bJEO+cs2yc2ogej9yzq7sWDxpXP3NCtfSGktQkjea jM1u9lWRw8H5xLekU5izh8rfEL9mu8uEulw+HWUI1IW1rUM.C7OHuhVoXbhh I3sVj4h4sVzCrUqn712CZEqhrnfZs2nC9Vq23ItO3Idvvi4JpmDO4CFbLFd7 IPS1fhFzIPS5fglz9nbPCJ4bJ3jLXnIYbQNYiK3zGm7gKlCtOjy3Jh7.lfnO IrvC3Kq9D1wBZzHCOCD+zmHO3AT+zGuKb5HT+D+Eviq9PRY4STYU8dZghtp4 GERS2rI1tLtqqsNXnj9DqY81RQgDot9Wkt32cRWsq6mmACMmy6g+ADYRBXF -----------end_max5_patcher-----------

Yes, in fact you really *need* to do something like this if your calculations can produce an Inf or NaN and you don’t want your patch to trip up because of it.

There is a convenience object for this in the MSP domain: [bitsafe~] ("Replace NaN and infinite signal values with 0").

My favorite way to filter out NaN in Max (not MSP) is [if $f1==$f1 then $f1 else 0.]. The IEEE spec for floating point explicitly states that the expression (NaN == NaN) must evaluate to false (which makes sense, if you think about it).

Ahh, that’s very helpful. Thank you.

Of course, now I’m confused by all this inf business.. and `[if $f1==$f1 then $f1 else 0.]`

doesn’t address the problem of inf.

Even if something like `if ($f1==$f1&&$f1<=2147483647) then $f1 else 0]`

was adequate to filter inf output, I still don’t understand why the max window will handle up to 2^1023 and flonum will handle up to 2^127.. and I would’t want to filter those larger values unnecessarily. Yet Max is only 32-bit and I always seem limited to 6 decimal places of precision. Seems inconsistent.

Anyway, I don’t mean to take advantage of your time. It’s too bad I can’t buy a round of beers to motivate you to stick around. :)

No, my little code example only addresses NaN. In C one could write an ISINF macro as follows:

`#define ISNAN(x) ((x) != (x))`

#define ISINF(x) (!ISNAN(x) && ISNAN(x-x))

Except nowadays I’d write them as inline functions (to avoid the standard unwanted macro side effects). And except if I were writing in a compiled code environment it would arguably be better to use compiler-supplied test functions. But hopefully you get the idea.

Yet Max is only 32-bit and I always seem limited to 6 decimal places of precision.

Max 6.1 is only 32-bit if you tell it to be so. It is 64-bit if you allow it to be so.

The "six decimal places of precision" is, largely, a display issue only. When posting to the Max window, [print] seems to call the standard C function sprintf() with a default "%f" parameter, which rounds the output to six decimal digits. Some other objects display other degrees of precision (capture~, for instance, normally displays three digits after the decimal point, and so on). But floats are always passed between objects with full 32-bit precision (and most objects use 64-bit precision internally).

The 2,147,483,647 you cite is the highest value for a 32-bit signed *integer*. Floats and integers are different animals and have different min/max values (comparing a float to the maximum integer value is of somewhat limited value, btw). 2^127 is the largest exponent a 32-bit float can have (the largest possible value is greater than that, since the mantissa can be as large as just-less-than-two). 2^1023 is the highest exponent for 64-bit floats.

You might want to spend some quality time with http://en.wikipedia.org/wiki/IEEE_floating_point if you want this to all really make sense.

Finally, one reason the sprintf() function has a default precision of six significant decimal places for floats is because the most common size for floats when the C Standard Libraries were first being developed was 32 bits, and 32-bit floats have 24-bit mantissas, which gives approximately six decimal places of precision. Not much point in the default display precision being higher than that.

Enlightening. It’s still a bit ambiguous to me if the "full 32-bit precision" that is passed between objects entails 24-bit mantissas/6 decimal places – which would mean that 6 decimal places is more than just a display issue. I’ll check out the IEEE info and see if I can’t clear that up myself… :) Thanks for all the insight.

Forums > MaxMSP