Weird bug with cage.sdif.ptrack.toroll

[baskind]

Dear all,

As I am debugging a bigger project, I found a strange bug with cage.sdif.ptrack.toroll that I tried to isolate as well as possible. To summarize: for "some" sdif files, cage.sdif.ptrack.toroll outputs a void roll, unless "some other specific" sdif files are being sent to the object before, then cage.sdif.ptrack.toroll seems to work fine for every kind of sdif. It happened to me with several different sdif files, I was not able to find the logic of which information in the sdif creates the problem, and which information in the sdif solves it.

So: to reproduce it,
a/ open the patch below, and try to click on the first message box, which is a sdif-based llll.
=> I would expect cage.sdif.ptrack.toroll to output "roll [ [ 312.35829 [ 9617.30236 199.909299 1 ] ] ]"
=> but it outputs simply "roll []"

b/ then click on the second message box, which is another, slightly more complex sdif-based llll.
=> cage.sdif.ptrack.toroll outputs the correct information corresponding to the second sdif

c/ but then, click again on the first message box: cage.sdif.ptrack.toroll now provides the correct output

d/ another weird thing is that "unlocking" one instance of cage.sdif.ptrack.toroll by sending it the second sdif file allows ALL the instances of cage.sdif.ptrack.toroll to respond correctly to the first sdif file. I suspect the problem to come from the shared table in cage.sdif.ptrack.unpack since the table has a global name "table cage_sdif_ptrack_renumber_tbl", i.e. not specific to the instance with #0- for instance.

Best regards,

Alexis



<pre><code>
----------begin_max5_patcher----------
1142.3oc6XszbhiCD9L7qPwmIJ5okzbb2+Aas2xjJksQjnY.aW1x4wN07eea
IYXBARBahyV6g0T.1sZ0u0W2vOlOKqr4AaeF5KnKQyl8i4ylEIEHLa74YYaJ
dnZcQejsrplMar09rEo071G7Q5zsTV0T66c+kMPMWfIijKGJKWa6cKiKvGo1
V3qt0Uey0c1JexL3RXOHICKWfTlv8ZFlftZbG0Cab0qs9n0P2S3OkBvVyfeK
eaMB2xns1T9syohr.seNed3iEePumMsdOUqBe8Y597oz84Sk6SojX1Wq+r8e
1j5+Wf72ZQ2accKg6.eB45gaJ7nulMTuto56.sulgZpsHWcuuntxhZVgpJtw
h6W5Vga8cEUeG6a5ZVuFU9Hp2VuLJHeT181pl5kn0v0NY1CRLrVC7Q2N41+E
jCawKPUqcQ8BZMx1FaeOnOToccy8Hv1.967Csn1tl6fbSOpnFY2z5eDELBL5
2F76IDNpXkGzzSow90tC5npoKjMQPzucXWfZsqFL+gZ+ak9M4XBbQolzkBpE
DoyBDd3qvCudwval5yeOY9Z68vdOHw+B4us7kLD+is1j+kks.duy9OwHfRZv
TJWP3jzUNCfHXrP7f8hGNXGMdvNLdneOwiwZoCBHWhHAu3O+ieGwoLLWpYls
DtDdQvHFkjik4xbk.dDbGfQz4DLip3LUfiqFeMtOQPPTlgIOPRzbrJmJTxnj
nDhFtwHDFN8XBJmgYFBSpNlfBVSvNDJiQ+zce0QKiYuXN90yuFrLjCki4WMz
lKOUaazwTZnEv+jTJ8vTpYBKwKKptE214pAbnXw8tdcmp6ooQbbi50KXOcra
xVKnu3N6xqAZfAbcg224JG7o4YlsyKmkcmsq20TCBtz1EVTGJUhKFiQS1T.W
f.8ibqB8.5QAbgyKK5siv1gVBctatw1YWt.vZCsJrIn4Uttden6vhDfdD8Lz
fXuECRXDf8ryN60RCh73XDJUZVp3SLxGNxOoCMPu3jhTI2eu3BrbrMU1aNHg
HNGAmNUA.1mDVIf1rOhDWSwZoTI3QjMtVjiNmgMbhvHRfSvF.9nZrfwjvxA9
zbUNJ.6pHZ4QP.0LNGPLE4B8yUnhDTHWnRfxDkAcNEaTLCUsmBkXsfo.L6De
ACiBflJczVOPiBFESUZMcOMFkj.y0FodqFEw1.BsJ2rSiQKihA+yPxi.zg3h
fZf6oBigydtBMToFyEBVt4HJTCn+xXugPzD7hXf6Mf54uOndwXUG4vt2FVrv
TX9vP8x+KOMigeX2.dnd3owChbRmlg7+iy7u33LoeupJeZmeIW7YN.C8U5aX
RML.z2obhEo9SZhkncESjO6OwI5ZA56Gu5aF5p1lYSSJt.8KuC9UbdWcgGT8
S3Qm34nYjSUOvwx2VQxIQSmfhnjIPQPQ5ID6lBMIeeJJUbTz1NVME0RPGvwl
u0jJqVDezUmdLd.MqydmaK+wR7rhN3bhGJYG5h1U1CAmOt0lk1t5AWj24AuC
TY7HYcA.p1Vjbj3I24+b9eK5CRyE
-----------end_max5_patcher-----------
</code></pre>

[danieleghisi]

Thanks so much for spotting this bug and I'm sorry for the long delay in my answer.
A very sneaky one, indeed. I think I have an hotfix for it, you can find it here:

https://www.bachproject.net/download.ph ... 220121.zip

Can you tell me if by replacing the three abstraction in the zip file everything works properly?

Thanks,
Daniele

[baskind]

Hi Daniele,

Thanks for working on this. I can confirm on my side that it seems to work well now!

All the best,

Alexis

[agustinissidoro]

I am having the same issue with the .peaks and .chord abstractions. I have replaced the patches from the .zip and work just fine! Would it be possible to fix the bug for the other modules? Thank you very much for your time!

[danieleghisi]

Hello, as far as I can tell, the same issue does not affect .chordseq./.peaks.
So perhaps it's a DIFFERENT one? Can you please post a minimal snippet showing the unwanted behavior? I will look into it.