`reset` doesn't work for shared objects

[weefuzzy]

The reset message is broken for shared objects (fluid.dataset~ and friends). The intended behaviour is that an object will revert to the state of its defaults, modulo what values were set in the box at instantiation time.

Patch to reproduce

----------begin_max5_patcher----------
652.3ocyWt0jZBCE.9Y3WQFdl5PB26S6+iN6rSDitYKDrIAqs6r82dyEQocY
oHnVeAMGOgy46bKwWcc7VVumH7.eF7EfiyqtNNFQZANGV63Ug2WThEF07Jpq
pHLomu82jj8RibFdEtUHqohxJIRyNfmDV2HakFbPJckY20Ke4Svr18uEKKdl
x17DmTHsNGJIcQfO.kko+.FGXVodBdTum2bc0O7mIDU3uR.XPwyX1FxLoIcD
zDkeMoQ9LU.3DYCmI.xZ.kQkfc3xFh.fE.x9sJGhrBztwRJiTT2vL6F058bh
P8xwRZM6od0Xhwm3AhOvbSDAFD2I9DFdGmsiFhlTj1+SCtDI6JhPfO4tGgQm
lj8BApWHf8.Apc+V8j+XKwRfmG3wA3Cla6MSLoISNCgtv7sTaWA8mDUnyGTR
vbFGKIffEvYRMbhTGDrH11CGeJsNUrYjuqbl2Q85xF5pEUkptvMpLrnl+KvC
cgOD7voHSbvfsxinzN78wmzOL7rT0234qcxZrT+kwTkDlYKVfn1hk6s1fjIV
ODl0Yl0LKG9H7T7rlS9FHJXdLFMMFygmFjkDe8J3W1rtZcQgpVuEXz0nzFdo
JsismSklXq.BlUoMVJ4Mzy37ndxuiYRt1NcKp792.FE18HLz+Q.yNG.ONgbH
DCsCjPY2KHleNHd7LgQfXb9PHZd2ltr+5+EXdiZ4+I2h5FdQqm0dMBPvQWbE
QHoLy8G6nTpUmdCsi1PvajgxuQ1I6FYmjQXG3EvNQ2H6fljcrE53sa2Q3hCJ
aLgpU9kZSaUluYIkYWZZRUWwXGsUenUDlq50jpFsFtwu71mXOg0qpdEgyTiB
zJ6poSYSybBFVcH+VrEDy3D22b+MP8Un7C
-----------end_max5_patcher-----------

I think this is because I didn't consider that for shared objects we are now dealing with reference semantics for the params, and so the the snapshot we take at instantiation time is effectively a pointer 🤦 Rather than start with making arcane assignment operators for the shared params, I think the neatest solution here is to change the overall behaviour to take advantage of the from/toTuple methods recently introduced, and keep the snapshots as tuples. This means that we can rely on parameter updates propagating properly when reset is called.

There is, of course, the potential for confusion here when multiple boxes pointing to the same name init with different params. However, I think the simple approach is the one to follow here, which is that the late bird gets the worm. i.e. each box still stores its own values, and the last one wins.

[tremblap]

is this still true and isnt't it a max/pd (so core) issue?

[weefuzzy]

This is still true, and it's a Max issue, but the same would hold in the PD wrapper too.

[weefuzzy]

Hmm. Actually easier to make it restore according to the box one clicks reset on. I'm ambivalent about which is more or less confusing (because all reference semantics are going to be confusing).

[tremblap]

I don't understand your last comment, but reseting to the state of the box is useful - a sort of powerclear instead of delete-undo sequence ;)

[weefuzzy]

So, above I wrote

There is, of course, the potential for confusion here when multiple boxes pointing to the same name init with different params. However, I think the simple approach is the one to follow here, which is that the late bird gets the worm. i.e. each box still stores its own values, and the last one wins.

The issue being what 'counts' as the original set of params when multiple boxes are sharing the same set of params: if we have N boxes do we have

1. N sets of 'original' params (one for each box)
2. One set of 'original' params, that are also (somehow) shared, and for which some convention of precedence would need to be established.

In the quote above, I was thinking in terms of (2), and suggesting that the shared 'original' params would simply be whatever the last-created-box was initialised with. However, what we've ended up with is (1), so the side effects of reset depend on the box you send the message to. Both options are potentially confusing, IMO.

[tremblap]

ah yes I understand and I agree. we could

• write a warning for reset in the max window in the effect that it doesn't work for named objects when someone uses it
• just remove the handle so it is not available and see if anyone ever notices.

the only use case I can think of is mlp - when one noodles the many parameters, one is responsible to know what state the object is in at that moment. 'reset' will not help though as you say, as soon as we have 2 named instances...

so for now I'd vote for removing the message altogether for lib_manip

[weefuzzy]

But wait – it works now , so I'm not sure I'd agree with removing it altogether. We just need to make sure the documentation is explicit. The way it is now (at HEAD) is actually better than the original plan, I think:

[tremblap]

wow! I need to test it - it means that the shared state of the object is whatever version get the 'reset' but I need to check with all the other params (network structure etc) which can be, as you so eloquently say, confusing to the user.

==
actually after giving it a swirl it doesn't work all the time. I'll ping you to show what is probably a user error.

[tremblap]

after this discussion, let's close this issue and make a new one for the documentation of reset's relation to stateful named objects