You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:In the above, the
action
for~ds.addPoint(\2...
will zap the previously stored one. This rears its head when folk are, e.g. callingkNearest
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 likefit
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
The text was updated successfully, but these errors were encountered: