entrymatcher or descriptor pitch behaviour discrepancy
Closed this issue · 15 comments
this used to work in 32 bit and isn't in 64 bit.
- feed descriptor~ pitch value for no pitch (0.000000 something) in entrymatcher
- try to match with pitch == 0.
in 32 bit, it yield them
in 64 bit, it does not. I replaced with pitch < 0.001 but I presume it is either an output value change (0 vs 0.000000xxx) or a match tolerance. Either way, I'll replace in my patches but I'm surprised.
I've actually replaced them with pitch <-> 0.1 0. and it is more elegant. I don't know which is more CPU hungry
entry matcher doesn't know anything about pitches. I'm afraid there is simply not enough information here to reproduce the bug, as there seems to be an assumption about the configuration of the objects in question, so I don't really know where to go from here.
Can you clarify by:
1 - providing a small example patch?
2 - confirming whether you are using a universal build of the objects and comparing 64 and 32 bit behaviour, or comparing current behaviour to that of an older version of the object.
Thanks.
example patch attached. Tested on Max6 in 32 bit more and Max 7 in 64.
- press the button to fill the entrymatcher
- press the matching message
- observe the result
Max6 = 10 indicies are yield
Max7 = no indicies.
pa
----------begin_max5_patcher----------
986.3ocyX00bapCD8Y7uBM7raF8AHL2Y5C2eGctSFYrHUsXgGgHMtcZ+sekV
gcbSINDaYWONFBKK9r5vd1cgeLKIcY6SxtTz+f9DJI4GyRR.SdCICGmjtV7T
UinCbKcYu01pSmGNktesR2Hsv4HCF6raajfyG3Vau8k9sQXq9rR+v8FYkMDC
DN9N7bTNA1Qy1sE8eCWS3mwtciLbAoKE5GR2eZ0J.21ke4CTdp21OmMyuY9D
WdqkcchGjit9nCFqa01N02gHfPcg3yl0h0gU9+ZThlzymPJJtK2wGAZgTP.B
gdLBYbxHKBjgU9jMX2GmRSGZixh93GQtXBLcyvZb+uOJis.XsL1oxZzSg0tr
JDJjBPnkms.gTdJqNs7atK9ORI5+tBQvW2D.1QXobfk3KB4Au88efkl+7dk1
NNoUDQRain5qHo1Z1hTnZ+mQIv7+BJHJmbfDpjdhJHBOhzkEsz8o4nJqqZRF
EnEVFnEyvu+rrw4r7HxYUs8ZqzfHul57hkbk85DGih8c0XEfvz0h6MINubzy
WCeeU0YVDotlVwpvMpqY9F4XzFjnwfs7oltMJOwh43.9EZmqNlDlGnqd8Myb
.rLnO.EGZGfKO0xXzHlWsrutVZ9EpS0H0UR2gtHCecyxnGgyJCSMkWd3fFGk
ypcRE695ZiQfkwLe6CjE36PveXLGWx14QiRKgBdGV39udRHgAYerP2hbnlmu
kw6LGbQLoPgVzrsSdPN3MilkDjrT14IYi4fGvHZCOziKjPrqqX8HcRINwpqS
Z1hA1ZBsRaTc66kt6+g8iwhY6iQwixU26L4f9dg0ZTtGyI7lCR1SlIox0Kkv
UOrp8AswsncifbuTKVFVmX3bv8lXkPWWaAj5bE6yV338EyQqjcUF0FaqA5NY
dXquPKJG61PPqkqTBsukU0mcUR37cVbMv.+becaCFGsBC81oBSwyCRkQgc9h
NuSICKhRlC39ecyL.EgyA8AGJpTvmnXYzIBhY03ZUSiuYF41Yvogg.Bc+yN4
4lvGRSfGfD5EuwQH.71+ctqqs2Ts62OTSeN54PvkhYUZgU0pOvGRvmQu6LUb
xl.NzeOXZMqjFfTu7H6ch7mHiOKjYWItkRm.PYQ.HR4TVQEw.ohIfDOF.wuV
bW9T3NdrPhNEjnw.IxagTTXuroxdjyEoonZYiWnhd4QlPuD0HmFz3wg97JRR
tZEuvS.nxX.zDvYw38aHWbfeQYnQuIFFpPrYyiRS2vkCf5F85Ksf6EygCU5v
gvKFH0HeTsye3cflJLtofrtQf5MgoldhGd7mz0sNf08pgUsC4eN6+05g1VH
-----------end_max5_patcher-----------
OK - I will investigate the issue at some point.
In the meantime:
- the output for no pitch is not 0.0 from descriptors~ - it should be an inf.
- an == 0 should not match a non-zero value (which is what you have in both 32 and 64 bit).
Interesting. So descriptors~ spitting 0(32b) or almost (64b) and my assumption
your second conclusion is cryptic. == 0 in this patch does work in 32b, and has done so forever, hence my bug report. It probably is descriptors~ or loss of precision or whatever. Let me know if that is a behaviour that will change so I will update all my pieces.
Sorry - ignore both of my previous comments. I have misremembered the code and misread the patch - indeed you are getting zero for pitch (I was reading a different value). The code that is running is compiled from the same source, so it is unclear what is happening here. There will not be a change of behaviour but entrymatcher is broken in this regard for 64bit. Likely this is to do with behind the scenes details of storage of values.
Can I use it safely on a gig in 64bit? with my cheat (pitch <-> 0.1 0.) above it seems to behave...
I don't know - you can test and see if you are happy with the behaviour, but without knowing why the bug is happening I don't know what it affects.
OK - this isn't entrymatcher and the value coming out of descriptors~ isn't really zero - it's just small. As far as I can see this might be a numerical calculation difference rather strictly a bug.
When you create your silent buffer it is not silent - it has DC (frequency of 0Hz) and under 64 bit operation that calculates the pitch (or more technically f0) as a minuscule number in Hz (which in 32 bit gets quashed to zero because there aren't enough bits). Thus your == match stops working. If I force the values I store in entrymatcher for pitch to zero OR if I fill the buffer with real silence I get the right result in 64bit
ok so it means that descriptors~ used to send such a value as 0. (or it was truncated in the message to form the entry) hence the == working... and now it keeps its precision and it isn't
good to know. the DC was just a way to get 0, in my piece it is the very noisy stuff that yields that value of 0 in 32b and almost 0 in 64b - real signal, low periodicity.
Actually - I somehow mistested and it's always giving me a super small value rather than a zero for no pitch, but it's a descriptors~ issue - that much I know - more than that I can't really say at this time for definite.
good to know I was vaguely useful at something
The behaviour is changed in the latest version. Invalid pitches now output infs (not near zero). This is due for some revision, so I am open to suggestions, but this will be revised along with all the outputs for silent/non-valid frames which can currently take one of three values:
-180 (dB minimum), 0 (e.g. no change between two silent frames), inf (no value can be calculated - e.g, centroid pitch etc.).
There might be an option to alter how the infs report (NaN would be a more accurate answer anyway) but they have an important internal role, as they don't participate in stats calculations, so the change would need to happen at the final moment of output.
Thoughts welcome, but likely I'll close this soon. You can download to test if you wish but on the Mac side the current builds for the descriptors objects are called descriptorstest~ and descriptorsrttest~ which allows running alongside older versions.
I'd leave the value to the user and translate at the ouput. default would be inf and @whatever could be selected - arbitrary values are interesting when computing distances.
my 2 cents
OK - thanks. One issue is that some descriptors have valid uses offer or negative values so there is no obvious single choice that is always good and that varies between descriptors, but yes - most likely you can choose a specific value or atom to output for these cases. I will close this and leave that item on my to do list.