Here's a simple solution which should give you an idea...

Another one, bit more easy to expand and configure

Hi,

this is just a variation on Lee's work using uzi.

I think it's nice to use zero as the output if there is no match.

Richard

i would use expr (as we know)

[zl compare] [zl compare] [zl compare] [zl compare] [expr ($i1=1) + ($i2=1)*2 + ($i3=1)*3 + ($i4=1)*4]

this, as well as the solutions by the others, wont work when more than one condition is true.

-110

Thanks all. I think the best solution for me is to use 4 [zl.compare] with [expr]. But it's all not so good... None of the algorythms is working with my setup, because of some bug, or i don't know. [zl.compare] somehow is not comparing complex lists even if they are equal. But with simple lists everything is ok. Here is example.

it looks like it's got something to do with rounding error in floating point representation in max. here's a version which 'works', if the magnitudes are rounded to the nearest 1/64 (-36db error)

Thanks, for help. I thought about that this problem is with lists in message boxes which are already rounded.

And if you're just interesting in finding the closest list, you can use zsa.dist:

Sorry, Emmanuel, but my max4live version is not supporting this library even in 32bit compatibility mode.

use this expression to truncate the rounding error to 6 decimal places vexpr int($f1 * 1000000.)/1000000.

this will give you a -140db error

Hi

@ivnos it should work both in 32 or 64 bits. At least that's what I'm seeing here using the latest versions of Max, Live and zsa.descriptors. Feel free to contact me if you're still experiencing some problems.

Floating Point, thanks again, but your previous variant were enough. =)

eltopo, sorry but i don't understand your patch.

Emmanuel, sorry, forgot to install it properly (forgot to copy it into packages).