Re: [sc-dev] [commit] Still More OSCresponder issues

["Ronald J. Kuivila" <rkuivila@xxxxxxxxxxxx>]

Hi there,

Perhaps path responders should be removed as the default and be required
to reinsert themselves.  Then you would simply clear the entry (keeping
the list).

Pathresponders to SendTrig's usually persist but most others (responding
to a node terminating, for example), go away.

RJK

PS: The bug in Multiresponder is certainly my fault.

On Sun, 21 Nov 2004, Julian Rohrhuber wrote:

> /*
> Here is an error due to this problem. Try this with the old version
> of OSCMultiResponder-value:
>
> (
> s = Server.local;
> s.boot;
> )
>
> (
> SynthDef("help-SendTrig",{
> 	SendTrig.kr(Dust.kr(0.1), 0, 0.9);
> }).send(s);
>
> // register to receive this message
> a = OSCresponderNode(s.addr, '/tr', { arg time, responder, msg;
> 	[time, responder, msg].postln; responder.remove;
> }).add;
> b = OSCresponderNode(s.addr, '/tr', { arg time, responder, msg;
> 	[time, responder, msg].post; "this is another call".postln;
> responder.remove;
> }).add;
>
> )
>
>
> x = Synth.new("help-SendTrig");
> a.remove;
> b.remove;
> x.free;
>
> The first responder executes and removes itself. Since the Set 'all'
> is now one smaller, Set-do thinks it's reached the end of its array,
> and the second responder will not respond until the next trigger.
> This defeats the whole purpose of having OSCresponderNode, i.e.
> multiple responses to the same cmd.
>
> Since removing a responder when it responds is a pretty basic and
> obvious thing to do, I don't see any other way around this. You need
> to copy the Set. But if you have a better way...?
> */
>
> ok, I see. Well, we have to live with copying it I guess, it is not that slow.
> in the new version it will be a simple array that is copied, which is
> a bit faster then.
> --
>
>
>
>
>
>
>
>
> .
> _______________________________________________
> sc-dev mailing list
> sc-dev@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
>