Description
Long-standing enhancement need: currently the actions attached to methods on the various data objects can only cope with one action per method in flight at any one time:
s.reboot
(
~ds = FluidDataSet(s);
~buf = Buffer.alloc(s,1);
~ds.addPoint(\1,~buf,{"Never called :-("});
~ds.addPoint(\2,~buf,{"I get called twice?".postln});
)In the above, the action for ~ds.addPoint(\2... will zap the previously stored one. This rears its head when folk are, e.g. calling kNearest or similar on a fitted model from different places (such as synths fire back to language OSCFuncs that then query the tree), or slower methods like fit are called quickly in succession.
I think the least awful fix is that, for the purposes OSC traffic, each message-response pair needs its own ID, supplemental to the ID of the object instance, and then an OSCFunc can be listening to just that particular message. This means changes to both the C++ and sclang code.
The conceptually simpler alternative of 'just' maintaining a queue of message handlers language side is (a) about as much work and (b) not robust to a packet getting dropped